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

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

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

Базовый метод — idempotency key: один транзакционный идентификатор на всю цепочку событий. Его нужно передавать из источника покупки в CRM, backend и систему трекинга. Если ключ совпал, событие не создаём повторно, а обновляем уже существующую запись.

Для событий без транзакции работают составные признаки:
— user_id или client_id
— event_name
— timestamp в заданном окне
— сумма, валюта, order_id, sku
Чем стабильнее набор полей, тем ниже риск ложного дубля. Но слишком широкое окно склейки тоже опасно: можно объединить разные действия одного пользователя.

На стороне валидации проверяйте не только количество событий, но и расхождения по статусам: created, paid, refunded, canceled. Если в логах есть один order_id с разными payload, дедупликацию лучше делать по приоритету источника: backend выше клиента, серверный лог выше пикселя. Проверим в системе трекинга.

Настраиваем эвенты так, чтобы видеть путь пользователя целиком: один объект — один бизнес-факт. Любая неточность в трекинге ведет к неверным бизнес-решениям.