ATT iOS: что это, механизм запроса на отслеживание и IDFA

Что такое ATT (App Tracking Transparency)?

App Tracking Transparency — это фреймворк от Apple для защиты приватности пользователей, представленный в iOS 14.5. Он требует от приложений получать явное разрешение на доступ к рекламному идентификатору устройства (IDFA) перед тем, как использовать его для отслеживания.

До появления ATT разработчики могли читать IDFA без запроса, что позволяло рекламным сетям строить профили пользователей и отслеживать их активность между приложениями и сайтами. Apple назвала такой подход нарушением приватности и ввела обязательный диалог согласия.

Фреймворк доступен начиная с iOS 14.0, но обязательным для всех приложений, использующих IDFA, он стал с выходом iOS 14.5 в апреле 2021 года. По данным Flurry Analytics, после внедрения ATT менее 25% пользователей США дали согласие на трекинг, что кардинально изменило рынок мобильной рекламы.

ATT проверяет наличие разрешения через специальный системный диалог, который приложение не может модифицировать или обойти. Пользователь видит стандартный попап с текстом, предоставленным разработчиком, и выбирает «Разрешить» или «Попросить приложение не отслеживать».

Как ATT связан с приватностью в iOS

Apple позиционирует ATT как часть общей стратегии приватности, включающей также Privacy Nutrition Label в App Store и Privacy Manifest. Все три механизма работают вместе: метки показывают, какие данные собирает приложение, Manifest декларирует причины использования API, а ATT даёт пользователю контроль над трекингом.

Отказ от отслеживания не блокирует работу самого приложения — пользователь может продолжать пользоваться всеми функциями, но рекламные сети не получат IDFA для персонализации и атрибуции. Альтернативой IDFA стали SKAdNetwork и Probabilistic Attribution от самой Apple.

Согласно Branch Metrics, после внедрения ATT доля приложений, получающих IDFA, снизилась с 70% до 20% в глобальном масштабе. Это привело к пересмотру подходов к атрибуции установок и монетизации через рекламу.

Изменения в iOS 15 и 16

В iOS 15 Apple не ужесточила требования ATT, но добавила App Privacy Report — отчёт, показывающий пользователю, как часто приложения обращаются к датчикам и данным. iOS 16 расширила контроль: пользователь может в любой момент изменить настройки трекинга через Настройки → Конфиденциальность → Отслеживание.

Важно: если пользователь выбирает «Попросить приложение не отслеживать» в диалоге ATT, приложение не получает значения IDFA, а вместо него возвращается строка нулей — 00000000-0000-0000-0000-000000000000. Попытка прочитать IDFA другим способом или обходными методами ведёт к отклонению приложения в App Store.

Начиная с iOS 17, Apple усилила проверки: если приложение запрашивает IDFA без отображения системного диалога ATT, оно получает отказ на уровне ОС, а не просто пустой идентификатор. Это исключает возможность фонового сбора IDFA без ведома пользователя.

Как работает запрос на отслеживание в iOS

Процесс запроса ATT состоит из трёх этапов: проверка статуса, отображение системного диалога и обработка ответа. Разработчик не может пропустить ни один из шагов — ОС контролирует каждый этап.

Проверка статуса авторизации

Перед вызовом диалога приложение должно проверить текущий статус через ATTrackingManager. Возможные статусы: notDetermined (ещё не запрашивалось), restricted (запрещено политиками устройства), denied (пользователь отказал), authorized (разрешено).

Если статус уже определён (authorized или denied), повторный вызов диалога невозможен — пользователь сделал выбор навсегда. Единственный способ изменить решение — через системные настройки iOS.

Для проверки статуса используется свойство ATTrackingManager.trackingAuthorizationStatus. Вызов должен происходить на главном потоке, так как системный диалог является UI-компонентом.

import AppTrackingTransparency
import AdSupport

func checkTrackingStatus() {
    let status = ATTrackingManager.trackingAuthorizationStatus
    switch status {
    case .notDetermined:
        requestTrackingPermission()
    case .authorized:
        readIDFA()
    case .denied, .restricted:
        useAlternativeTracking()
    @unknown default:
        break
    }
}

