<b>SKAN-атрибуция ломается не в SDK, а на этапе маппинга событий в конверсии</b>

<b>SKAN-атрибуция ломается не в SDK, а на этапе маппинга событий в конверсии</b>

Если postback пришёл, это ещё не значит, что атрибуция собрана правильно. Чаще всего ошибка не в сети, а в том, как MMP или внутренняя логика переводит in-app события в conversion value.

Базовый чек-лист:
— сначала фиксируйте одно целевое событие для оптимизации: install, registration, trial, purchase;
— затем строите CV-логику так, чтобы каждое окно отражало один и тот же бизнес-сигнал;
— не смешивайте в одну шкалу слишком разные события: один CV не должен означать и регистрацию, и депозит;
— проверяйте, что окна postback и тайминг события совпадают с вашей воронкой;
— отдельно тестируйте редкие события: если они слишком поздние, SKAN может их не успеть зафиксировать.

Самая частая ошибка — ожидать от SKAN user-level ясности. Он даёт агрегированную картину, поэтому смотреть нужно на распределение CV, а не на один postback. Если доля null/high CV резко меняется, проблема может быть в ивент-трекере, а не в трафике.

Ещё одна ловушка — одинаковая схема CV для всех гео и всех кампаний. В дешёвых гео и на холодном трафике воронка часто короче, и карта конверсий должна быть проще.

<blockquote>Проверка на каждый запуск: CV-карта, окно события, доля null, распределение по источникам. Если эти 4 пункта сходятся — атрибуция читается.</blockquote>