SKAdNetwork и AdAttributionKit: отчетность по iOS-трафику в 2026

Если вы льете iOS-трафик на приложение или работаете с app-offer'ами, отчетность по конверсиям выглядит как черный ящик: инсталлы есть в бэкенде, но в рекламном кабинете ноль, а цифры приезжают сутками позже и агрегированно. За это отвечают два фреймворка Apple - SKAdNetwork и AdAttributionKit. Разбираем, как они устроены внутри, куда теряются данные и как читать их отчетность, не сравнивая ее с Android напрямую.

Смежные материалы: MMP vs affiliate tracker, атрибуция без cookies, event_id и дедупликация.

Что такое SKAdNetwork и AdAttributionKit?

После того как ATT (App Tracking Transparency) отрезал массовый доступ к IDFA, связку "клик - инсталл - событие" нельзя восстановить на стороне сервера по идентификатору устройства. Apple заменила эту механику на privacy-preserving схему:

• Решение об атрибуции принимает сама iOS на устройстве, а не сеть или трекер.
• Результат приезжает агрегированным postback'ом: без device ID, без user-level данных, с ограниченным набором полей.
• Fingerprinting запрещен условиями App Store - попытки восстановить идентификацию через отпечатки устройства ведут к реджекту приложения.

При этом для вызова API атрибуции ATT-разрешение не требуется: приложение вызывает их независимо от статуса трекинга пользователя. Это официальная позиция документации AdAttributionKit.

Практическое следствие для медиабайера: iOS-отчетность всегда агрегированная и отложенная. Вопрос не в том, какой фреймворк выбрать, а в том, как правильно читать то, что он отдает.

Чем отличается AdAttributionKit от SKAdNetwork?

Ключевой факт, который путает даже опытных покупателей трафика: отдельной версии "SKAN 5" не существует. Слухи о ней ходили после WWDC 2023, но Apple такую версию так и не выпустила - развитие ушло в новый фреймворк. В официальных release notes SKAdNetwork перечислены только версии 1-4.

Ядро механики совпадает полностью: те же три конверсионных окна, те же пороги приватности, тот же формат fine и coarse conversion value. Apple прямо называет SKAdNetwork предшественником и рекомендует сетям мигрировать на новый фреймворк, сохраняя совместимость: зарегистрированный SKAN-идентификатор рекламной сети работает в обоих фреймворках.

Для покупателя трафика это значит одно: спор "SKAdNetwork или AdAttributionKit" некорректен. Выбор делает экосистема - сеть и SDK приложения. Ваша задача - понимать общую механику отчетности, она одна на оба фреймворка.

Как устроен postback: окна и задержки?

Механика окон - центральная вещь, которую нужно понять перед чтением любых iOS-цифр:

1. Первое окно открывается при инсталле и длится два дня. Приложение может обновлять conversion value до закрытия окна; более поздние обновления попадают во второе и третье окна.
2. Второе окно покрывает дни 3-7, третье - дни 8-35. В них доступен только coarse conversion value.
3. После закрытия каждого окна устройство добавляет случайную задержку и только потом отправляет postback: 24-48 часов для первого, 24-144 часа для второго и третьего.

Отсюда типовой сценарий: кампания запущена сегодня, реальные postback за нее приедут между вторым и шестым днем, а полная картина по трем окнам - примерно через шесть недель с учетом задержки. Любая оценка кампании раньше этих сроков - оценка по modeled-цифрам платформы, а не по измерению.

Lock window меняет правило игры в первом окне: приложение может зафиксировать conversion value заранее, postback готовится немедленно и последующие обновления игнорируются. Это способ получить быстрый сигнал ценой потери поздних событий.

Атрибуция по клику дает устройству 30 дней на инсталл, по показу - 24 часа. После инсталла у приложения есть 60 дней, чтобы отправить первое обновление conversion value. Для re-engagement в AdAttributionKit окно короче - 2 дня на первое обновление.

Что такое crowd anonymity tiers и куда деваются данные?

Crowd anonymity - механизм, который чаще всего объясняет "пропавшие" конверсии. Уровень tier вычисляется на устройстве в момент загрузки и определяет состав полей первого postback:

Три следствия, которые важно держать в голове:

