Apple столкнулась с антимонопольным иском в Великобритании из-за ATT? Будущее мобильной атрибуции с сохранением конфиденциальности

opoinstall
2026-09-14
5 min read

Apple столкнулась с антимонопольным иском в Великобритании из-за ATT? 3 сентября 2026 года в Апелляционный трибунал по вопросам конкуренции (CAT) Великобритании был подан иск, в котором утверждается, что рамки App Tracking Transparency (ATT) от Apple создали антиконкурентные ограничения для сторонних разработчиков, отдавая предпочтение собственному рекламному бизнесу компании. Ущерб для британских разработчиков оценивается в сумму до 2 миллиардов фунтов стерлингов. Для мобильных архитекторов, директоров по performance-маркетингу и инженеров по работе с данными внимание к теме мобильной атрибуции с сохранением конфиденциальности подчеркивает фундаментальный сдвиг в правилах привлечения пользователей на мобильных платформах. После того как ATT ограничила доступ к IDFA, заблокировав его механизмом обязательного запроса разрешения на отслеживание, экосистема мобильных приложений переориентировалась на протоколы агрегированного измерения данных на устройстве и воронки Web-to-App на основе собственных данных (first-party). Понимание того, как современная атрибуция работает без опоры на кросс-приложенческое отслеживание, требует анализа правовых рисков Apple наряду с техническими аспектами AdAttributionKit, уровнями анонимности толпы и сохранением параметров установки.

Антимонопольный иск на 2 миллиарда фунтов: правовые претензии и управление платформой

Коллективный иск, поданный в Лондоне, представляет собой серьезный вызов системе управления данными Apple. Иск был подан специально созданной организацией ATT Collective Action Limited под руководством бывшего старшего директора Управления по защите конкуренции и рынков Великобритании (CMA) Энн Поуп при поддержке юридической фирмы Hausfeld. Иск направлен на получение компенсации от имени британских разработчиков приложений, которые монетизировали свои продукты через внутриприложенческую рекламу или закупали рекламные места для продвижения iOS-приложений после внедрения ATT 26 апреля 2021 года.

Краткий обзор

  • Иск о компенсации в 2 миллиарда фунтов стерлингов: Подан в Апелляционный трибунал по вопросам конкуренции Великобритании 3 сентября 2026 года. Иск утверждает, что Apple создала неравные коммерческие условия под предлогом защиты конфиденциальности пользователей.
  • Обвинения в самопредпочтении: В иске утверждается, что сторонние разработчики столкнулись с ограничительными запросами на получение доступа к рекламным идентификаторам, в то время как собственная рекламная сеть Apple расширялась на страницах App Store без аналогичных барьеров.
  • Статус разбирательства: Иск ожидает сертификации трибуналом; обвинения остаются недоказанными в суде, а Apple отвергает претензии, утверждая, что ATT применяет одинаковые стандарты для защиты данных пользователей во всех приложениях.

Иллюстрация современных механизмов конфиденциальности и контроля отслеживания данных на мобильных платформах

Согласно отчетам Reuters и заявлениям истцов, опубликованным Hausfeld, в иске доказывается, что хотя конфиденциальность пользователей является жизненно важной защитой, Apple внедрила ATT в одностороннем порядке без должного обсуждения с индустрией, что подорвало экономический фундамент независимых издателей и разработчиков.

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

Прежде чем дело дойдет до суда, CAT должен определить, является ли иск подходящим для коллективного разбирательства. Данное дело пополнило список крупных исков против платформы, рассматриваемых трибуналом, включая апелляцию Kent v. Apple по поводу комиссии App Store и иск Which? о хранении данных в облаке.

+-------------------------------------------------------------------------+
|                  ХРОНОЛОГИЯ РЕГУЛЯТОРНЫХ СПОРОВ ATT                     |
+--------------------------+-----------------------+----------------------+
| Дата / Период            | Этап платформы        | Операционное влияние |
+--------------------------+-----------------------+----------------------+
| 26 апреля 2021           | Обязательный запуск ATT| iOS 14.5 блокирует IDFA через диалог |
| 2021–2025                | Переход экосистемы    | Снижение доступности IDFA ускоряет внедрение постбэков |
| 2024–2026                | Расширение AAK & SKAN | AdAttributionKit расширяет возможности атрибуции с несколькими окнами конверсии |
|                          |                       |                                       |
| 3 сентября 2026          | Иск в CAT             | Коллективный антимонопольный иск на £2 млрд от имени разработчиков |
| Ожидается (2026–2027)    | Сертификация CAT      | Трибунал решает вопрос о сертификации коллективного иска |
+--------------------------+-----------------------+----------------------+

