<b>MMM ломается не в пикселях, а в границах ролей: где искать источник правды</b>

<b>MMM ломается не в пикселях, а в границах ролей: где искать источник правды</b>

MMM часто считают «системой, которая просто собирает всё», но на практике она отвечает только за свой кусок цепочки. Если у вас есть сайт, приложение, CRM и офлайн-лиды, почти всегда начинают спорить три слоя: рекламная платформа, трекер и MMP.

Чтобы не утонуть в расхождениях, зафиксируйте роли:
— рекламная платформа отвечает за клик и показ;
— трекер — за маршрут лида и постбэк;
— MMP — за установку, in-app событие и атрибуцию внутри приложения.

Дальше проверьте три вещи: окно атрибуции, источник timestamp и логику дедупликации. Если один и тот же лид прилетает через web-view, app и CRM, без правил приоритета цифры будут расползаться даже при идеальной передаче событий. Особенно часто ломается связка, где purchase есть в CRM, но не проходит в MMP из-за задержки или потери идентификатора.

Полезная привычка — рисовать не воронку, а схему решений: откуда приходит id, где он сохраняется, кто его режет, и в какой точке событие становится «истиной». Это быстрее выявляет баги, чем бесконечная сверка отчетов.

Если источник правды не назначен заранее, его назначат расхождения. И почти всегда это будет самый неудобный для вас отчет.