Как на самом деле работает SKAdNetwork: гайд по iOS-аналитике без розовых очков

Аналитика SKAdNetwork работает с агрегированными и задержанными постбэками, а не с пользователями. Об установке вы узнаете conversion value - число от 0 до 63; каждое обновление CV обнуляет 24-часовой таймер, затем iOS добавляет случайную задержку от 0 до 24 часов, и постбэк приходит в рекламную сеть и MMP через 24-48 часов, иногда позже, и без user_id. Поэтому значения расшифровывает и привязывает к расходам MMP, а склейка с событиями Firebase происходит в BigQuery, не внутри самого Firebase.

Когда вышла iOS 14.5 с окном App Tracking Transparency (ATT), привычная атрибуция через IDFA сломалась. Сейчас SKAdNetwork (SKAN) от Apple остался единственным способом хоть как-то оценить эффективность рекламы на iOS. Нам всем пришлось забыть об отслеживании конкретных пользователей и учиться работать с общими когортами и задержанными данными. Если ваша команда научится грамотно связывать данные SKAN, MMP и Firebase, вы перестанете сливать бюджет в пустоту и сможете нормально оптимизировать CAC.

Контекст: с чем мы столкнулись

До ATT все было просто: пользователь кликал по рекламе, сеть отдавала ID устройства (IDFA) в MMP, а после установки MMP склеивал клик и конверсию со 100% точностью.

Новая реальность со SKAN выглядит иначе:

1. Агрегация данных: мы больше не видим конкретного пользователя. Данные прилетают общими пачками.
2. Задержка постбэков: уведомления о конверсии специально задерживаются на 24-48 часов (иногда дольше), чтобы мы не могли вычислить пользователя по времени установки.
3. Ограничение событий: появилась система Conversion Values (ценность конверсии). Это просто число от 0 до 63. И у вас есть совсем небольшое окно, чтобы передать в этом числе самую важную информацию.

Естественно, возникает вопрос: как быстро оптимизировать рекламные кампании, если результат прилетает только через пару дней и в таком урезанном виде?

Deep Dive: как это работает под капотом

Чтобы нормально работать со SKAN, нужно понимать весь путь данных от клика до дашборда. Здесь участвуют устройство (iOS), сама Apple, рекламная сеть и ваш MMP.

Таймеры SKAN: почему постбэк опаздывает

Conversion value, два таймера и задержка 24-48 часов

1. Первый запуск

   стартует 24h таймер

   • CV 0-63

2. Действия в app

   CV растет только вверх

   апдейт сбрасывает таймер

   • reset 24h

3. Случайный таймер

   еще 0-24 часа

   защита от вычисления

   • lag 24-48h

4. Постбэк

   в сеть и MMP

   агрегированная пачка

   • без user_id

Каждое обновление CV обнуляет таймер: данных больше, постбэк позже.

Оценивайте когорту на 3-4 день - daily-оптимизация на SKAN не работает.

Логика таймеров и Conversion Values (CV)

В основе SKAN лежит система Conversion Values (CV). Как только пользователь впервые открывает приложение, запускается 24-часовой таймер. Любое важное действие (регистрация или покупка) может обновить значение CV, но только в большую сторону.

Важный нюанс: каждое успешное обновление CV обнуляет 24-часовой таймер. Мы собираем больше данных о поведении, но еще сильнее оттягиваем момент отправки постбэка.

Когда пользователь перестает совершать нужные действия и таймер истекает, iOS запускает второй, случайный таймер (от 0 до 24 часов). Постбэк уходит в рекламную сеть и MMP только после его завершения. Именно из-за этого случайного таймера цифры в рекламных кабинетах всегда запаздывают.

Путь интеграции (SKAN + MMP + Firebase)

Без нормальной инфраструктуры данные SKAN так и останутся непонятными числами от 0 до 63. Наша задача - расшифровать их, привязать к расходам на рекламу и положить в основную аналитику (Firebase, GA4 или BigQuery).

Роль MMP (AppsFlyer, Adjust, Branch)

MMP здесь работает как центральный хаб:

• Настройка маппинга CV: в кабинете MMP вы задаете правила. Например, CV 1 = "Регистрация", CV 2 = "Покупка < $10".
• Сбор постбэков: сети присылают SKAN-постбэки в MMP, а он их расшифровывает по вашим правилам.
• Склейка данных: MMP объединяет эти данные со своими атрибуциями и расходами из рекламных кабинетов.

Интеграция с Firebase и BigQuery

Так как в SKAN-постбэках нет user_id или app_instance_id, мы не можем просто так взять и связать их с сессиями пользователей в Firebase. Правильная архитектура строится через хранилище:

SKAN + MMP + Firebase через BigQuery

Не пушим SKAN-события в Firebase - сводим сырые данные в хранилище

1. SKAN-постбэки

   сети шлют в MMP

   CV без user_id

   • агрегаты

2. MMP

   AppsFlyer, Adjust

   маппинг CV в события

   расходы кабинетов

   • Data Locker
   • Pull API

3. BigQuery

   raw data из MMP

   события Firebase

   • единая модель

4. Отчеты

   Blended ROAS

   pLTV по когортам

   • окна 3-7 дней

В SKAN-постбэке нет user_id - склейка возможна только на уровне агрегатов.

Сырые данные MMP и Firebase сводятся в BigQuery в Blended ROAS.

Вместо того чтобы пытаться пушить события SKAN напрямую в Firebase, мы выгружаем сырые данные из MMP (через Data Locker или Pull API) и сырые события из Firebase в единую базу - BigQuery. И уже там собираем агрегированные отчеты вроде Blended ROAS.¹ Blended ROAS рассчитывается как отношение всего сгенерированного дохода к общим расходам на рекламу.

Оптимизировать кампании в реальном времени - плохая идея. Из-за задержек SKAN адекватно оценить когорту можно только на 3-4 день после установки. Дайте кампаниям время.

Что делать дальше

Маркетологам:

• Оценивайте кампании окнами по 3-7 дней, забудьте про daily-оптимизацию.
• Сфокусируйтесь на прогнозировании LTV (pLTV). Найдите те действия в первые 24 часа, которые лучше всего говорят о будущих покупках, и настройте на них Conversion Values.
• Смотрите на Blended ROAS (Общий доход / Общий бюджет) для оценки картины в целом.

Аналитикам:

• Настройте выгрузку Raw Data из MMP в Google BigQuery.
• Соберите единую модель данных, которая свяжет расходы из кабинетов, SKAN-постбэки и события из Firebase.

Разработчикам:

• Проверьте, что SDK MMP инициализируется сразу после старта приложения. Иначе вы потеряете начало окна установки.
• Показывайте запрос ATT (App Tracking Transparency) в правильный момент онбординга, чтобы пользователи охотнее давали согласие на трекинг.

Секрет в том, чтобы выйти за рамки старых метрик атрибуции и собрать стек на базе BigQuery, который будет нормально работать даже при жестких ограничениях приватности.

Источники

1. Firebase & BigQuery Integration Guide