Jak przygotować tracking plan dla aplikacji e-commerce?
Praktyczny model zdarzeń od wejścia do zakupu: nazwy, parametry, odpowiedzialność, server-side purchase i walidacja przed premierą.
Tracking plan aplikacji e-commerce to uzgodniony kontrakt opisujący zdarzenia, moment ich wywołania, wymagane parametry, pytanie biznesowe i właściciela walidacji. Powstaje przed implementacją SDK. Zakup powinien być potwierdzany przez backend, a nie wyłącznie przez ekran sukcesu w aplikacji.
Najpierw pytania biznesowe, potem nazwy zdarzeń
Lista eventów bez decyzji, do której mają prowadzić, szybko zamienia się w telemetryczny śmietnik. Zacznijcie od pytań: gdzie odpada klient, które wyszukiwania nie zwracają produktów, jaki kanał przyciąga kupujących, która metoda płatności zawodzi i czy użytkownik wraca po pierwszym zamówieniu.
Dopiero potem mapujemy ścieżkę na zdarzenia. Nazwy powinny opisywać zakończone zachowanie, na przykład view_item, add_to_cart i begin_checkout. Parametry przenoszą kontekst: produkt, kategoria, cena, waluta, koszyk, kampania i wersja aplikacji.
Minimalny słownik zdarzeń dla pierwszej wersji
Pierwsza wersja nie potrzebuje stu eventów. Potrzebuje kompletnej ścieżki zakupowej i kilku sygnałów diagnostycznych. Każde zdarzenie ma jeden opis triggera oraz wymagane parametry.
- app_open i view_item — wejście oraz zainteresowanie produktem.
- search i search_no_results — popyt oraz braki katalogu.
- add_to_cart, view_cart i begin_checkout — intencja zakupowa.
- add_shipping_info i add_payment_info — tarcie w dostawie oraz płatnościach.
- purchase, payment_failed i refund — wynik finansowy potwierdzony przez system.
- push_open i loyalty_redeem — powrót klienta i użycie programu lojalnościowego.
Zakup i zwrot muszą pochodzić z backendu
Ekran podziękowania nie jest źródłem prawdy: aplikacja może zostać zamknięta, odpowiedź operatora płatności może przyjść później, a klient może wrócić deep linkiem. purchase wysyłamy po potwierdzeniu płatności i zapisaniu zamówienia, z unikalnym transaction_id. Ten sam identyfikator zabezpiecza przed podwójnym raportowaniem.
Walidacja przed premierą
QA przechodzi cały lejek na iOS i Androidzie, porównuje parametry z kontraktem i sprawdza sytuacje błędne: brak sieci, ponowienie płatności, powrót z operatora, kupon, pusty wynik wyszukiwania oraz zwrot. Raport sprzedaży porównujemy z backendem na kontrolnej próbce zamówień.
- Zatwierdź słownik i właścicieli.
- Zaimplementuj eventy w jednej warstwie aplikacji.
- Potwierdź purchase i refund po stronie serwera.
- Sprawdź parametry w trybie debug.
- Porównaj raport z zamówieniami backendu.
- Zamroź wersję kontraktu na premierę.
Właściciel, wersja i proces zmiany
Tracking plan nie kończy się wraz z premierą. Każde nowe pole checkoutu, metoda dostawy, program lojalnościowy lub eksperyment może zmienić kontrakt danych. Dlatego dokument powinien mieć wersję, datę, właściciela biznesowego oraz właściciela technicznego. Zmiana nazwy istniejącego eventu wymaga planu migracji, bo inaczej historyczne raporty przestają być porównywalne.
Najprostszy proces działa jak code review: właściciel funkcji opisuje pytanie i oczekiwany event, analityka sprawdza spójność słownika, engineering ocenia źródło oraz parametry, a QA dopisuje przypadki testowe. Dopiero zatwierdzona wersja trafia do aplikacji i dashboardu.
Źródła i gotowy punkt startowy
GA4 ecommerce events: https://developers.google.com/analytics/devguides/collection/ga4/ecommerce
Firebase Analytics: https://firebase.google.com/docs/analytics
Przykładowy tracking plan CSV: https://gmi.software/resources/mobile-commerce-tracking-plan.csv
Najczęstsze pytania
- Ile zdarzeń powinien mieć tracking plan?
- Tyle, ile jest potrzebnych do odtworzenia kluczowego lejka i decyzji. Dla pierwszej wersji commerce często wystarcza 12–25 dobrze opisanych zdarzeń zamiast setek eventów bez właściciela.
- Czy GA4 automatycznie mierzy zakupy w aplikacji?
- Nie. Zdarzenia e-commerce i wymagane parametry trzeba zaimplementować, a purchase najlepiej potwierdzić po stronie backendu.
- Kto powinien być właścicielem tracking planu?
- Właściciel biznesowy odpowiada za pytania i decyzje, a właściciel techniczny za kontrakt, implementację oraz jakość. Pozostawienie dokumentu wyłącznie developerom lub marketingowi zwykle tworzy luki.
Treść zaktualizowano: 26 sierpnia 2026
Google Preferred Sources
Czytaj GMI częściej w Google
Dodaj gmi.software do preferowanych źródeł. Google może częściej wyróżniać nasze nowe materiały w Top Stories i obsługiwanych widokach AI.