Следење дејства во контекст

Најважната одлука при инструментaција е како ги именувате настаните и каде го сместувате контекстот. Ако ја донесете правилно, еден настан одговара на десетина прашања; ако ја утнете, каталогот се распаѓа на стотици речиси исти имиња што ниедна инка не може да ги порамни. Овој водич е канонскиот образец на Kixo — истиот дизајн што го препорачува AI советникот за инструментaција (suggest_instrumentation во chat).

Образецот: еден општ настан + богати својства

Следете еден настан за секое корисничко дејство и опишете го контекстот со својства — никогаш не го раздвојувајте името на настанот по контекст. Објава отворена од пребарување и објава отворена од feed се истото дејство (post_opened) со различно својство source.

Антиобразец

Не не создавајте post_opened_from_search, post_opened_from_feed, post_opened_from_profile. Три имиња на настани значат три работи за одржување, ниедна инка не може да ги опфати сите, а додавање четврта површина значи промена во кодот насекаде. Еден post_opened со source се проширува на кој било број површини без дополнителна работа.

Не правете вака (посебен настан по контекст)	Правете вака (еден настан + едно својство)
`post_opened_from_search` `post_opened_from_feed`	`post_opened` со `{ source: "search" \| "feed" }`
`video_played_mobile` `video_played_web`	`video_played` — платформата веќе автоматски се додава на секој настан
`checkout_from_cart` `checkout_from_buy_now`	`cart_checked_out` со `{ source: "cart" \| "buy_now" }`

Именување: snake_case (object)(verb), минато време

Именувајте го секој настан (object)_(verb) во snake_case, во минато време — post_opened, video_played, cart_checked_out. Истото име мора дословно да се користи на Web, iOS и Android за инките преку повеќе платформи да се порамнат, и за детекторот на стандардни настани на Kixo да може да ги препознае канонските имиња.

Прво објектот, потоа глаголот — ги групира сродните настани додека го прелистувате каталогот (post_opened, post_liked, post_shared).
Минато време — настан бележи нешто што се случило.
snake_case — не postOpened, не PostOpened. Детекторот и совпаѓањето со речникот не разликуваат големи и мали букви, но една единствена форма ги одржува инките чисти.

Својства на настани наспроти својства на корисници

Другата половина од одлуката е каде живее една вредност.

	Својство на настан	Својство на корисник
Опишува	Оваа поединечна појава на дејството	Лицето, трајно низ сите негови настани
Се поставува со	`Kixo.track(name, { ... })`	`Kixo.setUserProperty(key, value)`
Примери	`source`, `screen`, `post_id`, `amount_cents`	`plan`, `vip`, `signup_cohort`, `lifetime_orders`
Овозможува	Филтри по чекор во инка, расчленувања, распределби	Сегментација, таргетирање публики, подобност за кампањи

Совет

Практично правило: ако вредноста може да се разликува меѓу два настани од ист корисник (кое објава, кое извор), тогаш е својство на настан. Ако е факт за корисникот што важи без оглед на дејството (неговиот план, дали е VIP), тогаш е својство на корисник. Ставете source на настанот; ставете plan на корисникот.

Секогаш праќајте стабилен ID на ентитетот

Проследете стабилен ID за објектот што го засега дејството — post_id, video_id, order_id. Без него можете да изброите колку објави се отворени, но не можете да групирате, дедуплицирате или поврзувате настани за истата истиот објава. Инка како search → open-from-search → like дава јасно корисничко патување само кога секој чекор го носи својството што ги врзува чекорите заедно.

Разработен пример: search → open → like

Да речеме дека сакате да знаете колку корисници пребарување, потоа отвори објава од резултатите од пребарување, па потоа го лајкне. Тоа се три настани — но контекстот „from search“ е source својство на post_opened, а не посебен настан:

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

Потоа вашата инка го филтрира чекор 2 (и чекор 3) според source = "search" — едно својство како услов, без жонглирање со имиња на настани. Точните SDK повици за секоја платформа:

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

Наместо тоа, означување на корисникот

Ако „has liked a post from search“ е трајна особина по која сакате да сегментирате (а не само сигнал на поединечен настан), поставете својство на корисник по дејството: Kixo.setUserProperty("liked_from_search", true). Потоа audience explorer и условите за подобност за кампања можат директно да ги таргетираат тие корисници.

Нека AI го осмисли наместо вас

Во chat во Kixo dashboard, опишете на обичен англиски што сакате да мерите — „track posts opened from search and then liked“ — и асистентот ќе ви врати препорачани настани, својства и copy-paste исечоци за сите три платформи, а и ќе ви каже кои настани веќе пристигнуваат за вашиот проект и што сè уште бара работа во SDK. Го применува токму образецот од оваа страница.

Видете и: Референца за настани за единаесетте канонски имиња на настани што Kixo ги препознава автоматски, како и SDK водичите по платформа за Web, iOS и Android.