Сколько событий достаточно для старта?

Боевой минимум — 8–10: регистрация, просмотр товара, просмотр категории, добавление в корзину, начало оформления, заказ, оплата, отмена. Этого хватит на шесть-семь сценариев. Остальное подключайте итерациями по мере роста выручки с триггеров.

Что делать, если своих разработчиков нет?

Часть поведенческих событий заводится через Google Tag Manager и dataLayer без полноценной разработки, часть отдают вебхуки самой платформы магазина. Заказы все равно лучше передавать серверно — тут экономия выйдет боком.

Какие события дают больше всего выручки?

В большинстве проектов лидируют брошенная корзина, незавершенное оформление и возврат товара в наличие. Точный расклад зависит от ассортимента и цикла покупки: в магазине с долгим выбором сильнее работают просмотры, в магазине повторных покупок — кросс-сейл после заказа.

Как проверить, что события доходят до Mindbox?

Заведите тестовую учетную запись, пройдите полный путь покупателя — от просмотра категории до заказа — и откройте лог операций. Все, что вы делали на сайте, должно появиться в логе с корректными параметрами. Пропавшие или отклоненные события и есть ваш список доработок.

Ecommerce-события для рассылок: полный чек-лист для триггерных сценариев

Типичная картина на аудите: Mindbox внедрен полтора года назад, триггеров запущено четыре — приветственная цепочка, брошенная корзина, письмо после заказа, реактивация. Доля триггерной выручки держится на уровне 5–7% от email-канала, и команда считает, что это потолок платформы.

Потолок почти всегда упирается в данные. Сайт передает в CRM крошечный набор событий: регистрацию, заказ, иногда добавление в корзину. Все остальное поведение клиента — просмотры, поисковые запросы, избранное, отмены — происходит мимо CRM, и реагировать на него просто нечем. Ниже — полный регистр ecommerce событий для рассылок, разбитый по слоям. Василина Бреусенко, CRM-маркетолог ClientCore, собирает событийные модели для e-commerce-проектов и знает, где прячутся разрывы.

Что сайт обычно передает в CRM и почему этого мало

Базовый минимум при внедрении выглядит так: идентификация пользователя, оформление заказа, добавление в корзину. На этом интеграцию считают законченной и переходят к письмам. Из 30–40 полезных событий сайта для триггеров в работе остается четыре-пять.

Последствия предсказуемые. Брошенный просмотр не запустить — CRM не знает, что человек смотрел товар. Письмо о снижении цены не отправить — цена меняется в каталоге, а событие об этом никто не передает. Реактивация стартует на 90-й день молчания, хотя клиент заснул еще на 40-й: сигнала «перестал заходить» в системе нет.

События просмотра: карточка товара, категория, поиск

Верх воронки — самый недооцененный слой. Минимальный набор:

Просмотр карточки товара — с параметрами: id, категория, бренд, цена, наличие. Запускает сценарии «брошенный просмотр», «снижение цены на то, что смотрели», «товар заканчивается».
Просмотр категории — интерес без конкретного товара. Активирует подборку лидеров категории и дожим по интересу.
Поисковый запрос — отдельно ценны запросы без результатов: человек искал и не нашел. Тут работает письмо с аналогами или обещанием сообщить о появлении.
Просмотр товара не в наличии — прямой повод предложить подписку на возврат в сток.

Норма

событие просмотра несет параметры товара: id, цену, наличие, категорию;
id товара в событии совпадает с id в товарном фиде CRM;
просмотры передаются для всех сессий, не только авторизованных.

Red flag

событие фиксирует только факт просмотра без параметров — письмо собрать не из чего;
id в событии и в фиде различаются регистром или форматом, товарные блоки в письмах пустые;
просмотр отправляется на каждый скролл страницы, лог забит дублями.

События корзины и заказа

Здесь живут деньги, поэтому и разрывов тут больше всего. Полный набор:

Добавление в корзину и удаление из корзины. Удаление почти никто не передает, а это сигнал сомнения — повод предложить отложить товар или показать похожие.
Начало оформления — человек дошел до чекаута. Отдельный, более горячий сценарий дожима.
Выбор доставки и оплаты — этап, на котором бросают чаще всего. Если событие передается, видно, кто именно упал на стоимости доставки, и можно вернуть его промокодом.
Заказ создан, оплачен, отменен, возвращен — четыре разных статуса, а не один «заказ». На отмену нужен win-back, на возврат — деликатная цепочка с заботой и заменой.

