Rejestrowanie akcji w kontekście

Najważniejsza decyzja w instrumentacji dotyczy nazewnictwa zdarzeń i tego, gdzie zapisujesz kontekst. Jeśli zrobisz to dobrze, jedno zdarzenie odpowie na kilkanaście pytań. Jeśli źle — katalog rozrośnie się do setek niemal duplikujących się nazw, których nie da się sensownie zestawić w lejku. Ten przewodnik opisuje standardowy wzorzec Kixo — ten sam, który poleca doradca AI do instrumentacji (suggest_instrumentation na czacie).

Wzorzec: jedno uogólnione zdarzenie + bogate właściwości

Rejestruj jedno zdarzenie na jedną akcję użytkownika, a kontekst opisuj przez właściwości — nigdy nie twórz osobnej nazwy zdarzenia dla każdego kontekstu. Otwarcie posta z wyszukiwania i z feedu to ta sama akcja (post_opened), tylko z inną właściwością source.

Antywzorzec

Nie twórz post_opened_from_search, post_opened_from_feed ani post_opened_from_profile, żeby opisać nie. Trzy nazwy zdarzeń to trzy byty do utrzymania, żaden pojedynczy lejek nie obejmie ich wszystkich, a dodanie czwartej powierzchni oznacza zmiany w kodzie wszędzie. Jedno post_opened z source skaluje się bez wysiłku na dowolną liczbę powierzchni.

Nie rób tak (osobne zdarzenie dla każdego kontekstu)	Tak (jedno zdarzenie + właściwość)
`post_opened_from_search` `post_opened_from_feed`	`post_opened` z `{ source: "search" \| "feed" }`
`video_played_mobile` `video_played_web`	`video_played` — platforma i tak jest automatycznie dodawana do każdego zdarzenia
`checkout_from_cart` `checkout_from_buy_now`	`cart_checked_out` z `{ source: "cart" \| "buy_now" }`

Nazewnictwo: snake_case, obiekt + czasownik, czas przeszły

Każde zdarzenie nazywaj w (object)_(verb): używaj snake_case i czasu przeszłego — post_opened, video_played, cart_checked_out. Ta sama nazwa musi być użyta dosłownie w Web, iOS i Androidzie, żeby lejki międzyplatformowe się zgadzały i żeby detektor zdarzeń standardowych Kixo mógł dopasować nazwy kanoniczne.

Najpierw obiekt, potem czasownik — grupuje powiązane zdarzenia podczas przeglądania katalogu (post_opened, post_liked, post_shared).
Czas przeszły — zdarzenie zapisuje coś, co wydarzyło się.
snake_case — nie postOpened ani PostOpened. Detektor i dopasowywanie słownictwa nie rozróżniają wielkości liter, ale trzymanie się jednej formy utrzymuje porządek w lejkach.

Właściwości zdarzeń a właściwości użytkowników

Drugą częścią tej decyzji jest to, gdzie trafi dana wartość.

	Właściwość zdarzenia	Właściwość użytkownika
Opisuje	To pojedyncze wystąpienie akcji	Ta osoba — trwale we wszystkich swoich zdarzeniach
Ustawiane przez	`Kixo.track(name, { ... })`	`Kixo.setUserProperty(key, value)`
Przykłady	`source`, `screen`, `post_id`, `amount_cents`	`plan`, `vip`, `signup_cohort`, `lifetime_orders`
Obsługuje	Filtry na poszczególnych krokach lejka, podziały, rozkłady	Segmentacja, targetowanie odbiorców, kwalifikacja do kampanii

Wskazówka

Praktyczna zasada: jeśli wartość może się różnić między dwoma zdarzeniami tego samego użytkownika (który post, który źródło), to jest to właściwość zdarzenia. Jeśli to fakt o użytkowniku niezależny od akcji — jego plan albo to, czy jest VIP — to jest to właściwość użytkownika. Umieść source na zdarzeniu, a plan na użytkowniku.

Zawsze przekazuj stabilny identyfikator encji

Przekazuj stabilny identyfikator obiektu, którego dotyczy akcja — post_id, video_id, order_id. Bez niego policzysz, ile postów otwarto, ale nie pogrupujesz, nie odfiltrujesz duplikatów ani nie połączysz zdarzeń dotyczących tego samego tego samego. Lejek taki jak wyszukiwanie → otwarcie z wyszukiwania → polubienie układa się w spójną ścieżkę użytkownika tylko wtedy, gdy każdy krok niesie właściwość, która łączy te kroki.

Przykład: wyszukiwanie → otwarcie → polubienie

Załóżmy, że chcesz wiedzieć, ilu użytkowników wyszukiwanie, potem otwiera post z wyników wyszukiwania, a potem go polubi. To trzy zdarzenia — ale kontekst „z wyszukiwania” jest właściwością source w post_opened, a nie osobnym zdarzeniem:

search_performed — { query }
post_opened — { source: "search", screen, post_id }
post_liked — { source: "search", screen, post_id }

Wtedy w kroku 2 (i 3) filtrujesz lejek po source = "search" — jednym warunkiem na właściwości, bez żonglowania nazwami zdarzeń. Dokładne wywołania SDK dla każdej platformy:

// User runs a search
Kixo.track('search_performed', {
  query: 'running shoes',
});

// User taps a result — the post was opened FROM search
Kixo.track('post_opened', {
  source: 'search',          // ← context as a property, not the event name
  screen: 'search_results',
  post_id: 'post_8f3a1c',
});

// User likes the post they opened from search
Kixo.track('post_liked', {
  source: 'search',
  screen: 'post_detail',
  post_id: 'post_8f3a1c',
});

Tagowanie użytkownika zamiast zdarzenia

Jeśli „polubił post z wyszukiwania” to trwała cecha, według której chcesz segmentować użytkowników, a nie tylko sygnał pojedynczego zdarzenia, ustaw po tej akcji właściwość użytkownika: Kixo.setUserProperty("liked_from_search", true). Dzięki temu eksplorator odbiorców i kwalifikacja do kampanii mogą kierować przekaz bezpośrednio do tych użytkowników.

Niech AI zaprojektuje to za Ciebie

Na czacie w dashboardzie Kixo opisz prostym językiem, co chcesz mierzyć — „track posts opened from search and then liked” — a asystent zwróci zalecane zdarzenia, właściwości i gotowe fragmenty do wklejenia dla wszystkich trzech platform. i pokaże też, które zdarzenia już napływają do projektu, a co nadal wymaga pracy w SDK. To dokładnie ten sam wzorzec, który opisujemy na tej stronie.

Zobacz też: Referencja zdarzeń z jedenastoma kanonicznymi nazwami zdarzeń, które Kixo rozpoznaje automatycznie, oraz przewodniki SDK dla Web, iOS i Android.