SKAdNetwork ломается не в отчёте, а в настройке событий и окон

SKAdNetwork ломается не в отчёте, а в настройке событий и окон

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

Что проверять в первую очередь:
— есть ли карта ивентов под воронку, а не просто набор «популярных» действий;
— не слишком ли рано вы отправляете сигнал, из-за чего теряете данные по качеству пользователя;
— умеет ли команда читать coarse/fine conversion value как модель, а не как факт;
— совпадает ли логика между продуктом, MMP и BI, иначе постбек «правильный», а выводы — нет.

Главная ошибка — строить отчётность вокруг одного события. В SKAdNetwork лучше работает связка: ранний сигнал для оптимизации + поздний сигнал для оценки качества. Тогда можно разделять объёмы, конверсии и удержание, а не спорить с тем, почему «атрибуция пропала».

Ещё одна типовая ловушка — тестировать схему на одном источнике и считать её универсальной. У разных каналов разная скорость отклика, разное окно до ценности и разная доля пустых постбеков. Сначала проверьте карту на нескольких типах трафика, потом закрепляйте правила.

Если коротко: SKAdNetwork нужно проектировать как систему сигналов, а не как поле в дашборде.