Аудит интеграции Mindbox: как проверить, что платформа видит все заказы, события и профили

Mindbox внедрен, триггеры запущены, в отчетах красивые цифры. А потом финансовый отдел спрашивает: почему выручка CRM-канала в платформе на 12% больше, чем в управленческом учете? Или хуже — email показывает жалкие результаты, канал чуть не режут из бюджета, хотя реальные деньги он приносит.

В большинстве проектов, которые приходят к нам на аудит интеграции Mindbox, причина находится быстро: платформа просто не видит часть заказов, событий или профилей. Триггеры честно работают на тех данных, что есть. Только «есть» — это обычно 95% реальности. Иногда 90%. Как измерить этот процент и закрыть дыры — рассказывает сооснователь ClientCore Азим Вишняков.

Чем грозят 3–5% потерянных заказов

Три процента звучат как допустимая погрешность. На практике эти проценты распределены неравномерно. Данные редко теряются «равномерным слоем» по всей базе — чаще провал локальный: не долетают заказы из мобильного приложения, из офлайн-точек или из колл-центра, где менеджер оформляет покупку вручную.

Дальше цепная реакция. RFM-сегментация строится на неполной истории покупок — и «спящий» клиент на самом деле купил на прошлой неделе, просто заказ ушел мимо платформы. Выручка канала считается криво, и на совете директоров CRM-направление получает меньше бюджета, чем заработало. Управленческие решения принимаются на цифрах, которым нельзя доверять.

Типовая картина при разборе: заказы с конкретным статусом не маппятся в Mindbox, офлайн-продажи идут отдельным контуром, а про настройку передачи заказов в Mindbox из B2B-направления интегратор сказал «сделаем во второй фазе» — и второй фаза не наступила.

Сверка заказов: методика на один день

Проверка полноты заказов занимает несколько часов, если знать порядок действий:

1. Выгрузить заказы из источника истины — 1С, админки сайта, ERP — за последние 30 дней. 2. Выгрузить заказы из Mindbox за тот же период: через отчет по заказам или API. 3. Сравнить количество и сумму. Расхождение до 1–2% с понятным объяснением (тестовые заказы, ручные отмены в момент оплаты) — рабочая ситуация. Выше 3% — ищем причину. 4. Разложить разницу по срезам: источник заказа, статус, дата. Дыра почти всегда локальная, и срез показывает ее сразу.

Чаще всего находим один немаппленный статус. Видели проект, где 8% заказов не долетало, потому что статус „ожидает сборки“ просто не завели в интеграцию. Заказ потом доезжал с другим статусом, но с опозданием в сутки — и брошенная корзина успевала выстрелить по уже оплаченным покупкам».

Азим Вишняков

Co-founder, ClientCore

События: что проверять кроме факта доставки

Второй слой данных — поведенческие события: просмотр товара, добавление в корзину, начало оформления. Здесь работают четыре проверки.

Первая — покрытие платформ. События должны лететь с сайта, iOS и Android одинаково. Часто мобильное приложение шлет события по своей логике, и в профиле клиента половина истории отсутствует.

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

Третья — провалы по времени. Если события регулярно отваливаются ночью, падает очередь или крон на стороне сайта. Видно на графике потока за две недели.

Четвертая — дедупликация. Одно событие, прилетающее дважды (например, с сайта и через серверный хук одновременно), удваивает метрики вовлечения и путает условия триггеров.

Быстрый ручной тест: пройдите путь клиента сами — просмотр, корзина, оформление, оплата — и смотрите свой профиль в Mindbox в реальном времени. Все, что не появилось в течение пары минут, до платформы не доходит.

Профили и дубли: тихий источник ошибок

Дубль — это когда один живой человек существует в базе дважды или трижды: email с сайта, телефон из офлайн-чека, отдельный externalId из мобильного приложения. Mindbox склеивает профили по идентификаторам, и если разные системы шлют разные идентификаторы, платформа честно плодит новых «клиентов».

Последствия ощутимые. Welcome-цепочка уходит человеку дважды. RFM считает одного покупателя двумя клиентами с разной историей. Лимиты частоты рассылок сгорают на дублях, а реальный клиент получает в два раза больше писем, чем планировалось.

Как посчитать масштаб: выгрузить профили, нормализовать телефоны и email (плюсы, скобки, регистр), посчитать пересечения. До 2–3% дублей в базе — обычный фон. Встречается и 15% — это уже отдельный проект по склейке.

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

Триггеры на грязных данных

Аудит триггерных цепочек Mindbox начинается с данных, а не с текстов писем. Классические симптомы: брошенная корзина стреляет после оплаты, потому что событие оплаты дошло с задержкой; реактивация уходит клиентам, которые покупали вчера; welcome-серия стартует на дубль профиля.

Когда мы проводили аудит CRM-маркетинга в Mindbox для Tripster, часть потерь выручки нашлась именно на стыке данных и механик (кейс). На практике письма переписывают по кругу, а причина сидит в потоке событий.

Один битый webhook — и за неделю теряешь до 15% триггерной выручки, потому что половина цепочек стартует от событий. Мы такое чинили трижды за последний год, и каждый раз клиент до аудита был уверен, что проблема в контенте».

Азим Вишняков

Co-founder, ClientCore

Регламент: разовый аудит и постоянный контроль

Полный аудит интеграции занимает две-три недели: сверка заказов, событий, профилей, прогон триггеров, отчет с приоритетами правок. Но разовая проверка не защищает от будущего — сайт релизится каждый месяц, и любой релиз может сломать поток.

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

Когда мониторинг выстроен, данные перестают требовать ручного надзора. Мы выстраивали такой процесс для Urbantiger — команда ушла от ручного контроля коммуникаций, потому что система следит за собой сама (кейс).