SKAdNetwork ломается не в постбеке, а в логике атрибуции

SKAdNetwork ломается не в постбеке, а в логике атрибуции

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

Базовый чек-лист:
— заранее определить, какое событие будет главным для оптимизации;
— не пытаться тащить слишком много конверсий в один postback;
— держать логику window conversion value простой и однозначной;
— отдельно проверить, что события внутри фида реально доходят до окна измерения.

Самая частая поломка — когда команда строит воронку под привычный MMP-отчет, а потом ждет от SKAN той же гранулярности. В итоге теряются не только конверсии, но и доверие к данным: отчеты начинают спорить друг с другом, а байинг — с продуктом.

Для запуска лучше собирать схему от ответа на один вопрос: какое действие действительно предсказывает LTV? Всё остальное — вспомогательные сигналы. Чем меньше лишних веток в conversion mapping, тем проще потом читать postback и искать, где именно отваливается атрибуция.

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