SKAN ломается не в postback, а в настройке окна, CV и источника маппинга

SKAN ломается не в postback, а в настройке окна, CV и источника маппинга

Если атрибуция выглядит «плавающей», проверьте не сеть, а базовую схему: одно и то же событие должно попадать в один и тот же conversion value; окно измерения не должно конфликтовать с логикой монетизации; а правила для ранних и поздних событий — быть раздельными. Иначе вы сравниваете не кампании, а ошибки маппинга.

Минимальный чек-лист перед масштабированием:
— CV-карта покрывает первые 24–72 часа жизни юзера
— в карте нет дублей событий с одинаковой ценностью
— revenue-события не смешаны с engagement-событиями без приоритета
— postback-лог проверяется не по одному инсталлу, а по выборке

На практике самая частая проблема — слишком агрессивная детализация. Когда на один CV приходится много сценариев, SKAN начинает «сглаживать» сигнал, и вы теряете разницу между качественным и шумным трафиком. Лучше меньше уровней, но с понятной бизнес-логикой: install, trial, purchase, high value.

Ещё одна ошибка — смотреть на атрибуцию только в разрезе сети. Сравнивайте связку сеть + кампания + креатив + окно конверсии. Тогда видно, где postback приходит стабильно, а где сигнал распадается на границе раннего события. Настройка должна отвечать на вопрос: какой источник даёт не просто install, а install с нужной вероятностью LTV.