События клиентов для поведенческой сегментации
Фиксируйте, что клиент только что сделал — повышение уровня, платёж, неделю тишины — именно в тот момент, когда это произошло. Сценарии реагируют в реальном времени, а сегменты могут спрашивать не только «что верно сейчас», но и как часто и как давно.
Одни факты — это цифры, другие — моменты
Знать текущий уровень клиента — это факт. Знать, что он отменил подписку час назад, — факт другого рода. Это произошло в конкретный момент, и реагировать стоит именно в этот момент, а не при следующей плановой отправке.
Для этого и существует событие. Тег говорит, что верно про кого-то прямо сейчас. Событие говорит, что он только что сделал.
Что может хранить событие
Вы описываете событие один раз: его имя, данные, которые оно несёт. Затем отправляете его каждый раз при наступлении — через SDK или API. Дальше оно питает триггеры сценариев и фильтры сегментов из одного и того же реестра.
| Стандартные события | Пользовательские события | |
|---|---|---|
| Источник | Встроенные: PW_InAppPurchase, Log out, Payment method changed и другие задокументированные события | Определяются на уровне аккаунта — в Control Panel или через API createEvent |
| Атрибуты | До 100, типизированные | До 100, типизированные |
| Типы | Integer, String, List, Date, Boolean, Price | Те же 6 типов. Нет типа Version, в отличие от тегов |
| Retention | Настраивается по типу события | Настраивается по типу события |
Привяжите revenue и retention прямо к событию
Атрибут типа Price в паре с флагом trackRevenue напрямую связывает событие с revenue-отчётностью. Retention настраивается по каждому типу события, а не один раз для всего аккаунта: событие о платеже может храниться год, пока низкоценное событие вовлечённости устаревает за месяц.
Как часто, и как давно
Профиль, построенный только на текущем состоянии, говорит, кто есть кто. Он не говорит, что с этим человеком только что произошло. Поведенческая сегментация, которая умеет фильтровать только «верно сейчас», не отличит клиента, сделавшего что-то три раза за неделю, от того, кто сделал это один раз полгода назад.
События позволяют сегменту спрашивать, как часто и как давно, и формулировать «не делал X 14 дней» так же точно, как «делал X». Именно это делает единый профиль клиента пригодным для действия.
Как это работает
-
Определите событие, если хотите контролировать его
В Control Panel (Audience → Events → Create Event) или через API createEvent: имя, описание, до 100 типизированных атрибутов, опциональный флаг trackRevenue и окно retention. Пропустите этот шаг — и postEvent создаст событие при первой отправке, определив типы атрибутов по payload.
-
Отправьте его из приложения
В момент, когда это произошло, через postEvent SDK (iOS, Android, Web) или REST-эндпоинт /postEvent.
-
Используйте
Как фильтр сегмента (количество плюс временное окно), как триггер входа в сценарий, или как условие ветвления на canvas.
Шаги один и три — no-code, в Control Panel. Шаг два требует разработчика для добавления вызова SDK или API.
Одно событие читают три разные функции
Событие, сработавшее при оформлении заказа, может завести пользователя в win-back сценарий через триггерный вход, разветвить этот сценарий по собственному атрибуту суммы корзины из события через Condition split и отметить сценарий как успешный через цели конверсии. Три продукта читают одно и то же событие в момент его поступления.
Создано, чтобы питать всю остальную платформу
Триггерный вход читает событие, чтобы запустить сценарий. Condition split читает его атрибуты, чтобы направить ветвление. Цели конверсии читают его, чтобы закрыть сценарий как выигранный. Одно событие, три задачи, без переопределений.
Для чего нужны события
| Задача | Индустрии | Что срабатывает |
|---|---|---|
| Реактивные сценарии | Мобильные игры, e-commerce, FinTech | Level-up, брошенная корзина, крупная транзакция: сценарий реагирует в той же сессии |
| Сегменты по частоте и давности | Любая | «Делал X три раза и более за 30 дней» или «не делал X 14 дней» |
| События, привязанные к revenue | Мобильные игры, e-commerce | Атрибут Price плюс trackRevenue, напрямую связанный с revenue-отчётностью |
| Ступени retention и неактивности | Мобильные игры, подписочные приложения | inactivity_7, inactivity_30, d7_retention: ступенчатая реактивация вместо одного флага |
Как проверить, что это работает
Статистика Events & Tags показывает, сколько раз сработало каждое событие и у скольких уникальных пользователей — за любое выбранное окно. Это вид, который стоит проверить перед тем, как доверять сценарию или сегменту, построенному на событии, которое вы только что добавили.
Что важно учитывать
Превратите действия клиентов в то, что происходит дальше
Тег говорит, кто есть кто. Событие говорит, что он только что сделал, — и именно на это сценарий или сегмент может отреагировать в тот же момент, когда это происходит.
Другие продукты
Шлюз на уровне SDK для iOS, Android, Unity и Web и встроенный double opt-in для подписных форм. Данные не собираются до согласия пользователя.
Привяжите текст, числа, дату, валюту и версию приложения к устройству или пользователю, затем используйте это для сегментов, ветвления сценариев и персонализации сообщений.
Запускайте сценарий в момент события: условия по атрибутам, контроль повторного входа и несколько сессий на пользователя по order_id или product_id.
Направляйте пользователя по одной из до 10 веток на основе сегмента, тега или атрибута события без ожидания, с гарантированной веткой All other users.
Задайте событие, которое означает успех сценария, учитывайте поздние конверсии до 30 дней после выхода и завершайте цепочку сразу после конверсии пользователя.
Повышайте вовлечённость с помощью сегментации в реальном времени. Создавайте динамические аудитории, запускайте кампании в нужный момент и максимизируйте конверсию.