Дедупликация данных: как сохранить единый профиль клиента
Откуда появляются дубли
Полностью одинаковые записи — только один из вариантов дублей. Чаще профили одного клиента отличаются отдельными полями, форматом значений или набором доступных сведений.
Основные причины:
- Данные поступают из нескольких систем. Один клиент регистрируется на сайте, оформляет заказ в магазине и вступает в программу лояльности. Если источники используют разные идентификаторы, для него могут создать несколько профилей.
- Значения записаны в разных форматах. Номера
+7 900 000-00-00и89000000000выглядят по-разному, хотя могут принадлежать одному человеку. То же происходит из-за различий в регистре email-адреса, пробелов, сокращений и вариантов написания имени. - В данных есть ошибки. Опечатка в адресе, пропущенная цифра телефона или устаревшая фамилия мешают обнаружить совпадение.
- При импорте выбран неверный идентификатор. Если система ищет существующий профиль по email, а один человек использует несколько адресов, для него могут создаваться отдельные записи.
- Интеграция повторно передаёт данные. Например, система-источник не получила подтверждение из-за обрыва соединения и повторила запрос. Без защиты от повторов событие или профиль могут записаться ещё раз.
Зачем дедупликация нужна маркетингу
Повторные записи искажают представление об аудитории и влияют на процессы, которые используют клиентские данные.
Без дедупликации:
- размер базы завышается;
- история покупок и действий распределяется между несколькими профилями;
- один человек попадает в разные сегменты;
- клиент получает одинаковые или противоречащие друг другу сообщения;
- частота коммуникаций рассчитывается отдельно для каждого дубля;
- показатели конверсии, удержания и ценности клиента становятся менее точными;
- бонусы и промокоды назначаются несколько раз.
Например, в одном профиле клиента хранится история покупок, а в другом — реакция на рассылки. Маркетолог видит двух пользователей: покупателя без активности в сообщениях и активного подписчика без заказов. В результате оба профиля попадают в неподходящие сегменты.
Дедупликация восстанавливает связь между контактами, действиями и транзакциями. После объединения маркетолог оценивает клиента по общей истории, а не по отдельным фрагментам.
Как проходит дедупликация
Дедупликация состоит из нескольких последовательных операций. Конкретная схема зависит от качества исходной базы и доступных идентификаторов.
- Определение объекта сравнения. Сначала устанавливают, какие сущности нужно проверять: клиентов, заказы, товары, обращения или события.
- Нормализация значений. Данные приводят к единому виду: убирают лишние пробелы и символы, выравнивают регистр, унифицируют телефоны, даты и адреса.
- Поиск совпадений. Записи сравнивают по одному или нескольким полям. Это может быть CRM ID, email, телефон, сочетание имени и даты рождения либо другой набор признаков.
- Оценка совпадения. Система или специалист определяет, относятся ли найденные записи к одной сущности.
- Обработка группы дублей. Лишние записи удаляют, связывают с основной или объединяют в одну итоговую запись.
- Контроль результата. Проверяют спорные совпадения и случаи, когда сведения из источников противоречат друг другу.
Точное и нечёткое сопоставление
| Подход | Как определяется дубль | Пример | Главный риск |
|---|---|---|---|
| Точное сопоставление | Значения выбранных полей полностью совпадают | Одинаковый CRM ID или email | Дубли с опечатками и разным форматом останутся незамеченными |
| Нечёткое сопоставление | Оценивается сходство нескольких признаков | Похожие ФИО, адрес и дата рождения | Разных людей могут ошибочно объединить |
При нечётком поиске недостаточно одного похожего признака. Совпадение имени или адреса ещё не доказывает, что записи принадлежат одному клиенту. Чем выше цена ошибки, тем строже должны быть правила автоматического объединения.
Как выбрать ключ для поиска дублей
Ключ дедупликации — поле или сочетание полей, по которым записи сравнивают. Надёжный ключ должен однозначно обозначать сущность, редко меняться и присутствовать во всех нужных источниках.
- внутренний ID клиента из CRM или учётной системы;
- email-адрес;
- номер телефона;
- идентификатор участника программы лояльности;
- составной ключ из нескольких атрибутов.
Внутренний ID обычно надёжнее контактных данных, если все системы получают его из общего источника. Email и телефон удобны, но могут меняться, принадлежать нескольким членам семьи или отсутствовать в части записей.
Составной ключ снижает зависимость от одного поля. Например, совпадение телефона и даты рождения надёжнее совпадения только по фамилии. Однако слишком строгая комбинация пропустит дубли, если хотя бы одно значение записано с ошибкой.
Какие сведения сохранять при объединении
После обнаружения дублей нужно определить основную запись и правила переноса значений. Такой выбор приоритетных данных также называют survivorship.
Возможные правила:
- сохранять значение из доверенного источника;
- выбирать последнее обновлённое значение;
- не заменять заполненное поле пустым;
- хранить несколько допустимых контактов;
- отправлять конфликтующие сведения на ручную проверку.
Одно правило нельзя безопасно применять ко всем полям. Для адреса доставки может подойти самое новое значение, а для идентификатора клиента — только значение из основной учётной системы.
Отдельной логики требуют подписки, отписки и сведения о согласии на коммуникацию. Более свежая запись не всегда означает более корректную: при объединении нельзя автоматически заменять ограничивающий статус активным только потому, что он поступил позже из другого источника.
Чем дедупликация отличается от смежных процессов
| Процесс | Что происходит |
|---|---|
| Нормализация | Значения приводятся к единому формату |
| Валидация | Проверяется соответствие данных установленным требованиям |
| Матчинг | Система ищет записи, которые могут относиться к одной сущности |
| Дедупликация | Найденные дубли удаляются, связываются или объединяются |
| Обогащение | В запись добавляются сведения из других источников |
Матчинг — один из этапов дедупликации, но совпадение ещё не означает автоматическое слияние. Сначала нужно определить степень уверенности и правила обработки конфликтов.
Нормализация также не устраняет дубли сама по себе. Она делает сравнение точнее: например, приводит телефоны к одному формату, после чего система может обнаружить одинаковые номера.
Как предотвращать дубли в Altcraft
В Altcraft есть механизм поиска и идентификации существующего профиля при импорте и обновлении данных. Если совпадение найдено, профиль обновляется, если нет — создаётся новый. Это снижает риск появления дублей при повторной загрузке данных.
profile_id или пользовательскому полю — например, ID клиента из CRM. Также доступен мультиматчинг по email и телефону. Механика и доступные режимы описаны в документации Altcraft. Матчинг используется при импорте из файла, через API и из внешней SQL-таблицы.Как контролировать качество дедупликации
Однократная очистка базы не решает проблему надолго. Если источники продолжают создавать записи по разным правилам, дубли появятся снова.
Для постоянного контроля стоит отслеживать:
- долю записей без основного идентификатора;
- количество новых профилей при каждом импорте;
- число совпадений и отклонённых записей;
- группы профилей с одинаковыми контактами;
- случаи ручного разделения ошибочно объединённых клиентов;
- источники, из которых поступает больше всего дублей.
Резкий рост новых профилей после изменения способа передачи данных может указывать на неверный режим поиска, изменение формата идентификатора или отсутствие нужного поля в запросе.
Заключение
Дедупликация данных находит записи одной сущности и превращает разрозненные сведения в согласованную структуру. Для этого данные нормализуют, сопоставляют по выбранным признакам, проверяют конфликты и объединяют по заранее установленным правилам.
В клиентской базе важно не просто удалить одинаковые строки, а сохранить контакты, историю действий, подписки и другие полезные сведения. Чтобы дубли не появлялись снова, всем источникам нужен согласованный принцип идентификации клиента, а результаты импорта следует регулярно контролировать.


