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

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

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

Базовый набор полей для дедупликации: transaction_id, event_id, user_id + timestamp, а для сложных потоков — ещё source и event_name. Приоритет простой: сначала уникальный идентификатор события, потом бизнес-ID транзакции, и только затем связка атрибутов. Ключ должен быть стабильным между клиентом, сервером и CRM.

На практике используют три метода:
• точное совпадение по event_id или order_id;
• окно времени + набор полей, если ID нет;
• идемпотентность на стороне приёмника, когда повторный запрос с тем же ключом игнорируется.
Проверим в системе трекинга: если один заказ может прийти из двух каналов, дедуп делается до записи в хранилище, а не после.

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

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