Tegevuste jälgimine kontekstis

Kõige olulisem instrumenteerimisotsus on, kuidas te sündmusi nimetate ja kuhu konteksti paigutate. Kui see on õigesti tehtud, vastab üks sündmus tosinale küsimusele; kui valesti, paisub kataloog sadadeks peaaegu duplikaatseteks nimedeks, mida ükski lehter ei suuda joondada. See juhend kirjeldab Kixo kanoonilist mustrit — sama lähenemist, mida soovitab AI instrumenteerimisnõustaja (suggest_instrumentation vestluses).

Muster: üks üldistatud sündmus + rikkalikud omadused

Jälgige üks sündmus iga kasutajategevuse kohta ja kirjeldage konteksti omadusega omadused — ärge hargitage sündmuse nime konteksti järgi. Otsingust avatud postitus ja voost avatud postitus on sama tegevus (post_opened) erineva omadusega source.

Antimuster

Ära loo mitte asemel sündmusi post_opened_from_search, post_opened_from_feed, post_opened_from_profile. Kolm sündmusenime tähendab kolme eraldi asja, mida hooldada; ükski lehter ei ulatu neist üle ning neljanda pinna lisamine nõuab igal pool koodimuudatusi. Üks post_opened koos omadusega source skaleerub ilma lisatööta mistahes arvu pindadele.

Ära tee nii (iga konteksti jaoks eraldi sündmus)	Tee nii (üks sündmus + omadus)
`post_opened_from_search` `post_opened_from_feed`	`post_opened` koos `{ source: "search" \| "feed" }`-ga
`video_played_mobile` `video_played_web`	`video_played` — platvorm lisatakse igale sündmusele juba automaatselt
`checkout_from_cart` `checkout_from_buy_now`	`cart_checked_out` koos `{ source: "cart" \| "buy_now" }`-ga

Nimetamine: snake_case, objekt enne tegusõna, minevik

Nimetage iga sündmus kujul (object)_(verb), vormingus snake_case ja minevikus — post_opened, video_played, cart_checked_out. Sama nime tuleb kasutada Webis, iOS-is ja Androidis täpselt samal kujul, et platvormiülesed lehtrid joonduksid ja Kixo standardsündmuste tuvastaja leiaks kanoonilised nimed.

Kõigepealt objekt, siis tegusõna — koondab seotud sündmused kataloogi sirvimisel ühte rühma (post_opened, post_liked, post_shared).
Minevik — sündmus talletab midagi, mis juhtus.
snake_case — mitte postOpened, mitte PostOpened. Tuvastaja ja sõnavara vastendaja on tõstutundetud, kuid ühe kuju kasutamine hoiab lehtrid puhtana.

Sündmuse omadused vs kasutajaomadused

Otsuse teine pool on see, kus väärtus asub.

	Sündmuse omadus	Kasutajaomadus
Kirjeldab	See konkreetne tegevuse kord	Inimene püsivalt kõigi oma sündmuste lõikes
Määratakse käsuga	`Kixo.track(name, { ... })`	`Kixo.setUserProperty(key, value)`
Näited	`source`, `screen`, `post_id`, `amount_cents`	`plan`, `vip`, `signup_cohort`, `lifetime_orders`
Toidab	Sammupõhised lehtrifiltrid, jaotused ja distributsioonid	Segmenteerimine, auditooriumi sihtimine, kampaania sobivus

Nipp

Rusikareegel: kui väärtus võib sama kasutaja kahe sündmuse vahel erineda (milline postitus, milline allikas), on see sündmuse omadus. Kui see on kasutaja kohta käiv püsiv fakt sõltumata tegevusest (tema pakett, kas ta on VIP), on see kasutajaomadus. Pange source sündmusele; pange plan kasutajale.

Lisa alati stabiilne üksuse ID

Andke edasi stabiilne ID objektile, mida tegevus puudutas — post_id, video_id, order_id. Ilma selleta saate küll lugeda, mitu postitust avati, kuid te ei saa sama sama postitusega seotud sündmusi rühmitada, deduplikeerida ega omavahel siduda. Lehter nagu search → open-from-search → like muutub ühtseks kasutajateekonnaks ainult siis, kui igal sammul on omadus, mis sammud omavahel seob.

Läbitud näide: search → open → like

Oletame, et tahate teada, kui paljud kasutajad otsing, siis avavad postituse otsingutulemustest, siis märgivad meeldivaks. Need on kolm sündmust — aga kontekst "from search" on sündmuse post_opened omadus source, mitte eraldi sündmus:

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

Seejärel filtreerib lehter sammu 2 (ja sammu 3) omaduse source = "search" järgi — üks omaduse tingimus, ei mingit sündmusenimede vahel laveerimist. Täpsed SDK kutsed iga platvormi jaoks:

// 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',
});

Selle asemel kasutaja märgistamine

Kui "has liked a post from search" on püsiv tunnus, mille järgi soovite segmenteerida, mitte ainult üksiku sündmuse signaal, seadke pärast tegevust kasutajaomadus: Kixo.setUserProperty("liked_from_search", true). Siis saavad auditooriumi vaade ja kampaania sobivus neid kasutajaid otse sihtida.

Lase AI-l see enda jaoks kavandada

Kirjeldage Kixo töölaua vestluses lihtsas inglise keeles, mida soovite mõõta — "track posts opened from search and then liked" — ning abiline tagastab soovitatud sündmused, omadused ja kopeeritavad koodilõigud kõigi kolme platvormi jaoks. ja näitab, millised sündmused juba teie projekti jõuavad ja mis vajab veel SDK tööd. See järgib täpselt selle lehe mustrit.

Vaata ka: Sündmuste viide üheteistkümne kanoonilise sündmusenime kohta, mida Kixo automaatselt tunneb, ning platvormipõhiseid SDK juhendeid: Web, iOS ja Android.