Conversion value mapping в SKAN ломают не на отчёте, а на первом конфликте событий

Conversion value mapping в SKAN ломают не на отчёте, а на первом конфликте событий

В SKAN у команды есть один ограниченный канал сигнала. Если в mapping пытаются уместить всё подряд — purchase, trial, signup, revenue buckets, engagement — ценность окна быстро превращается в шум.

Рабочая схема обычно такая:
— верх карты: 1–2 события, которые почти всегда случатся и дают быстрый сигнал
— середина: события для сегментации по качеству, а не для красоты
— низ: только то, что реально влияет на bid/scale decision, иначе картина размоется

Главная ошибка — строить карту от продукта, а не от решения медиабаера. Если по postback вы не можете ответить, кого масштабировать, а кого резать, значит conversion value mapping не работает. Слишком мелкая сетка даёт пустые ячейки, слишком грубая — убивает различие между cohort’ами.

Перед сборкой карты проверьте три вещи: частоту событий, задержку до сигнала и сколько из них реально проходит в окно. Если событие случается на 3-й день, а окно уже закрыто, оно полезно для BI, но бесполезно для SKAN-оптимизации.

Хорошая карта не «умещает всё». Она даёт 2–3 решения на один postback: лить дальше, менять креатив, резать аудиторию. Это и есть нормальный mapping, а не склад событий.