SKAN-атрибуция ломается не в postback, а в логике ожиданий команды

SKAN-атрибуция ломается не в postback, а в логике ожиданий команды

SKAN не даёт user-level путь, поэтому его нельзя читать как классический MMP-отчёт. Рабочая схема такая: сначала задаёте окна измерения, потом выбираете, какие ранние события реально двигают conversion value, и только после этого строите выводы по закупке.

Основные ошибки в атрибуции:
— сравнивать SKAN installs с raw installs один к одному;
— ждать, что postback покажет всю воронку;
— менять карту conversion value без фиксации версии схемы;
— оптимизировать кампанию по слишком позднему событию, которое приходит за пределами окна.

Если в первые часы после инсталла у вас есть только часть сигнала, не пытайтесь угадать LTV по одному postback. Лучше собрать компактную схему: 1–3 ранних события, 1 событие качества и понятный rule-based маппинг CV. Тогда даже при задержке и агрегировании отчёт остаётся читаемым.

Ещё один важный слой — проверка источника правды. Сравнивайте не только SKAN-отчёт, но и cohort-метрики: retention, payer rate, time-to-purchase, долю органики. Если все три слоя не сходятся, проблема обычно в разметке событий или в том, как MMP сопоставляет окно атрибуции.

Лучший подход — держать SKAN как систему раннего сигнала, а не как финальный отчёт о прибыли. Тогда атрибуция перестаёт спорить с аналитикой и начинает ей помогать.