Для удаления дублей в CRM сначала разделяют повтор технического события, повторное обращение клиента и две карточки одного контакта. Для каждой ситуации нужны разные правила. Объединение по одному телефону может уничтожить отдельную сделку и исказить сведения о том, откуда пришло обращение.
Условный пример: клиент оставил заявку на сайте, затем написал в бот о другом продукте. Контакт один. Обращений два. Если автоматизация объединит всё в одну «последнюю заявку», менеджер потеряет одну задачу. Из аналитики исчезнет один путь покупки.
Три уровня данных
Рекомендуем проектировать отдельно событие, контакт и коммерческий запрос. Событие фиксирует конкретную отправку формы или сообщение. Контакт представляет человека или организацию. Запрос отражает потребность, которую ведут как обращение, заявку или сделку в выбранной CRM.
Названия объектов зависят от продукта. Поэтому перед настройкой интеграции сопоставьте бизнес-смысл со структурой именно вашей системы.
| Уровень | Возможный идентификатор | Что считать повтором |
|---|---|---|
| Событие | Источник + внешний номер отправки | Повтор доставки того же события |
| Контакт | Внутренний номер клиента, проверенные контакты | Две записи, достоверно относящиеся к одному субъекту |
| Запрос | Номер обращения + предмет | Повтор той же операции по согласованному правилу |
Документация HubSpot показывает, что API контактов работает с идентификатором записи, email или специальным уникальным свойством. Возможности создания и обновления зависят от выбранного метода. HubSpot: Contacts API. Это пример конкретной реализации, набор возможностей своей CRM нужно проверить отдельно.
Сначала уберите технические повторы
Для отправки формы полезен устойчивый идентификатор операции. Один и тот же запрос, повторённый после сбоя, должен ссылаться на прежнюю заявку. Новая форма с новым намерением получает новый номер.
Защиту от параллельной обработки стоит реализовать на уровне хранилища. В PostgreSQL уникальное ограничение может действовать на сочетание полей. PostgreSQL: Unique Constraints.
В интеграции можно задать уникальность пары «система-источник + идентификатор события». Значения должны быть обязательными по выбранной схеме, иначе пропуски могут нарушить ожидания по защите от дублей. Конкретное ограничение и обработку пустых значений проверяет разработчик.
Такое правило предотвращает повтор события. Оно не решает, относятся ли два разных запроса к одной сделке.
Правила сопоставления контактов
Начните с сильных признаков: внутренний идентификатор авторизованного клиента или подтверждённая связь с существующей карточкой. Телефон и email помогают найти кандидатов, но их смысл зависит от процесса. Общий номер отдела может принадлежать нескольким сотрудникам. Общий почтовый адрес, нескольким заявителям.
Нормализацию формата выполняют по понятным правилам: убирают лишние пробелы, приводят телефон к согласованной форме с учётом страны. Исходное значение полезно сохранить для разбора. Произвольная переделка адреса или номера может объединить разных людей.
Предлагаем два режима: точное автоматическое сопоставление по заранее проверенным основаниям и очередь кандидатов для ручной проверки. Сходство имени и совпадение домена обычно лучше использовать для поиска кандидатов, чем для безусловного объединения.
Как разрешать конфликт полей
Условная таблица показывает рекомендуемую политику. Порядок должен быть согласован с отделами, которые используют эти данные.
| Конфликт | Предлагаемое действие | Что сохранить |
|---|---|---|
| Разные ответственные | Проверить активную сделку и распределение | Прежние значения и причину выбора |
| Два телефона | Добавить оба с пометками после проверки | Происхождение каждого |
| Пустое новое поле | Сохранить заполненное старое | Событие получения пустого значения |
| Разные потребности | Оставить отдельные запросы | Связь с общим контактом |
| Разные источники | Хранить цепочку событий | Дату и источник каждого обращения |
| Конфликт условий коммуникации | Направить на проверку | Исходные записи и основания |
Правило «побеждает самая свежая карточка» подходит далеко не для всех полей. Новая запись может содержать опечатку или быть заполнена частично. Поэтому полезнее определять приоритет по каждому типу сведений.
Условия коммуникации и обработки данных проверяют по реальной схеме проекта. Объединение записей не должно использоваться как повод автоматически расширять такие условия.
Источник обращения должен пережить объединение
Рекомендуем вести историю входных событий: время, канал, идентификатор, нужные для разбора метки перехода и связанную заявку. Для персональных данных заранее определите состав, доступ и срок хранения; исправления фиксируйте в журнале. Сводные поля контакта затем рассчитывают по выбранным правилам атрибуции.
Для условного клиента можно сохранить первое известное обращение с сайта, второе из бота и связь обоих событий с конкретными запросами. Тогда объединение карточек контакта не стирает происхождение каждой заявки.
Различайте известный источник и предполагаемый. Если метка потерялась при переходе, не заполняйте её из догадки менеджера без отметки. Поле «не определён» честнее ложной точности.
Как провести первую очистку
Перед массовым объединением выгрузите разрешённый состав данных и проверьте возможность восстановления. На небольшой группе кандидатов оцените, что происходит со сделками, задачами, историей сообщений и внешними связями.
В HubSpot, например, документация описывает объединение записей с сохранением части истории и предупреждает, что отменить объединение штатной операцией нельзя. HubSpot: Merge Records. У другой CRM могут быть иные ограничения, поэтому сценарий возврата выясняют заранее.
Фиксируйте старые идентификаторы, итоговую карточку, правило и исполнителя объединения. При синхронизации с другими системами проверьте, что следующий импорт не создаст удалённый дубль заново.
Как оценить качество правил
Возьмите выборку объединённых записей и выборку тех, которые система оставила раздельными. Первая покажет ошибочные объединения. Вторая покажет пропущенные дубли. Считать только сокращение числа карточек недостаточно.
Приёмочный результат должен показывать, что повтор события не создаёт заявку повторно, новая потребность сохраняется, источники доступны, а спорная пара попадает сотруднику. Такой набор проверок связывает чистоту CRM с сохранностью реальной работы продаж.
Источники
- HubSpot Contacts API: способы идентификации и обновления контакта.
- PostgreSQL Constraints: уникальные ограничения на сочетание полей.
- HubSpot Merge Records: последствия объединения и ограничения отмены. Правила данных и таблицы предложены редакцией.