Отслеживание действий в контексте

Самое важное решение при инструментировании — как называть события и куда выносить контекст. Если сделать это правильно, одно событие отвечает на десяток вопросов; если нет — каталог разрастается до сотен почти одинаковых имён, которые не складываются в воронки. В 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` — платформа уже автоматически добавляется в каждое событие
`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. Детектор и сопоставление со словарём не чувствительны к регистру, но единая форма keeps funnels clean.

Свойства событий и пользователей

Вторая часть решения — понять, где хранить это значение.

	Свойство события	Свойство пользователя
Описывает	Этот конкретный случай действия	Характеристика самого пользователя, общая для всех его событий
Задаётся через	`Kixo.track(name, { ... })`	`Kixo.setUserProperty(key, value)`
Примеры	`source`, `screen`, `post_id`, `amount_cents`	`plan`, `vip`, `signup_cohort`, `lifetime_orders`
Что можно анализировать	Фильтры по шагам воронки, разбиения, распределения	Сегментация, таргетинг аудиторий, право на участие в кампаниях

Совет

Простое правило: если значение может отличаться у двух событий одного пользователя, например который пост или который источник, это свойство события. Если это характеристика пользователя, не зависящая от конкретного действия, например его тариф или статус VIP, это свойство пользователя. source передавайте в событии, а plan — в профиле пользователя.

Всегда передавайте стабильный идентификатор сущности

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

Пусть схему предложит AI

В чате дашборда Kixo опишите простыми словами, что хотите измерять: «отслеживать посты, открытые из поиска и затем лайкнутые». Ассистент вернёт рекомендуемые события, свойства и готовые фрагменты кода для всех трёх платформ, а и покажет, какие события уже поступают в проект, а где ещё нужна интеграция SDK. Он применяет ровно тот же паттерн, что и на этой странице.

См. также: Справочник событий с одиннадцатью каноническими именами событий, которые Kixo распознаёт автоматически, и руководства по SDK для Веб, iOS и Android.