События сайта для триггеров: какие данные передавать, чтобы сценарии срабатывали
Сценарий активен, а отправок ноль? Почти всегда дело в событиях сайта. Разбираем, какие данные передавать в CRM, чтобы триггерные сценарии срабатывали.
Письмо о брошенной корзине написано, сценарий в Mindbox активен, дизайн согласован. Через месяц открываете статистику: 14 отправок. При трафике в 300 тысяч сессий. Знакомо?
Причина почти никогда не прячется в настройках сценария. Умирают данные: событие «добавил в корзину» либо вообще не уходит с сайта, либо приезжает пустым — от анонимного посетителя и без состава корзины. А триггер живет ровно настолько, насколько его кормят события. Что передавать, в каком виде и как проверить, что все доезжает, — разбирает Василина Бреусенко, CRM-маркетолог ClientCore.
ЧИТАЙТЕ ТАКЖЕ
«Штраф до 18 млн и заблокированная рассылка — реальная цена за криво собранные согласия. Разбираем, как закрыть юридические дыры в CRM.»
Триггер в CRM-платформе — это правило: «если пришло событие X и за N часов не пришло событие Y — отправь письмо». Правило начинается со слова «пришло». Если событие не пришло, проверять нечего. В интерфейсе сценарий при этом остается зеленым и активным — платформа не сообщает, что ей нечего есть. Она просто молчит.
По нашим аудитам молчащие триггеры разваливаются в трех местах:
1. Событие не отправляется. Разработчики поставили цель в Яндекс Метрике и решили, что этого хватит. Метрика корзину видит, Mindbox — нет, в него никто ничего не передает. 2. Событие уходит от анонима. Визит есть, корзина есть, идентификатора клиента нет. CRM честно записала событие на безымянный профиль — писать некому. 3. Событие приезжает пустым. Передали факт добавления, но не передали ID товара и цену. Письмо либо не собирается, либо уходит с битыми карточками.
Диагностика занимает минут десять. Откройте профиль тестового клиента в CRM и посмотрите ленту событий. Событий нет — проблема на стороне сайта. События есть, профиль анонимный — проблема в идентификации. События есть, профиль известный — смотрите параметры внутри события.
На аудите я первым делом прошу показать ленту событий тестового профиля, а настройки сценария открываю в последнюю очередь. Из последних пяти проектов с „молчащей корзиной“ настройки были в порядке у всех пяти. У троих событие пропало после редизайна, у двоих уходило без ID товара — и письмо собиралось с пустыми карточками».
Василина Бреусенко
CRM-маркетолог, ClientCore
Какие события сайта передавать: минимальный комплект
События делятся на два слоя. Поведенческие — то, что делает посетитель: смотрит товар, кладет в корзину, идет оформлять. Транзакционные — факты бизнеса: заказ создан, оплачен, отменен. Для email-сценариев нужны оба слоя.
Вот минимальный комплект событий сайта для триггеров — он же базовый набор ecommerce-событий для рассылок:
Просмотр товара. Питает «брошенный просмотр» и рекомендации.
Добавление в корзину. Основное событие для брошенной корзины.
Удаление из корзины. Без него CRM считает, что товар все еще лежит в корзине, и письмо предложит то, от чего человек уже отказался.
Начало оформления. Отделяет «покрутил корзину» от «пошел покупать» — нужно для сценария брошенного чекаута.
Заказ: создан, оплачен, отменен. Стоп-событие для всех брошенных цепочек и старт для постпродажных.
Подписка и регистрация. Точка входа в welcome-цепочку.
Из этого списка чаще всего забывают удаление из корзины и статусы заказа. Первое ломает актуальность писем, второе — стоп-логику: человек давно купил, а ему прилетает «вы забыли товар».
Отдельная история — события каталога: товар появился в наличии, цена изменилась. Их генерирует не сайт, а фид. Если каталог не шлет изменения остатков, триггеры back in stock и price drop мертвы, даже когда подписки на товар собираются исправно.
Что должно лежать внутри события
Событие «добавил в корзину» само по себе — галочка. Письму нужны детали, иначе карточку товара не собрать.
Стандартный состав:
ID товара;
название и цена с валютой;
категория и бренд — для сегментации и рекомендаций;
количество;
ссылка на товар и на картинку, если CRM не тянет их из фида;
время события и ID сессии.
Про ID отдельный разговор. В половине проектов, где письма приходили с пустыми карточками, причина была одна: на сайте товар живет под внутренним SKU, в товарном фиде — под vendor code. Событие приходит, CRM ищет товар в фиде, не находит. Снаружи это выглядит как «Mindbox глючит».
Вторая тонкость — цена. Передавайте ее в момент события, с учетом скидки на сайте. Иначе в письме всплывет цена из фида, которая расходится с той, что видел клиент. Письмо с «неправильной» ценой бьет по доверию сильнее, чем отсутствие письма.
Норма
ID товара в событии совпадает с ID в фиде — проверено руками на 5–10 позициях;
цена и скидка передаются в момент события;
состав корзины — структурированный массив товаров.
Идентификация клиента на сайте: кто совершил событие
Событие без владельца CRM пишет на анонимный профиль. Такие профили копятся тысячами, и для email-сценариев они бесполезны — писать некому. Идентификация клиента на сайте — вторая половина задачи, и без нее точные события работают вхолостую.
Где аноним становится известным:
подписка на рассылку: поп-ап, форма в футере, чекбокс в заказе;
авторизация в личном кабинете;
переход по ссылке из письма — CRM узнает посетителя по метке и приклеивает сессию к профилю;
email или телефон на чекауте, даже если заказ не завершили;
подписка на web push — дает идентификатор устройства.
Ключевой механизм здесь — склейка. Человек три дня смотрел товары с телефона анонимно, потом перешел из письма. Если платформа умеет склеивать профили, вся анонимная история подтянется к нему, и «брошенный просмотр» отработает по полной истории. Если нет — события останутся на анониме и сгорят.
Обидный кейс из прошлого года: ритейлер с трафиком под полмиллиона сессий. Корзина собиралась, события уходили, сценарий настроен идеально — и при этом 70% событий висело на анонимах, потому что единственной точкой идентификации был завершенный заказ. Добавили передачу email с чекаута и приклеивание сессии по переходу из письма. За месяц доля узнанных посетителей выросла до 38%, отправки по корзине увеличились вчетверо».
Василина Бреусенко
CRM-маркетолог, ClientCore
Точки идентификации дают измеримый эффект. В проекте для «Браво-Оптики» мы внедрили Mindbox, запустили поп-апы для лидогенерации и каскадные цепочки — за 10 месяцев это дало +14,62% к выручке от CRM-направления (кейс). Каждый поп-ап там работал на узнаваемость: подписчик — это профиль, к которому приклеивается история поведения на сайте.
Норма
переход из письма автоматически приклеивает сессию к профилю;
email с чекаута улетает в CRM сразу, до подтверждения заказа;
анонимные события склеиваются с профилем после идентификации.
Red flag
единственная точка идентификации — завершенный заказ;
email из поп-апа копятся в админке сайта и никуда не передаются;
один человек с телефона и ноутбука живет в базе как два клиента.
Какие сценарии какими событиями питаются
Соберем все в одну карту. Удобно сверять со своим набором сценариев:
| Сценарий | Чем питается | |---|---| | Брошенная корзина | «добавление в корзину» + отсутствие заказа за N часов | | Брошенный просмотр | «просмотр товара» без добавления в корзину | | Брошенный чекаут | «начало оформления» без события «заказ создан» | | Товар снова в наличии | подписка на товар + событие каталога «остатки больше нуля» | | Снижение цены | просмотр или избранное + событие каталога «цена упала» | | Реактивация | отсутствие событий визита N дней |
Последняя строка — ловушка. Триггер на молчание работает, только если система видит активность. Когда визиты не передаются, CRM не отличит ушедшего клиента от того, кого просто не видно, — и начнет «реактивировать» живых, раздавая скидки тем, кто и так вернулся бы.
Когда события доезжают полностью, триггерные цепочки показывают другую экономику. В проекте AR Fashion мы перезапустили email-маркетинг как систему: аудит, контент-план, дизайн и триггеры. Выручка триггерных рассылок выросла на 1063%, массовых — на 68,9% (кейс). При дырявой передаче данных такие цифры невозможны физически: цепочке просто не на что реагировать.
Как проверить события и не потерять их после релиза
Ручная проверка занимает минут двадцать:
1. Заведите тестовый email и подпишитесь на сайте. 2. Пройдите путь клиента: просмотр товара, корзина, чекаут без оплаты. 3. Откройте свой профиль в CRM и сверьте ленту событий с реальными действиями. Проверьте параметры: ID, цена, состав корзины. 4. Дождитесь срабатывания сценария и посмотрите, что пришло в письме.
Эти двадцать минут заменяют неделю переписки с поддержкой платформы.
Дальше — мониторинг. События ломаются молча: переверстали корзину, переименовали dataLayer, переехали на новый чекаут — поток упал до нуля, а заметят это через месяц, когда просядет выручка канала. Поэтому ставим контрольные точки: дневной объем событий «добавление в корзину» упал в разы относительно обычного уровня — алерт. И правило без исключений: любой релиз на сайте — регрессионная проверка событий.
Три частые технические грабли:
SPA-сайты. Страница не перезагружается, триггеры GTM на просмотр страницы не срабатывают. События надо пушить в dataLayer на действия пользователя.
Дубли. Событие уходит и с фронта, и с бэкенда — клиент получает два письма. Для каждого события нужен один источник правды.
Рассинхрон фронта и бэкенда. Корзина живет на фронте, заказ приходит с бэкенда в другом формате и с другим временем. Стоп-логика сценария начинает сбоить.
Впишите проверку событий в чек-лист любого релиза. Один переезд на новую корзину — и три месяца растущей триггерной выручки обнуляются за неделю. Мы возвращаемся к клиентам через полгода после редизайна и видим: половина сценариев жила на событиях, которых на сайте больше нет».
Василина Бреусенко
CRM-маркетолог, ClientCore
ЧИТАЙТЕ ТАКЖЕ
«Рекомендации не кликают и не продают? В 8 случаях из 10 проблема не в алгоритме, а в фиде. Разбираем требования и ошибки.»
Какие события передавать в первую очередь, если ресурсов разработки мало?
Начните с четырех: подписка, просмотр товара, добавление в корзину и заказ. Этот минимум оживляет welcome-цепочку, брошенную корзину и брошенный просмотр. Остальное докручивается по мере появления ресурсов: статусы заказа, начало чекаута, события каталога.
Что надежнее: отправка событий с фронта через JS или с бэкенда?
У них разные зоны ответственности. Поведенческие события рождаются в браузере — их отправляют с фронта. Заказы и оплаты надежнее гнать с бэкенда: адблокеры режут JS-трекинг, и заметная доля фронтовых событий теряется. Главное — у каждого события должен быть один источник, иначе получите дубли.
Триггер не срабатывает. Как понять, где проблема — в событиях или в настройках?
Идите по цепочке. Откройте ленту событий тестового профиля: событий нет — не передает сайт; события есть, но профиль анонимный — не работает идентификация; события есть и профиль известный — открывайте сценарий и проверяйте условия: фильтры, таймер, лимиты отправок на клиента.
Как заметить, что события теряются по дороге?
Сверьте счетчики. Число событий «заказ создан» в CRM должно совпадать с числом заказов в админке сайта: расхождение в 1–3% нормально, больше — повод копать. По поведенческим событиям эталона нет, поэтому ориентируйтесь на динамику: падение дневного объема в разы при том же трафике — почти всегда технический сбой.