Технический анализ: от детерминированного IDFA к агрегированным рамкам конфиденциальности

Чтобы оценить операционные реалии, лежащие в основе судебного разбирательства, инженерным командам необходимо разобрать, как архитектура атрибуции iOS эволюционировала до и после ATT.

Исторически мобильные рекламные сети полагались на Identifier for Advertisers (ASIdentifierManager.shared().advertisingIdentifier). IDFA — это 128-битный UUID, специфичный для устройства, который обеспечивал детерминированное измерение между различными приложениями. Рекламная сеть могла записать IDFA во время взаимодействия с рекламой, передать его провайдеру атрибуции и сопоставить с тем же IDFA, считанным при первом открытии установленного приложения, устанавливая точную связь между показом и конверсией.

Обзор инструментов разработки Apple и платформных инструментов

После вступления ATT в силу доступ к IDFA был ограничен интерфейсом ATTrackingManager.requestTrackingAuthorization. Если пользователь выбирает «Попросить не отслеживать» или если отслеживание ограничено на уровне системы, API возвращает UUID, состоящий из одних нулей (00000000-0000-0000-0000-000000000000). Поскольку показатели согласия стабилизировались на уровнях значительно ниже универсального охвата, детерминированное отслеживание между приложениями перестало быть надежной основой для масштабируемого привлечения пользователей.

Чтобы обеспечить атрибуцию кампаний без обмена идентификаторами пользователей между приложениями, Apple представила SKAdNetwork, а затем AdAttributionKit. Важно отметить, что AdAttributionKit работает независимо от статуса авторизации ATT пользователя, поскольку его результаты не содержат идентификаторов отслеживания конкретного пользователя или устройства.

Механика AdAttributionKit базируется на трех архитектурных принципах:

  1. Двойная криптографическая проверка: Рекламные сети генерируют криптографически подписанные показы рекламы с использованием JSON Web Signatures (JWS). При установке и конверсии операционная система проверяет токен показа на устройстве, а затем генерирует постбэк атрибуции, криптографически подписанный Apple, что позволяет рекламным сетям убедиться, что конверсия была сертифицирована iOS.
  2. Окна отложенной доставки постбэков: Чтобы предотвратить возможность использования рекламными сетями точных временных меток установки для проведения атак по сторонним каналам (timing attacks), постбэки отправляются после рандомизированных задержек. Apple устанавливает минимальный интервал от 24 до 48 часов между подготовкой постбэка и его получением, при этом общее время доставки увеличивается, так как окна конверсии (например, начальное 48-часовое окно) остаются открытыми, если они не заблокированы.
  3. Уровни анонимности толпы: Apple распределяет постбэки атрибуции по четырем уровням анонимности (от 0 до 3), определяемым на основе данных об источнике рекламы, рекламируемом приложении, географии установки и иерархическом идентификаторе источника. На нижних уровнях поля постбэка ограничены: значения точной конверсии (0–63) заменяются на грубые значения (low, medium, high) или полностью исключаются на уровне 0, а идентификатор источника обрезается с четырех знаков до двух.
+-------------------------------------------------------------------------+
|             ДЕТЕРМИНИРОВАННЫЙ IDFA VS. АГРЕГИРОВАННАЯ АТРИБУЦИЯ      |
+-------------------------------------------------------------------------+
|                                                                         |
|  [ ПАРАДИГМА ПРЕД-ATT: ДЕТЕРМИНИРОВАННАЯ ]                             |
|  Показ рекламы (Запись IDFA: UUID-1)                                    |
|         |                                                               |
|         v                                                               |
|  Первый запуск приложения (Чтение IDFA: UUID-1)                         |
|  Результат: Детерминированная, пользовательская, real-time атрибуция.   |
|                                                                         |
+-------------------------------------------------------------------------+
|                                                                         |
|  [ ПРОТОКОЛ ПОСТ-ATT: AdAttributionKit / SKAN ]                         |
|                                                                         |
|  Показ рекламы (JWS-токен, подписанный сетью)                           |
|         |                                                               |
|         v                                                               |
|  [ Пользователь устанавливает через App Store ]                         |
|         |                                                               |
|         v                                                               |
|  [ Атрибуция на устройстве ]                                            |
|         |                                                               |
|         |-- (Расчет окон конверсии: рандомизированная задержка 24–48ч)  |
|         |-- (Применение маскирования по уровням анонимности 0–3)        |
|         v                                                               |
|  [ Анонимный постбэк, подписанный Apple, отправлен на эндпоинт сети ]   |
|  Полезная нагрузка: Грубое значение, точное значение или Null           |
|                     Идентификатор источника (2–4 знака)                 |
|                                                                         |
+-------------------------------------------------------------------------+

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