Что это запускает: каскад брошенной корзины (письмо через 30–60 минут, пуш, SMS на вторые сутки), дожим незавершенного чекаута, подтверждение заказа с кросс-сейлом, цепочки после отмены и возврата.

Когда триггеры получают полный набор событий, это видно в деньгах. В проекте для AR Fashion мы перезапустили email как систему с полноценными триггерами — и выручка триггерных рассылок выросла на 1063% (кейс).

Сигналы интереса: избранное, подписки на товар, отзывы

Этот слой собирает намерения, которые клиент озвучивает сам:

Добавление в избранное — мягкий дожим, напоминание, уведомление о скидке на товар из вишлиста.
Подписка на появление в наличии и подписка на снижение цены — человек поднял руку и сказал, чего хочет.
Повторный просмотр одного товара несколько раз за неделю — собирается из потока просмотров, работает как усилитель: дожим запускается не после первого визита, а после третьего.
Отзыв оставлен / не оставлен после доставки — запрос отзыва и бонус за него, а по негативному отзыву — сценарий для службы заботы.

События жизненного цикла клиента

Последний слой — то, что происходит с самим клиентом:

Регистрация и подписка на рассылку — передавать раздельно. Подписчик без аккаунта и владелец личного кабинета — разные стартовые цепочки.
Первый заказ — отдельное событие. Запускает онбординг в программу лояльности и сценарий доведения до второй покупки.
Второй заказ — клиент закрепился, пора переводить его в другой режим коммуникации.
День рождения и годовщина регистрации — классика, которая до сих пор приносит заказы, если поздравление не сводится к промокоду.
Отсутствие событий — самый недооцененный пункт. Молчание длиной в N дней (без визитов, без заказов) тоже считается событием: на нем строится вся линейка засыпания и реактивации. Порог считается от цикла покупки конкретного магазина, а не по шаблонным 90 дням.

Mindbox: как настроить события и проверить, что они доходят

В Mindbox события — это операции. Схема, которая работает на практике: поведенческие события (просмотры, поиск, корзина) идут через JS SDK на сайте, а заказы и их статусы — через серверный API. Заказы с фронта отправлять нельзя: блокировщики рекламы режут часть вызовов, и в CRM теряется до 10% транзакций.

Порядок действий: зарегистрировать операции в админке, договориться с разработкой об именовании и обязательных параметрах, поднять передачу, пройти путь покупателя тестовой учеткой и проверить лог операций. В логе видно, какое событие пришло, с какими параметрами и почему отклонено.

Норма

заказы и оплаты идут с сервера, поведение — с фронта;
id товаров в событиях сверены с фидом;
лог операций проверяется еженедельно, это 15 минут.

Red flag

о поломке узнают по падению триггерной выручки в конце месяца;
событие «заказ» одно на все статусы, отмена и возврат невидимы;
событие уходит, но не проходит валидацию — и об этом никто не знает.

Когда событийная модель настроена целиком, эффект суммируется. В проекте для «Браво-Оптики» мы внедрили Mindbox, подняли email-канал и запустили каскадные цепочки — за 10 месяцев это дало +14,62% к выручке от CRM-направления (кейс).

Чек-лист самопроверки перед запуском

Пройдитесь по списку и отметьте, что реально передается:

Поведение: просмотр товара с параметрами, просмотр категории, поисковый запрос, добавление и удаление из корзины, избранное.

Заказ: начало оформления, выбор доставки, создание, оплата, отмена, возврат.

Клиент: регистрация, подписка на рассылку, первый и второй заказ, день рождения, таймер молчания.

Подписки на товар: появление в наличии, снижение цены.

Дальше три проверки. Первая — у каждого события есть сценарий: если событию нечего запускать, оно либо лишнее, либо под него не хватает триггера. Вторая — параметры полные: без цены и наличия товарный блок в письме не соберется. Третья — мониторинг: лог операций должен кто-то открывать регулярно, иначе о разрыве вы узнаете последними.