SKAN ломают не сети, а 3 типовые ошибки в настройке и чтении postback

SKAN ломают не сети, а 3 типовые ошибки в настройке и чтении postback

Первое — ждать точного user-level матчинга. В SKAN вы не ищете пользователя, вы читаете агрегат: campaign id, conversion value, coarse value, postback delay. Если команда сравнивает это с MMP-отчётом «один к одному», начинается ложная паника по CPA и ROAS.

Второе — не фиксировать карту CV до запуска. Если события, окна и приоритеты не описаны заранее, часть ранних сигналов просто теряется. Для игр обычно важны tutorial_complete, purchase, ad_revenue proxy; для утилит — registration, trial, subscription_start. Карта должна отвечать на вопрос: какое действие лучше всего предсказывает LTV на горизонте закупки.

Третье — смотреть на postback как на финальный ответ. На практике он приходит с задержкой, а в первые часы после инсталла у вас есть только прокси-сигналы: CTR, CV distribution, доля low/medium/high. Если не строить когорты по задержке и не сверять их с окнами атрибуции, можно переоценить «плохой» источник или, наоборот, перелить бюджет в шум.

Хорошая схема проста: заранее описать карту событий, отдельно валидировать источник по задержке postback, затем сравнивать не CPI сам по себе, а CPI против прогнозного LTV по cohort. Тогда SKAN перестаёт быть чёрным ящиком и начинает работать как источник управляемых сигналов.