Sporing af handlinger i kontekst

Den vigtigste beslutning i instrumenteringen er, hvordan du navngiver events, og hvor du lægger kontekst. Gør du det rigtigt, kan ét event besvare et dusin spørgsmål; gør du det forkert, eksploderer kataloget i hundredvis af næsten ens navne, som ingen tragt kan få til at flugte. Denne guide er Kixo's kanoniske mønster — det samme design, som AI-rådgiveren til instrumentering (suggest_instrumentation i chatten) anbefaler.

Mønsteret: ét generaliseret event + detaljerede egenskaber

Spor ét event pr. brugerhandling, og beskriv konteksten med egenskaber — del aldrig eventnavnet op efter kontekst. Et opslag åbnet fra search og et opslag åbnet fra feedet er den samme handling (post_opened) med en anden source-egenskab.

Antimønster

Opret ikke ikke, post_opened_from_search, post_opened_from_feed, post_opened_from_profile. Tre eventnavne er tre ting, der skal vedligeholdes, ingen enkelt tragt kan gå på tværs af dem, og en fjerde flade kræver kodeændringer overalt. Ét post_opened med source skalerer uden ekstra arbejde til et vilkårligt antal flader.

Undgå dette (ét event pr. kontekst)	Gør sådan (ét event + én egenskab)
`post_opened_from_search` `post_opened_from_feed`	`post_opened` med `{ source: "search" \| "feed" }`
`video_played_mobile` `video_played_web`	`video_played` — platform tilføjes allerede automatisk på alle events
`checkout_from_cart` `checkout_from_buy_now`	`cart_checked_out` med `{ source: "cart" \| "buy_now" }`

Navngivning: snake_case (objekt)(verbum), datid

Navngiv hvert event (object)_(verb) i snake_case og datid — post_opened, video_played, cart_checked_out. Det samme navn skal bruges ordret på tværs af Web, iOS og Android, så tragter på tværs af platforme flugter, og så Kixo's standardeventdetektor kan matche de kanoniske navne.

Objekt først, verbum bagefter — samler relaterede events, når du skimmer kataloget (post_opened, post_liked, post_shared).
Datid — et event registrerer noget, der skete.
snake_case — ikke postOpened, ikke PostOpened. Detektoren og ordlistematcheren skelner ikke mellem store og små bogstaver, men én fast form holder tragterne rene.

Eventegenskaber vs. brugeregenskaber

Den anden halvdel af beslutningen er hvor en værdi hører hjemme.

	Eventegenskab	Brugeregenskab
Beskriver	Denne ene forekomst af handlingen	Personen, varigt på tværs af alle deres events
Sættes med	`Kixo.track(name, { ... })`	`Kixo.setUserProperty(key, value)`
Eksempler	`source`, `screen`, `post_id`, `amount_cents`	`plan`, `vip`, `signup_cohort`, `lifetime_orders`
Understøtter	Filtre, opdelinger og fordelinger pr. trin i tragten	Segmentering, målretning af målgrupper, kampagnekvalificering

Tip

Tommelfingerregel: Hvis værdien kan være forskellig mellem to events fra samme bruger (som opslag, som kilde), er det en eventegenskab. Hvis det er et forhold ved brugeren, som gælder uanset handlingen (brugerens abonnement, om vedkommende er VIP), er det en brugeregenskab. Sæt source på eventet; sæt plan på brugeren.

Medtag altid et stabilt entitets-id

Send et stabilt id for det objekt, handlingen berørte — post_id, video_id, order_id. Uden det kan du tælle, hvor mange opslag der blev åbnet, men du kan ikke gruppere, deduplikere eller kæde events om det samme opslag sammen. En tragt som search → open-from-search → like bliver kun til en sammenhængende brugerrejse, når hvert trin har den egenskab, der binder trinnene sammen.

Eksempel: search → open → like

Lad os sige, at du vil vide, hvor mange brugere søgning, derefter åbner et opslag fra søgeresultaterne, derefter liker det. Tre events — men konteksten "from search" er en source-egenskab på post_opened, ikke et separat event:

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

Derefter filtrerer din tragt trin 2 (og trin 3) på source = "search" — ét egenskabsfilter, ingen jonglering med eventnavne. Her er de præcise SDK-kald for hver platform:

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

Tagging af brugeren i stedet

Hvis "has liked a post from search" er et varigt kendetegn, du vil segmentere på — ikke bare et signal på et enkelt event — så sæt en brugeregenskab efter handlingen: Kixo.setUserProperty("liked_from_search", true). Så kan målgruppeoversigten og kampagnekvalificering målrette de brugere direkte.

Lad AI designe det for dig

I chatten i Kixo-dashboardet beskriver du i almindeligt sprog, hvad du vil måle — "track posts opened from search and then liked" — og assistenten returnerer anbefalede events, egenskaber og kodebidder, du kan kopiere direkte til alle tre platforme. og viser, hvilke events der allerede kommer ind for jeres projekt, og hvad der stadig kræver arbejde i SDK. Den følger præcis mønsteret på denne side.

Se også Eventreference for de elleve kanoniske eventnavne, som Kixo genkender automatisk, og de platformspecifikke SDK-guides til Web, iOS og Android.