Если одна и та же конверсия живёт в CRM, MMP и кабинете, сначала договоритесь о главном: какой ID считается источником истины. Без этого одно событие уедет в три отчёта и превратится в «рост», которого не было.
Рабочая схема обычно такая:
— CRM хранит факт сделки и статус оплаты
— MMP ловит установку, in-app и связку с устройством
— платформа получает только то событие, которое нужна ей для оптимизации
Ключ к дедупликации — стабильный набор связок: click_id, external_id, order_id, user_id. На стороне CRM и MMP нужен один и тот же order_id или transaction_id, иначе вы не сможете склеить повторную отправку, офлайн-апдейт и postback в один логический заказ. Ещё важно заранее решить, какое окно повторной отправки допустимо и кто отсекает дубликат: интеграция, трекер или сервер.
Проверяйте три типовых сбоя: 1) один заказ отправляется и по вебхуку, и по ручному апдейту; 2) MMP шлёт reinstall как новую конверсию; 3) рекламная платформа принимает событие без уникального ключа и считает его отдельно. Если есть расхождения, первым делом сравнивайте не суммы, а сырые ID и время создания события.
Лучше один раз зафиксировать правила дедупликации в схеме данных, чем потом вручную объяснять, почему в отчётах три разных правды.
Attribution Lens
@AttributionLens
Как дедуплицировать конверсии между CRM, MMP и рекламными платформами без потери атрибуции
Этот пост опубликован в Telegram-канале Attribution Lens. Подписаться можно по ссылке: @AttributionLens.