Клиент покупает на сайте, а через неделю приходит в магазин. CRM должна увидеть продолжение его истории, однако на практике может появиться второй профиль. Бывает и обратная ошибка: система объединяет двух людей с общим контактом, после чего одному предлагают товары на основе чужих покупок. Проверка интеграции должна защищать от обоих случаев.

Mindbox собирает клиентские данные из разных источников и использует их в маркетинговых сценариях. Объединение профилей — это решение считать несколько записей одним клиентом. Оно влияет на покупки, сегменты, бонусы и коммуникации, поэтому уменьшение числа записей само по себе ещё не означает улучшение качества базы.

Документация Mindbox связывает объединение с совпадающими идентификаторами и отсутствием противоречий. Например, совпадение email при разных телефонах не означает автоматического объединения двух профилей. [1] Ниже — набор приёмочных проверок CRM Lab для связки сайта и розницы.

Опишите значения идентификаторов

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

Mindbox различает собственный MindboxID, внешние уникальные идентификаторы и другие идентификаторы. Возможность объединения клиентов с разными внешними ID и сохранение истории зависят от настроек. Поэтому название поля «customer_id» в интеграции ещё не описывает правило его обработки. [2]

Составьте таблицу: источник, поле, смысл, уникальность, возможность изменения, приоритет. Уточните, одинаковые ли пространства номеров у сайта и кассовой системы. Если клиент 125 на сайте и клиент 125 в рознице могут быть разными людьми, передавать оба значения как один общий ключ опасно.

Задайте ожидаемый результат до теста

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

Зафиксируйте правила общего email семьи, нового номера телефона и покупки подарка. Получатель заказа не всегда покупатель. Нельзя автоматически переносить историю на контакт доставки только потому, что он указан в чеке или заказе.

Для приёмки используйте отдельные тестовые контакты и заказы. Перед началом сохраните исходное состояние профилей, подписок и бонусных счетов, если они участвуют в проекте. Массовое исправление реальной базы не подходит для первого эксперимента с настройками объединения.

Тестовая ситуацияЧто проверяемКритерий приёмки
Тот же клиент покупает в двух каналахСовпадение согласованных ключейОдна история без потери заказов
Одинаковый email и конфликт телефоновПравило конфликтаНет необоснованного объединения
Смена подтверждённого телефонаПостоянный ID и обновление контактаИстория остаётся у нужного клиента
Два человека используют одно устройствоАвторизация и принадлежность действийЧужая история не переносится автоматически
Повторная передача заказаКлюч заказа и обработка повтораОдин заказ в итоговой истории

Проведите сквозной тест покупки

Условный пример. У клиента есть постоянный ID C104. Сайт передаёт заказ WEB71 с этим ID; касса передаёт POS82 после предъявления карты лояльности, связанной с тем же клиентом. Ожидаем две покупки в общей истории. Повторная отправка POS82 не должна создавать третью покупку.

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

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

Проверьте последствия объединения

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

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

Не исправляйте обнаруженный конфликт немедленной ручной склейкой. Сначала сохраните доказательства и выясните, не создала ли интеграция неверный идентификатор. Иначе ручное действие скроет причину, а следующая загрузка повторит ошибку. Для уже ошибочно объединённых профилей нужен отдельный план восстановления с проверкой принадлежности истории.

Оформите приёмку как повторяемый набор проверок

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

Для рабочей базы отслеживайте долю заказов без найденного клиента, конфликты идентификаторов и необычные всплески объединений. Порог тревоги выбирайте по обычному потоку своего проекта. Цель контроля — вовремя найти изменение логики, пока оно не повлияло на массовые сценарии и расчёт ценности клиента.

Источники

1. Mindbox. Как Mindbox создает единый профиль клиента? Документация Mindbox. Проверено 23.09.2026.

2. Mindbox. Идентификаторы клиента в Mindbox. Документация Mindbox. Проверено 23.09.2026.