Интеграция с Mindbox: единый профиль клиента вместо трёх баз

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

Задача

Крупный ритейл с онлайн-магазином, учётной системой 1С и офлайн-точками выходил на Mindbox — платформу, которая собирает данные о клиенте в единый профиль и на их основе запускает коммуникации. Технически задача звучала как «интегрировать сайт с Mindbox».

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

Что нашли на аудите

• Три базы вместо одной. Клиенты сайта, клиенты 1С и офлайн-покупатели хранились отдельно и не пересекались.
• Дубли. Один и тот же человек мог существовать в нескольких записях внутри одной системы.
• Нет сквозных идентификаторов. Связать профили было не по чему — Mindbox требуется уникальный ключ клиента.
• Разные маски ввода. Телефоны и адреса почты вводились в формах по-разному: с восьмёркой, с плюсом, со скобками. Один номер превращался в три разных строки.
• Конфликты каналов входа. Регистрация и авторизация работали независимо в разных точках, создавая коллизии.

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

Стандартизация данных

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

Дальше — очистка. Мы обработали большой объём записей, нашли дубли, связали онлайн- и офлайн-профили и вывели систему актуализации данных. В неё вошли:

• сравнение последних данных авторизации по клиенту;
• проверка наличия клиента в разных системах рассылок;
• предупредительные рассылки при расхождениях.

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

Свой SDK вместо готовой библиотеки

Для работы с API Mindbox мы написали собственный SDK на PHP. Причина простая: готовые модули навязывают свою модель работы с событиями и сущностями, а проект требовал гибкости — нестандартных сценариев и быстрой итерации.

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

Авторизация: от четырёх способов входа к одному

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

Мы предложили решение — единый уникальный идентификатор в Mindbox, номер телефона, к которому привязаны все проверки. Это не упрощение ради упрощения: Mindbox построен вокруг телефона как ключа клиента, и попытка обойти это ведёт к конфликтам на стороне платформы.

Настроили отправку запросов по API, получение ответов, вывод ошибок в интерфейсе — так, чтобы пользователь понимал, что произошло, а не видел техническую ошибку.

Регистрация: схемы логики

С регистрацией работа оказалась объёмнее, чем с авторизацией: точек регистрации много, а часть пользователей вообще не была зарегистрирована на сайте — это ограничение CRM-системы, которое пришлось учитывать.

Мы составили схемы логики для каждого сценария: что происходит, если человек уже есть в базе; если он есть в 1С, но не на сайте; если данные расходятся между системами. В финале, как и в авторизации, оставили единственный путь — по номеру телефона.

Что потребовало участия вендора

Часть проблем лежала не на нашей стороне: в процессе выявились несовместимости и нарушенные бизнес-процессы внутри самой Mindbox. Мы собрали и описали эти случаи, и разработчики платформы доработали ряд методов системы.

Для заказчика это тоже вывод: интеграция с CDP — совместная работа трёх сторон, где площадка не всегда готова «из коробки».

Тестирование и эксплуатация

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

На эксплуатации проект остаётся на поддержке: отслеживаем ошибки и падения, разбираем нетиповые кейсы и предлагаем решения. Грамотно собранная интеграция не требует ежедневного вмешательства, но полностью автономной она не становится — обмен данными между несколькими системами всегда имеет слабые места на стыках.

Результат

Первый этап интеграции завершён и работает автономно: данные клиентов собраны в единый профиль, дубли устранены, авторизация и регистрация переведены на один идентификатор, обмен событиями с Mindbox налажен.

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

Что забрали в другие проекты

• Аудит данных — до интеграции. Переносить грязную базу в новую систему бессмысленно: та же проблема просто переедет на новую платформу.
• Единый идентификатор лучше четырёх. Каждый дополнительный способ входа — источник коллизий в клиентских данных.
• Свой SDK там, где нужна гибкость. Готовая библиотека экономит неделю на старте и стоит месяцы на доработках.
• Этапность вместо большого запуска. Разбиение на этапы позволило получить работающий результат раньше, чем закончился весь проект.

Частые вопросы

С чего начинать интеграцию с Mindbox?

С аудита клиентских данных, а не с API. Нужно понять, сколько источников данных существует, есть ли дубли и по какому признаку связывать профили. В этом проекте выяснилось, что данные лежат в трёх несвязанных базах — интеграция началась с их очистки и стандартизации.

Зачем нужен собственный SDK для Mindbox?

Готовые модули диктуют свою логику работы с событиями и сущностями. Собственный SDK на PHP даёт прямой доступ к методам API, полный контроль над обработкой ошибок и возможность быстро добавлять нестандартные сценарии.

Почему авторизацию лучше строить на одном идентификаторе?

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

Проект выполнен в рамках услуг «Программирование и доработка сайтов» и «Техническая поддержка сайтов».