SKAdNetwork ломается не в постбеке, а в вашей логике маппинга

SKAdNetwork ломается не в постбеке, а в вашей логике маппинга

SKAdNetwork нужен не «для галочки», а чтобы собрать install- и post-install-сигналы без user-level трекинга. Ошибка №1 — пытаться читать его как обычную атрибуцию: там нет привычных кликов, нет полного пути пользователя, а окно измерения короткое и жёстко ограниченное.

Базовый чек-лист:
— заранее определите, какие события реально двигают conversion value;
— не пихайте в CV всё подряд, оставьте 1–3 ключевых сигнала;
— разделяйте схемы для D0, D1–D2 и более длинных окон, если продукт это позволяет;
— проверяйте, что события приходят в правильном порядке, а не только «вообще приходят».

Ещё один типовой провал — когда media buying и продукт живут в разных картах событий. Байер оптимизируется на purchase, а приложение пишет в CV onboarding complete. В итоге отчёт вроде есть, а оптимизация идёт вслепую. Для SKAdNetwork важна не «богатая» схема, а согласованная: одно событие = один смысл = одно решение в закупке.

И главный совет: сначала спроектируйте схему измерения, потом креативы и бюджет. Если CV-карта не отвечает на вопрос, что произошло после инсталла, то postback превращается в шум, а не в сигнал.