Отображение системного диалога

Для показа диалога вызывается метод requestTrackingAuthorization с замыканием, которое получает результат выбора пользователя. Важно: диалог отображается только один раз. Если разработчик попытается вызвать его повторно, система проигнорирует запрос.

Текст в диалоге состоит из двух частей: системный заголовок (его нельзя изменить) и кастомное сообщение, которое разработчик указывает в Info.plist через ключ NSUserTrackingUsageDescription.

Диалог должен появляться в естественном контексте — не сразу при запуске приложения, а при первой попытке использования функциональности, связанной с трекингом. Apple рекомендует показывать диалог после того, как пользователь понял ценность функции.

func requestTrackingPermission() {
    ATTrackingManager.requestTrackingAuthorization { status in
        DispatchQueue.main.async {
            switch status {
            case .authorized:
                let idfa = ASIdentifierManager.shared().advertisingIdentifier
                print("IDFA: \(idfa)")
            case .denied:
                print("User denied tracking")
            default:
                break
            }
        }
    }
}

IDFA и ограничение доступа

IDFA (Identifier for Advertisers) — уникальный рекламный идентификатор устройства iOS, используемый для таргетированной рекламы и атрибуции установок. До ATT разработчики получали его через ASIdentifierManager без ограничений. После введения ATT доступ к IDFA блокируется, пока пользователь не даст явное согласие.

Что такое IDFA и зачем он нужен

IDFA — это UUID-строка, уникальная для каждого устройства iOS. Рекламные сети используют IDFA для: отслеживания установок приложений (атрибуция), показа релевантной рекламы на основе интересов пользователя, измерения эффективности рекламных кампаний и retargeting — возврата пользователей, которые не завершили целевое действие.

После отказа пользователя от трекинга ASIdentifierManager возвращает значение 00000000-0000-0000-0000-000000000000. При этом приложение всё ещё может читать IDFA для технических целей (например, антифрод), но не может передавать его рекламным сетям.

По данным Singular (2024), глобальный уровень согласия на ATT составляет 25-35%, при этом в Европе (GDPR) показатель выше (40-50%), чем в США (15-25%). Это заставило рекламные платформы разрабатывать альтернативные методы атрибуции.

Альтернативы IDFA: SKAdNetwork и Probabilistic Attribution

SKAdNetwork — фреймворк от Apple для атрибуции установок без раскрытия IDFA. Он работает на уровне ОС: рекламная сеть отправляет подписанный постбэк, который Apple проверяет и передаёт разработчику. Атрибуция происходит без идентификации конкретного пользователя, только на уровне кампании.

Probabilistic Attribution использует множество сигналов устройства — модель, версию iOS, часовой пояс, яркость экрана — для вероятностного сопоставления установок с рекламными показами. Однако Apple запрещает этот метод в своих правилах, и его использование может привести к отклонению приложения.

Google, Adjust и AppsFlyer разработали свои гибридные решения, комбинирующие SKAdNetwork с собственными агрегированными данными. Например, Google Ads Conversion Tracking использует SKAdNetwork постбэки и собственные модели машинного обучения для атрибуции без IDFA.

Реализация ATT в коде приложения

Для интеграции ATT требуется добавить ключ NSUserTrackingUsageDescription в Info.plist и импортировать фреймворк AppTrackingTransparency. Ниже приведены шаги для Swift и Objective-C.

Настройка Info.plist

Первый шаг — добавить в Info.plist ключ NSUserTrackingUsageDescription с текстом, объясняющим, зачем приложению нужно отслеживание. Этот текст отобразится в системном диалоге. Пример: «Ваш IDFA используется для показа персонализированной рекламы и отслеживания эффективности кампаний».

Без этого ключа вызов requestTrackingAuthorization приведёт к крашу приложения — Apple явно проверяет наличие NSUserTrackingUsageDescription перед показом диалога. Текст должен быть кратким, конкретным и соответствовать реальному использованию данных.

Важно: ключ добавляется вручную через Xcode Info tab или редактированием XML исходника Info.plist. После добавления пересоберите проект и проверьте, что ключ отображается в итоговом бинарнике.

