7 ошибок в работе с MMP, которые ломают атрибуцию и отчёты

7 ошибок в работе с MMP, которые ломают атрибуцию и отчёты

MMP — это не «истина в последней инстанции», а слой правил между источниками, SDK и вашей аналитикой. Если на входе грязные события, кривые окна атрибуции и дубли, на выходе вы получите уверенные, но бесполезные цифры.

— Не сверяют имена событий между продуктом, MMP и BI: один и тот же purchase может приехать как revenue, order_paid и buy.
— Не фиксируют дедупликацию: один и тот же инсталл может пройти как click-through и view-through, а потом попасть в два отчёта.
— Не проверяют таймзоны и окно ретроспективы: из-за этого конверсии «переезжают» между днями и кампаниями.
— Слепо доверяют postback: если не смотреть raw logs, легко пропустить потери, задержки и странные re-engagement.

Ещё одна типовая ошибка — считать MMP источником оптимизации вместо источника верификации. MMP хорошо отвечает на вопрос «что произошло и где это записано», но плохо спасает от плохой семантики событий, если вы её не выстроили заранее.

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