После обновления SDK сумма по purchase_succeeded выросла почти в 2 раза, но платёжный провайдер этого не подтверждает. Что наиболее вероятно и какое действие по качеству данных самое уместное?

AПользователи стали покупать чаще после обновления SDK, и рост purchase_succeeded по user_id отражает реальный спрос в продукте
BСтоит подождать неделю: метрики purchase_succeeded и revenue «усреднятся» сами и расхождение с провайдером исчезнет без правок
CНужно удалить все события с одинаковым event_time в одном user_id, потому что такие совпадения почти всегда означают дубликат на стороне сервера
DВероятна повторная отправка событий (at-least-once); нужен уникальный event_id или dedup_key и дедупликация в пайплайне приёма событий
Правильный ответ. Дубликаты часто возникают из-за повторной отправки при сетевых ретраях, поэтому нужна дедупликация через event_id или dedup_key.

Разбор

Если источник истины (провайдер) не подтверждает рост, это сильный сигнал, что проблема в инструментировании или в обработке событий. Удаление по event_time опасно: реальные покупки могут происходить близко по времени, а часы на устройстве могут быть неточными. Правильнее закладывать дедупликацию на уровне идентификаторов события и транзакции. Затем инварианты по уникальности order_id помогут автоматически ловить повторения.

Тренировать продукт в Telegram

Ещё вопросы по теме «Инструментация и качество данных»