• Пороговые значения Apple нигде не публикует. Проверка происходит на устройстве в реальном времени, и единственный способ подняться на высокий tier - увеличить объем однородного трафика.
• Система сама выбирает длину source identifier: считает tier для 2-, 3- и 4-значных вариантов и берет лучший. При низких tier'ах длинный идентификатор все равно обрезается до двух цифр - то есть до 100 значений на всю структуру кампаний.
• Структура кампаний "много мелких адсетов под каждый креатив", привычная по Android, на iOS ломает сбор данных: каждая ветка набирает слишком мало объема, чтобы пройти порог. Концентрация бюджета в меньшем числе кампаний - прямой способ получить больше данных.

Как уместить конверсии в 6 бит: fine и coarse conversion value?

Conversion value задает разработчик приложения: каждый значимый in-app событие переводится в число 0-63. Budget из 64 значений распределяется между всем, что вы хотите измерить. Типовая схема от MMP выглядит так:

• Градации дохода: например, покупки разбиваются на бакеты по сумме. Классический legacy-мэппинг AppsFlyer: от $1 до $63 шагом $1 или от $1 до $630 шагом $10.
• Ключевые события: регистрация, триал, подписка - каждое получает свои значения.
• Приоритеты: компонент priority ранжирует события так, чтобы более ценное перезаписывало менее ценное - high-priority измерение вытесняет low-priority.

Coarse value - это ответ Apple на проблему низких tier'ов: даже когда точное значение недоступно, устройство передает грубую оценку low/medium/high во всех трех окнах. Практический вывод: coarse-градации стоит мапить на осмысленную шкалу, например low = событие есть, medium = средний чек, high = крупный чек.

Распространенная ошибка - примитивная схема: одно событие активации без fine-значений. Такая кампания технически работает, но оптимизировать по ней нечего: платформа не видит разницы между пустым инсталлом и целевым действием. Обратная ошибка - пытаться впихнуть каждую вариацию суммы покупки как отдельное значение и остаться без бюджета на ключевые события.

Где строить схему при работе с несколькими сетями - вопрос из реальной практики. Ответ зависит от стека: если в цепочке есть MMP, схема строится там и раздается сетям; без MMP каждую сеть настраивают отдельно, и консистентность значений между сетями теряется. Разбор ролей MMP и трекера - в статье MMP vs affiliate tracker.

Нужно ли переезжать с SKAdNetwork на AdAttributionKit?

Документация Apple описывает совместимость явно: идентификаторы сетей форматов .skadnetwork и .adattributionkit работают в обоих фреймворках, система сортирует впечатления из обоих источников вместе и выбирает одного победителя атрибуции, а вызовы обновления conversion value зеркалятся из SKAdNetwork в AdAttributionKit. Показательный факт: Apple Ads сам зарегистрировался как рекламная сеть в AdAttributionKit весной 2025.

Что реально дает переезд:

1. Re-engagement: атрибуция повторных открытий приложения по клику с iOS 18. Отдельный conversion-type=reengagement в postback, лимиты на месяц на приложение и год на устройство. Для ретеншн-кампаний это первая нативная возможность измерить возвраты без MMP-моделирования.
2. Альтернативные маркеты: если приложение распространяется вне App Store (требование DMA в EU), SKAdNetwork его просто не видит.
3. Конфигурируемые правила: AttributionWindows позволяет сузить стандартные 30 дней кликового окна до 1-30 дней, AttributionCooldown - задать паузу между засчитанными конверсиями от 0 до 720 часов.
4. Тестирование: development postbacks в Settings > Developer на устройстве генерируют постбеки без реальной рекламы, с симуляцией tier'ов. Задержка в тестовом режиме сокращается до минут вместо суток.

Технически миграция - работа SDK и рекламной сети, не покупателя. Со стороны медиабайера достаточно убедиться, что используемая сеть отправляет трафик через AdAttributionKit, где это возможно, и что MMP корректно разбирает новые поля postback.

Почему цифры iOS не сходятся с бэкендом?

Типовой сценарий расхождения: за три дня бэкенд насчитал сотни инсталлов, кабинет показывает ноль. Причины складываются независимо:

