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("Користувач заборонив відстеження")
            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 речення. Приклад для додатка без реклами: «Ідентифікатор використовується для аналітики та запобігання шахрайству. Дані не передаються третім особам і не використовуються для профілювання».