# Ecommerce-события для рассылок: полный чек-лист для триггерных сценариев > Триггеры молчат, когда сайт передает в CRM только заказ. Чек-лист ecommerce-событий для рассылок: что передавать и какой сценарий запускает каждое. **Рубрика:** Статьи **Автор:** Василина Бреусенко, CRM-маркетолог, ClientCore **Дата:** 2026-09-21 Типичная картина на аудите: Mindbox внедрен полтора года назад, триггеров запущено четыре — приветственная цепочка, брошенная корзина, письмо после заказа, реактивация. Доля триггерной выручки держится на уровне 5–7% от email-канала, и команда считает, что это потолок платформы. Потолок почти всегда упирается в данные. Сайт передает в CRM крошечный набор событий: регистрацию, заказ, иногда добавление в корзину. Все остальное поведение клиента — просмотры, поисковые запросы, избранное, отмены — происходит мимо CRM, и реагировать на него просто нечем. Ниже — полный регистр ecommerce событий для рассылок, разбитый по слоям. Василина Бреусенко, CRM-маркетолог ClientCore, собирает событийные модели для e-commerce-проектов и знает, где прячутся разрывы. > **Читайте также:** [Идентификация клиента на сайте: как склеить анонимов с базой и вернуть выручку](https://clientcore.ru/blog/articles/identifikaciya-klienta-na-sayte-kak-skleit-anonimov-s-bazoy-i-vernut-vyruchku) ## Что сайт обычно передает в CRM и почему этого мало Базовый минимум при внедрении выглядит так: идентификация пользователя, оформление заказа, добавление в корзину. На этом интеграцию считают законченной и переходят к письмам. Из 30–40 полезных событий сайта для триггеров в работе остается четыре-пять. Последствия предсказуемые. Брошенный просмотр не запустить — CRM не знает, что человек смотрел товар. Письмо о снижении цены не отправить — цена меняется в каталоге, а событие об этом никто не передает. Реактивация стартует на 90-й день молчания, хотя клиент заснул еще на 40-й: сигнала «перестал заходить» в системе нет. > На аудите fashion-ритейлера видели такое: просмотр карточки товара передавался только от авторизованных пользователей. Гости смотрели товары, уходили — а CRM их даже не фиксировала. Завели событие просмотра для всех сессий, добавили дожим по категориям — триггерная выручка выросла примерно на треть за квартал без единой новой механики. > > — Василина Бреусенко, CRM-маркетолог, ClientCore ## События просмотра: карточка товара, категория, поиск Верх воронки — самый недооцененный слой. Минимальный набор: - **Просмотр карточки товара** — с параметрами: id, категория, бренд, цена, наличие. Запускает сценарии «брошенный просмотр», «снижение цены на то, что смотрели», «товар заканчивается». - **Просмотр категории** — интерес без конкретного товара. Активирует подборку лидеров категории и дожим по интересу. - **Поисковый запрос** — отдельно ценны запросы без результатов: человек искал и не нашел. Тут работает письмо с аналогами или обещанием сообщить о появлении. - **Просмотр товара не в наличии** — прямой повод предложить подписку на возврат в сток. **Норма** - событие просмотра несет параметры товара: id, цену, наличие, категорию; - id товара в событии совпадает с id в товарном фиде CRM; - просмотры передаются для всех сессий, не только авторизованных. **Red flag** - событие фиксирует только факт просмотра без параметров — письмо собрать не из чего; - id в событии и в фиде различаются регистром или форматом, товарные блоки в письмах пустые; - просмотр отправляется на каждый скролл страницы, лог забит дублями. ## События корзины и заказа Здесь живут деньги, поэтому и разрывов тут больше всего. Полный набор: - **Добавление в корзину** и **удаление из корзины**. Удаление почти никто не передает, а это сигнал сомнения — повод предложить отложить товар или показать похожие. - **Начало оформления** — человек дошел до чекаута. Отдельный, более горячий сценарий дожима. - **Выбор доставки и оплаты** — этап, на котором бросают чаще всего. Если событие передается, видно, кто именно упал на стоимости доставки, и можно вернуть его промокодом. - **Заказ создан, оплачен, отменен, возвращен** — четыре разных статуса, а не один «заказ». На отмену нужен win-back, на возврат — деликатная цепочка с заботой и заменой. Что это запускает: каскад брошенной корзины (письмо через 30–60 минут, пуш, SMS на вторые сутки), дожим незавершенного чекаута, подтверждение заказа с кросс-сейлом, цепочки после отмены и возврата. Когда триггеры получают полный набор событий, это видно в деньгах. В проекте для AR Fashion мы перезапустили email как систему с полноценными триггерами — и выручка триггерных рассылок выросла на 1063% ([кейс](https://clientcore.ru/blog/articles/keis-ar-fashion-rost-vyruchki-email)). ## Сигналы интереса: избранное, подписки на товар, отзывы Этот слой собирает намерения, которые клиент озвучивает сам: - **Добавление в избранное** — мягкий дожим, напоминание, уведомление о скидке на товар из вишлиста. - **Подписка на появление в наличии** и **подписка на снижение цены** — человек поднял руку и сказал, чего хочет. - **Повторный просмотр одного товара** несколько раз за неделю — собирается из потока просмотров, работает как усилитель: дожим запускается не после первого визита, а после третьего. - **Отзыв оставлен / не оставлен** после доставки — запрос отзыва и бонус за него, а по негативному отзыву — сценарий для службы заботы. > Письмо «товар снова в наличии» стабильно показывает конверсию в заказ в 3–5 раз выше, чем промо-рассылка по базе. Причина простая: человек сам сформулировал спрос, мы лишь сообщаем, что можно забирать. Но событие подписки на наличие есть у двух клиентов из десяти. > > — Василина Бреусенко, CRM-маркетолог, ClientCore ## События жизненного цикла клиента Последний слой — то, что происходит с самим клиентом: - **Регистрация** и **подписка на рассылку** — передавать раздельно. Подписчик без аккаунта и владелец личного кабинета — разные стартовые цепочки. - **Первый заказ** — отдельное событие. Запускает онбординг в программу лояльности и сценарий доведения до второй покупки. - **Второй заказ** — клиент закрепился, пора переводить его в другой режим коммуникации. - **День рождения и годовщина регистрации** — классика, которая до сих пор приносит заказы, если поздравление не сводится к промокоду. - **Отсутствие событий** — самый недооцененный пункт. Молчание длиной в N дней (без визитов, без заказов) тоже считается событием: на нем строится вся линейка засыпания и реактивации. Порог считается от цикла покупки конкретного магазина, а не по шаблонным 90 дням. ## Mindbox: как настроить события и проверить, что они доходят В Mindbox события — это операции. Схема, которая работает на практике: поведенческие события (просмотры, поиск, корзина) идут через JS SDK на сайте, а заказы и их статусы — через серверный API. Заказы с фронта отправлять нельзя: блокировщики рекламы режут часть вызовов, и в CRM теряется до 10% транзакций. Порядок действий: зарегистрировать операции в админке, договориться с разработкой об именовании и обязательных параметрах, поднять передачу, пройти путь покупателя тестовой учеткой и проверить лог операций. В логе видно, какое событие пришло, с какими параметрами и почему отклонено. **Норма** - заказы и оплаты идут с сервера, поведение — с фронта; - id товаров в событиях сверены с фидом; - лог операций проверяется еженедельно, это 15 минут. **Red flag** - о поломке узнают по падению триггерной выручки в конце месяца; - событие «заказ» одно на все статусы, отмена и возврат невидимы; - событие уходит, но не проходит валидацию — и об этом никто не знает. > Самая частая причина «триггер не сработал» — событие ушло, но не прошло валидацию: пустой email, id товара в другом регистре, пропущенный обязательный параметр. Один битый webhook — и за неделю теряешь до 15% триггерной выручки, мы такое чинили трижды за последний год. > > — Василина Бреусенко, CRM-маркетолог, ClientCore Когда событийная модель настроена целиком, эффект суммируется. В проекте для «Браво-Оптики» мы внедрили Mindbox, подняли email-канал и запустили каскадные цепочки — за 10 месяцев это дало +14,62% к выручке от CRM-направления ([кейс](https://clientcore.ru/blog/articles/keis-bravo-optika-rost-vyruchki-crm)). ## Чек-лист самопроверки перед запуском Пройдитесь по списку и отметьте, что реально передается: **Поведение:** просмотр товара с параметрами, просмотр категории, поисковый запрос, добавление и удаление из корзины, избранное. **Заказ:** начало оформления, выбор доставки, создание, оплата, отмена, возврат. **Клиент:** регистрация, подписка на рассылку, первый и второй заказ, день рождения, таймер молчания. **Подписки на товар:** появление в наличии, снижение цены. Дальше три проверки. Первая — у каждого события есть сценарий: если событию нечего запускать, оно либо лишнее, либо под него не хватает триггера. Вторая — параметры полные: без цены и наличия товарный блок в письме не соберется. Третья — мониторинг: лог операций должен кто-то открывать регулярно, иначе о разрыве вы узнаете последними. > **Читайте также:** [События сайта для триггеров: какие данные передавать, чтобы сценарии срабатывали](https://clientcore.ru/blog/articles/sobytiya-sayta-dlya-triggerov-kakie-dannye-peredavat-chtoby-scenarii-srabatyvali) --- [Открыть статью на сайте](https://clientcore.ru/blog/articles/ecommerce-sobytiya-dlya-rassylok-polnyy-chek-list-dlya-triggernyh-scenariev)