<b>Singular ломается не в дашборде, а в грязной схеме событий и атрибуции</b>

<b>Singular ломается не в дашборде, а в грязной схеме событий и атрибуции</b>

Если подключаете MMP как Singlular, сначала фиксируйте не “красивый отчёт”, а модель данных. У одного и того же события должны быть: единое имя, единые параметры, единый смысл. Иначе отчёты начинают расходиться уже на уровне installs, re-engagement и revenue.

Три места, где чаще всего ошибаются:
— смешивают app event и custom event с похожими названиями;
— отправляют в MMP события без стабильного user_id / device_id;
— меняют логику постбека, не обновляя схему у медиабаинга и BI.

Отдельно проверьте окна атрибуции и порядок приоритетов. Если источник трафика, SKAdNetwork и web-to-app живут по разным правилам, вы получите не “несовпадение цифр”, а три разных правды в одной воронке. Это особенно больно, когда команды смотрят на разные отчёты и спорят не про качество трафика, а про методологию.

Минимальный чек-лист:
— одно событие = одно действие;
— одинаковые нейминги в app, MMP и BI;
— заранее описанные postback rules;
— отдельный контроль дублей и late events;
— регулярная сверка cohort-логики между источниками.

Если у вас “поехал” Singular, почти всегда сначала лечится не интеграция, а дисциплина схемы.