Spåra åtgärder i sitt sammanhang

Det viktigaste instrumenteringsbeslutet är hur ni namnger händelser och var ni lägger kontexten. Blir det rätt kan en enda händelse besvara ett dussin frågor. Blir det fel exploderar katalogen i hundratals nästan identiska namn som ingen tratt kan linjera. Den här guiden visar Kixos kanoniska mönster — samma upplägg som AI-rådgivaren för instrumentering (suggest_instrumentation i chatten) rekommenderar.

Mönstret: en generell händelse + rika egenskaper

Spåra en händelse per användaråtgärd och beskriv kontexten med properties — dela aldrig upp händelsenamnet efter kontext. Ett inlägg som öppnas från sök och ett inlägg som öppnas från flödet är samma åtgärd (post_opened) med olika värde på egenskapen source.

Antimönster

Skapa inte post_opened_from_search, post_opened_from_feed, post_opened_from_profile för inte. Tre händelsenamn betyder tre saker att underhålla, ingen enskild tratt kan omfatta dem alla, och om ni lägger till en fjärde yta krävs kodändringar överallt. En post_opened med source skalar utan extra arbete till hur många ytor som helst.

Gör inte så här (en händelse per kontext)	Gör så här (en händelse + egenskap)
`post_opened_from_search` `post_opened_from_feed`	`post_opened` med `{ source: "search" \| "feed" }`
`video_played_mobile` `video_played_web`	`video_played` — plattform finns redan automatiskt på varje händelse
`checkout_from_cart` `checkout_from_buy_now`	`cart_checked_out` med `{ source: "cart" \| "buy_now" }`

Namngivning: snake_case, objekt först, verb sedan, i dåtid

Namnge varje händelse (object)_(verb) i snake_case och dåtid — post_opened, video_played, cart_checked_out. Samma namn måste användas exakt likadant i Web, iOS och Android så att plattformsövergripande trattar linjerar, och så att Kixo kan matcha kanoniska namn i sin standardhändelsedetektor.

Objekt först, verb sedan — grupperar relaterade händelser när du överblickar katalogen (post_opened, post_liked, post_shared).
Dåtid — en händelse registrerar något som hände.
snake_case — inte postOpened, inte PostOpened. Detektorn och ordlistematchningen är skiftlägesokänsliga, men om ni håller er till en form blir trattarna renare.

Händelseegenskaper kontra användaregenskaper

Den andra halvan av beslutet är var ett värde hör hemma.

	Händelseegenskap	Användaregenskap
Beskriver	Den här enskilda förekomsten av åtgärden	Personen, varaktigt över alla deras händelser
Sätts med	`Kixo.track(name, { ... })`	`Kixo.setUserProperty(key, value)`
Exempel	`source`, `screen`, `post_id`, `amount_cents`	`plan`, `vip`, `signup_cohort`, `lifetime_orders`
Driver	Filter, uppdelningar och fördelningar per trattsteg	Segmentering, målgruppsinriktning, kampanjbehörighet

Tips

Tumregel: om värdet kan skilja sig mellan två händelser från samma användare (vilken inlägg, vilken källa) är det en händelseegenskap. Om det är ett faktum om användaren som gäller oavsett åtgärd (deras plan, om personen är VIP) är det en användaregenskap. Lägg source på händelsen och plan på användaren.

Skicka alltid med ett stabilt objekt-id

Skicka med ett stabilt id för objektet som åtgärden gällde — post_id, video_id, order_id. Utan det kan du räkna hur många inlägg som öppnades, men du kan inte gruppera, avduplicera eller kedja ihop händelser om samma samma-inlägg. En tratt som sök → öppna-från-sök → gilla blir bara en sammanhängande användarresa när varje steg har egenskapen som binder ihop stegen.

Exempel: sök → öppna → gilla

Säg att du vill veta hur många användare som sök, sedan öppna ett inlägg från sökresultaten, sedan gillar det. Det är tre händelser — men kontexten "från sök" är en source-egenskap på post_opened, inte en separat händelse:

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

Då filtrerar tratten steg 2 och steg 3 på source = "search" — ett enda egenskapsvillkor, utan att behöva jonglera händelsenamn. Här är de exakta SDK-anropen för varje plattform:

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

Tagga användaren i stället

Om "has liked a post from search" är en varaktig egenskap som ni vill segmentera på, och inte bara en signal på en enskild händelse, sätter ni en användaregenskap efter åtgärden: Kixo.setUserProperty("liked_from_search", true). Då kan målgruppsutforskaren och kampanjbehörigheten rikta sig direkt till de användarna.

Låt AI utforma det åt dig

I chatten i Kixo-dashboarden beskriver du på vanlig engelska vad du vill mäta — "track posts opened from search and then liked" — och assistenten returnerar rekommenderade händelser, egenskaper och kodsnuttar att klistra in för alla tre plattformar. och visar vilka händelser som redan flödar in för projektet och vad som fortfarande kräver arbete i SDK. Den följer exakt mönstret på den här sidan.

Se även Händelsereferens för de elva kanoniska händelsenamn som Kixo känner igen automatiskt, och SDK-guiderna för Webb, iOS och Android.