Plan śledzenia (tracking plan)

Co zawiera plan śledzenia?

Co najmniej jeden wiersz na zdarzenie: nazwę zdarzenia, dołączone do niego właściwości, dokładny moment, w którym się uruchamia, i osobę, która za nie odpowiada. Dobre plany zapisują też, które narzędzia otrzymują zdarzenie i na jakie pytanie ma ono odpowiadać – zdarzenie, którego nikt nie odpytuje, to utrzymanie bez zysku. Format jest mniej ważny niż nawyk: arkusz kalkulacyjny, wersjonowany plik w repozytorium czy narzędzie do schematów, takie jak Segment Protocols albo Amplitude Data – wszystko działa, o ile plan jest aktualizowany w tym samym pull requeście co kod śledzący.

Jak nazywać zdarzenia?

Wybierz jedną konwencję i egzekwuj ją wszędzie. Najczęstsza to obiekt_akcja w snake_case: subscription_started, invoice_paid, report_exported. Najpierw obiekt, żeby powiązane zdarzenia sortowały się razem; akcja w czasie przeszłym, bo zdarzenie zapisuje coś, co się wydarzyło. To, którą konwencję wybierzesz, jest mniej ważne niż jej jednolitość – Sign Up, signup i user_signed_up w jednym zbiorze danych to trzy zdarzenia, które Twoje narzędzie analityczne traktuje jak obce sobie, a każdy wykres na nich oparty jest błędny.

Czym jest rozjazd śledzenia i dlaczego zabija analitykę?

Rozjazd (drift) to luka, która otwiera się między planem a tym, co kod faktycznie wysyła: zdarzenie dostaje nową nazwę bez aktualizacji planu, właściwość zmienia typ, pojawia się duplikat pod drugą nazwą. Każda zmiana jest drobna; razem sprawiają, że lejki zaniżają liczby, segmenty dynamiczne przestają obejmować użytkowników, których powinny, a panele dryfują w stronę fikcji – i wtedy zespół całkowicie przestaje ufać danym. Lekarstwo jest proceduralne, a nie techniczne: żadne zdarzenie nie trafia na produkcję bez wpisu w planie, a przegląd tego wpisu jest częścią code review.

Dlaczego to ważne dla dwuosobowego zespołu

Małe zespoły pomijają plan, bo wydaje się procedurą dla firmy, którą jeszcze nie są. Logika działa odwrotnie: przy dwóch osobach w październiku nikt nie pamięta, dlaczego istnieją jednocześnie checkout_completed i order_completed. Jednostronicowy plan napisany przed pierwszym zdarzeniem kosztuje jedno popołudnie – to pierwsze zadanie, jakie wykonuje Growth Engineer. O tym, jak plan wpisuje się w kompletną konfigurację, od SDK po zgody, przeczytasz w poradniku dane first-party i śledzenie.