Настройка передачи заказов в Mindbox: как сделать, чтобы каждый чек попадал в профиль клиента

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

За годы аудитов мы видели всякое: заказы, которые существуют только в браузере и сдуваются от любого блокировщика; возвраты, числящиеся выручкой; дубли чеков, потому что сайт и 1С отправляют одну покупку под разными ID. Закладывается это на этапе интеграции Mindbox с сайтом, а всплывает через полгода — когда сегменты и RFM уже посчитаны по битым данным. Как выстроить передачу так, чтобы каждый чек был виден в профиле клиента, рассказывает Егор Череватенко, CRM-маркетолог ClientCore.

Откуда Mindbox узнает о заказе: API, JS SDK и импорт

Передать заказ можно тремя способами. Серверный API: сайт или учетная система вызывает операции Mindbox после оформления заказа. JS SDK: скрипт на сайте отправляет событие прямо из браузера. Файловый импорт: периодическая выгрузка, подходит для истории и офлайн-продаж.

Рабочая схема для e-commerce обычно такая. Поведенческие события — просмотр товара, добавление в корзину, подписка — собирает JS SDK: они привязаны к сессии, и потеря части из них не критична. А вот финальный чек должен уходить с бэкенда. Браузер ненадежен: блокировщик режет скрипты, клиент закрывает вкладку до отработки пикселя, мобильный Safari приглушает фоновые вкладки. На проектах мы видим потерю 5–15% фронтенд-событий. Для просмотра товара это шум, для заказа — дыра в данных.

Когда клиенты спрашивают, mindbox события как настроить, чаще всего речь идет именно об этой связке: JS для поведения, API для денег.

Частая находка на аудите: заказ летит в Mindbox дважды. Один раз из браузера через JS SDK, второй — с бэкенда после подтверждения оплаты. Если у событий разные внешние ID, в профиле появляются два чека на одну покупку. Клиент потратил 8 000 рублей, а в сегментах значится на 16 000. RFM после этого можно выбрасывать».

Егор Череватенко

CRM-маркетолог, ClientCore

Какие поля заказа критичны

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

Минимум, без которого чек почти бесполезен:

• Внешний ID заказа. По нему заказ обновляется: смена статуса, возврат, частичная отмена. Без стабильного ID каждое обновление создает новый заказ.
• Идентификаторы клиента: email, телефон, ID на сайте. Заказ должен привязаться к профилю, иначе это анонимная строка в выгрузке.
• Позиции: ID товара из каталога, цена за единицу, количество. Без позиций не работают товарные рекомендации и сегменты по категориям.
• Итоговая сумма после скидок и списанных баллов. По ней считаются RFM и LTV.

Второй слой — поля, без которых жить можно, но с которыми заметно лучше: промокод, способ оплаты и доставки, пункт выдачи, источник заказа (сайт, приложение, розница). С ними появляются сегменты вроде «покупают только по промокодам» и отдельные цепочки для самовывоза.

Статусы: заказ живет после оформления

Чек появился на сайте — событие улетело в Mindbox. На этом останавливается примерно половина интеграций, которые мы разбираем. А дальше с заказом что-то происходит: его оплачивают, отменяют, доставляют, возвращают частично или целиком.

Каждое изменение должно приходить обновлением того же заказа. Маркетингу это дает три вещи:

• Неоплаченный заказ — повод для цепочки «оплатите, пока товар в резерве». Без статуса она не запускается.
• Отмененный заказ исключается из выручки, и клиент не получает «оцените покупку» на то, что ему не привезли.
• Возврат уменьшает сумму чека. Иначе CRM-канал в отчетах показывает деньги, которых в кассе нет.

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

Был проект, где возвраты полгода не уходили в Mindbox. Клиент считал, что VIP-сегмент дает треть выручки. Включили обновление статусов — и сегмент сдулся на 28%: это оказались люди, которые вернули товар, а в данных остались покупателями. Им все это время шли подборки „для постоянных клиентов“».

Егор Череватенко

CRM-маркетолог, ClientCore

Где интеграция теряет чеки: шесть типичных дыр

1. Заказ отправляет только фронтенд. Блокировщик, быстро закрытая вкладка, сбой скрипта — чека нет. 2. Дубли. Сайт и 1С шлют один заказ под разными ID. В профиле — две покупки, в RFM — завышенная сумма. 3. Офлайн-заказы не попадают в Mindbox. Розничные чеки и заказы по телефону живут в 1С и дальше не идут. Клиент с двумя годами покупок в магазине выглядит в базе новичком — и получает welcome-цепочку вместо коммуникации для лояльных. 4. Приложение. Сайт интегрировали, приложение забыли. Доля мобильных заказов растет, а в профилях их нет. 5. Частичный возврат. Клиент вернул одну позицию из трех, а интеграция умеет только «отменить целиком». В итоге возвраты либо завышают выручку, либо занижают. 6. Баллы и промокоды не вычитаются из суммы. Клиент оплатил половину чека баллами, а в данных — полная стоимость. Сегменты по среднему чеку поплыли.

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

Как проверить передачу заказов за один день

Полный аудит — это недели. Базовую диагностику можно сделать за день, без разработчиков.

Шаг первый — тестовый заказ end-to-end. Оформите покупку на сайте как обычный клиент, найдите заказ в профиле в Mindbox и проверьте поля: позиции, сумма, статус, привязка к вам. Шаг второй — смена статуса: отмените заказ в учетной системе и посмотрите, обновился ли он в Mindbox или повис «созданным» навсегда. Шаг третий — возврат: верните одну позицию и проверьте, как изменилась сумма.

Дальше сверка. Возьмите вчерашний день: количество заказов и выручка в Mindbox против CMS или 1С. Расхождение больше 1–2% — есть потери, идем искать. Отдельно проверьте офлайн и приложение, если они есть: там та же сверка по своим источникам.

Разовая проверка не спасает от будущих поломок, поэтому нужен мониторинг:

Причины сбоев чаще всего бытовые: обновили форму оформления, протух API-ключ, переехал домен. Без алерта это всплывает через неделю.

Самый дорогой сбой в моей практике выглядел невинно: на сайте обновили форму оформления, и событие перестало уходить. Молчали брошенная корзина и цепочка после покупки. Заметили через 12 дней, триггерная выручка за месяц просела на 18%. С тех пор алерт на падение числа заказов ставим на каждом проекте».

Егор Череватенко

CRM-маркетолог, ClientCore

Что делать, если кривые данные уже накопились

Вычистить базу задним числом не получится, но остановить поток мусора и восстановить картину можно. Порядок такой. Сначала карта источников: откуда вообще приходят заказы (сайт, 1С, приложение, розница) и какие события шлет каждый. Потом починка: единый ID заказа, перенос чека на бэкенд, статусы и возвраты. Дальше догрузка истории из учетной системы — чтобы RFM считался по полной истории, а не по последним месяцам.

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

Примерно таким маршрутом мы шли с «Галереей»: сначала собрали разрозненные CRM-коммуникации в единую систему и перевели их в Mindbox, включая передачу заказов, и только потом выстраивали механики поверх (кейс).