SKAN ломается не на атрибуции, а на неверной интерпретации postback

SKAN ломается не на атрибуции, а на неверной интерпретации postback

Первое правило: смотрите не на один postback, а на всю цепочку. В SKAN ранний сигнал часто отражает факт установки, а не качество пользователя. Если conversion value пустой или слишком низкий, это не всегда «плохой трафик» — иногда событие просто не успело попасть в окно.

Второе: сопоставляйте задержку postback с окном конверсии. Когда вы меняете схему событий, сравнение «до/после» без учета окна дает ложный вывод. Один и тот же источник может выглядеть хуже, если вы перенесли ключевое событие за пределы capture window.

Третье: не смешивайте кампании с разной логикой value mapping. Если в одной группе вы кодируете регистрацию, а в другой — первый purchase, отчёт по blended ROAS будет шуметь. Для чистого сравнения нужен одинаковый набор событий и одинаковая политика таймаутов.

Четвертое: проверяйте долю незаполненных или низких CV отдельно по источникам. Если у сети выше share пустых postback, это может быть проблемой матчинга, а не качества инвентаря. Сравнивайте не только installs, но и распределение CV по диапазонам.

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