Suivre les actions dans leur contexte

La décision d’instrumentation la plus importante porte sur le nommage des événements et l’endroit où vous mettez le contexte. Si vous faites le bon choix, un seul événement répond à une douzaine de questions ; sinon, votre catalogue explose en centaines de noms quasi identiques qu’aucun tunnel ne peut aligner. Ce guide présente le modèle de référence de Kixo — celui que recommande aussi le conseiller d’instrumentation AI (suggest_instrumentation dans le chat).

Le modèle : un événement générique avec des propriétés riches

Suivez un événement par action utilisateur et décrivez le contexte avec propriétés — ne déclinez jamais le nom de l’événement selon le contexte. Une publication ouverte depuis la recherche et une publication ouverte depuis le fil sont la même action (post_opened), avec une propriété source différente.

À éviter

N’utilisez pas pas pour créer post_opened_from_search, post_opened_from_feed, post_opened_from_profile. Trois noms d’événement, c’est trois variantes à maintenir ; aucun tunnel unique ne peut les couvrir, et ajouter une quatrième surface impose des changements de code partout. Un seul post_opened avec source s’adapte sans effort à autant de surfaces que nécessaire.

À éviter : un événement par contexte	À faire (un événement + une propriété)
`post_opened_from_search` `post_opened_from_feed`	`post_opened` avec `{ source: "search" \| "feed" }`
`video_played_mobile` `video_played_web`	`video_played` — la plateforme est déjà ajoutée automatiquement à chaque événement
`checkout_from_cart` `checkout_from_buy_now`	`cart_checked_out` avec `{ source: "cart" \| "buy_now" }`

Nommage : snake_case, objet puis verbe, au passé

Nommez chaque événement (object)_(verb) en snake_case, au passé — post_opened, video_played, cart_checked_out. Utilisez exactement le même nom sur le Web, iOS et Android pour aligner les tunnels multiplateformes et permettre au détecteur d’événements standard de Kixo de reconnaître les noms canoniques.

D’abord l’objet, puis le verbe — regroupe les événements liés lorsque vous parcourez le catalogue (post_opened, post_liked, post_shared).
Passé — un événement enregistre quelque chose qui s’est produit.
snake_case — pas postOpened, ni PostOpened. Le détecteur et le rapprochement du vocabulaire ignorent la casse, mais s’en tenir à une seule forme garde les tunnels propres.

Propriétés d’événement ou propriétés utilisateur

L’autre moitié de la décision consiste à savoir où placer une valeur.

	Propriété d’événement	Propriété utilisateur
Décrit	Cette occurrence précise de l’action	La personne, durablement à travers tous ses événements
Définie avec	`Kixo.track(name, { ... })`	`Kixo.setUserProperty(key, value)`
Exemples	`source`, `screen`, `post_id`, `amount_cents`	`plan`, `vip`, `signup_cohort`, `lifetime_orders`
Alimente	Filtres par étape, ventilations et distributions dans le tunnel	Segmentation, ciblage d’audience, éligibilité des campagnes

Conseil

Règle simple : si la valeur peut varier entre deux événements d’un même utilisateur (publication qui, source qui), c’est une propriété d’événement. Si c’est une caractéristique de l’utilisateur qui reste vraie quelle que soit l’action — son offre, le fait qu’il soit VIP — c’est une propriété utilisateur. Mettez source sur l’événement ; mettez plan sur l’utilisateur.

Incluez toujours un identifiant d’entité stable

Transmettez un identifiant stable pour l’objet concerné par l’action — post_id, video_id, order_id. Sans lui, vous pouvez compter combien de publications ont été ouvertes, mais pas regrouper, dédupliquer ni chaîner les événements concernant la même même publication. Un tunnel comme recherche → ouverture depuis la recherche → like ne reconstitue un parcours cohérent que si chaque étape porte la propriété qui relie les étapes entre elles.

Exemple complet : recherche → ouverture → like

Supposons que vous vouliez savoir combien d’utilisateurs ont fait recherche, puis ouvrir une publication depuis les résultats de recherche, puis l’aimer. Cela fait bien trois événements — mais le contexte « depuis la recherche » est une propriété source de post_opened, pas un événement distinct :

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

Vous filtrez alors l’étape 2, puis l’étape 3, sur source = "search" — une seule condition sur une propriété, sans jongler avec les noms d’événement. Voici les appels SDK exacts pour chaque plateforme :

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

Étiqueter l’utilisateur à la place

Si « has liked a post from search » est une caractéristique durable sur laquelle vous voulez segmenter, et pas seulement un signal porté par un événement, définissez une propriété utilisateur après l’action : Kixo.setUserProperty("liked_from_search", true). Vous pourrez ensuite cibler directement ces utilisateurs dans l’explorateur d’audience et dans les critères d’éligibilité des campagnes.

Laissez l’AI le concevoir pour vous

Dans le chat du tableau de bord Kixo, décrivez simplement ce que vous voulez mesurer — « track posts opened from search and then liked » — et l’assistant vous renvoie les événements, les propriétés et les extraits prêts à copier-coller pour les trois plateformes. et vous indique aussi quels événements remontent déjà sur votre projet et lesquels demandent encore du travail côté SDK. Il applique exactement le modèle présenté sur cette page.

Voir aussi : le Référence des événements pour les onze noms d’événement canoniques reconnus automatiquement par Kixo, ainsi que les guides SDK pour Web, iOS et Android.