苹果因 ATT 面临英国反垄断诉讼?探究隐私保护下的移动归因未来

opoinstall
2026-09-14
5 min read

苹果因 ATT 面临英国反垄断诉讼?2026 年 9 月 3 日,英国竞争上诉法庭(CAT)收到了一项集体诉讼请求,指控苹果的 App Tracking Transparency (ATT) 框架对第三方开发者施加了反竞争限制,同时偏袒其自身的广告业务,并估算给英国开发者造成了高达 20 亿英镑的损失。对于移动架构师、效果营销负责人及数据基础架构工程师而言,围绕隐私保护移动归因(Privacy-Preserving Mobile Attribution)的种种审查,凸显了移动端获客逻辑的本质转变。在 ATT 将 IDFA 访问权限置于显式跟踪授权之后,移动生态系统已转向基于设备的聚合测量协议和第一方 Web-to-App 发现路径。要评估在不依赖跨应用追踪的情况下如何实现现代化的归因功能,就需要审视苹果面临的法律风险,并剖析 AdAttributionKit、人群匿名等级(crowd anonymity tiers)以及安装边界参数持久化等技术细节。

20 亿英镑的英国反垄断诉讼:法律指控与平台治理

在伦敦提交的这项集体诉讼标志着对苹果平台数据治理的重大法律挑战。该诉讼由名为 ATT Collective Action Limited 的特殊目的实体发起,由英国竞争与市场管理局(CMA)前高级主管 Ann Pope 主持,并由 Hausfeld 律师事务所提供咨询。该诉讼代表自 2021 年 4 月 26 日 ATT 推出以来,通过应用内广告变现或购买广告投放以驱动 iOS 应用安装的英国开发者寻求赔偿。

概览

  • 20 亿英镑赔偿诉求:于 2026 年 9 月 3 日在英国竞争上诉法庭提交的这项“退出型”集体诉讼指控苹果以消费者隐私为名,制造了不公平的商业竞争环境。
  • 自我偏好指控:诉讼称,第三方开发者在获取广告标识符时受到限制性弹窗的束缚,而苹果自有的广告网络在 App Store 页面内扩张时却无需面对同等阻碍。
  • 诉讼状态:该诉讼尚待法庭认证;相关指控尚未在法庭上得到证实,苹果已否认了这些指控,并坚持认为 ATT 对所有应用执行一致的数据保护标准。

现代移动平台隐私与数据跟踪控制示意图

根据 路透社 的报道以及 Hausfeld 发布的原告声明,该诉讼认为,尽管消费者隐私是一项至关重要的保护,但苹果在未经充分行业协商的情况下单方面引入 ATT,扰乱了独立发布商和开发者的经济基础。

苹果否认了这些指控,称 App Tracking Transparency 旨在让用户能够精细化掌控外部应用是否可以在第三方平台跟踪其活动。苹果坚称,包括苹果自身在内的所有开发者都必须遵守关于跨公司跟踪的相同规则,且 ATT 已获得全球隐私倡导者的认可。

在诉讼进入庭审前,CAT 必须判定该诉讼是否符合集体诉讼程序。该案与法庭审理的其他平台诉讼案(如 Kent v. Apple 应用商店佣金上诉案以及 Which? 云存储诉讼案)同属一类。

+-------------------------------------------------------------------------+
|                  ATT 监管争议时间线                    |
+--------------------------+-----------------------+----------------------+
| 日期 / 周期            | 平台里程碑    | 运营影响   |
+--------------------------+-----------------------+----------------------+
| 2021年4月26日           | ATT 强制启动  | iOS 14.5 将 IDFA 权限置于显式授权对话框之后 |
| 2021–2025                | 生态系统转型  | IDFA 可用性降低,推动回传机制应用|
| 2024–2026                | AAK 与 SKAN 扩展  | AdAttributionKit 扩展多转化窗口  |
|                          |                       | 归因报告能力                             |
| 2026年9月3日        | CAT 集体诉讼  | 代表英国开发者发起 20 亿英镑反垄断诉讼  |
| 待定 (2026–2027)      | CAT 认证     | 法庭评估是否认证该集体诉讼|
+--------------------------+-----------------------+----------------------+

技术解析:从确定性 IDFA 到聚合隐私框架

为了评估诉讼背后的运营现实,工程团队必须剖析 iOS 归因架构在 ATT 实施前后的演变。

历史上,移动广告网络依赖于广告标识符(ASIdentifierManager.shared().advertisingIdentifier)。IDFA 是一种设备专用的广告标识符(表现为 128 位 UUID),能够在不同应用间实现确定性测量。广告网络可以在广告交互时记录 IDFA,将其传回给归因服务商,并在用户打开新安装的应用时与查询到的相同 IDFA 进行匹配,从而建立广告曝光与转化之间的确定性关联。

苹果开发者软件框架与平台工具概览

