Registrar accions amb context

La decisió d’instrumentació més important és com anomenes els esdeveniments i on poses el context. Si ho fas bé, un sol esdeveniment respon una dotzena de preguntes; si ho fas malament, el catàleg explota en centenars de noms gairebé duplicats que cap embut no pot alinear. Aquesta guia és el patró canònic de Kixo: el mateix disseny que recomana l’assessor d’instrumentació amb AI (suggest_instrumentation al xat).

El patró: un esdeveniment generalitzat + propietats riques

Registra un esdeveniment per acció d’usuari i descriu-ne el context amb propietats; no bifurquis mai el nom de l’esdeveniment segons el context. Una publicació oberta des de la cerca i una publicació oberta des del feed són la mateixa acció (post_opened) amb una propietat source diferent.

Antipatró

No no creïs post_opened_from_search, post_opened_from_feed, post_opened_from_profile. Tres noms d’esdeveniment volen dir tres coses a mantenir, cap embut únic no els pot abastar i afegir una quarta superfície obliga a tocar codi a tot arreu. Un sol post_opened amb source escala sense cost a qualsevol nombre de superfícies.

No ho facis així (un esdeveniment per context)	Fes-ho així (un esdeveniment + una propietat)
`post_opened_from_search` `post_opened_from_feed`	`post_opened` amb `{ source: "search" \| "feed" }`
`video_played_mobile` `video_played_web`	`video_played` — la plataforma ja s’afegeix automàticament a tots els esdeveniments
`checkout_from_cart` `checkout_from_buy_now`	`cart_checked_out` amb `{ source: "cart" \| "buy_now" }`

Nomenclatura: snake_case, objecte + verb, en passat

Anomena tots els esdeveniments (object)_(verb) en snake_case i en passat: post_opened, video_played, cart_checked_out. S’ha de fer servir exactament el mateix nom a Web, iOS i Android perquè els embuts multiplataforma quadrin i perquè el detector d’esdeveniments estàndard de Kixo pugui identificar els noms canònics.

Primer l’objecte, després el verb — agrupa esdeveniments relacionats quan repasses el catàleg (post_opened, post_liked, post_shared).
Passat — un esdeveniment registra una cosa que ha passat.
snake_case — no postOpened, ni PostOpened. El detector i el comparador de vocabulari no distingeixen entre majúscules i minúscules, però fer convergir els noms en una sola forma manté nets els embuts.

Propietats d’esdeveniment vs. propietats d’usuari

L’altra meitat de la decisió és on viu un valor.

	Propietat d’esdeveniment	Propietat d’usuari
Descriu	Aquesta ocurrència concreta de l’acció	La persona, de manera persistent a través de tots els seus esdeveniments
Es defineix amb	`Kixo.track(name, { ... })`	`Kixo.setUserProperty(key, value)`
Exemples	`source`, `screen`, `post_id`, `amount_cents`	`plan`, `vip`, `signup_cohort`, `lifetime_orders`
Impulsa	Filtres per pas de l’embut, desglossaments, distribucions	Segmentació, orientació d’audiències, elegibilitat de campanyes

Consell

Regla pràctica: si el valor pot variar entre dos esdeveniments del mateix usuari (quin publicació, quin font), és una propietat d’esdeveniment. Si és un fet sobre l’usuari que es manté independentment de l’acció (el seu pla, si és VIP), és una propietat d’usuari. Posa source a l’esdeveniment; posa plan a l’usuari.

Porta sempre un ID d’entitat estable

Passa un ID estable de l’objecte sobre el qual actua l’acció: post_id, video_id, order_id. Sense això pots comptar quantes publicacions s’han obert, però no pots agrupar, deduplicar ni encadenar esdeveniments sobre la mateix mateixa publicació. Un embut com cerca → obert-des-de-cerca → m’agrada només es resol com un recorregut d’usuari coherent quan cada pas porta la propietat que els lliga.

Exemple complet: cerca → obrir → m’agrada

Suposa que vols saber quants usuaris cerca, després obren una publicació des dels resultats de cerca i després hi facin m’agrada. Són tres esdeveniments, però el context «des de la cerca» és una propietat de source a post_opened, no un esdeveniment separat:

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

Llavors, el teu embut filtra el pas 2 (i el pas 3) per source = "search": un sol predicat de propietat, sense fer malabars amb els noms dels esdeveniments. Aquestes són les crides exactes de l’SDK per a cada plataforma:

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

Etiquetar l’usuari en lloc de l’esdeveniment

Si «ha marcat amb m’agrada una publicació des de la cerca» és un tret persistent sobre el qual vols segmentar (i no només un senyal d’un esdeveniment concret), defineix una propietat d’usuari després de l’acció: Kixo.setUserProperty("liked_from_search", true). Així, l’explorador d’audiències i l’elegibilitat de campanyes poden orientar-se directament a aquests usuaris.

Deixa que l’AI t’ho dissenyi

Al xat del dashboard de Kixo, descriu en llenguatge natural què vols mesurar —«track posts opened from search and then liked»— i l’assistent et retornarà els esdeveniments, les propietats i els fragments per copiar i enganxar recomanats per a les tres plataformes. A més, i t’indica quins esdeveniments ja estan arribant al teu projecte i quins encara requereixen feina d’SDK. Aplica exactament el patró d’aquesta pàgina.

Consulta també Referència d’esdeveniments per veure els onze noms d’esdeveniment canònics que Kixo reconeix automàticament, i les guies de l’SDK per plataforma per a Web, iOS i Android.