SKAdNetwork ломается не в трекинге, а в ожиданиях от него

SKAdNetwork ломается не в трекинге, а в ожиданиях от него

В SKAN нельзя ждать user-level атрибуции. Там работают агрегированные постбэки, ограниченное число окон и задержки, поэтому задача не «поймать пользователя», а правильно связать сигнал с кампанией, креативом и оконной логикой.

Что нужно проверить до запуска:
— campaign ID не должен смешивать разные гео, плейсменты и сильные креативные гипотезы;
— conversion value / coarse value должны отражать не «всё подряд», а один понятный путь к качеству;
— окно измерения должно совпадать с тем, когда у вас реально происходит ключевое событие;
— внутри команды должен быть один словарь: что считается install, engaged user, payer, re-engaged.

Самая частая ошибка — пытаться засунуть в SKAN привычную логику MMP: много сегментов, много разрезов, много ожиданий от отчёта. В итоге данные выглядят «бедно», хотя проблема не в сигнале, а в слишком мелкой нарезке и плохом мэппинге событий. ⚙️

Если строить SKAN как отдельную систему с собственными правилами, он перестаёт мешать и начинает работать как нормальный слой measurement.