Singular часто ломают не SDK, а схему событий и дедупликации

Singular часто ломают не SDK, а схему событий и дедупликации

Если атрибуция «плывёт», сначала проверьте не дашборд, а основу: единые названия событий, одинаковые окна атрибуции, one source of truth для revenue и понятный postback map между MMP, MMP и BI.

Типовые ошибки:
— purchase у приложения и purchase_web считаются как одно событие;
— reattribution включена там, где нужен только install credit;
— revenue приходит из двух систем, а дедупликации нет;
— в партнёрской сети ждут event_id, а передают только название ивента.

В Singular особенно важны: корректный mapping source/medium, раздельные тестовые и боевые окна, понятные правила для SKAN и Android. Иначе один и тот же пользователь может выглядеть как новый инсталл, повторный визит и конверсия одновременно.

Перед запуском любой связки прогоняйте короткий чек-лист: кто отдаёт ивент, кто его нормализует, где хранится первичный идентификатор, и что случится, если postback придёт дважды. Если на этот вопрос нет ответа, аналитика уже врёт.