1. Задержка postback: первый postback едет 24-48 часов после закрытия окна, второй и третий - до 144 часов. Данные за неделю могут приехать на третьей неделе.
2. Приватные пороги: часть трафика ушла в Tier 0-1, откуда платформа получила минимум полей или ничего.
3. Modeled data: платформы достраивают картину моделями, и на уровне ad set и объявления SKAN-цифры по признанию самих практиков не являются измерением.
4. Дополнительные слои: в EU платформы дополнительно агрегируют данные из-за консент-ограничений, а server-to-server биллинг подписочных сервисов конфликтует с on-device SKAN - ради дедупликации такие сервисы отключают автоматическое логирование событий в SDK, и фреймворк физически перестает получать данные для постбеков.

Антипаттерны чтения отчетности, которые дорого обходятся:

• Реакция на дневные колебания ROAS при живых задержках postback - алгоритм платформы получает обратную связь с лагом и корректируется циклами. Рабочий подход практиков: rolling-окна от пяти дней.
• Прямое сравнение с Android: Android-кампании в тех же гео живут на device-level атрибуции, iOS - на агрегированной. Разница уровней, а не поломка трекинга.
• Оптимизация креативов по ad-level SKAN-данным TikTok или Snap: это экстраполяция платформы, а не измерение.

SKAN-отчетность стоит считать направленным индикатором и сверять с бэкендом на фиксированном окне, например раз в неделю по когортам инсталла.

Чек-лист для privacy-limited iOS-кампаний

1. Проверьте, что conversion schema вообще настроена: в Meta это SKAdNetwork-схема в Events Manager, где единственное событие Activate App - красный флаг примитивной настройки.
2. Сконцентрируйте бюджет: меньше кампаний и адсетов - выше шанс пройти порог crowd anonymity и получить полный source identifier с fine value.
3. Распределите 64 значения осознанно: приоритет ценным событиям, градации дохода бакетами, coarse-шкала с понятным смыслом.
4. Не оценивайте кампанию раньше 72 часов: первый postback еще в пути, все, что показывает кабинет, - моделирование.
5. Сверяйтесь с бэкендом на фиксированном окне: недельные когорты вместо дневных графиков.
6. Не оптимизируйте по ad-level SKAN-цифрам: только campaign-level измерение, для креативов - собственные инструменты или гео-сплиты.
7. Используйте development postbacks в AdAttributionKit (iOS 18.4+) для проверки настройки без слива бюджета.

Если вы льете веб-трафик через прелендинги на app-offer, помните: SKAN закроет только финальный инсталл. Вся цепочка до стора - клики, преленды, суб-ID - живет в трекере, и качество сигнала туда определяется настройкой передачи конверсий, о чем подробнее в статье server-side tracking vs browser pixel.

Как это связано с Most?

SKAdNetwork и AdAttributionKit отвечают за одну ногу iOS-воронки: инсталл и in-app события внутри приложения. Все, что происходит до установки - клики, прелендинги, маршрутизация, суб-ID, - живет в вашем трекере, и конверсии оттуда нужно доставлять в рекламные платформы серверным путем, чтобы алгоритмы получали сигнал быстрее, чем это делают агрегированные postback.

Most автоматизирует именно этот последний этап: доставку конверсий из Keitaro и других трекеров в Meta CAPI и TikTok Events API с правильными идентификаторами, таймингом и дедупликацией. Бесплатный ручной инструмент для проверки пикселя - Pixel Activator, автоматизация доставки - Most.

Если трафик на приложение заливается через веб-прокладку - например, через решение класса OneLink - связать вебовую часть воронки с MMP-атрибуцией можно через трекер. При переходе MMP генерирует свой идентификатор клика и передает его в офер в Keitaro как sub-ID. Keitaro сохраняет идентификатор на клике, а при конверсии отправляет его обратно в MMP по S2S-постбеку. Так данные вебовой части воронки - прелендинги, суб-аккаунты, офферы - склеиваются с атрибуцией инсталла: в трекере видно не только факт конверсии, но и какая кампания или креатив за ней стоит. Для SKAN-кампаний это дополнительный слой сигнала поверх агрегированных постбеков Apple.

Summary

iOS-отчетность без IDFA навсегда останется компромиссом между приватностью и гранулярностью. Проигрывают те, кто ждет от нее device-level точности; выигрывают те, кто выстроил схему конверсий, концентрирует объемы и сверяет агрегаты с собственными данными.

Sources