Дедупликация транзакций и событий: 4 метода, которые защищают отчёт от дублей

Дедупликация транзакций и событий: 4 метода, которые защищают отчёт от дублей

Дубли появляются не только из-за повторного клика. Их дают ретраи, повторная отправка после таймаута, восстановление сессии, дубли в очереди и ошибки на стороне клиента. Аналитика — это не гадание, а интерпретация метрик, поэтому сначала фиксируем правило уникальности.

1) event_id или transaction_id — базовый ключ. Если событие может прийти повторно, сервер и клиент должны отправлять один и тот же идентификатор. Тогда система трекинга отсекает повтор по ключу, а не по имени события. 2) Составной ключ: пользователь + объект + время + тип события. Подходит, когда уникального id нет, но требует аккуратного округления времени.

3) Хэш полезной нагрузки. Сравниваем сумму полей, которые реально определяют факт: сумма, валюта, товар, заказ, источник. Метод хорош для логов и очередей, но ломается, если в payload есть нестабильные поля вроде timestamp или session_id. 4) Окно дедупликации по времени. Если одинаковые события пришли в коротком интервале, оставляем первое или последнее — по выбранной бизнес-логике.

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