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

Редакция mevrica

Аналитика4 мин чтения

Обновлено 2 августа 2026 г.

Дедупликация часто смешивает две разные задачи. Первая — не посчитать одно событие дважды после retry или перезагрузки. Вторая — понять, относятся ли разные сессии к одному человеку. Первая решается стабильным event_id. Вторая требует осторожной identity policy и не должна выполняться по случайному совпадению.

Главное различие

Event identity отвечает «это тот же факт?». Person identity отвечает «это тот же субъект?». Один субъект может создать много событий, а один повторно доставленный event остаётся одним фактом.

Откуда берутся повторы

• Повторная отправка postback после timeout
• Перезагрузка страницы подтверждения
• Доставка из online и offline источника
• Повторное чтение очереди
• Ручной backfill
• Несколько обработчиков одного сообщения

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

Как должен работать event_id

Идентификатор создаётся один раз в системе, где возник факт, и проходит через все повторные попытки. Он не строится только из текущего времени обработки. Google Ads рекомендует уникальный transaction ID для отдельной транзакции и использует совпадение внутри conversion action для предотвращения повторного счёта.

Новая попытка не всегда новое событие

Повторный запрос оплаты может быть новым attempt, но относиться к одному payment intent. Изменение статуса approved после pending является новой версией решения, но не новой конверсией. Модель данных должна сохранять оба уровня вместо удаления «лишней» строки.

Опасные способы склейки людей

Одинаковый IP, устройство, язык, адрес сети или похожее поведение не доказывают одного человека. Семья, офис или мобильный оператор могут разделять признаки. Автоматическая склейка по ним искажает частоту, attribution и ограничения, а также создаёт риск неверной обработки данных.

Детерминированная и вероятностная связь

Детерминированная связь опирается на согласованный стабильный идентификатор в разрешённом контексте. Вероятностная лишь оценивает похожесть и должна храниться отдельно с уровнем уверенности. Её нельзя незаметно превращать в постоянный user_id.

Порядок расследования дублей

1. Выбрать конкретный бизнес-факт
2. Найти все записи его event_id
3. Сверить payload hash и времена доставки
4. Проверить источники повторов
5. Убедиться, что новый статус не удалён
6. Исправить идемпотентность получателя
7. Безопасно пересчитать затронутый отчёт

Что сохранять после дедупликации

Canonical event остаётся в основном слое, а попытки доставки — в техническом журнале. Отброшенная копия не исчезает бесследно: сохраняются received_at, источник и причина duplicate. Это помогает отличить сетевой retry от ошибочного двойного producer.

Проверка качества

Контролируйте долю повторов по producer, schema version и часу, количество конфликтующих payload для одного ID и число событий без идентификатора. Резкий рост после релиза должен создавать инцидент, даже если итоговый отчёт пока не удвоился.

Не лечите дубли удалением похожих строк

Две одинаковые суммы в одну минуту могут быть разными действиями. Без стабильного идентификатора безопаснее отправить строки на проверку, чем объединить их по эвристике.

Источники и границы применимости

Google Ads transaction ID and duplicate conversions: https://support.google.com/google-ads/answer/6386790?hl=ru

Вывод

Надёжная дедупликация начинается с определения бизнес-факта и стабильного event_id. Повторы доставки сохраняются как техническая история, версии статуса — как история решения, а identity человека остаётся отдельной задачей. Такое разделение предотвращает и двойной счёт, и опасную склейку разных пользователей.