Singular ломается не в отчёте, а в вашей схеме трекинга

Singular ломается не в отчёте, а в вашей схеме трекинга

Если MMP показывает «красивые» конверсии, а баинг не сходится с revenue, проблема часто не в платформе, а в архитектуре: кто отправляет постбек, какой event считается источником истины и где теряются user_id, gclid, click_id или deep link параметры.

Проверьте базу:
— одно событие должно быть «главным» для атрибуции, а остальные — вспомогательными;
— окна атрибуции по инсталлу и ретеншну должны быть согласованы с продуктовой аналитикой;
— callback'и и server-to-server события не должны дублировать друг друга;
— для re-engagement отдельно фиксируйте окно и правила дедупликации;
— в fraud-фильтрах важнее не «жёсткость», а одинаковая логика для всех источников.

Отдельный источник боли — SDK и MMP одновременно. Если клиентская логика и серверная логика спорят за один и тот же ивент, отчёт начнёт «прыгать»: где-то появятся лишние инсталлы, где-то исчезнут покупки, а воронка перестанет быть сопоставимой между сетями.

Перед запуском новой связки прогоняйте не только тест-инсталл, но и полный путь: клик, first open, ключевой in-app event, purchase, reattribution. Если на одном шаге ID меняется или пропадает, Singular будет считать по правилам, которые вы сами ему дали.

Главное правило простое: сначала фиксируете схему данных, потом спорите про качество трафика. Երբ источник истины один, атрибуция перестаёт быть гаданием.