Проследяване на действия в контекст

Най-важното решение при инструментирането е как именувате събитията и къде поставяте контекста. Ако го направите правилно, едно събитие отговаря на десетина въпроса; ако сгрешите, каталогът ви се раздува до стотици почти еднакви имена, които никоя фуния не може да подреди. Това ръководство описва каноничния модел на 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. Разпознаването и съпоставянето с речника не различават малки и главни букви, но ако се придържате към една форма, фуниите остават чисти.

Свойства на събитията и потребителски свойства

Другата половина от решението е къде се съхранява дадена стойност.

	Свойство на събитие	Потребителско свойство
Описва	Тази конкретна поява на действието	Потребителят — трайно, през всички негови събития
Задава се чрез	`Kixo.track(name, { ... })`	`Kixo.setUserProperty(key, value)`
Примери	`source`, `screen`, `post_id`, `amount_cents`	`plan`, `vip`, `signup_cohort`, `lifetime_orders`
Поддържа	Филтри по стъпки във фунията, разбивки, разпределения	Сегментиране, таргетиране на аудитории и допустимост за кампании

Съвет

Практическо правило: ако стойността може да е различна между две събития от един и същ потребител (кое публикация, кое източник), това е свойство на събитие. Ако е факт за потребителя, който е валиден независимо от действието (планът му, дали е VIP), това е потребителско свойство. Поставете source на събитието; поставете plan на потребителя.

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

Подайте стабилен идентификатор за обекта, който действието засяга — post_id, video_id, order_id. Без него можете да броите колко публикации са отворени, но не можете да групирате, премахвате дубликати или свързвате събития за същата същата публикация. Фуния като search → open-from-search → like се превръща в последователен потребителски път само когато всяка стъпка носи свойството, което свързва стъпките помежду им.

Пример: search → open → like

Да кажем, че искате да знаете колко потребители search, после отворят публикация от резултатите от търсене, после я харесат. Това са три събития — но контекстът „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.