Настройка событий Mindbox: как проверить, что платформа видит все действия клиента
Сценарий собран верно, а триггер молчит? Причина обычно уровнем ниже — в событиях, которые не доходят до Mindbox. Разбираем, как сверить событийный контур и закрыть дыры до запуска.
«Брошенная корзина» активна, письма сверстаны, сегменты посчитаны — а сценарий отправляет три письма в день при сотнях корзин на сайте. Команда лезет в настройки триггера, перепроверяет условия, пишет в поддержку. Поддержка отвечает вежливо: со стороны платформы все работает, событий просто нет.
Знакомая история? С нее начинается почти каждый наш аудит Mindbox, где платформа внедрена, но работает ниже потенциала. Егор Череватенко, CRM-маркетолог ClientCore, рассказывает, как проверить событийный контур и где прячутся типичные дыры.
ЧИТАЙТЕ ТАКЖЕ
«Триггеры молчат, а выручка не сходится с 1С? Скорее всего, чеки теряются на пути в Mindbox. Разбираем критичные поля, типичные дыры и проверку за один день.»
Событие не дошло: почему триггер молчит при верных настройках
Цепочка, по которой рождается триггерная коммуникация, выглядит так: клиент делает действие на сайте → JS SDK или серверный вызов отгружает событие → в Mindbox создается операция → триггер ловит операцию → сценарий отправляет письмо. Сценарий здесь — последнее звено из пяти. Когда письмо не уходит, первым делом копают именно его. Разрыв обычно случается на первом или втором звене.
На уровне платформы mindbox события и триггеры работают как единая система: первые фиксируют действие, вторые на него реагируют. Цена этой связки — триггерная выручка. В проекте для AR Fashion мы перезапустили email-канал как систему, и выручка от триггерных рассылок выросла на 1063% (кейс). Такие цифры складываются из десятков цепочек, каждая стартует от события. Потеряете треть событий «добавил в корзину» — потеряете треть потенциала цепочки. Простая арифметика, о которой вспоминают поздно.
Реальный случай: у клиента цепочка на начало оформления заказа работала вполсилы. Полдня проверяли сценарий — все чисто. Оказалось, событие BeginCheckout улетало только для авторизованных пользователей, а гости оформляли через быстрый заказ в один клик. Добавили вызов на гостевой сценарий — число входов в цепочку выросло в 2,3 раза за неделю».
Егор Череватенко
CRM-маркетолог, ClientCore
Минимальный регистр: какие события обязаны быть в контуре
Прежде чем проверять, зафиксируйте, что вообще должно приходить. Настройка событий Mindbox начинается с регистра — для e-commerce он выглядит так:
Просмотр товара (ViewProduct) — с ID товара, ценой, категорией.
Просмотр категории (ViewProductCategory).
Добавление в корзину (AddToCart) и изменение ее состава.
Начало оформления (BeginCheckout).
Создание заказа (CreateOrder) — с внешним ID, составом, суммой, промокодом.
Оплата и смена статусов заказа: отменен, оплачен, доставлен.
Регистрация, авторизация, подписка на коммуникации.
Если у вас не классическая розница, список будет другим, но принцип тот же: в регистр попадает каждое действие, на которое завязан хотя бы один сценарий, плюс действия, по которым строите сегменты. Нет события — нет сценария, как бы красиво он ни был нарисован в конструкторе.
Когда мы внедряли Mindbox для «Браво-Оптики» с нуля, событийный контур собирали до запуска первой цепочки: регистр, передача, тестовые прогоны. Каскадные цепочки и поп-апы заработали сразу, а за 10 месяцев CRM-направление дало +14,62% к выручке (кейс).
Норма
Заказ приходит серверным вызовом с внешним ID, составом и суммой.
ID товара в событиях совпадает с ID в товарном фиде — иначе молчат рекомендации и «брошенный просмотр».
У каждого события есть привязка: к клиенту или хотя бы к устройству (deviceUUID).
Red flag
Заказ трекается только JS-событием на странице «спасибо за заказ».
В событии «просмотр товара» летит артикул, а в фиде — GUID.
Корзина анонимного посетителя никуда не пишется «до регистрации».
Три канала доставки: сайт, сервер, мобильное приложение
JS SDK — трекер на сайте. Через него идут поведенческие сигналы: просмотры, корзина, оформление. Слабые места известны: блокировщики рекламы режут скрипт, а в SPA переходы между страницами происходят без перезагрузки, и трекер «не замечает» половину визитов, если вызовы не повешены на роутер.
Серверный API — канал для фактов. Заказ, оплата, смена статуса, начисление бонусов: все, что влияет на деньги, должно идти сервер-сервер. В документации Mindbox API операции делятся на синхронные и асинхронные. Первые нужны, когда ответ ждут прямо сейчас — например, применить промокод на сайте. Вторые — для отгрузки событий. И передавайте внешний ID: повторный вызов с тем же orderId обновит операцию, а не создаст дубль.
Мобильные SDK — iOS и Android. Отдельно проверяйте, что приложение шлет не только установку и пуш-токен, но и поведенческие события: просмотры, корзину, заказы. Частая картина на аудите: сайт отдает в Mindbox двадцать операций, приложение — три.
Рабочее правило: все, от чего зависит выручка, дублируем сервером. JS остается для поведенческих сигналов, которые жалко, но не критично потерять.
Тестовый прогон: как проверить контур руками
Автотесты автотестами, а базовая проверка делается руками за час:
1. Заведите тестового клиента — отдельные email и телефон, которых нет в базе. 2. Пройдите путь покупателя: просмотр товара → корзина → оформление → заказ → оплата. 3. Откройте карточку клиента в Mindbox и сверьте ленту: все операции на месте, порядок верный, параметры заполнены. 4. Загляните в логи операций. Событие могло дойти, но упасть на валидации — например, из-за неверного формата поля. 5. Убедитесь, что триггер стартует от реального события: тестовый клиент вошел в сценарий, письмо пришло. 6. Повторите прогон с мобильного устройства и с включенным блокировщиком рекламы. Результаты удивят.
На одном проекте письмо „заказ оформлен“ приходило клиентам дважды. Причина: страница благодарности при обновлении заново отгружала событие создания заказа. Починили за час — перешли на серверную отгрузку с внешним ID. А до этого поддержка месяц разгребала жалобы».
Егор Череватенко
CRM-маркетолог, ClientCore
Типичные дыры в событийном контуре
Места, где события теряются чаще всего:
Блокировщики рекламы. Режут JS SDK у 10–30% посетителей в зависимости от аудитории. Критичные события дублируйте сервером.
SPA и быстрые переходы. Трекер не перезагружается — просмотры не уходят. Вешайте вызовы на роутер приложения.
Событие уходит до идентификации. Аноним положил товар в корзину, потом залогинился — а действия с профилем не сшились. Проверьте механику слияния по deviceUUID.
Битый вебхук оплаты. Платежный шлюз дергает ваш сервер, тот отвечает ошибкой 500 — и событие «оплачен» в Mindbox не попадает. Нужны ретраи и мониторинг.
Несовпадение ID товаров. В событиях один формат, в фиде другой — персональные рекомендации молчат, и никто не понимает почему.
Задержки и часовые пояса. Событие пришло через час, а у триггера ограничение частоты — клиента пропустили.
После запуска: как не узнать о поломке из месячного отчета
Событийный контур живет вместе с сайтом. Формы меняются, релизы выкатываются — и каждый может молча сломать передачу. Минимум контроля:
Еженедельная сверка: заказы в CMS против заказов в Mindbox. Расхождение больше 2–3% — повод копать.
Алерт на нулевой поток: если за час пикового трафика не пришло ни одного AddToCart, что-то сломалось.
Тестовый прогон после каждого крупного релиза.
Назначенный ответственный за контур — человек, который получает алерты.
После очередного релиза у клиента отвалился вебхук смены статуса заказа. Неделю в Mindbox не приходили „оплачен“ и „доставлен“ — молчали постпродажные цепочки и запросы отзывов. Заметили по сверке, а могли бы — по падению выручки в конце месяца. С тех пор алерт на поток событий ставим по умолчанию».
Егор Череватенко
CRM-маркетолог, ClientCore
Норма
Сверка заказов — каждую неделю, расхождения разбираются в тот же день.
Алерт срабатывает раньше, чем падает выручка.
Прогон контура — пункт в чек-листе релиза.
Red flag
О поломке узнают из отчета по CRM-выручке.
События проверяли один раз — при внедрении два года назад.
За контур отвечают все, поэтому никто.
ЧИТАЙТЕ ТАКЖЕ
«Приложение скачивают, а пуши не продают? Разбираем, какие события передавать в Mindbox, где ломается связка SDK–API и как найти дыры по чек-листу.»
Ничем по сути — это терминология платформы. Действия клиента в Mindbox называются операциями: стандартными (просмотр товара, создание заказа) и кастомными, которые заводите под свои процессы. Системные имена и обязательные параметры операций перечислены в документации Mindbox API — сверяйтесь с ней, когда ставите задачу разработчикам.
С чего начать проверку, если событий много?
С денег. Первыми проверяйте создание заказа, оплату и добавление в корзину — от них зависит основная триггерная выручка. Затем поведенческие события для сегментации, в конце — второстепенные кастомные операции.
Как проверить события, если нет доступа к коду сайта?
Для базовой сверки он и не нужен. Пройдите путь тестового клиента и смотрите карточку в Mindbox: какие операции появились, с какими параметрами. Логи операций покажут ошибки валидации. Доступ к коду понадобится только на этапе починки.
События приходят с задержкой — это нормально?
Асинхронные операции обрабатываются не мгновенно, задержка в пару минут — рабочая ситуация. Если события доходят часами, смотрите очередь на стороне вашего сервера и логи: где-то копятся ошибки или ретраи.
