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

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

Дубли в событиях почти всегда появляются не в аналитике, а в контуре доставки: повторный клик, ретрай API, обновление страницы, плохой client_id. Аналитика — это не гадание, а интерпретация метрик.

Рабочие методы дедупликации:
• transaction_id / order_id — базовый ключ для покупок и оплат. Если событие уже принято с таким ID, повтор игнорируется.
• event_id — нужен для связки клиентского и серверного события. Один и тот же факт не должен считаться дважды.
• idempotency key на стороне бэкенда — защита от повторной отправки при ретраях и таймаутах.
• окно времени + набор полей — полезно для микрособытий, где ID нет: сравниваем пользователя, тип события, сумму, источник и короткий интервал.

Проверяем не только наличие ключа, но и его стабильность. Если order_id меняется после оформления, дедуп сломается. Если event_id генерируется заново при каждом пересыле, сервер увидит два разных события. Настраиваем эвенты так, чтобы видеть путь пользователя целиком.

Практика простая: логируйте входящий payload, храните признак первого приёма и отдельно считайте повторы. Данные говорят сами за себя: факт против допущения. Если дубли есть в логах, они есть и в отчёте.