Rexistrar accións con contexto

A decisión de instrumentación máis importante é como nomeas os eventos e onde gardas o contexto. Se o fas ben, un só evento responde unha ducia de preguntas; se o fas mal, o catálogo énchese de centos de nomes case duplicados que ningún funil consegue aliñar. Esta guía é o patrón canónico de Kixo: o mesmo deseño que recomenda o asesor de instrumentación de AI (suggest_instrumentation no chat).

O patrón: un evento xeral + propiedades ricas

Rexistra un evento por acción do usuario e describe o contexto con propiedades; nunca dividas o nome do evento por contexto. Unha publicación aberta desde a busca e unha publicación aberta desde o feed son a mesma acción (post_opened) cunha propiedade source distinta.

Antipatrón

Non non creando post_opened_from_search, post_opened_from_feed, post_opened_from_profile. Tres nomes de evento son tres cousas que manter, ningún funil único os pode abranguer e engadir unha cuarta superficie implica cambiar código en todas partes. Un só post_opened con source escala a calquera número de superficies sen custo adicional.

Non fagas isto (un evento por contexto)	Fai isto (un evento + unha propiedade)
`post_opened_from_search` `post_opened_from_feed`	`post_opened` con `{ source: "search" \| "feed" }`
`video_played_mobile` `video_played_web`	`video_played` — a plataforma xa vai en cada evento automaticamente
`checkout_from_cart` `checkout_from_buy_now`	`cart_checked_out` con `{ source: "cart" \| "buy_now" }`

Nomenclatura: snake_case (obxecto)(verbo), en pasado

Ponlle a cada evento o nome (object)_(verb) en snake_case e en pasado: post_opened, video_played, cart_checked_out. O mesmo nome debe usarse literalmente en Web, iOS e Android para que os funís multiplataforma cadran e para que o detector de eventos estándar de Kixo poida identificar os nomes canónicos.

Primeiro o obxecto, despois o verbo — agrupa eventos relacionados cando revisas o catálogo (post_opened, post_liked, post_shared).
Pasado — un evento rexistra algo que ocorreu.
snake_case — non postOpened, nin PostOpened. O detector e o comparador de vocabulario non distinguen maiúsculas de minúsculas, pero converxer nunha soa forma mantén os funís limpos.

Propiedades de evento fronte a propiedades de usuario

A outra metade da decisión é onde vive un valor.

	Propiedade de evento	Propiedade de usuario
Describe	Esta ocorrencia concreta da acción	A persoa, de forma persistente ao longo de todos os seus eventos
Defínese con	`Kixo.track(name, { ... })`	`Kixo.setUserProperty(key, value)`
Exemplos	`source`, `screen`, `post_id`, `amount_cents`	`plan`, `vip`, `signup_cohort`, `lifetime_orders`
Impulsa	Filtros por paso do funil, desagregacións e distribucións	Segmentación, orientación de audiencias, elegibilidade para campañas

Consello

Regra práctica: se o valor pode variar entre dous eventos do mesmo usuario (publicación cal, orixe cal), é unha propiedade de evento. Se é un dato sobre o usuario que se mantén independentemente da acción (o seu plan, se é VIP), é unha propiedade de usuario. Pon source no evento; pon plan no usuario.

Leva sempre un ID de entidade estable

Pasa un ID estable do obxecto sobre o que actúa a acción: post_id, video_id, order_id. Sen el podes contar cantas publicacións se abriron, pero non podes agrupar, deduplicar nin encadear eventos sobre a mesma publicación mesmo. Un funil como search → open-from-search → like só representa unha viaxe de usuario coherente cando cada paso leva a propiedade que une os pasos.

Exemplo completo: search → open → like

Imaxina que queres saber cantos usuarios busca, despois abre unha publicación desde os resultados de busca e despois darlle gústame. Son tres eventos, pero o contexto "from search" é unha propiedade source en post_opened, non un evento aparte:

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

Despois, o teu funil filtra o paso 2 (e o paso 3) por source = "search": un único predicado sobre propiedades, sen andar a xogar cos nomes dos eventos. Estas son as chamadas exactas do SDK para 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 o usuario no seu lugar

Se "deulle gústame a unha publicación desde a busca" é un trazo persistente polo que queres segmentar, e non só un sinal nun evento concreto, define unha propiedade de usuario despois da acción: Kixo.setUserProperty("liked_from_search", true). Así, o explorador de audiencias e a elegibilidade das campañas poden dirixirse directamente a eses usuarios.

Deixa que AI o deseñe por ti

No chat do dashboard de Kixo, describe en linguaxe natural o que queres medir —"seguir as publicacións abertas desde a busca e ás que despois se lles deu gústame"— e o asistente devolverache os eventos recomendados, as propiedades e fragmentos listos para copiar e pegar nas tres plataformas. Ademais, e indícache que eventos xa están chegando ao teu proxecto e cales aínda requiren traballo no SDK. Aplica exactamente o patrón desta páxina.

Consulta tamén Referencia de eventos para os once nomes de evento canónicos que Kixo recoñece automaticamente, e as guías do SDK por plataforma para Web, iOS e Android.