当 ATT 生效后,IDFA 的访问权限被置于 ATTrackingManager.requestTrackingAuthorization 接口之后。如果用户选择“要求应用不跟踪”,或者在系统层面限制了跟踪,API 将返回一个全零的 UUID (00000000-0000-0000-0000-000000000000)。随着用户授权率远低于全民覆盖水平,确定性的跨应用跟踪不再是大规模获客的可靠基石。

为了在不共享跨应用用户身份的情况下提供广告系列归因,苹果引入了 SKAdNetwork 以及随后的 AdAttributionKit。值得注意的是,AdAttributionKit 的运行独立于用户的 ATT 授权状态,因为其输出不包含任何用户或设备专用的跟踪标识符。

AdAttributionKit 的机制基于三个核心架构原则:

  1. 双重加密校验:广告网络使用 JSON Web Signatures (JWS) 生成经过加密签名的广告曝光记录。在安装和转化时,操作系统会在设备端验证曝光令牌,并随后生成由苹果加密签名的归因回传(postback),允许广告网络验证该转化已由 iOS 认证。
  2. 延迟回传投递窗口:为了防止广告网络利用精确的安装时间戳执行旁路时序攻击,回传会在随机延迟后进行调度。苹果规定从回传准备到接收之间存在 24 到 48 小时的随机间隔,由于转化窗口(如初始的 48 小时窗口)在锁定前始终开放,总投递时间可能进一步延长。
  3. 人群匿名数据等级:苹果将归因回传分配至四个人群匿名等级(等级 0 到等级 3)之一,该等级由广告来源、广告应用、安装地域和层级源标识符的状态决定。在较低等级中,回传字段会受到限制:精细转化值(0 到 63)被替换为粗略值(lowmediumhigh)或在等级 0 中被完全省略,且源标识符从四位被截断为两位。
+-------------------------------------------------------------------------+
|             确定性 IDFA 与聚合隐私归因对比       |
+-------------------------------------------------------------------------+
|                                                                         |
|  [ ATT 前确定性范式 ]                                     |
|  广告曝光 (记录 IDFA: UUID-1)                                   |
|         |                                                               |
|         v                                                               |
|  应用首次启动 (读取 IDFA: UUID-1)                                  |
|  结果:确定性、用户级、实时广告归因。           |
|                                                                         |
+-------------------------------------------------------------------------+
|                                                                         |
|  [ ATT 后聚合协议: AdAttributionKit / SKAN ]              |
|                                                                         |
|  广告曝光 (网络签名 JWS 令牌)                               |
|         |                                                               |
|         v                                                               |
|  [ 用户通过 App Store 安装 ]                                        |
|         |                                                               |
|         v                                                               |
|  [ 设备端归因处理 ]                                   |
|         |                                                               |
|         |-- (计算转化窗口: 随机 24–48 小时延迟)    |
|         |-- (应用人群匿名等级 0–3 字段掩码)            |
|         v                                                               |
|  [ 发送至网络端的匿名苹果签名回传 ]     |
|  载荷: 粗略值、精细值或空 (取决于等级)            |
|           源标识符 (2–4 位)                                |
|                                                                         |
+-------------------------------------------------------------------------+

虽然 AdAttributionKit 旨在衡量广告系列效果并减少用户级数据暴露,但其延迟回传和聚合报告特性对实时算法竞价提出了运营挑战。

下游移动获客与第一方安装边界

由于在聚合回传模型下跨应用用户跟踪的数据保真度降低,效果营销团队扩大了对 Web-to-App 转化链路的依赖。在 Web-to-App 架构中,用户获取始于自有第一方移动网页。

