SKAdNetwork ломает аналитику не через атрибуцию, а через ошибки в настройке событий

SKAdNetwork ломает аналитику не через атрибуцию, а через ошибки в настройке событий

Первый провал почти всегда один и тот же: воронка есть, а конверсии в postback не бьются с продуктовой аналитикой. Причина обычно не в MMP, а в том, что событие для SKAN выбрано слишком рано, слишком поздно или вообще не отражает ценность пользователя.

Держите базовый чек-лист:
— определите 1–3 события, которые реально коррелируют с LTV, а не просто легко срабатывают;
— не перегружайте окно измерения: чем сложнее схема, тем выше шанс потерять сигнал;
— проверьте, что одинаковые действия в приложении не размечены разными именами;
— заранее решите, что считать валидной конверсией, если часть ивентов не доезжает.

Еще одна частая ошибка — пытаться читать SKAN как user-level отчёт. Это не такой инструмент. Здесь работают агрегаты, окна, coarse value и логика вероятности, а не привычный разбор по клику, устройству и сессии. Если команда ждёт от него детализацию как в классическом MMP, она почти гарантированно ошибётся в выводах.

На практике лучше строить схему от продукта: сначала определить целевое действие, потом привязать к нему value mapping, и только после этого крутить медиабай. Тогда postback перестаёт быть шумом и начинает показывать, где трафик реально окупается.