Registrar acciones con contexto

La decisión de instrumentación más importante es cómo nombras los eventos y dónde colocas el contexto. Si lo haces bien, un solo evento responde a una docena de preguntas; si lo haces mal, el catálogo explota en cientos de nombres casi duplicados que ningún embudo puede alinear. Esta guía recoge el patrón canónico de Kixo: el mismo diseño que recomienda el asesor de instrumentación AI (suggest_instrumentation en el chat).

El patrón: un evento generalista + propiedades ricas

Registra un evento por acción del usuario y describe el contexto con propiedades; no dividas nunca el nombre del evento según el contexto. Abrir una publicación desde búsqueda y abrirla desde el feed es la misma acción (post_opened) con una propiedad source distinta.

Antipatrón

No crees post_opened_from_search, post_opened_from_feed y post_opened_from_profile para no. Tres nombres de evento son tres cosas distintas que mantener, ningún embudo único puede abarcar las tres, y añadir una cuarta superficie obliga a cambiar código en todas partes. Un solo post_opened con source escala gratis a cualquier número de superficies.

No hagas esto (un evento por contexto)	Haz esto (un evento + una propiedad)
`post_opened_from_search` `post_opened_from_feed`	`post_opened` con `{ source: "search" \| "feed" }`
`video_played_mobile` `video_played_web`	`video_played` — la plataforma ya se añade automáticamente a todos los eventos
`checkout_from_cart` `checkout_from_buy_now`	`cart_checked_out` con `{ source: "cart" \| "buy_now" }`

Nomenclatura: snake_case, objeto primero, verbo después, en pasado

Nombra todos los eventos (object)_(verb) en snake_case y en pasado: post_opened, video_played, cart_checked_out. Debe usarse exactamente el mismo nombre en Web, iOS y Android para que los embudos multiplataforma cuadren y para que el detector de eventos estándar de Kixo pueda identificar los nombres canónicos.

Primero el objeto, después el verbo — agrupa eventos relacionados al recorrer el catálogo (post_opened, post_liked, post_shared).
Pasado — un evento registra algo que ha ocurrido.
snake_case — no postOpened ni PostOpened. El detector y el comparador de vocabulario no distinguen entre mayúsculas y minúsculas, pero unificarlo en una sola forma mantiene limpios los embudos.

Propiedades de evento frente a propiedades de usuario

La otra mitad de la decisión es dónde vive un valor.

	Propiedad de evento	Propiedad de usuario
Describe	Esta ocurrencia concreta de la acción	La persona, de forma persistente en todos sus eventos
Se define con	`Kixo.track(name, { ... })`	`Kixo.setUserProperty(key, value)`
Ejemplos	`source`, `screen`, `post_id`, `amount_cents`	`plan`, `vip`, `signup_cohort`, `lifetime_orders`
Impulsa	Filtros por paso del embudo, desgloses y distribuciones	Segmentación, targeting de audiencias y elegibilidad de campañas

Consejo

Regla práctica: si el valor puede variar entre dos eventos del mismo usuario (qué del post, qué de origen), es una propiedad de evento. Si es un dato del usuario que se mantiene independientemente de la acción (su plan, si es VIP), es una propiedad de usuario. Pon source en el evento; pon plan en el usuario.

Incluye siempre un ID de entidad estable

Pasa un ID estable del objeto sobre el que actúa la acción: post_id, video_id, order_id. Sin él puedes contar cuántos posts se han abierto, pero no agrupar, deduplicar ni encadenar eventos sobre el mismo post mismo. Un embudo como búsqueda → abrir-desde-búsqueda → me_gusta solo refleja un recorrido de usuario coherente cuando cada paso incluye la propiedad que conecta unos pasos con otros.

Ejemplo completo: búsqueda → abrir → me gusta

Imagina que quieres saber cuántos usuarios búsqueda, luego abrir un post desde los resultados de búsqueda y después darle a me gusta. Son tres eventos, pero el contexto «desde búsqueda» es una propiedad de source en post_opened, no un evento aparte:

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

Así, tu embudo filtra el paso 2 (y el paso 3) por source = "search": una sola condición sobre una propiedad, sin ir alternando nombres de evento. Estas son las llamadas exactas del SDK en 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 al usuario en su lugar

Si «ha dado like a un post desde búsqueda» es un rasgo duradero por el que quieres segmentar, y no solo una señal por evento, define una propiedad de usuario después de la acción: Kixo.setUserProperty("liked_from_search", true). Así, el explorador de audiencias y la elegibilidad de campañas pueden dirigirse directamente a esos usuarios.

Deja que la AI lo diseñe por ti

En el chat del dashboard de Kixo, describe en lenguaje natural lo que quieres medir —«registrar posts abiertos desde búsqueda y después marcados con like»— y el asistente te devuelve los eventos, las propiedades y los fragmentos listos para copiar y pegar en las tres plataformas. Además, y te indica qué eventos ya están llegando a tu proyecto y cuáles aún requieren trabajo en el SDK. Aplica exactamente el patrón de esta página.

Consulta también Referencia de eventos para ver los once nombres de evento canónicos que Kixo reconoce automáticamente, y las guías del SDK de Web, iOS y Android.