Адсочванне дзеянняў у кантэксце

Самае важнае рашэнне ў інструментаванні — як вы называеце падзеі і куды кладзяце кантэкст. Калі зрабіць гэта правільна, адна падзея адкажа на дзясятак пытанняў; калі не, каталог разрасцецца да сотняў амаль дубляваных назваў, якія ніводная варонка не зможа нармальна супаставіць. Гэта кананічны патэрн Kixo — менавіта такі дызайн раіць AI-кансультант па інструментаванні (suggest_instrumentation у чаце).

Патэрн: адна абагульненая падзея + багатыя ўласцівасці

Адсочвайце адна падзея на адно дзеянне карыстальніка, а кантэкст апісвайце праз properties — ніколі не раздзяляйце назву падзеі па кантэксце. Пост, адкрыты з пошуку, і пост, адкрыты са стужкі, — гэта адно і тое ж дзеянне (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) у 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. Без яго можна палічыць, колькі пастоў адкрылі, але нельга згрупаваць, дэдублікаваць або звязаць падзеі пра той самы той самы. Варонка накшталт пошук → адкрыццё-з-пошуку → лайк становіцца цэласным карыстальніцкім шляхам толькі тады, калі на кожным кроку ёсць уласцівасць, якая звязвае гэтыя крокі.

Прыклад: пошук → адкрыццё → лайк

Напрыклад, вы хочаце ведаць, колькі карыстальнікаў пошук, потым адкрыць пост з вынікаў пошуку, потым паставіць лайк. Гэта тры падзеі — але кантэкст «з пошуку» тут з’яўляецца ўласцівасцю 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',
});

Пазначаць замест гэтага карыстальніка

Калі «паставіў лайк посту з пошуку» — гэта ўстойлівая прыкмета, па якой вы хочаце сегментаваць карыстальнікаў, а не проста сігнал у межах адной падзеі, задайце ўласцівасць карыстальніка пасля дзеяння: Kixo.setUserProperty("liked_from_search", true). Тады агляд аўдыторыі і правілы ўдзелу ў кампаніях змогуць наўпрост нацэльвацца на такіх карыстальнікаў.

Даручыце схему AI

У чаце аналітычнай панэлі Kixo апішыце звычайнай мовай, што хочаце вымераць, напрыклад: «адсочваць пасты, адкрытыя з пошуку, а потым лайкнутыя». Памочнік верне рэкамендаваныя падзеі, уласцівасці і гатовыя фрагменты кода для ўсіх трох платформаў, а і пакажа, якія падзеі ўжо паступаюць у ваш праект, а дзе яшчэ патрэбна праца з SDK. Тут выкарыстоўваецца роўна той самы падыход, што і на гэтай старонцы.

Глядзіце таксама: Даведнік па падзеях з адзінаццаццю кананічнымі назвамі падзей, якія Kixo распазнае аўтаматычна, і кіраўніцтвы па SDK для Web, iOS і Android.