Tracciare le azioni nel loro contesto

La decisione di strumentazione più importante è come nomini gli eventi e dove metti il contesto. Se la prendi giusta, un solo evento risponde a una dozzina di domande; se sbagli, il catalogo esplode in centinaia di nomi quasi duplicati che nessun funnel riesce ad allineare. Questa guida presenta lo schema canonico di Kixo: lo stesso design consigliato dall'assistente AI per la strumentazione (suggest_instrumentation in chat).

Lo schema: un evento generalizzato + proprietà ricche

Traccia un evento per azione utente e descrivi il contesto con proprietà; non duplicare mai il nome dell'evento in base al contesto. Un post aperto dalla ricerca e un post aperto dal feed sono la stessa azione (post_opened) con una proprietà source diversa.

Anti-pattern

Non non creare post_opened_from_search, post_opened_from_feed, post_opened_from_profile. Tre nomi evento significano tre varianti da mantenere, nessun funnel unico può attraversarle tutte e aggiungere una quarta superficie richiede modifiche al codice ovunque. Un solo post_opened con source scala gratis a qualunque numero di superfici.

Non così (un evento per contesto)	Fai così (un evento + una proprietà)
`post_opened_from_search` `post_opened_from_feed`	`post_opened` con `{ source: "search" \| "feed" }`
`video_played_mobile` `video_played_web`	`video_played` — la piattaforma è già presente automaticamente in ogni evento
`checkout_from_cart` `checkout_from_buy_now`	`cart_checked_out` con `{ source: "cart" \| "buy_now" }`

Nomi: snake_case, oggetto prima e verbo al passato

Dai a ogni evento un nome (object)_(verb) in snake_case, al passato — post_opened, video_played, cart_checked_out. Lo stesso nome va usato identico su Web, iOS e Android, così i funnel multipiattaforma restano allineati e il rilevatore di eventi standard di Kixo può riconoscere i nomi canonici.

Prima l'oggetto, poi il verbo — raggruppa eventi correlati quando sfogli il catalogo (post_opened, post_liked, post_shared).
Passato — un evento registra qualcosa che è successo a successo.
snake_case — non postOpened, non PostOpened. Il rilevatore e il matcher del vocabolario non distinguono tra maiuscole e minuscole, ma convergere su una sola forma mantiene puliti i funnel.

Proprietà evento e proprietà utente

L'altra metà della decisione è dove vive un valore.

	Proprietà evento	Proprietà utente
Descrive	Questa singola occorrenza dell'azione	La persona, in modo stabile attraverso tutti i suoi eventi
Impostata con	`Kixo.track(name, { ... })`	`Kixo.setUserProperty(key, value)`
Esempi	`source`, `screen`, `post_id`, `amount_cents`	`plan`, `vip`, `signup_cohort`, `lifetime_orders`
Supporta	Filtri per step del funnel, breakdown, distribuzioni	Segmentazione, targeting del pubblico, idoneità alle campagne

Suggerimento

Regola pratica: se il valore può cambiare tra due eventi dello stesso utente (quale post, quale source), è una proprietà evento. Se invece descrive l'utente indipendentemente dall'azione (il piano, se è VIP), è una proprietà utente. Metti source sull'evento; metti plan sull'utente.

Includi sempre un ID entità stabile

Passa un ID stabile per l'oggetto toccato dall'azione — post_id, video_id, order_id. Senza questo dato puoi contare quanti post sono stati aperti, ma non puoi raggruppare, deduplicare o concatenare eventi relativi allo stesso post. Un funnel come ricerca → apertura-da-ricerca → like restituisce un percorso utente coerente solo quando ogni passaggio include la proprietà che collega gli step.

Esempio pratico: ricerca → apertura → like

Mettiamo che tu voglia sapere quanti utenti ricerca, poi aprono un post dai risultati di ricerca, poi mettono like. Gli eventi sono tre, ma il contesto "from search" è una proprietà source di post_opened, non un evento separato:

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

A quel punto il funnel filtra il passaggio 2 (e il 3) su source = "search": un solo predicato su proprietà, senza dover gestire nomi evento diversi. Ecco le chiamate SDK esatte per ogni piattaforma:

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

Etichettare invece l'utente

Se "has liked a post from search" è una caratteristica stabile su cui vuoi segmentare, e non solo un segnale del singolo evento, imposta una proprietà utente dopo l'azione: Kixo.setUserProperty("liked_from_search", true). Così l'esploratore del pubblico e l'idoneità alle campagne possono colpire direttamente quegli utenti.

Lascia che l'AI lo progetti per te

Nella chat della dashboard di Kixo, descrivi in linguaggio naturale che cosa vuoi misurare — "track posts opened from search and then liked" — e l'assistente restituisce gli eventi consigliati, le proprietà e gli snippet da copiare per tutte e tre le piattaforme; e ti dice quali eventi stanno già arrivando nel progetto e quali richiedono ancora lavoro sull'SDK. Applica esattamente lo schema di questa pagina.

Vedi anche Riferimento degli eventi per gli undici nomi evento canonici che Kixo riconosce automaticamente, e le guide SDK per Web, iOS e Android.