MMM ломается не в отчётах, а в точке, где события не сходятся между собой

MMM ломается не в отчётах, а в точке, где события не сходятся между собой

Когда mobile measurement mix строят «по ощущениям», потом удивляются: installs есть, покупки есть, а в MMP, BI и рекламном кабинете разные ответы. Проблема почти всегда в том, что не зафиксирован источник правды и не описаны правила матчинга событий.

Что нужно проверить первым:
— одно ли окно атрибуции у MMP, трекера и медиаплатформы;
— одинаково ли считаются reattribution, reinstall и organic;
— не теряются ли postback и in-app events на стыке SDK, server-side и app logic;
— совпадает ли event name, timestamp и currency conversion во всех слоях.

Дальше смотрим на идентификаторы. Если IDFV, GAID, click ID и user-level events живут в разных системах без общего ключа, то расхождения будут всегда. Особенно когда часть конверсий приходит с задержкой, а часть — только по агрегированным сигналам. Тогда дашборд выглядит аккуратно, но для оптимизации он бесполезен.

Хорошая схема MMM начинается не с красивой визуализации, а с таблицы правил: какой event считаем основным, что делаем с дублями, где режем ботов, как обрабатываем late postback и кто имеет право менять логику. Один раз это описать дешевле, чем каждый раз «сверять руками».

Если у вас нет документа с правилами сопоставления, MMM превращается в набор спорящих источников. Сначала фиксируете логику, потом строите отчёты — иначе любая оптимизация будет опираться на шум.