Привлечение пользователей и граница установки по собственным данным (first-party)

Поскольку при агрегированных моделях постбэков отслеживание пользователей между приложениями стало менее информативным, команды performance-маркетинга расширили использование воронок Web-to-App. В архитектуре Web-to-App привлечение пользователя начинается на собственном мобильном веб-ресурсе компании.

Согласно правилам Apple, отслеживание определяется как связывание пользовательских данных или данных устройства, собранных из приложения одной компании, с аналогичными данными из приложений, веб-сайтов или офлайн-ресурсов других компаний в целях целевой рекламы или измерения. Когда рекламодатель направляет трафик на собственный веб-сайт (например, https://brand.example.com), это взаимодействие происходит в рамках собственных данных (first-party). Взаимодействие с пользователями, демонстрация промо-акций и захват намерений о покупке на принадлежащем домене не является отслеживанием между компаниями, при условии, что полученные данные не объединяются с наборами данных третьих сторон.

Однако перевод пользователя с мобильной лендинг-страницы в нативное iOS-приложение вводит границу установки:

+-------------------------------------------------------------------------+
|             ПУТЬ ПРИВЛЕЧЕНИЯ ПОЛЬЗОВАТЕЛЯ                              |
+-------------------------------------------------------------------------+
|                                                                         |
|  [ Пользователь на собственном веб-сайте ]                              |
|  Контекст: ?channel=partner_promo&discount=SAVE20&sku=8831              |
|         |                                                               |
|         v                                                               |
|  [ Клик по кнопке загрузки приложения ]                                 |
|         |                                                               |
|         v                                                               |
|  [ Переход в Apple App Store ]                                          |
|         |                                                               |
|         v                                                               |
|  [ ГРАНИЦА УСТАНОВКИ: Стандартный поток App Store НЕ передает          |
|    запросы URL или параметры в бинарный файл приложения ]               |
|         |                                                               |
|         v                                                               |
|  [ Пользователь впервые открывает нативное приложение (Cold Boot) ]     |
|         |                                                               |
|         v                                                               |
|  [ Механизм отложенного диплинка (Deferred Deep Linking) ]              |
|         |                                                               |
|         v                                                               |
|  [ Восстановление параметров пред-установки и онбординг ]              |
+-------------------------------------------------------------------------+

Когда пользователь переходит из Safari в App Store, стандартные потоки дистрибуции не передают произвольные строки запроса URL в установленное приложение. При первом запуске нативное приложение не может самостоятельно определить, какая веб-кампания или страница продукта направила пользователя.

Чтобы преодолеть эту границу без использования неавторизованных идентификаторов, инженерные команды внедряют архитектуры обработки ссылок:

Архитектура маршрутизации Статус приложения Сохранение параметров Архитектура конфиденциальности
Verified Universal Links Установлено Обход App Store; прямая навигация Использует HTTPS-ассоциацию домен-приложение; конфиденциальность зависит от сбора данных
AdAttributionKit / SKAN Не установлено Агрегированный постбэк; нет параметров Агрегированное измерение; задержка 24-48ч; нет контекста уровня пользователя
Deferred Deep Linking (DDL) Не установлено Восстановление параметров на первом запуске Восстановление контекста через сервер, при условии соблюдения правил платформы

В производственных архитектурах команды внедряют решения для отложенных диплинков (Deferred Deep Linking), такие как Branch, AppsFlyer, Adjust или Opoinstall. Платформа, подобная Opoinstall, фиксирует контекст кампании (такой как промо-токены или SKU продукта) на лендинге продавца перед перенаправлением пользователя в App Store.

При холодном запуске приложения клиентский SDK запрашивает бэкенд атрибуции для восстановления кэшированных параметров сессии. Согласно документации на главной странице Opoinstall, данный фреймворк сквозной передачи параметров может восстанавливать их при первом запуске в 98% случаев, предоставляя автоматизированную альтернативу ручным промокодам.

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

// Пример реализации на Swift для восстановления контекста при первом запуске.
// Использует параметры отложенной атрибуции при холодном запуске без
// опоры на постоянные рекламные идентификаторы (IDFA).

import UIKit

struct AttributionPayload: Decodable {
    let channel: String
    let campaignId: String
    let targetRoute: String
    let promoCode: String?
}

final class FirstLaunchAttributionManager {
    static let shared = FirstLaunchAttributionManager()
    
    // Флаг состояния запуска (не является атрибуционным или устройственным идентификатором)
    private let hasCompletedFirstLaunchKey = "com.app.hasCompletedFirstLaunchRestoration"
    
    private init() {}

    /// Указывает, завершено ли восстановление параметров при первом запуске
    var isRestorationPending: Bool {
        return !UserDefaults.standard.bool(forKey: hasCompletedFirstLaunchKey)
    }

    /// Отмечает процесс восстановления как выполненный
    func markRestorationCompleted() {
        UserDefaults.standard.set(true, forKey: hasCompletedFirstLaunchKey)
    }

    /// Извлекает параметры пред-установки из колбэка SDK.
    func handleDeferredAttribution(with payloadResult: Result<AttributionPayload, Error>,
                                   in window: UIWindow?) {
        guard isRestorationPending else {
            return
        }

        switch payloadResult {
        case .success(let payload):
            markRestorationCompleted()
            applyNavigationRoute(payload, in: window)
            
        case .failure(let error):
            print("Ошибка получения атрибуции: \(error.localizedDescription)")
        }
    }

    private func applyNavigationRoute(_ payload: AttributionPayload, in window: UIWindow?) {
        DispatchQueue.main.async {
            guard let navigationController = window?.rootViewController as? UINavigationController else {
                return
            }

            if payload.targetRoute.hasPrefix("products/"),
               let sku = payload.targetRoute.split(separator: "/").last.map(String.init) {
                let detailVC = ProductDetailViewController(sku: sku, promoCode: payload.promoCode)
                navigationController.pushViewController(detailVC, animated: true)
            }
        }
    }
}

Часто задаваемые вопросы (FAQ)

Какое именно нарушение инкриминируется Apple в антимонопольном иске в Великобритании?
В иске, поданном в Апелляционный трибунал по вопросам конкуренции, утверждается, что Apple занималась антиконкурентным самопредпочтением, применяя к сторонним разработчикам iOS-приложений более строгие барьеры конфиденциальности и согласия на отслеживание (ATT), чем к своим собственным рекламным сервисам. Истцы утверждают, что это неравное применение правил снизило доход от сторонней рекламы и повысило стоимость привлечения клиентов. Apple отвергает эти обвинения, настаивая на том, что ATT защищает конфиденциальность пользователей и правила применяются единообразно ко всем приложениям.
Чем AdAttributionKit отличается от Identifier for Advertisers (IDFA)?
IDFA — это идентификатор устройства, который исторически обеспечивал детерминированное отслеживание на уровне пользователей в приложениях и на сайтах разных компаний. AdAttributionKit не опирается на постоянные идентификаторы пользователей или устройств в своих постбэках. Вместо этого iOS криптографически проверяет показы рекламы на устройстве и доставляет агрегированные, задержанные и маскированные по уровням постбэки рекламным сетям, что исключает восстановление профилей пользователей между приложениями.
Как кампании Web-to-App на основе собственных данных (first-party) взаимодействуют с ATT?
Согласно политике конфиденциальности Apple, отслеживание предполагает связывание данных пользователей, собранных из одного приложения, с данными из других приложений или сайтов для целевой рекламы. Поток Web-to-App на основе собственных данных может сохранять контекст кампании без использования IDFA, когда данные остаются внутри разрешенного использования рекламодателем и не передаются третьим лицам. Отложенный диплинк восстанавливает этот контекст, но сам по себе не освобождает от требований ATT.

Стратегическое руководство для мобильных архитекторов и команд роста

Иск в Великобритании на сумму 2 миллиарда фунтов стерлингов из-за ATT отражает непреложную истину индустрии: неограниченное детерминированное отслеживание устройств между приложениями не вернется. Независимо от решений трибуналов по вопросам предпочтений платформы, мобильные операционные системы будут продолжать соблюдать строгие границы конфиденциальности.

Для мобильных инженерных команд и лидеров роста адаптация к этой среде требует трех обязательств:

  • Внедрение нативных фреймворков конфиденциальности: Используйте AdAttributionKit и SKAdNetwork в процессах закупки рекламы для захвата агрегированных конверсий без использования устаревших методов отслеживания.

  • Укрепление путей Web-to-App: Стройте устойчивые лендинг-архитектуры, фиксирующие намерения клиентов в контексте собственных данных (first-party), внедряя верифицированные Universal Links для установленных приложений и Deferred Deep Linking для поддержания непрерывности после установки.

  • Маршрутизация приложений в соответствии с намерениями: Структурируйте онбординг так, чтобы потреблять полезную нагрузку динамических параметров, а не идентификаторы уровня отслеживания, обеспечивая надежную передачу промо-скидок и глубоких ссылок через процесс «холодного» запуска.

Источники

Share this article