<!-- Info.plist -->
<key>NSUserTrackingUsageDescription</key>
<string>This identifier is used to deliver
personalized ads and measure campaign performance.</string>

Полная интеграция на Swift

В реальном проекте запрос ATT лучше вызывать перед первым запуском рекламного модуля или трекера. Рекомендуется предварительно объяснить пользователю ценность согласия на отдельном экране (pre-permission prompt) — это повышает процент согласий на 20-30%.

Pre-permission prompt — это собственный UI, который показывает выгоду от включения трекинга («Помогите нам показывать релевантную рекламу»). Только после нажатия кнопки «Продолжить» вызывается системный диалог ATT. Adjust (2024) зафиксировал рост согласия на 40% при использовании pre-permission экрана.

final class TrackingManager {
    static let shared = TrackingManager()

    func requestTrackingIfNeeded() {
        guard ATTrackingManager.trackingAuthorizationStatus
            == .notDetermined
        else { return }

        ATTrackingManager.requestTrackingAuthorization { _ in
            NotificationCenter.default.post(
                Notification(Name("trackingStatusChanged"))
            )
        }
    }
}

Ошибки при работе с ATT

Разработчики часто допускают типовые ошибки при интеграции ATT, которые приводят к снижению конверсии согласий или к отклонению приложения модераторами App Store. Разберём пять самых распространённых проблем.

Запрос ATT сразу после запуска приложения

Самая частая ошибка — показывать системный диалог ATT в первый же экран после загрузки приложения. Пользователь ещё не понимает ценности приложения и с высокой вероятностью нажимает «Отказать». IronSource (2023) показал снижение согласия на 32% при запросе на первом экране по сравнению с запросом после третьего сеанса.

Рекомендация: запрашивать трекинг после того, как пользователь совершил целевое действие (просмотрел контент, начал прохождение онбординга) или после 3-5 сессий использования приложения. Это повышает доверие и осознание ценности.

Отсутствие pre-permission экрана

Показ системного диалога ATT без предварительного объяснения — ошибка, которая снижает конверсию до 15-20%. Пользователь видит неожиданный запрос и инстинктивно отказывается. Pre-permission экран с объяснением выгоды повышает согласие до 35-45%.

Текст pre-permission должен быть конкретным: «Разрешите показывать релевантную рекламу — это помогает нам оставаться бесплатными». Избегайте общих фраз — они снижают доверие. GameAnalytics в 2023 году показал, что pre-permission с объяснением выгоды даёт на 28% больше согласий, чем пустой экран.

Игнорирование статуса restricted и denied

Если пользователь уже отказал в трекинге или статус restricted (родительский контроль, корпоративные политики), приложение не должно повторно вызывать диалог ATT. Повторный вызов не работает и воспринимается как нарушение приватности. Вместо этого переключайтесь на SKAdNetwork и контекстную рекламу.

В статусе restricted приложение не может определить, включена ли опция «Разрешить запросы на отслеживание» в настройках. В этом случае всегда используйте безальтернативную атрибуцию через SKAdNetwork и не показывайте pre-permission экран.

Проверка IDFA без вызова ATT

Чтение IDFA через ASIdentifierManager.shared().advertisingIdentifier без предварительного разрешения ATT возвращает строку нулей. Некоторые разработчики пытаются использовать старые методы доступа к IDFA через приватные API — это гарантированно приводит к отклонению приложения при ревью.

Apple использует статический анализатор кода и машинное обучение для поиска обходных путей. Даже если приложение проходит ревью, последующие обновления или автоматические проверки могут выявить нарушение и привести к бану аккаунта разработчика.

Некорректный текст NSUserTrackingUsageDescription

Слишком длинный, расплывчатый или вводящий в заблуждение текст в ключе NSUserTrackingUsageDescription — причина отклонения приложения модераторами. Apple проверяет, что описание соответствует реальному использованию данных. Если в приложении нет рекламы, но указано «для рекламных целей», модератор отклонит сборку.

Рекомендуемый формат: конкретное описание цели использования IDFA длиной 2-3 предложения. Пример для приложения без рекламы: «Идентификатор используется для аналитики и предотвращения мошенничества. Данные не передаются третьим лицам и не используются для профилирования».