Darbību izsekošana kontekstā

Svarīgākais instrumentācijas lēmums ir tas, kā nosaucat notikumus un kur glabājat kontekstu. Ja to izdara pareizi, viens notikums atbild uz duci jautājumu; ja kļūdās, katalogs uzsprāgst simtos gandrīz vienādu nosaukumu, kurus neviena piltuve nespēj salāgot. Šis ceļvedis ir Kixo kanoniskais modelis — tieši šo pašu pieeju iesaka AI instrumentācijas padomdevējs (suggest_instrumentation čatā).

Modelis: viens vispārināts notikums ar bagātīgām īpašībām

Izsekojiet viens notikums katrai lietotāja darbībai un aprakstiet kontekstu ar īpašības — nekad nesazarojiet notikuma nosaukumu pēc konteksta. Ieraksts, kas atvērts no meklēšanas, un ieraksts, kas atvērts no feed, ir viena un tā pati darbība (post_opened) ar atšķirīgu source īpašību.

Anti-piemērs

Neveidojiet ne kā post_opened_from_search, post_opened_from_feed, post_opened_from_profile. Trīs notikumu nosaukumi nozīmē trīs atsevišķas lietas, kas jāuztur, neviena piltuve nevar tās aptvert kopā, un ceturtas virsmas pievienošana nozīmē koda izmaiņas visur. Viens post_opened ar source bez papildu darba mērogojas uz jebkuru virsmu skaitu.

Nedariet tā (atsevišķs notikums katram kontekstam)	Dariet tā (viens notikums + īpašība)
`post_opened_from_search` `post_opened_from_feed`	`post_opened` ar `{ source: "search" \| "feed" }`
`video_played_mobile` `video_played_web`	`video_played` — platforma jau tiek automātiski pievienota katram notikumam
`checkout_from_cart` `checkout_from_buy_now`	`cart_checked_out` ar `{ source: "cart" \| "buy_now" }`

Nosaukšana: snake_case, objekts vispirms, darbība pēc tam, pagātnes laiks

Katru notikumu nosauciet (object)_(verb) snake_case formā un pagātnes laikā — post_opened, video_played, cart_checked_out. Tas pats nosaukums burtiski jālieto Web, iOS un Android, lai starpplatformu piltuves sakristu un Kixo standarta notikumu detektors varētu atpazīt kanoniskos nosaukumus.

Vispirms objekts, pēc tam darbība — grupē saistītus notikumus, kad pārskatāt katalogu (post_opened, post_liked, post_shared).
Pagātnes laiks — notikums fiksē kaut ko, kas notika.
snake_case — nevis postOpened un nevis PostOpened. Detektors un vārdnīcas salīdzinātājs ignorē burtu reģistru, bet viena konsekventa forma uztur piltuves tīras.

Notikuma īpašības un lietotāja īpašības

Otra lēmuma puse ir tas, kur šī vērtība atrodas.

	Notikuma īpašība	Lietotāja īpašība
Apraksta	Šī konkrētā darbības reize	Pats lietotājs, noturīgi visos viņa notikumos
Iestata ar	`Kixo.track(name, { ... })`	`Kixo.setUserProperty(key, value)`
Piemēri	`source`, `screen`, `post_id`, `amount_cents`	`plan`, `vip`, `signup_cohort`, `lifetime_orders`
Nodrošina	Filtri pa soļiem, sadalījumi un sadalījuma analīze piltuvēs	Segmentēšana, auditorijas mērķēšana, kampaņu atbilstība

Ieteikums

Īkšķa likums: ja vērtība var atšķirties starp diviem viena lietotāja notikumiem (kas ieraksts, kas avots), tā ir notikuma īpašība. Ja tas ir fakts par lietotāju, kas ir spēkā neatkarīgi no darbības (piemēram, plāns vai VIP statuss), tā ir lietotāja īpašība. source lieciet uz notikuma; plan lieciet uz lietotāja.

Vienmēr nododiet stabilu entītijas ID

Nododiet stabilu ID objektam, kuru darbība skāra — post_id, video_id, order_id. Bez tā varat saskaitīt, cik ierakstu tika atvērts, bet nevarat grupēt, deduplicēt vai sasaistīt notikumus par to pašu tas pats ierakstu. Piltuve kā meklēšana → atvēršana no meklēšanas → patīk kļūst par sakarīgu lietotāja ceļu tikai tad, ja katrs solis nes īpašību, kas šos soļus savieno.

Praktisks piemērs: meklēšana → atvēršana → patīk

Pieņemsim, ka vēlaties zināt, cik lietotāju meklēšana, pēc tam atver ierakstu no meklēšanas rezultātiem, pēc tam atzīmē ar “patīk”. Tie ir trīs notikumi — bet konteksts “from search” ir source īpašība uz post_opened, nevis atsevišķs notikums:

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

Tad jūsu piltuvē 2. solis (un 3. solis) tiek filtrēts pēc source = "search" — viens īpašības nosacījums, bez žonglēšanas ar notikumu nosaukumiem. Precīzie SDK izsaukumi katrai platformai:

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

Tā vietā tiek marķēts lietotājs

Ja “has liked a post from search” ir noturīga pazīme, pēc kuras vēlaties segmentēt lietotājus (nevis tikai vienreizējs notikuma signāls), pēc darbības iestatiet lietotāja īpašību: Kixo.setUserProperty("liked_from_search", true). Tad auditorijas pārlūkā un kampaņu atbilstības noteikumos šos lietotājus varēsiet atlasīt tieši.

Lai AI to izveido jūsu vietā

Kixo paneļa čatā vienkāršā angļu valodā aprakstiet, ko vēlaties mērīt — “track posts opened from search and then liked” — un asistents atgriezīs ieteicamos notikumus, īpašības un nokopēšanai gatavus fragmentus visām trim platformām. un parādīs, kuri notikumi jūsu projektā jau pienāk un kam vēl vajadzīgs SDK darbs. Tas izmanto tieši šajā lapā aprakstīto modeli.

Skatiet arī: Notikumu atsauce par vienpadsmit kanoniskajiem notikumu nosaukumiem, ko Kixo atpazīst automātiski, un SDK ceļvežus platformām Web, iOS un Android.