Singular ломается не в отчётах, а в схеме событий и постбеков

Singular ломается не в отчётах, а в схеме событий и постбеков

У MMP типа Singular почти всегда проблемы начинаются не с «плохой атрибуции», а с кривой модели данных. Если в app event naming живёт по принципу «как назвал разработчик», потом аналитик, потом UA — дедупликация и валидация начинают врать.

Проверь базовые вещи:
— install, reattribution и in-app events должны быть разделены не на словах, а в логике интеграции;
— одно и то же событие не должно улетать разными именами из iOS и Android;
— revenue, trial, subscribe и purchase лучше нормализовать до одной схемы, иначе отчёты будут «плыть»;
— постбек на сеть должен приходить с теми же правилами, по которым событие считалось в MMP, а не по фантазии ad network.

Отдельно смотри на окна атрибуции и приоритеты. Если source of truth не зафиксирован, один и тот же конверт может попасть в разные каналы в зависимости от порядка обработки, а не от реального вклада.

Ещё одна типовая ошибка — доверять интерфейсу больше, чем raw export. Для сверки нужны хотя бы: сырые события, настройки postback mapping и список исключений по fraud-protection. Иначе любой спор по инкрементальности превращается в спор о том, «как у кого называется purchase».

Если в Singular нет единой схемы событий, это не проблема отчёта — это проблема трекинга. Сначала выравнивай таксономию, потом уже спорь с MMP.