Атрибуция mobile‑трафика ломается не в MMP, а в ваших событиях и правилах матчинга

Атрибуция mobile‑трафика ломается не в MMP, а в ваших событиях и правилах матчинга

Заказчики часто ждут от трекера «истину», но атрибуция держится на трёх вещах: корректный event schema, стабильные ID и одинаковая логика дедупликации между SDK, сервером и рекламной сетью. Если хотя бы один слой живёт по своим правилам, ROAS начинает врать.

Проверьте базу:
— event names и параметры должны быть одинаковыми в продукте, MMP и BI;
— purchase, trial и signup нельзя смешивать в один «conversion»;
— postback не должен дублировать событие, которое уже улетело server-to-server;
— окно атрибуции, lookback и re-attribution должны быть согласованы для всех каналов.

Отдельно смотрите на идентификаторы. Для iOS это обычно SKAdNetwork-логика, для Android — advertising ID, но в реальности всё упирается в качество consent, доступность ID и то, как MMP матчится на click/install. Чем больше «unknown», тем важнее не гнаться за последним касанием, а смотреть на cohort-уровень и инкрементальность.

Если отчёты спорят между собой, сначала ищите не «ошибку в модели», а расхождение в правилах: разные таймзоны, разные окна, разные источники truth. Один и тот же инсталл может стать тремя разными конверсиями, если система настроена без общего договора.

Держите атрибуцию как инженерный контур: один словарь событий, одна логика дедупа, одна таблица приоритетов каналов. Тогда MMP перестаёт быть источником магии и становится просто аккуратным счетчиком.