Событийные данные: как превратить действия клиентов в маркетинговые сигналы
Из чего состоят событийные данные
Событие описывает отдельный факт, который уже произошёл. Например: клиент открыл письмо, добавил товар в корзину или оплатил заказ. Чтобы этот факт можно было использовать, одной отметки «покупка совершена» обычно недостаточно. Записи нужен дополнительный контекст.
Состав события зависит от системы, но обычно запись содержит:
- Название или тип — например,
product_viewed,cart_updatedилиorder_paid. - Идентификатор связанного объекта — пользователя, заказа, товара или другой сущности. Идентификатор пользователя даёт возможность связать действие с профилем клиента. Для неизвестного посетителя может использоваться временный идентификатор браузера или устройства.
- Дата и время — указывают момент, когда действие произошло. Иногда отдельно фиксируется время поступления записи в систему.
- Источник — сайт, мобильное приложение, CRM, касса, email-рассылка или другая система.
- Параметры события — сведения, которые раскрывают контекст: идентификатор товара, сумма заказа, категория, адрес страницы, канал продаж, статус платежа.
- Идентификатор события — отличает отдельные записи, используется для поиска дублей и контроля обработки.
order_id, а значением — номер заказа. Такой же принцип для передачи дополнительного контекста пользовательских действий используется в Google Analytics.| Поле | Пример | Что означает |
|---|---|---|
| Название | order_paid | Заказ оплачен |
| Пользователь | client_157 | Кто совершил действие |
| Время | 2026-08-31T12:40:00Z | Когда произошла оплата |
| Источник | mobile_app | Откуда поступили данные |
| Параметры | order_id, value, currency | Номер, сумма и валюта заказа |
| ID события | evt_98421 | Идентификатор записи для контроля дублей |
Параметры выбирают под будущую задачу. Если маркетолог планирует отправлять уведомление о снижении цены просмотренного товара, в событии просмотра нужны как минимум идентификатор товара и связь с пользователем. Без них запись покажет активность, но не даст сформировать конкретное предложение.
Чем события отличаются от данных профиля
Данные профиля описывают клиента или его текущее состояние: имя, город, дату рождения, уровень программы лояльности, наличие подписки. События формируют хронологию изменений и действий.
| Данные профиля | Событийные данные |
|---|---|
| Город: Казань | Изменил город доставки |
| Статус: постоянный клиент | Перешёл на новый уровень лояльности |
| Последняя покупка: 20 августа | Оформил заказ 20 августа в 16:15 |
| Категория интереса: электроника | Трижды просмотрел смартфоны за неделю |
| Баланс: 1 500 баллов | Получил 500 баллов за покупку |
Поле «последняя покупка» отвечает на вопрос о текущем состоянии профиля. Последовательность событий показывает количество заказов, интервалы между ними, состав покупок и действия перед каждой транзакцией.
send_discount или remind_user описывают требуемое действие. Для событий точнее использовать названия вроде product_viewed, price_reduced или payment_failed, а решение об отправке сообщения задавать отдельно. Так, брошенную корзину можно определять как условие по отсутствию покупки или регистрировать как отдельное производное событие cart_abandoned.
Откуда поступают события
Источники зависят от клиентского пути и инфраструктуры компании:
- Сайт передаёт просмотры страниц и товаров, поисковые запросы, клики, добавления в корзину и заполнения форм.
- Мобильное приложение фиксирует запуск, регистрацию, использование функций, покупки и реакции на push-уведомления.
- Коммуникационные каналы регистрируют отправки, доставки, открытия или прочтения, переходы по ссылкам, отписки и ошибки доставки — в зависимости от возможностей конкретного канала.
- CRM и отдел продаж передают создание лида, смену этапа сделки, обращение клиента или результат звонка.
- Интернет-магазин, касса и платёжная система формируют данные о заказах, оплатах, возвратах и изменениях статуса.
- Программа лояльности фиксирует начисление и списание баллов, переход между уровнями и применение промокодов.
События могут передаваться пакетно по расписанию или вскоре после возникновения. Второй вариант нужен для сценариев, чувствительных ко времени: подтверждения заказа, предупреждения об ошибке платежа или реакции на брошенную корзину. При этом «в реальном времени» не всегда означает мгновенную обработку: задержка может возникнуть в источнике, очереди сообщений, при передаче данных или в системе-получателе.
Как событийные данные используют в маркетинге
Событийные данные применяют в нескольких основных задачах:
- Поведенческая сегментация. Аудиторию выделяют по действиям за определённый период: например, просмотрел категорию не менее трёх раз за семь дней, покупал товары для животных за последние три месяца, перестал открывать сообщения или зарегистрировался, но не выполнил первое целевое действие. Период принципиально важен: просмотр страницы вчера и год назад отражает разный уровень интереса. Поэтому при построении сегмента учитывают тип события, количество, параметры и давность действия.
- Автоматизация коммуникаций. Событие может запускать одно сообщение или последовательность действий. После регистрации клиент получает welcome-письмо, после оплаты — подтверждение, после изменения статуса доставки — уведомление. При этом важно различать произошедшее событие и условие, вычисляемое системой: «оплатил заказ» — событие, а «не оплатил за 30 минут» — отсутствие ожидаемого события в заданный срок.
- Персонализация. Параметры события используют в содержании сообщения: например, подставляют название просмотренного товара, номер заказа, сумму или дату записи на услугу. Контекст должен относиться к событию, которое запустило коммуникацию, иначе клиент может получить устаревшие или посторонние сведения.
- Аналитика клиентского пути. Последовательность событий формирует воронку: просмотр товара → добавление в корзину → переход к оплате → покупка. По ней находят этапы с наибольшими потерями и сравнивают поведение групп клиентов. События также используют в когортном анализе, расчёте частоты действий и оценке времени между этапами. При этом важно различать количество событий и уникальных пользователей: один клиент может открыть письмо несколько раз.
Как работать с событийными данными в Altcraft
В истории профиля Altcraft события расположены по времени и содержат связанный с действием контекст
В Altcraft триггер можно настроить на конкретное событие и дополнительно отбирать срабатывания по его параметрам
Что проверить перед сбором событий
Большое количество записей само по себе не делает аналитику точнее: избыточный сбор повышает стоимость хранения и усложняет поддержку схемы. Сначала нужно определить бизнес-вопросы и действия, которые влияют на решения.
При проектировании событийной модели стоит проверить:
- Единые правила названий. События
order_paid,paid_orderиpayment_successмогут обозначать один факт. Без общего справочника аналитика разделит их на разные действия. - Стабильные идентификаторы. Если сайт, приложение и CRM используют несвязанные ID, события одного клиента окажутся в разных профилях.
- Обязательные параметры. Для каждого типа события задают минимальный набор полей и их типы. Сумма заказа не должна попеременно приходить строкой и числом.
- Время возникновения. Для анализа поведения важен момент действия, а не только время поступления данных в хранилище.
- Защиту от дублей. Повторная отправка события покупки может исказить выручку и дважды запустить коммуникацию. Для контроля используют идентификатор события и обработку, которая не создаёт повторный результат при повторной передаче одной и той же записи.
- Мониторинг задержек и пропусков. Резкое падение количества событий может означать изменение поведения клиентов или ошибку передачи данных.
- Необходимость каждого поля. В событие передают только сведения, нужные для заявленных задач и допустимые правилами обработки данных.
Изменения в структуре нужно документировать. Если команда переименовала параметр или изменила его формат без согласования, старые сегменты, отчёты и сценарии могут перестать учитывать новые записи.
Заключение
Событийные данные фиксируют отдельные действия и изменения вместе с их контекстом. В отличие от полей профиля и агрегированных метрик, они сохраняют последовательность поведения клиента: что произошло, когда, в каком канале и с какими параметрами.
В маркетинге события используют для поведенческой сегментации, триггерных коммуникаций, персонализации и анализа клиентского пути. Надёжность этих процессов зависит от единых правил именования, корректных идентификаторов, времени событий, обязательных параметров и контроля дублей.
Читайте по теме
