Дедупликация транзакций: как не считать один и тот же event дважды

Дедупликация транзакций: как не считать один и тот же event дважды

Дубли в трекинге чаще всего появляются не из-за «плохого пикселя», а из-за логики отправки: повторный клик, refresh страницы, ретрай на стороне клиента, параллельный пуш из CRM и браузера. Аналитика — это не гадание, а интерпретация метрик.

Основные методы дедупликации:
— уникальный transaction_id или order_id для каждой покупки;
— event_id для событий, где одна транзакция может уйти из разных источников;
— серверный idempotency key, чтобы повторный запрос не создавал новую запись;
— сравнение ключевых полей: сумма, валюта, пользователь, время в допустимом окне.

Правило простое: дедупликация должна жить на стороне приема, а не только в интерфейсе отчета. Если источник шлет дубль, но хранилище его не режет, downstream-метрики уже искажены. Проверим в системе трекинга: ищем одинаковые ключи, одинаковые payload и повторные статусы доставки.

Отдельно контролируйте сценарии с отложенной отправкой: офлайн-конверсии, ретраи webhook, повторная синхронизация из очереди. Там лучше использовать связку из id события + временного окна + статуса обработки. Безопасность и полнота данных — наш приоритет при проектировании инфраструктуры.

Настраивайте дедупликацию на уровне схемы событий и регулярно сверяйте сырые логи с витриной: только так можно отделить реальную конверсию от технического повтора.