Дубли данных между системами: идемпотентность и внешний ID

Короткий ответ

Дубли данных между системами предотвращаются пятью техническими правилами: хранить в системе-приёмнике идентификатор записи из источника (внешний ID); вместо простого создания использовать операцию «обновить, если есть, иначе создать» (upsert); давать каждому событию уникальный ключ идемпотентности, чтобы повторная отправка не создавала вторую запись; при двусторонней синхронизации помечать, откуда пришло изменение, чтобы не возникал бесконечный цикл; регулярно делать отчёт сверки. Эти правила не решают бизнес-дубли — когда один человек пишет из трёх каналов; они защищают от дублей, которые создают сами системы.

Два вида дублей

Первый вид — бизнес-дубль: один клиент пишет в Instagram и WhatsApp, и появляются две карточки. Его предотвращают правила на входе — о них в статье о дублях лидов. Второй вид — технический: обращение пришло один раз, а интеграция создала его в приёмнике дважды. Эта статья — о втором виде.

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

Откуда берутся технические дубли

• Повторная отправка: отправитель не получил ответа и отправил событие снова, а получатель создал оба.
• Цикл двусторонней синхронизации: A обновляет B, B возвращает изменение в A как «новое», A отправляет снова.
• Параллельный импорт: один файл загружен дважды или двумя людьми.
• Нет общего ключа: приёмник не знает, приходила ли запись раньше.
• Два процесса одновременно: два обработчика берут одно событие в один момент.

Правило 1: внешний ID

Когда запись попадает в приёмник, её идентификатор в источнике сохраняется в отдельном поле: «источник: чат-платформа, ID: 48213». Когда тот же ID приходит снова, приёмник не создаёт новую запись, а находит существующую. Телефон и email тоже могут быть ключами, но они меняются, а внешний ID — нет. Надёжнее всего использовать оба: внешний ID как основной ключ, телефон — как запасную проверку.

Правило 2: upsert

Вместо операции «создать» используется «обновить, если есть, иначе создать». Приёмник сначала ищет по ключу: если запись есть — обновляет, если нет — создаёт. Многие CRM предлагают это из коробки — например, HubSpot при импорте обновляет контакт с тем же email, а не создаёт новый. Без upsert каждая повторная отправка — новая запись.

Правило 3: ключ идемпотентности

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

Правило 4: защита от циклов синхронизации

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

Правило 5: отчёт сверки

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

Иллюстративный пример

Это иллюстративный пример. Интернет-магазин передаёт лиды из чат-платформы в CRM через webhook. Руководитель продаж замечает, что некоторые клиенты в CRM появляются дважды. Расследование показывает: CRM иногда отвечает с задержкой, чат-платформа, не получив ответа, отправляет событие снова, а CRM создаёт оба как новые лиды.

Исправление: в CRM добавляют поле «внешний ID», интеграция использует upsert вместо создания, а получатель 24 часа помнит обработанные ID событий. Еженедельный отчёт сверки показывает, что расхождение сократилось до нуля.

Типичные ошибки

• Считать технический дубль тем, что «клиент написал дважды».
• Сопоставлять только по имени.
• Настроить повторы без идемпотентности.
• Синхронизировать все поля в обе стороны.
• Удалять дубли вручную, не исправив причину, — завтра они вернутся.

Ограничения

Эти правила зависят от возможностей обеих систем: если приёмник не поддерживает upsert или поле внешнего ID, может понадобиться промежуточный сервис. Очистка уже существующих дублей — отдельная работа, она разобрана в статье о дублях карточек в CRM. В среде из многих систем полная согласованность достижима редко, поэтому отчёт сверки должен быть постоянным.

Кто отвечает

Владелец технических дублей — владелец интеграции, обычно IT или сторона, построившая интеграцию. Бизнес-пользователи, увидев дубль, не должны его удалять, а должны сообщить владельцу интеграции: каждый дубль — доказательство для поиска причины. Отчёт сверки тоже уходит владельцу интеграции, а кто расследует расхождение, договариваются заранее.

Дубли в Vexvon

В Vexvon, если в той же компании есть открытый лид с тем же номером, новый лид привязывается к нему как дубль; при импорте CSV повторяющиеся номера проверяются во время загрузки; в правилах автоматических звонков есть окно дедупликации на уровне компании. Статус webhook, приходящих из каналов, отслеживается, а неудачные обрабатываются повторно. Для webhook, которые Vexvon отправляет в систему компании, правила upsert и идемпотентности на стороне получателя согласуются вместе в плане интеграции. Подробнее — интеграции.

Следующий шаг

Выполните в приёмнике один запрос: сколько записей с одинаковым телефоном или ID источника и через сколько секунд друг после друга они созданы? Разница в несколько секунд — признак технического дубля. Другие статьи — в разделе о корпоративной интеграции; интеграцию можно проверить вместе во время демо.