Urmărirea acțiunilor în context

Cea mai importantă decizie de instrumentare este cum denumești evenimentele și unde pui contextul. Dacă o iei bine, un singur eveniment răspunde la o duzină de întrebări; dacă o iei prost, catalogul explodează în sute de nume aproape duplicate, pe care niciun funnel nu le mai poate alinia. Acest ghid este modelul canonic Kixo — același design pe care îl recomandă și consilierul AI pentru instrumentare (suggest_instrumentation în chat).

Modelul: un eveniment general + proprietăți bogate

Urmărește un eveniment pentru fiecare acțiune a utilizatorului și descrie contextul prin proprietăți — nu separa niciodată numele evenimentului în funcție de context. O postare deschisă din căutare și una deschisă din feed sunt aceeași acțiune (post_opened), cu o proprietate source diferită.

Anti-pattern

Nu nu crea post_opened_from_search, post_opened_from_feed, post_opened_from_profile. Trei nume de evenimente înseamnă trei lucruri de întreținut, niciun funnel nu le poate acoperi pe toate, iar adăugarea unei a patra suprafețe înseamnă modificări de cod peste tot. Un singur post_opened cu source scalează natural la oricâte suprafețe, fără cost suplimentar.

Nu (un eveniment pentru fiecare context)	Da (un eveniment + o proprietate)
`post_opened_from_search` `post_opened_from_feed`	`post_opened` cu `{ source: "search" \| "feed" }`
`video_played_mobile` `video_played_web`	`video_played` — platforma este deja adăugată automat la fiecare eveniment
`checkout_from_cart` `checkout_from_buy_now`	`cart_checked_out` cu `{ source: "cart" \| "buy_now" }`

Denumire: snake_case (obiect)(verb), la timpul trecut

Denumește fiecare eveniment (object)_(verb) în snake_case, la timpul trecut — post_opened, video_played, cart_checked_out. Același nume trebuie folosit identic pe Web, iOS și Android, ca funnelurile cross-platform să se alinieze și detectorul Kixo de evenimente standard să poată recunoaște denumirile canonice.

Mai întâi obiectul, apoi verbul — grupează evenimentele înrudite când parcurgi catalogul (post_opened, post_liked, post_shared).
Timpul trecut — un eveniment înregistrează ceva ce s-a întâmplat.
snake_case — nu postOpened, nu PostOpened. Detectorul și potrivirea vocabularului ignoră literele mari și mici, dar folosirea unei singure forme păstrează funnelurile curate.

Proprietăți de eveniment vs. proprietăți de utilizator

Cealaltă jumătate a deciziei este unde locul în care se află o valoare.

	Proprietate de eveniment	Proprietate de utilizator
Descrie	Această apariție a acțiunii	Persoana, în mod persistent, în toate evenimentele ei
Se setează cu	`Kixo.track(name, { ... })`	`Kixo.setUserProperty(key, value)`
Exemple	`source`, `screen`, `post_id`, `amount_cents`	`plan`, `vip`, `signup_cohort`, `lifetime_orders`
Susține	Filtre pe pașii funnelului, defalcări, distribuții	Segmentare, țintirea audienței, eligibilitate pentru campanii

Sfat

Regula practică: dacă valoarea poate diferi între două evenimente ale aceluiași utilizator (postarea care, sursa care), este o proprietate de eveniment. Dacă este un fapt despre utilizator care rămâne valabil indiferent de acțiune (planul lui, dacă este VIP), este o proprietate de utilizator. Pune source pe eveniment; pune plan pe utilizator.

Include întotdeauna un ID stabil al entității

Trimite un ID stabil pentru obiectul asupra căruia s-a făcut acțiunea — post_id, video_id, order_id. Fără el poți număra câte postări au fost deschise, dar nu poți grupa, deduplica sau lega între ele evenimentele despre aceeași postare aceeași. Un funnel precum căutare → deschidere-din-căutare → apreciere devine un parcurs coerent al utilizatorului doar dacă fiecare pas include proprietatea care leagă pașii între ei.

Exemplu concret: search → open → like

Să zicem că vrei să afli câți utilizatori fac căutare, apoi deschid o postare din rezultatele căutării, apoi dau like. Sunt trei evenimente — dar contextul „din căutare” este o proprietate source pe post_opened, nu un eveniment separat:

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

Apoi filtrezi pasul 2 (și pasul 3) din funnel după source = "search" — o singură condiție pe proprietate, fără să jonglezi cu numele evenimentelor. Mai jos sunt apelurile SDK exacte pentru fiecare platformă:

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

Etichetarea utilizatorului în schimb

Dacă „a dat like unei postări din căutare” este o trăsătură persistentă pe care vrei să segmentezi utilizatorii, nu doar un semnal la nivel de eveniment, setează o proprietate de utilizator după acțiune: Kixo.setUserProperty("liked_from_search", true). Astfel, exploratorul de audiențe și eligibilitatea pentru campanii îi pot viza direct pe acei utilizatori.

Lasă AI să-l proiecteze pentru tine

În chatul din dashboardul Kixo, descrii în engleză simplă ce vrei să măsori — „track posts opened from search and then liked” — iar asistentul îți returnează evenimentele recomandate, proprietățile și fragmentele gata de copiat pentru toate cele trei platforme; și îți spune ce evenimente ajung deja pentru proiectul tău și ce mai necesită lucru în SDK. Aplică exact modelul de pe această pagină.

Vezi și Referință pentru evenimente pentru cele unsprezece denumiri canonice de evenimente pe care Kixo le recunoaște automat, plus ghidurile SDK pentru Web, iOS și Android.