根据苹果的隐私指南,跟踪(Tracking)特指为了定向广告或测量目的,将从某家公司的应用收集的用户或设备数据,与从其他公司的应用、网站或线下资产收集的用户或设备数据进行关联。当广告主将流量引导至其自有网站(例如 https://brand.example.com)时,该交互发生在第一方语境下。只要生成的数据未与第三方数据集结合,在自有域名下吸引用户、提供促销优惠及捕获购买意向并不构成跨公司跟踪。

然而,将用户从第一方移动落地页引导至原生 iOS 应用时,会引入安装边界:

+-------------------------------------------------------------------------+
|             离散的下游移动获客路径              |
+-------------------------------------------------------------------------+
|                                                                         |
|  [ 用户抵达第一方移动网页 ]                          |
|  捕获上下文: ?channel=partner_promo&discount=SAVE20&sku=8831      |
|         |                                                               |
|         v                                                               |
|  [ 用户点击应用下载行动号召 ]                            |
|         |                                                               |
|         v                                                               |
|  [ 重定向至 Apple App Store ]                                        |
|         |                                                               |
|         v                                                               |
|  [ 安装边界: 标准 App Store 下载流程不会传递 URL 查询参数或自定义字符串至 App ]    |
|         |                                                               |
|         v                                                               |
|  [ 用户首次打开原生应用 (冷启动) ]                   |
|         |                                                               |
|         v                                                               |
|  [ 延迟深度链接引擎 (服务端辅助恢复) ]         |
|         |                                                               |
|         v                                                               |
|  [ 合格的预安装参数恢复与自动 onboarding ]     |
+-------------------------------------------------------------------------+

当未安装应用的用户从 Safari 切换到 App Store 时,标准分发流程不会将任意 URL 查询字符串转发到已安装的应用包中。在首次启动时,原生应用无法自动识别是哪个具体的网页广告系列或产品页面引导了用户。

为了在不依赖未经授权的跨公司跟踪标识符的情况下跨越该边界,工程团队实现了不同的链接处理架构:

路由架构 用户应用状态 安装前后的参数保留 平台隐私架构
已验证通用链接 (Universal Links) 已安装目标应用 绕过 App Store;直接场景导航 使用已验证的 HTTPS 域名到应用关联;隐私取决于数据收集及后续使用
AdAttributionKit / SKAN 未安装目标应用 聚合回传;无自定义查询参数 聚合广告系列测量;至少 24–48 小时延迟回传;无行级上下文
延迟深度链接 (DDL) 未安装目标应用 在首次冷启动时恢复合格的预安装参数 服务端辅助的合格预安装上下文恢复,受服务商实现和平台规则约束

在生产架构中,开发团队会部署延迟深度链接框架,如 Branch、AppsFlyer、Adjust 或 Opoinstall。像 Opoinstall 这样的平台会在用户被重定向到 App Store 之前,在商家的落地页上捕获合格的广告系列上下文(如促销令牌或产品 SKU)。

在应用首次冷启动时,客户端 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)
            }
        }
    }
}

// 示例视图控制器消费已恢复的广告系列状态
class ProductDetailViewController: UIViewController {
    private let sku: String
    private let promoCode: String?

    init(sku: String, promoCode: String?) {
        self.sku = sku
        self.promoCode = promoCode
        super.init(nibName: nil, bundle: nil)
    }

    required init?(coder: NSCoder) { 
        fatalError("init(coder:) 未实现") 
    }

    override func viewDidLoad() {
        super.viewDidLoad()
        view.backgroundColor = .systemBackground
        title = "产品: \(sku)"
        
        if let code = promoCode {
            // 应用从网页落地页传递的促销折扣
            print("自动应用已恢复的优惠码: \(code)")
        }
    }
}

常见问题解答 (FAQ)

英国反垄断诉讼指控苹果违反了什么特定规则?
提交给英国竞争上诉法庭的诉讼指控苹果实施了反竞争的“自我偏好”,即苹果在 ATT 下对第三方 iOS 应用开发者施加了比其自身广告服务更严格的隐私和跟踪授权障碍。原告主张这种不平等的执法行为削弱了第三方广告收入,并抬高了获客成本。苹果否认了这些指控,并坚持认为 ATT 保护了消费者隐私,且其规则在所有应用中均一致适用。
AdAttributionKit 与广告标识符 (IDFA) 有何不同?
IDFA 是一种设备专用的广告标识符,历史上用于在不同公司拥有的应用和网站间实现确定性的用户级跟踪。AdAttributionKit 在其回传中不依赖持久的用户或设备专用标识符。相反,iOS 在设备端对广告曝光进行加密验证,并向广告网络发送聚合、延迟且具有层级掩码的回传,从而防止了跨应用个人用户画像的重构。
第一方 Web-to-App 广告系列如何与 ATT 交互?
根据苹果的隐私政策,“跟踪”特指为了定向广告或测量目的,将从某家公司的应用收集的用户或设备数据,与从其他公司的应用或网站收集的数据进行关联。第一方 Web-to-App 链路在数据保持在广告主允许的第一方使用范围内、且未与其他第三方数据集关联以进行跨公司跟踪时,可以在不依赖 IDFA 的情况下保留合格的广告系列或目的地上下文。延迟深度链接可以恢复此第一方上下文,但它本身并不能使归因行为免于 ATT 的范畴。

为移动架构师与增长团队提供策略建议

因 ATT 引发的 20 亿英镑英国诉讼反映了一个持久的行业真相:不受限制的跨应用确定性设备跟踪将不再复现。无论法庭对平台自我偏好裁定如何,移动操作系统都将继续强制执行严格的隐私边界。

对于移动工程团队和增长负责人而言,适应当前环境需要三个技术承诺:

  • 采用平台原生隐私框架:在广告采买流程中集成 AdAttributionKit 和 SKAdNetwork,以捕获聚合广告系列转化,而无需依赖被弃用的跟踪实践。

  • 加强第一方 Web-to-App 链路:构建稳健的网页落地架构,在第一方语境下捕获用户意向,为已安装用户部署已验证的通用链接,并利用延迟深度链接在应用安装过程中保持连续性。

  • 使应用路由适配用户意向:将原生 onboarding 结构化为消费动态参数载荷,而非依赖身份级跟踪令牌,从而确保促销折扣和深度链接目的地能够透明且可靠地穿过冷启动序列。

参考资料

Share this article