Toimintojen seuranta kontekstissa

Instrumentoinnin tärkein yksittäinen ratkaisu on, miten nimeät tapahtumat ja mihin sijoitat kontekstin. Kun tämä menee oikein, yksi tapahtuma vastaa tusinaan kysymykseen. Kun se menee pieleen, tapahtumaluettelo paisuu sadoiksi lähes päällekkäisiksi nimiksi, joita mikään suppilo ei saa linjaan. Tämä opas kuvaa Kixo:n kanonisen mallin — saman rakenteen, jota AI-instrumentointineuvoja (suggest_instrumentation chatissa) suosittelee.

Periaate: yksi yleinen tapahtuma + kuvaavat ominaisuudet

Seuraa tapahtumaa yksi tapahtuma per käyttäjän toiminto ja kuvaa konteksti ominaisuudella ominaisuudet — älä koskaan jaa tapahtumanimeä eri versioihin kontekstin perusteella. Hausta avattu julkaisu ja syötteestä avattu julkaisu ovat sama toiminto (post_opened); vain ominaisuuden source arvo muuttuu.

Vältettävä malli

Älä ei: luo post_opened_from_search, post_opened_from_feed ja post_opened_from_profile. Kolme tapahtumanimeä tarkoittaa kolmea ylläpidettävää asiaa, mikään yksittäinen suppilo ei voi kattaa niitä yhtenä kokonaisuutena, ja neljännen pinnan lisääminen vaatii koodimuutoksen kaikkialle. Yksi post_opened, jossa source, skaalautuu ilman lisätyötä mille tahansa määrälle pintoja.

Älä tee näin (tapahtuma per konteksti)	Tee näin (yksi tapahtuma + ominaisuus)
`post_opened_from_search` `post_opened_from_feed`	`post_opened`, jossa `{ source: "search" \| "feed" }`
`video_played_mobile` `video_played_web`	`video_played` — platform tulee automaattisesti mukaan jokaiseen tapahtumaan
`checkout_from_cart` `checkout_from_buy_now`	`cart_checked_out`, jossa `{ source: "cart" \| "buy_now" }`

Nimeäminen: snake_case, objekti ensin, verbi toisena, mennyt aikamuoto

Nimeä jokainen tapahtuma (object)_(verb)-muodossa snake_case ja menneessä aikamuodossa — post_opened, video_played, cart_checked_out. Samaa nimeä on käytettävä täsmälleen samassa muodossa Webissä, iOS:ssä ja Androidissa, jotta alustojen väliset suppilot asettuvat oikein ja Kixo:n vakiotapahtumien tunnistin löytää kanoniset nimet.

Objekti ensin, verbi toisena — ryhmittelee toisiinsa liittyvät tapahtumat, kun selaat luetteloa (post_opened, post_liked, post_shared).
Mennyt aikamuoto — tapahtuma kirjaa jotain, joka tapahtui.
snake_case — ei postOpened eikä PostOpened. Tunnistin ja sanastotäsmäys eivät huomioi kirjainkokoa, mutta yksi vakiintunut muoto pitää suppilot siisteinä.

Tapahtumaominaisuudet vs. käyttäjäominaisuudet

Päätöksen toinen puoli on se, jossa arvo kuuluu.

	Tapahtumaominaisuus	Käyttäjäominaisuus
Kuvaa	Tämä yksittäinen toiminnon suoritus	Henkilö pysyvästi kaikissa tapahtumissaan
Asetetaan näin	`Kixo.track(name, { ... })`	`Kixo.setUserProperty(key, value)`
Esimerkit	`source`, `screen`, `post_id`, `amount_cents`	`plan`, `vip`, `signup_cohort`, `lifetime_orders`
Käyttökohteet	Vaihekohtaiset suppilosuodattimet, jaottelut ja jakaumat	Segmentointi, yleisökohdistus, kampanjakelpoisuus

Vinkki

Nyrkkisääntö: jos arvo voi vaihdella saman käyttäjän kahden tapahtuman välillä (joka julkaisu, joka lähde), se on tapahtumaominaisuus. Jos arvo kuvaa käyttäjää riippumatta toiminnosta (esimerkiksi tilaus tai VIP-status), se on käyttäjäominaisuus. Laita source tapahtumaan ja plan käyttäjälle.

Liitä mukaan aina vakaa entiteettitunniste

Välitä vakaa tunniste sille objektille, johon toiminto kohdistui — post_id, video_id, order_id. Ilman sitä voit laskea, montako julkaisua avattiin, mutta et voi ryhmitellä, deduplikoida tai ketjuttaa saman sama-julkaisun tapahtumia. Suppilo kuten haku → avaus hausta → tykkäys muodostaa yhtenäisen käyttäjäpolun vain, jos jokaisessa vaiheessa on mukana ominaisuus, joka sitoo vaiheet yhteen.

Esimerkki: search → open → like

Oletetaan, että haluat tietää, kuinka moni käyttäjä haku, sitten avaa julkaisun hakutuloksista ja sitten tykkää siitä. Tapahtumia on kolme, mutta "from search" on tapahtuman post_opened source-ominaisuus, ei erillinen tapahtuma:

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

Silloin suppilon vaihe 2:n (ja vaiheen 3:n) voi suodattaa arvolla source = "search" — yksi ominaisuusehto, ei tapahtumanimien kikkailua. Täsmälliset SDK-kutsut eri alustoille:

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

Käyttäjän merkitseminen sen sijaan

Jos "has liked a post from search" on pysyvä ominaisuus, jonka perusteella haluat segmentoida etkä vain yksittäisen tapahtuman signaali, aseta toiminnon jälkeen käyttäjäominaisuus: Kixo.setUserProperty("liked_from_search", true). Sen jälkeen yleisöjen selaimessa ja kampanjakelpoisuudessa nämä käyttäjät voidaan kohdistaa suoraan.

Anna AI:n suunnitella se puolestasi

Kuvaile Kixo-dashboardin chatissa selkeällä englannilla, mitä haluat mitata — "track posts opened from search and then liked" — niin avustaja palauttaa suositellut tapahtumat, ominaisuudet ja kopioitavat koodikatkelmat kaikille kolmelle alustalle. ja kertoo, mitkä tapahtumat tulevat projektiisi jo nyt ja mikä vaatii vielä SDK-työtä. Se noudattaa täsmälleen tämän sivun mallia.

Katso myös: Tapahtumaviite, jossa on ne yksitoista kanonista tapahtumanimeä, jotka Kixo tunnistaa automaattisesti, sekä alustakohtaiset SDK-oppaat: Web, iOS ja Android.