SKAdNetwork ломается не в атрибуции, а в подготовке событий до отправки

SKAdNetwork ломается не в атрибуции, а в подготовке событий до отправки

Если смотреть на SKAN как на замену MMP, почти всегда получаете шум. Полезнее считать его каналом с жёсткими правилами: вы не “читаете пользователя”, а собираете сигнал, который ещё нужно правильно закодировать.

Перед запуском проверьте три вещи:
— какие события реально влияют на LTV, а не просто красиво выглядят в BI;
— укладывается ли вся логика в ограничение по конверсионным значениям;
— есть ли у команды единая схема: кто меняет mapping, кто валидирует postback, кто сравнивает сырые и агрегированные данные.

Ошибка №1 — пытаться запихнуть в один slot и ранний активационный сигнал, и монетизацию, и сегмент. Ошибка №2 — менять логику событий без версии и без фиксации даты переключения. Ошибка №3 — сравнивать SKAN-отчёт с user-level атрибуцией как будто это один и тот же источник.

Если нужен стабильный результат, сначала стройте матрицу: 1) окно, 2) событие, 3) ценность, 4) правило обновления. Потом тестируйте не “точность”, а читаемость сигнала для медиабаинга 📌