Дубли данных в процессах: откуда берутся и в каком порядке их сводить

Что считают дублем, а что — разными людьми

Дубль — это две записи об одном объекте: клиенте, контрагенте, адресе доставки. Бывают полные копии (запись целиком продублирована импортом) и частичные, где совпадает только часть полей: телефон один, а имя записано иначе. Рядом стоит третья категория, которая всё портит, — похожие, но разные записи: тёзки, супруги с общим телефоном, сотрудники одной компании с общей корпоративной почтой.

Ошибка возможна в две стороны, и вторая дороже. Оставили дубль — клиент получает два звонка с одним предложением, скидку дважды, а руководитель видит удвоенную базу. Склеили разных людей — один человек видит чужие заказы и счета, и это уже не неудобство, а инцидент. Поэтому дедупликация — это не «убрать лишние строки», а решение о том, кто именно считается одним клиентом.

Как один клиент превращается в четыре записи

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

Пока ключи не связаны, «склейка» держится на памяти менеджера. Это работает, пока клиентов десятки и менеджер один. На сотнях карточек память кончается, и появляются симптомы, которые обычно замечают поздно: клиент говорит «мне уже звонили», а в CRM он числится новым.

Шесть источников дублей, которые встречаются чаще всего

• Импорт из файла: выгрузили старую базу, залили рядом с новой — совпадения никто не проверял.
• Интеграции: каждая форма на сайте, телефония и чат создают запись, даже если клиент уже есть в базе.
• Разные написания одного и того же: «+7 (910) 582-82-06», «89105828206» и «8 910 582 82 06» — три карточки.
• Несколько отделов или филиалов: у каждого своя база и свой взгляд на то, кто «их» клиент.
• Смена данных клиента: новая фамилия, адрес или паспорт обновились не во всех системах.
• Разные роли одного лица: физлицо и ИП, плательщик и получатель — формально разные записи.

Сколько дублей бывает на самом деле

Публичные оценки расходятся в разы, потому что считают разное: одни — долю новых записей, другие — долю всей базы. По данным Plauti, которая в 2021 году разобрала больше 12 млрд записей в Salesforce своих клиентов, дубликатами оказались более 45% новых записей; у записей, приходящих из интеграций — маркетинговых сервисов и веб-форм, — доля доходила до 80%, у импортируемых файлов была заметно ниже — 19%. Это данные вендора по своему пулу клиентов и одной платформе, а не отраслевой стандарт.

Второй ориентир — разбор реальной базы amoCRM на 318 тыс. контактов, описанный интегратором в 2022 году. Предварительная оценка давала около 10% дублей, после скриптовой проверки и ручного разбора нашли и объединили 73 тыс. записей — почти четверть базы. Ещё одна цифра оттуда же объясняет, почему тему не откладывают: при слиянии двух банков пересечение клиентских баз доходит до 10%, а внутри систем дублирование бывает заметно выше.

Что дубль делает с процессом

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

• Клиент получает два звонка с одним предложением и делает вывод о компании, а не о базе.
• Менеджеры разных отделов ведут одного клиента параллельно: время потрачено дважды, между людьми — конфликт.
• Автоматика срабатывает на каждой карточке отдельно: два письма, два счёта, две задачи на склад.
• Аналитика врёт вверх: клиентов «больше», повторные продажи «растут», конверсия искажена.
• Растут расходы на сам учёт: в разобранном кейсе дубли упирались в лимиты тарифа, и компании пришлось бы докупать 15 лицензий — около 150 тыс. рублей в год.

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

Единый ключ: что считать главным идентификатором

Порядок начинается с ответа на вопрос: по какому признаку мы считаем, что это один и тот же клиент? Универсального ответа нет, есть иерархия надёжности. И главное: внутренний идентификатор должен быть свой, не зависящий от телефона или почты, — иначе смена номера снова разорвёт историю.

Рабочая схема — два уровня. Первый: внутренний мастер-ключ, который присваивается один раз и не меняется никогда. Второй: набор атрибутов для сопоставления — нормализованный телефон, почта, ИНН — по которым новая запись ищет свою пару. Как такой контур устроен в проектах, разобрано в разделе подход.

Порядок наведения: правила, чистка, сверка

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

1. Инвентаризация: перечислить системы, где живут клиенты, и ключ каждой из них.
2. Нормализация на входе: телефон в один формат, почта в нижнем регистре, обрезанные пробелы.
3. Запрет на создание: система ищет совпадение до сохранения и предлагает существующую карточку.
4. Пилот на выборке 1–2 тыс. записей: проверить правила на живых данных и вручную разобрать спорные пары.
5. Разовая чистка с журналом: что с чем склеено, кто подтвердил, как откатить.
6. Регламент владения полями: у каждого ключевого поля один источник правды, остальные системы его принимают.
7. Регулярная сверка и метрика: доля дублей, доля записей без ключа, число слияний за период.

Как измерить долю дублей за один день

Полная сверка «каждый с каждым» не нужна и не по средствам: в разборе на Хабре приведён расчёт, где сравнение двух баз по миллиону записей даёт триллион операций — почти 12 дней непрерывной работы даже при микросекунде на сравнение. Поэтому считают не всё, а выборку: берут 1–2 тыс. записей, нормализуют ключ, группируют по нему и смотрят долю групп больше одного. Этого достаточно, чтобы понять масштаб и защитить бюджет проекта.

Полная чистка по тому же принципу занимает часы, а не месяцы: в кейсе с 318 тыс. контактов скриптовая проверка шла больше 30 часов, зато ручное объединение, по оценке исполнителей, заняло бы больше месяца и остановило бы остальные работы. Разница между «посчитать» и «склеить» — в проверке пар человеком: её нельзя ускорить, можно только сузить.

Где остаётся человек

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

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