Відстеження дій у контексті

Найважливіше рішення в інструментуванні — як називати події і куди виносити контекст. Якщо зробити це правильно, одна подія відповідає на десяток запитань; якщо ні — каталог розростається до сотень майже однакових назв, які жодна воронка не зведе докупи. Це канонічний патерн Kixo — саме такий підхід радить AI-помічник з інструментування (suggest_instrumentation у чаті).

Патерн: одна узагальнена подія + змістовні властивості

Відстежуйте одна подія на одну дію користувача, а контекст описуйте через властивості — не розгалужуйте назву події за контекстом. Відкриття допису з пошуку і відкриття допису зі стрічки — це одна й та сама дія (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` — platform уже автоматично додається до кожної події
`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. Без нього можна порахувати, скільки дописів відкрили, але не можна групувати, дедуплікувати або пов’язувати події про той самий той самий. Воронка на кшталт пошук → відкриття з пошуку → вподобання складається в цілісний шлях користувача лише тоді, коли кожен крок містить властивість, що пов’язує ці кроки між собою.

Приклад: пошук → відкриття → вподобання

Припустімо, ви хочете знати, скільки користувачів пошук, потім відкрили допис із результатів пошуку, а потім вподобали його. Це три події — але контекст "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). Тоді оглядач аудиторій і правила відповідності для кампаній зможуть напряму націлюватися на таких користувачів.

Нехай AI спроєктує це за вас

У чаті дашборда Kixo опишіть звичайною англійською, що саме хочете вимірювати — "track posts opened from search and then liked" — і помічник поверне рекомендовані події, властивості та готові фрагменти коду для всіх трьох платформ. і покаже, які події вже надходять у ваш проєкт, а для яких ще потрібна інтеграція SDK. Він застосовує той самий підхід, що описаний на цій сторінці.

Див. також Довідник подій з одинадцятьма канонічними назвами подій, які Kixo розпізнає автоматично, і SDK-гайди для Веб, iOS та Android.