Postback delay в SKAN ломает оптимизацию быстрее, чем плохой креатив

Postback delay в SKAN ломает оптимизацию быстрее, чем плохой креатив

В SKAN сигнал приходит не тогда, когда юзер сделал событие, а когда Apple решает его отправить. Из-за этого у баера в первые часы после запуска почти всегда неполная картина: install уже есть, а postback по нему ещё в пути.

Три типовые проблемы:
• early ROAS выглядит хуже реального, потому что конверсии из хвоста ещё не доехали
• алгоритм режет рабочий ad set раньше, чем он набрал статистику
• CV mapping начинает шуметь: одно и то же окно даёт разные выводы по дням

Что делать на практике:
— не принимать решение по SKAN-кампании по короткому окну; смотрите минимум 24–72 часа
— сравнивайте не только current day, но и лагированные когорты
— держите отдельный лог по time-to-postback: если хвост длинный, оптимизация должна быть медленнее
— не смешивайте iOS-кампании с разной скоростью постбэка в один вывод по крео

Если postback delay не учтён, вы оптимизируете не трафик, а задержку атрибуции. В SKAN сначала надо дождаться данных, потом уже жать стоп.