CRM-аналитика
Как разъединить ошибочно склеенные профили клиентов
Время чтения: 6 мин
Уровень материала: Для экспертов
Содержание
Клиент сообщает, что видит чужие покупки, или маркетолог обнаруживает в одной карточке два противоречащих друг другу набора данных. Причиной может быть ошибочное объединение профилей: система решила, что разные люди — один клиент. Исправить имя и убрать лишний телефон недостаточно. На смешанной истории уже могли пересчитаться сегменты, бонусы и будущие сообщения.
Разъединение профилей — восстановление принадлежности исходных записей и связанных решений. Задача сложнее, чем отмена редактирования поля: часть действий уже произошла за пределами CDP, то есть платформы клиентских данных.
План восстановления нужно строить от происхождения данных. Для каждого заказа, контакта и разрешения выясняют, из какого источника запись пришла и какой идентификатор клиента содержала до объединения.
Сначала ограничьте последствия
Приостановите персонализированные рекламные сценарии для затронутого профиля и отмените доступные к отмене задания. Определите вместе с продуктом, нужно ли временно ограничить показ смешанной истории в кабинете. Служебные процессы, необходимые для действующих заказов, рассматривайте отдельно, по достоверным участникам конкретного заказа.
Сохраните снимок состояния и журнал изменений. Снимок — копия данных на определённый момент; он нужен для расследования, но сам по себе не является правильной версией профиля. Не удаляйте записи до выяснения причины: иначе исчезнут основания для восстановления.
В документации Twilio Segment прямо указано, что удаление идентификатора сохраняет историю профиля, включая события и историю объединений. Следовательно, удаление ошибочного контакта через такой механизм нельзя считать разъединением всей клиентской истории. Поведение других платформ нужно проверять отдельно.
Найдите исходное неверное соединение
Ищите событие, после которого две истории впервые оказались вместе. Это может быть общий email, телефон-заглушка в импорте, повторно использованный номер или идентификатор общего браузера. Важно восстановить цепочку, а не ограничиться последним изменённым полем.
Например, сначала профили A и B объединились по общему телефону, затем к объединённой записи добавился профиль C по email клиента B. Если исправить только первую связь, данные C могут остаться не на своём месте. Поэтому проверяют весь набор связей, возникших после исходной ошибки.
Остановите правило или источник, который создаёт неправильное соединение. Иначе восстановленные профили снова объединятся при следующей синхронизации или повторной обработке старых событий.
Распределите записи по степени уверенности
Надёжное основание — исходный аккаунт заказа, подтверждённая связь в системе авторизации или другой проверенный ключ. Имя, категория покупки и похожий адрес могут помочь расследованию, но не должны автоматически определять владельца записи.
| Запись | Основание для переноса | Если принадлежность неясна |
|---|---|---|
| Заказ | Исходный ID покупателя в системе заказов | Оставить спорным до сверки с источником |
| Подтверждённый контакт | Журнал подтверждения и аккаунт | Не использовать для персонального обращения |
| Разрешение на коммуникацию | Исходная запись с областью действия | Не создавать разрешение заново |
| Анонимный просмотр | Доказуемая связь с сессией и аккаунтом | Исключить из персональных выводов |
| Уже выполненная отправка | Фактический адресат и ID сообщения | Сохранить как произошедшее действие |
Не требуется любой ценой распределить сто процентов событий. Иногда честный статус «принадлежность не установлена» безопаснее уверенного, но выдуманного назначения. Такие записи можно сохранить для ограниченного анализа, если это допускают принятые правила работы с данными.
Восстановите профиль и пересчитайте производные данные
Производные данные — показатели, рассчитанные из исходных записей: число покупок, последняя категория, ожидаемая дата повторного заказа, сегмент. После разделения они должны пересчитываться по правильной истории, а не копироваться из смешанного профиля.
Отдельно проверьте внешние системы. Сервис рассылок мог уже получить неверный сегмент, программа лояльности — начисление, рекламная система — аудиторию. Исправление внутри CDP не доказывает, что эти последствия устранены.
Если платформа не умеет разъединять историю, возможен контролируемый пересбор профилей из исходных записей. Это отдельная миграция: с новыми связями, блокировкой отправок, защитой от повторных действий и проверкой зависимых систем. Просто удалить смешанный профиль и загрузить данные заново опасно.
Условный пример восстановления
В объединённой карточке находятся 12 заказов. Девять содержат исходные коды аккаунтов: пять принадлежат A, четыре — B. Ещё три старых заказа переданы только с общим телефоном. Автоматически отнести их к одному из людей невозможно.
Команда возвращает девять подтверждённых заказов владельцам, три спорных временно исключает из персональных рекомендаций и проверяет в системе заказов. Бонусы не делятся пропорционально количеству заказов: каждое начисление сверяют с операцией, на основании которой оно возникло.
Уже отправленное письмо остаётся в журнале с фактическим адресом и временем. Его нельзя «перенести в прошлое» другому человеку, чтобы улучшить отчёт. Если решение об объединении повлияло на эксперимент, аналитик отдельно оценивает нарушение назначенных групп.
Составьте журнал восстановления по объектам
В рабочей таблице достаточно ID записи, исходного владельца, восстановленного владельца, основания, исполнителя и результата проверки. Для спорной записи указывают причину неопределённости и следующее действие. Весь набор персональных данных копировать в таблицу не нужно.
Пересчёт бонусов или клиентской ценности выполняйте после восстановления исходных операций. Если итоговый баланс уже использован, арифметически разделить его недостаточно: потребуется отдельное решение владельца программы по фактически совершённым списаниям.
Для эксперимента сохраняйте первоначальное назначение и журнал контактов. Нельзя перераспределить заказы так, чтобы результат теста стал удобнее. Если восстановить независимые группы невозможно, этот случай отмечают как нарушение дизайна и оценивают его влияние по заранее согласованной методике. Обычная починка профиля не восстанавливает задним числом условия эксперимента.
Проверьте что ошибка не повторится
Приёмка включает три уровня. В исходных данных правильно восстановлены владельцы записей. В производных показателях нет чужих покупок и разрешений. В каналах не осталось заданий, созданных на неверной истории.
После этого повторно передайте событие, вызвавшее ошибку, в тестовой среде. Если профили снова объединяются, восстановление ещё не завершено. Зафиксируйте изменённое правило, владельца исправления и контрольную проверку следующей полной синхронизации.
В рабочем регламенте должны остаться порядок остановки, перечень доказательств принадлежности и способ восстановить зависимые системы. Именно эти сведения позволяют разбирать следующий случай без импровизации.
Источники
Twilio Segment. Delete Profile Identifier API. Документация Unify. Разделы Deletion scope и Identifier reintroduction. На дату проверки функция обозначена как public beta. Проверено 22.09.2026.