Plan śledzenia zdarzeń dla startupów

Czym jest plan śledzenia

Plan śledzenia to jeden dokument, który wymienia każde zdarzenie zapisywane przez produkt, właściwości dołączone do każdego z nich, dokładny moment, w którym jest wysyłane, i osobę, która za nie odpowiada. To umowa między kodem, który wysyła dane, a panelami, które je czytają. Traktuj go jak żywą specyfikację, która zmienia się razem z produktem, a nie dokument, który piszesz raz i o nim zapominasz. Definicję w jednym zdaniu znajdziesz w haśle plan śledzenia; ten poradnik pokazuje, jak go zbudować.

Dlaczego plan wygrywa ze śledzeniem ad hoc

Bez planu śledzenie narasta warstwami. Jeden inżynier wysyła signup, drugi Sign Up, trzeci user_registered – trzy nazwy jednej akcji, a każdy lejek, który dotyka rejestracji, po cichu się rozdziela albo psuje. To rozjazd i główny powód, dla którego ludzie przestają ufać analityce. Plan ustala słownictwo, zanim kod trafi na produkcję, więc liczby, które pobierzesz za pół roku, nadal znaczą to, co myślisz. Czyste, spójne zdarzenia to też paliwo dla mapy drogowej eksperymentów – nie zmierzysz testu metryką, którą zapisujesz na trzy różne sposoby.

Nazywaj zdarzenia według wzorca object_action i trzymaj się go

Konwencja, którą poleca większość narzędzi analitycznych, to object_action: najpierw obiekt, potem to, co się z nim stało – subscription_started, invite_sent, checkout_completed. Segment, Amplitude i PostHog opisują własne warianty (Segment używa „Object Action”, PostHog – małych liter w snake_case, Amplitude – rzeczownika z czasownikiem w czasie przeszłym). Dokładna wielkość liter ma dużo mniejsze znaczenie niż wybranie jednej konwencji i niełamanie jej. Większość wartości dają dwie zasady: zachowuj spójny czas czasownika i nigdy nie buduj nazw zdarzeń dynamicznie – zdarzenie nazwane plan_${name}_upgraded tworzy osobne zdarzenie dla każdego klienta i nie da się go odpytywać.

8–10 zdarzeń, które opisują Twój lejek

Nie śledź wszystkiego. Zacznij od garstki zdarzeń, które prowadzą użytkownika od pierwszego kontaktu do płacenia – rejestracja, aktywacja i przychód – i dobrze je wdróż, zanim zaczniesz śledzić więcej szczegółów. Poniżej zestaw startowy dla typowego B2B SaaS; zmień nazwy na rzeczowniki ze swojego produktu. Każde zdarzenie staje się wierszem w planie, a razem tworzą Twój pierwszy zbiór danych first-party – surowiec dla każdego lejka, kohorty i krzywej retencji, które zbudujesz. To, gdzie wdrażasz każde zdarzenie – w przeglądarce czy na serwerze – to osobna decyzja: podział opisuje poradnik śledzenie po stronie serwera a po stronie klienta.

Szczegóły niosą właściwości, porządek – właściciele

Zdarzeń ma być mało i mają być ogólne; szczegóły przenoś do właściwości. Zamiast osobnego zdarzenia dla każdego planu wysyłaj subscription_started z właściwościami plan_name i amount_usd – jedno, dobrze opisane zdarzenie da się dalej odpytywać. Zestaw właściwości każdego zdarzenia trzymaj w ryzach – kilka, które naprawdę odpytujesz, jest lepsze niż dziesiątki nieużywanych. Potem ustal właściciela: w większości małych zespołów to Growth Engineer albo ktokolwiek wdraża opomiarowanie, a każde nowe zdarzenie powinno przechodzić przez tę osobę, żeby plan i kod nigdy się nie rozjechały. Na koniec miej jasność, gdzie trafiają zdarzenia. Wysyłanie ich do hostowanego narzędzia analitycznego lub CDP jest szybkie, ale umieszcza Twoje dane behawioralne na cudzych serwerach; trzymanie ich jako first-party – w Postgresie hostowanym samodzielnie, we własnej hurtowni danych – zostawia je u Ciebie i to jest sedno wyboru między open source a SaaS w narzędziach do komunikacji z klientami.