Conversion value mapping в SKAN ломается не из-за Apple, а из-за вашей логики событий

Conversion value mapping в SKAN ломается не из-за Apple, а из-за вашей логики событий

В SKAN конверсия — это не “все события подряд”, а жёсткий бюджет сигналов. Команды, которые мапят туда покупки, регистрации, туториал и ещё 10 микроивентов, быстро упираются в шум: value становится частым, а полезного сигнала мало.

Рабочая схема обычно строится сверху вниз:
— 1–2 ранних события, которые реально коррелируют с LTV
— 1 событие на платёжный факт
— 1–2 ветки на глубину вовлечения, если платёж позже
— остальное — в modeled layer, а не в value mapping

Главная ошибка — пытаться запихнуть в CV всё, что трекает MMP. Тогда postback показывает активность, но не помогает оптимизировать CPI и ROAS. Лучше заранее выбрать, какие действия отвечают за сегментацию трафика: payer, engaged non-payer, churn risk, high-intent. И уже под них резать 6–8 бит, а не “максимум доступных” ради красоты.

Проверьте mapping на трёх вопросах: 1) событие случается достаточно часто; 2) оно стабильно связано с доходом; 3) оно не дублирует соседнюю ступень. Если на один CV у вас попадает и free trial, и первый платёж, и возврат в приложение, оптимизация начнёт стрелять в пустоту.

Хороший mapping не должен быть длинным. Он должен быть различимым для аукциона и полезным для закупки.