Műveletek mérése kontextussal együtt

Az instrumentáció legfontosabb döntése az, hogyan nevezed el az eseményeket, és hová teszed a kontextust. Ha ezt jól csinálod, egyetlen esemény tucatnyi kérdésre választ ad; ha nem, az eseménykatalógus több száz, majdnem azonos névre esik szét, amelyeket egyetlen tölcsér sem tud összehangolni. Ez az útmutató a kanonikus Kixo-minta — ugyanaz a felépítés, amelyet az AI instrumentációs tanácsadó is javasol (suggest_instrumentation a chatben).

Minta: egy általános esemény + gazdag tulajdonságkészlet

A(z) egy esemény minden felhasználói művelethez eseményt kövesd, a kontextust pedig a(z) tulajdonságok mezőben írd le — az eseménynevet soha ne bontsd szét kontextus szerint. A keresésből megnyitott bejegyzés és a hírfolyamból megnyitott bejegyzés ugyanaz a művelet (post_opened), csak a(z) source tulajdonságuk más.

Ellenpélda

Ne ne hozz létre post_opened_from_search, post_opened_from_feed, post_opened_from_profile eseményeket. Három eseménynév három külön karbantartandó dolgot jelent, egyetlen tölcsér sem tudja őket átfogni, és egy negyedik felület bevezetése mindenhol kódmódosítást igényel. Egyetlen post_opened a source tulajdonsággal külön munka nélkül skálázódik bármennyi felületre.

Kerülendő minta (külön esemény minden kontextushoz)	Jó minta (egy esemény + tulajdonság)
`post_opened_from_search` `post_opened_from_feed`	`post_opened` ezzel: `{ source: "search" \| "feed" }`
`video_played_mobile` `video_played_web`	`video_played` — a platform automatikusan szerepel minden eseményen
`checkout_from_cart` `checkout_from_buy_now`	`cart_checked_out` ezzel: `{ source: "cart" \| "buy_now" }`

Elnevezés: snake_case, objektum + ige, múlt idő

Minden eseményt (object)_(verb) szerint nevezz el: snake_case, múlt időben — post_opened, video_played, cart_checked_out. Ugyanezt a nevet szó szerint kell használni Weben, iOS-en és Androidon is, hogy a többplatformos tölcsérek összeálljanak, és a Kixo standardesemény-felismerője egyeztetni tudja a kanonikus neveket.

Előbb az objektum, utána az ige — a katalógus áttekintésekor összetartozó eseményeket csoportosít (post_opened, post_liked, post_shared).
Múlt idő — egy esemény azt rögzíti, ami megtörtént.
snake_case — ne postOpened, és ne PostOpened. A felismerő és a névegyeztetés nem érzékeny a kis- és nagybetűkre, de az egységes forma tisztán tartja a tölcséreket.

Eseménytulajdonságok és felhasználói tulajdonságok

A döntés másik fele az, hogy hol él ez az érték.

	Eseménytulajdonság	Felhasználói tulajdonság
Leírja	A művelet egy konkrét előfordulása	A személyhez tartozik, tartósan, az összes eseményén át
Beállítás módja	`Kixo.track(name, { ... })`	`Kixo.setUserProperty(key, value)`
Példák	`source`, `screen`, `post_id`, `amount_cents`	`plan`, `vip`, `signup_cohort`, `lifetime_orders`
Alapja	Lépésenkénti tölcsérszűrők, bontások és eloszlások	Szegmentálás, közönségcélzás, kampányjogosultság

Tipp

Ökölszabály: ha ugyanannak a felhasználónak két eseménye között változhat egy érték (amely bejegyzés, amely forrás), akkor az eseménytulajdonság. Ha a felhasználóra jellemző, a művelettől független tényről van szó (milyen csomagja van, VIP-e), akkor felhasználói tulajdonság. A(z) source kerüljön az eseményre, a(z) plan pedig a felhasználóra.

Mindig adj át stabil entitásazonosítót

Adj át egy stabil azonosítót ahhoz az objektumhoz, amelyet a művelet érintett — post_id, video_id, order_id. Enélkül meg tudod számolni, hány bejegyzést nyitottak meg, de nem tudod ugyanahhoz a(z) azonos bejegyzéshez tartozó eseményeket csoportosítani, deduplikálni vagy összefűzni. Egy search → open-from-search → like típusú tölcsér csak akkor rajzol ki összefüggő felhasználói utat, ha minden lépés tartalmazza az őket összekapcsoló tulajdonságot.

Kidolgozott példa: keresés → megnyitás → kedvelés

Tegyük fel, azt szeretnéd látni, hány felhasználó keresés, aztán bejegyzés megnyitása a keresési találatokból, majd kedvelték. Ez három esemény — a „from search” kontextus viszont a(z) post_opened egyik source tulajdonsága, nem külön esemény:

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

Ezután a tölcsér 2. lépését — és a 3.-at is — a(z) source = "search" alapján szűröd: egyetlen tulajdonságfeltétel, eseménynevek zsonglőrködése nélkül. Az egyes platformok pontos SDK-hívásai:

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

A felhasználó címkézése helyette

Ha a „has liked a post from search” olyan tartós jellemző, amely alapján szegmentálni szeretnél, és nem csak egy eseményhez kötött jelzés, akkor a művelet után állíts be egy felhasználói tulajdonságot: Kixo.setUserProperty("liked_from_search", true). Így a közönségkezelő és a kampányjogosultság közvetlenül ezeket a felhasználókat tudja célozni.

Terveztesd meg az AI-val

A Kixo dashboard chatben írd le egyszerű angolsággal, mit szeretnél mérni — például: „track posts opened from search and then liked” —, és az asszisztens visszaadja az ajánlott eseményeket, tulajdonságokat, valamint a mindhárom platformra bemásolható kódrészleteket. A(z) és azt is megmutatja, mely események érkeznek már a projektedből, és mihez kell még SDK-munka. Pontosan az ezen az oldalon bemutatott mintát követi.

Lásd még: Eseményreferencia a Kixo által automatikusan felismert tizenegy kanonikus eseménynévről, valamint a platformonkénti SDK-útmutatókat: Web, iOS és Android.