Post purchase в Mindbox: какие события нужны постпокупочной цепочке и как собрать каскад без техдолга
Post purchase в Mindbox падает там, где сайт, 1С и CRM не передают нужные статусы. Разбираем карту событий и каскад email–push–SMS без переплат на SMS.
Клиент оплатил заказ — и тишина. Ни письма с подтверждением, ни сообщения о прибытии в пункт выдачи, ни запроса на отзыв. Сценарий в Mindbox при этом живой: просто до него не доходят события. Сайт пишет про оплату одним словом, 1С — другим, CRM не пишет ничего. Постпокупочная механика держится на статусах заказа, и пока карта этих статусов не собрана, цепочка будет падать на первом же нестандартном заказе.
Ниже — разбор Егора Череватенко, CRM-маркетолога ClientCore: какие события должны писать сайт, 1С или CRM, как зафиксировать их так, чтобы через год не пришлось все переделывать, и как выстроить каскад email–push–SMS без сжигания бюджета на последнем шаге.
ЧИТАЙТЕ ТАКЖЕ
«Какие метрики показывают, что post-purchase цепочка приносит деньги: конверсия во вторую покупку, время между заказами и когортный отчёт. Разбор с примерами из практики.»
Постпокупочный сценарий закрывает четыре задачи: подтвердить заказ и рассказать про статус, собрать отзыв, предложить сопутствующий товар, вернуть человека на повторную покупку. Триггер у всех шагов один — статус заказа. «Оплачен» запускает thank-you-письмо, «передан в доставку» отправляет трек-номер, «прибыл в пункт выдачи» сообщает номер бокса, «выдан» открывает ветку с отзывом и cross-sell через заданное число дней.
Mindbox welcome цепочка провожает человека до первой покупки. Post purchase цепочка подхватывает на том месте, где welcome закончила, — на первом оплаченном заказе. Поэтому постпокупочная механика не стартует, пока у заказа не появится хоть какой-то статус. Нет события — нет входа в сценарий, и маркетинг видит в отчете ноль вместо выручки.
Какие события должны писать сайт, 1С или CRM
Минимальный набор, который стоит требовать от интеграции:
order.created — заказ оформлен. Нужен для синхронизации, как триггер почти не используется
order.shipped — заказ передан в доставку. Письмо с трек-номером
order.ready_for_pickup — прибыл в пункт выдачи. Сообщение о сроках хранения
order.delivered — выдан или доставлен. Отсюда стартуют отзыв и cross-sell
order.cancelled — отмена. Стоп для всех веток
order.returned — возврат. Отдельный стоп или отдельная ветка коммуникации
Источники разные. Сайт пишет оформление и оплату — обычно через вебхук платежной системы. 1С отдает статусы склада и доставки. CRM становится источником, если доставка живет там. Способы доставки в Mindbox тоже различаются: REST API дает событие в моменте, файловая выгрузка по расписанию привозит статус через час или сутки — и триггер «здесь и сейчас» уже не сработает. Для post purchase цепочки это критично: письмо о прибытии в пункт выдачи, пришедшее через день, просто бесполезно.
Из десяти неработающих постпокупочных сценариев, которые мы разбирали, в восьми не хватало именно событий. Один проект передавал из 1С только „Новый“ и „Выполнен“, хотя между ними жили еще четыре статуса. Половина цепочки просто не имела входа. Дописали карту из шести событий — сценарий пошел».
Егор Череватенко
CRM-маркетолог, ClientCore
Карта событий: как избежать техдолга
Главный прием — реестр. Одна таблица, где против каждого статуса в системе записано событие в Mindbox, источник и живой пример payload. Когда такая таблица есть, маркетинг проверяет интеграцию за час. Когда ее нет, раскопки настроек растягиваются на недели, и каждая новая ветка сценария превращается в археологию.
Второй прием — единая точка входа. Пусть в Mindbox пишет один модуль или middleware, собирающий данные из всех систем. И третий — нейминг: snake_case и фиксированный словарь значений, чтобы order.delivered не превращался в «Выдан», «ВЫДАН» и «done» одновременно. Плюс идемпотентность: уникальный идентификатор события, повторная передача которого не плодит дубли заказов.
Норма
реестр событий в одном месте, доступ есть у маркетинга
у каждого события — пример payload с реальным заказом
повторная передача статуса не создает дубликат
Red flag
статусы из 1С приходят сырым текстом без нормализации: «Выдан», «ВЫДАН», «done»
за события отвечают «и сайт, и 1С, и CRM» без зоны ответственности
в Mindbox лежат два похожих события, и при настройке выбирают «любое»
Каскад email → push → SMS без переплат
SMS — дорогой канал, email стоит копейки, push почти ничего. Поэтому в логике каскада SMS должна стоять последней и доставаться тем, кто игнорировал предыдущие шаги. Схема простая: после события отправляем email, ставим wait-узел на 4–6 часов; не открыл — уходит push; если email-адреса нет, ветка сразу уходит в push; когда и push не доставлен, включается SMS. В Mindbox такой каскад собирается на wait-узлах и проверке активности по предыдущим сообщениям — классическая mindbox каскадная рассылка, только внутри триггерного сценария.
Детали решают экономику. Открытие email мы видим по пикселю, по push проверяем доставку. SMS-шаблон держим коротким, со ссылкой. Итог — канал с максимальной стоимостью расходуется на минимальный сегмент.
Отправлять SMS всей базе — прямой путь в перерасход. Мы выстроили правило: SMS уходит только тем, у кого нет email-подписки и кто не открыл push. В одном проекте бюджет на SMS по постпокупочным сценариям сократился примерно на 70%, охват сохранился».
Егор Череватенко
CRM-маркетолог, ClientCore
Мы это проверяли на практике: в проекте для «Браво-Оптики» внедрили Mindbox, запустили email-канал и каскадные цепочки, что за 10 месяцев дало +14,62% к выручке от CRM-направления (кейс).
Выводим в прод: тестовый заказ и мониторинг
Перед запуском заводим тестового клиента и тестовый заказ, потом вручную прокручиваем каждый статус из 1С и смотрим, какую ветку каскада прошел сценарий. Только после этого включаем на боевом трафике. Мониторинг строим на сводке событий по дням: ноль событий order.paid за день при живых продажах означает, что интеграция легла, и команда должна узнать об этом в тот же день. Раз в квартал добавляем аудит нейминга — иначе словарь значений расползается.
На проекте с тремя сотнями заказов в день один зависший вебхук за выходные — это шесть сотен человек без письма о статусе. Поэтому ставим алерт на нулевой приток событий: реагируем в тот же день, а не по месячному отчету».
Егор Череватенко
CRM-маркетолог, ClientCore
ЧИТАЙТЕ ТАКЖЕ
«Клиент купил один раз и пропал. Разбираем cross-sell после покупки: когда писать, что предлагать и как поднять частоту заказов без лишних скидок.»
Три: order.paid, order.delivered и order.cancelled. Первый запускает благодарность, второй — ветку отзыва и cross-sell, третий останавливает сценарий. Остальные добавляем по мере роста цепочки.
Что делать, если 1С отдает только два статуса?
Дорабатывать 1С до нужного набора либо брать промежуточные статусы из TMS или службы доставки напрямую. Без события «выдан» отзыв и cross-sell не запустятся корректно — запуск по финальному статусу «выполнен» тоже рабочий вариант.
SMS обязателен в каскаде?
Нет. Если подписок на email и push хватает, SMS убираем или держим для сегмента без подписок. Каскад выстраивается под реальную структуру контактов базы.
Кто должен владеть интеграцией?
Одна система-источник и один ответственный. Когда события пишут все понемногу, реестр не ведется и техдолг копится ровно до того момента, когда цепочка начнет падать.
