CRM-аналитика
Как работать с общим email семьи без ошибочной склейки
Время чтения: 6 мин
Уровень материала: Для экспертов
Содержание
Сервис рассылок нашёл одинаковый email в двух карточках и предложил убрать дубль. На первый взгляд это полезная уборка: в базе станет меньше записей, история покупок соберётся в одном месте. Но адресом могут пользоваться супруги, а корпоративный ящик может принадлежать целому отделу. После объединения одному человеку начнут приписывать чужие заказы и интересы.
В CRM нужно различать человека, его аккаунт и контакт. Человек может иметь несколько аккаунтов, а один контакт может использоваться несколькими людьми. Объединение профилей, или склейка, означает решение системы считать разные записи одним клиентом. Такое решение требует более сильного основания, чем совпадение поля.
Разберём, как сохранить полезную историю и при этом не превратить общий адрес в доказательство личности. Предлагаемые правила — редакционная модель CRM Lab; её нужно проверить на устройстве вашей базы и возможностях платформы.
Определите что именно вы объединяете
Начните с постоянного идентификатора клиента — внутреннего кода, который не меняется при смене телефона или email. У магазина это может быть код авторизованного аккаунта. Он надёжен в пределах своей системы, но сам по себе ещё не доказывает, что два аккаунта принадлежат одному человеку.
Отдельно храните контакты и связи с ними. Связь «профиль использует адрес» полезнее правила «адрес и есть профиль»: у неё могут быть дата подтверждения, назначение и признак общего использования. Общий семейный адрес при этом не обязан становиться отдельной сущностью «семья», если у бизнеса нет сценариев работы с домохозяйством.
Документация Adobe показывает, как общий браузер способен связать двух разных пользователей, и описывает ограничения на объединение идентификаторов. Это конкретная реализация защиты в продукте, а не гарантия правильной склейки при любых исходных данных.
Разделите уверенные и сомнительные совпадения
Надёжность зависит от происхождения признака. Email, введённый кассиром со слов покупателя, и связь, подтверждённая входом в два собственных аккаунта, дают разные основания. Два слабых совпадения не всегда превращаются в одно сильное: общий адрес доставки и общий телефон могут относиться ко всей семье.
| Ситуация | Решение в нашей модели | Что сохраняем |
|---|---|---|
| Один постоянный ID из доверенного источника | Обновляем существующий профиль | Источник и время изменения |
| Два аккаунта с одинаковым email | Не объединяем автоматически | Два профиля и общий контакт |
| Клиент подтвердил владение обоими аккаунтами | Рассматриваем объединение по утверждённой процедуре | Основание и историю решения |
| Совпали устройство и адрес доставки | Используем только как повод для проверки | Слабые связи без переноса покупок |
| У множества профилей стоит адрес-заглушка | Исключаем значение из сопоставления | Причину исключения и источник ошибки |
Таблица должна применяться до запуска массовой склейки. Если платформа считает email уникальным ключом без исключений, сначала выясните, поддерживает ли она нужную модель. Иногда разумнее хранить персональные профили отдельно, а в сервис рассылок передавать подготовленного получателя на уровне адреса.
Не путайте объединение профилей с устранением повторных писем
Два разных клиента с общим адресом могут получить две одинаковые акции. Для решения этой проблемы не обязательно объединять их историю. Можно установить ограничение на число одинаковых сообщений одному контакту в рамках конкретной кампании.
Такое ограничение должно знать, какое сообщение выбирается. Если одному профилю положена персональная скидка, а другому — другой набор товаров, выбор по принципу «кто первым попал в выгрузку» будет случайным. Для общего адреса можно использовать нейтральную версию без имени и чувствительных деталей, если её отправка разрешена установленными правилами.
Отписки и разрешения рассматривайте отдельно. Нельзя переносить разрешение одного человека на второго вместе с общим email. Если клиент отказался от рассылки на общий адрес и невозможно установить более узкую область отказа, спорную рекламную отправку лучше остановить до уточнения. Техническое правило должно реализовывать принятую в компании модель согласий.
Условный пример семейного адреса
В базе есть Анна с аккаунтом A17 и Павел с аккаунтом P42. У обоих указан один email. Анна покупала товары для бега, Павел — настольные игры. Магазин хранит отдельные заказы и не имеет подтверждения, что это один человек.
После автоматической склейки профиль получает обе категории, а имя выбирается по последнему обновлению. Анне приходит письмо «Павел, продолжите коллекцию». Даже если предложение приведёт к покупке, качество данных и обращение к клиенту уже нарушены.
В предлагаемой схеме A17 и P42 остаются разными профилями. Общая акция отправляется на адрес один раз без обращения по имени. Персональную подборку магазин предлагает в авторизованном кабинете. Если появляются подтверждённые данные для иной модели, решение пересматривают с сохранением его истории.
Проверьте последствия до массового объединения
Соберите тестовые случаи: общий адрес, смена контакта, опечатка, два аккаунта одного человека, техническая заглушка и повторное поступление старого файла. Для каждого заранее запишите, сколько профилей должно остаться, кому принадлежат заказы и какие сообщения допустимы.
Проверьте также сценарий отмены решения. Если склейка оказалась ошибочной, команда должна восстановить принадлежность заказов и остановить обращения, созданные на основе смешанных данных. Удаление одного email не равнозначно восстановлению двух историй.
Оценивайте качество на проверенной вручную выборке. Доля объединённых записей показывает масштаб операции, но не её правильность. Полезнее считать ошибочные объединения среди проверенных случаев и отдельно пропущенные дубли среди подтверждённых пар. Случаи с общими контактами стоит проверять отдельной группой.
Сравните цену двух типов ошибок
Ложное объединение соединяет разных людей. Пропущенное объединение оставляет два профиля одного человека. Эти ошибки неравноценны: первая способна раскрыть чужую историю, вторая — завысить размер базы или повторить сообщение. Поэтому стремление убрать максимум дублей не является достаточной целью.
Для проверки соберите подтверждённые пары обоих типов. Не оценивайте правило только на случаях, которые оно само признало дублями: так вы не заметите пропущенные совпадения. Отдельно проверьте общие адреса, кассовые записи и недавно изменённые контакты.
Нормализация контакта также требует границ. Привести номер к единому формату полезно, но удалить из email значимые символы по правилу одного почтового сервиса — рискованно. Хеширование, то есть преобразование значения в цифровой отпечаток, не делает общий контакт индивидуальным: одинаковый исходный адрес по-прежнему останется общим.
Что закрепить в правилах
У каждого разрешённого объединения должны быть основание, владелец правила и способ восстановления. Для сомнительных совпадений задайте безопасный режим: сохранить записи раздельно, ограничить персонализацию и отправить случай на проверку.
Начать можно с небольшой матрицы из пяти ситуаций выше. Её практический результат — не минимальное количество строк в базе, а возможность объяснить, почему конкретные покупки и контакты оказались у одного клиента.
Источники
Adobe. Identity Optimization Algorithm. Adobe Experience Platform. Разделы Unique namespace и Shared device. Обновление 18.06.2026. Проверено 22.09.2026.