Acties in context tracken

De belangrijkste keuze bij instrumentatie is hoe je events benoemt en waar je context vastlegt. Doe je dat goed, dan beantwoordt één event al snel een tiental vragen. Doe je het verkeerd, dan groeit je catalogus uit tot honderden bijna gelijke namen die in geen enkele funnel netjes op elkaar aansluiten. Deze gids volgt het standaardpatroon van Kixo — hetzelfde ontwerp dat de AI-instrumentatieadviseur (suggest_instrumentation in chat) aanraadt.

Het patroon: één algemeen event + rijke properties

Track één event per gebruikersactie en leg de context vast in properties — splits de eventnaam nooit op per context. Een post die via search is geopend en een post die via de feed is geopend, zijn dezelfde actie (post_opened) met een andere source-property.

Antipatroon

Maak van niet niet post_opened_from_search, post_opened_from_feed, post_opened_from_profile. Drie eventnamen betekenen drie dingen om te onderhouden, geen enkele funnel kan ze samen omvatten, en zodra je een vierde context toevoegt, moet de code overal mee veranderen. Eén post_opened met source schaalt zonder extra werk naar elk aantal contexten.

Niet doen (event per context)	Wel doen (één event + property)
`post_opened_from_search` `post_opened_from_feed`	`post_opened` met `{ source: "search" \| "feed" }`
`video_played_mobile` `video_played_web`	`video_played` — platform staat al automatisch op elk event
`checkout_from_cart` `checkout_from_buy_now`	`cart_checked_out` met `{ source: "cart" \| "buy_now" }`

Naamgeving: snake_case (object)(werkwoord), verleden tijd

Geef elk event een naam als (object)_(verb) in snake_case, in de verleden tijd — post_opened, video_played, cart_checked_out. Gebruik exact dezelfde naam op Web, iOS en Android, zodat platformoverstijgende funnels goed op elkaar aansluiten en Kixo standaardevents op canonieke namen kan matchen.

Eerst het object, dan het werkwoord — groepeert verwante events als je door de catalogus bladert (post_opened, post_liked, post_shared).
Verleden tijd — een event legt iets vast dat plaatsgevonden.
snake_case — niet postOpened, niet PostOpened. De detector en vocabulairematcher zijn hoofdletterongevoelig, maar één vaste vorm houdt funnels overzichtelijk.

Eventproperties versus gebruikersproperties

De andere helft van die keuze is waar een waarde thuishoort.

	Eventproperty	Gebruikersproperty
Beschrijft	Deze ene uitvoering van de actie	De persoon, blijvend over al diens events heen
Instellen met	`Kixo.track(name, { ... })`	`Kixo.setUserProperty(key, value)`
Voorbeelden	`source`, `screen`, `post_id`, `amount_cents`	`plan`, `vip`, `signup_cohort`, `lifetime_orders`
Stuurt aan	Filters, uitsplitsingen en verdelingen per funnelstap	Segmentatie, doelgroeptargeting, campagnegeschiktheid

Tip

Vuistregel: als de waarde kan verschillen tussen twee events van dezelfde gebruiker (welke post, welke bron), dan is het een eventproperty. Als het een kenmerk van de gebruiker is dat losstaat van de actie (hun plan, of ze VIP zijn), dan is het een user property. Zet source op het event; zet plan op de gebruiker.

Geef altijd een stabiele entiteits-id mee

Geef een stabiele id mee voor het object waarop de actie betrekking heeft — post_id, video_id, order_id. Zonder die id kun je tellen hoeveel posts zijn geopend, maar kun je events over dezelfde dezelfde post niet groeperen, dedupliceren of aan elkaar koppelen. Een funnel zoals zoeken → openen-vanuit-zoeken → liken wordt pas een samenhangend gebruikerstraject als elke stap de property bevat die de stappen met elkaar verbindt.

Uitgewerkt voorbeeld: search → open → like

Stel dat je wilt weten hoeveel gebruikers zoekopdracht, daarna een post openen vanuit de zoekresultaten en daarna liken. Drie events — maar de context "from search" is een source-property op post_opened, geen apart event:

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

Filter daarna stap 2 van je funnel (en eventueel stap 3) op source = "search" — één propertyvoorwaarde, zonder gedoe met eventnamen. De exacte SDK-aanroepen per 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',
});

In plaats daarvan de gebruiker taggen

Als "has liked a post from search" een blijvend kenmerk is waarop je wilt segmenteren, en niet alleen een signaal per event, stel dan na de actie een user property in: Kixo.setUserProperty("liked_from_search", true). Daarna kunnen de doelgroepverkenner en campagnegeschiktheid deze gebruikers direct targeten.

Laat de AI het voor je ontwerpen

Beschrijf in de chat van het Kixo-dashboard in gewone taal wat je wilt meten — "track posts opened from search and then liked" — en de assistent geeft de aanbevolen events, properties en copy-paste-snippets voor alle drie de platforms. en laat zien welke events voor je project al binnenkomen en waarvoor nog SDK-werk nodig is. Het volgt precies het patroon op deze pagina.

Zie ook: de Eventreferentie met de elf canonieke eventnamen die Kixo automatisch herkent, en de SDK-gidsen per platform voor Web, iOS en Android.