应用追踪透明度实际管控的范围

ATT是Apple在iOS和iPadOS上强制执行的一道权限门槛。当应用希望访问设备的广告标识符（IDFA），或执行跨越其他运营商所有的应用和网站追踪用户的行为时，必须调用requestTrackingAuthorization并弹出系统提示，请求用户允许或拒绝追踪。用户的响应是二元的，在其于「设置」中主动更改之前持续有效，应用可通过trackingAuthorizationStatus API获取该状态。

Apple对「追踪」的定义

Apple的开发者指南对追踪作出了明确而狭义的界定：将从您的应用中收集的用户或设备数据，与从其他公司的应用、网站或线下资产中收集的用户或设备数据相关联，用于定向广告或测量目的；或将用户或设备数据共享给数据经纪商。该定义有意排除了对应用内数据的第一方使用、匿名聚合分析，以及出于防欺诈或法律合规目的的处理——无论用户是否授予ATT权限，这些活动均无需弹出ATT提示。

ATT不涉及的内容

ATT并非GDPR意义上的同意管理系统。它不收集细粒度的目的偏好，不记录带有政策版本的同意凭证，不向WKWebView内部的网络供应商传播信号，也不满足在用户设备上存储或读取Cookie的合法依据要求。将ATT提示视为混合应用全部合规措施的发行商，距离一张罚款通知书只差一封监管来信——因为网页视图内部的Cookie加载是ePrivacy下的独立事件，需要有自己的同意层。

GDPR和ePrivacy如何适用于WKWebView内部

混合应用内部的网页视图并不会神奇地豁免于适用桌面浏览器的规则。WKWebView一旦读写非严格必要的Cookie，ePrivacy即被触发。WKWebView一旦发出携带个人数据的分析或广告请求，GDPR即被触发。Apple的容器不会改变分析结论——改变的是实现层面，因为同意横幅必须在网页视图内部渲染，而同意状态必须对可能读取相同数据的原生代码可见。

网页视图内部的横幅

标准做法是在WKWebView内部以与网站完全相同的方式渲染CMP横幅。横幅在网页视图的Cookie存储中设置Cookie，向页面的JavaScript上下文发送同意更新事件，并更新页面分析和广告标签所读取的Google Consent Mode v2状态机。其实现与普通网页CMP并无差异——不同之处在于Cookie存储的作用域仅限于WKWebView，对其他应用和Safari不可见，这有助于隔离，但若发行商同时运营一个用户已经表达过同意的网站，则会带来不便。

网页视图与原生外壳之间的同意共享

更棘手的问题是WKWebView与原生外壳之间的桥接。原生外壳可能拥有自己的分析SDK，在用户授予ATT后读取IDFA；而网页视图拥有自己的同意横幅，用户可能接受也可能拒绝。如果用户授予ATT但在网页视图中拒绝广告同意，原生SDK仍可读取IDFA，但网页视图的标签不得触发。如果用户拒绝ATT但接受网页视图的广告同意，原生SDK被阻断，但网页视图的标签仍应触发——尽管原生SDK基于IDFA的标识符显然无法经由桥接传递。最简洁的模式是建立单一的可信来源——CMP——通过JavaScript桥接公开给原生外壳，原生外壳在应用启动时以及每次同意变更时读取该状态，同时配以平行的ATT提示，将其广告决策委托给CMP，而非重复询问。

CPRA与美国各州法律层

对于美国发行商而言，还有第三个层次。CPRA，以及随弗吉尼亚州、科罗拉多州、康涅狄格州和犹他州之后出台的一系列州法律，对IDFA的处理方式与网页Cookie相同——二者都是个人信息，其出售或共享触发退出权。网络浏览器发送的全球隐私控制（GPC）头部是面向消费者的信号，IAB的多州隐私协议（MSPA）及其关联的美国隐私字符串是面向发行商的信号。在美国上线的混合应用需要在应用内提供「请勿出售或共享我的个人信息」链接，将由此产生的退出请求同时路由到网页视图的CMP和原生外壳的测量SDK，并尊重通过深度链接到达网页视图的任何入站GPC头部。

混合应用中的儿童保护与COPPA

若应用的评级面向儿童，或合理预期存在儿童用户，美国的COPPA和欧盟的GDPR-K条款将在ATT和标准同意之上叠加额外限制。对于儿童账户，不得请求IDFA，网页视图的广告同意必须默认为拒绝，原生外壳中的任何第三方SDK在发布前均须确认符合COPPA规定。App Store审核会拒绝在儿童评级应用中显示标准ATT提示的行为，这是团队为所有受众构建单一二进制文件时常见的实现错误。

能够成功发布的工程实现模式

既能通过App Store审核、又能通过欧盟隐私审计的混合应用架构，具备少量可重复的要素。WKWebView内部的CMP横幅是广告同意的唯一可信来源。ATT提示仅在CMP完成解析后显示，仅在用户接受广告同意的情况下显示，且必须配有自定义预提示，向用户解释追踪将带来什么。JavaScript桥接在应用启动时将CMP的同意状态暴露给原生外壳，并在每次同意变更时发出事件。原生外壳的SDK同时受CMP广告同意和ATT授权状态的双重约束；任何一方拒绝请求均足以阻断SDK。

预提示与Apple准则

Apple允许——实践中也期望——在ATT系统提示之前显示一个预提示，以发行商的语气解释应用希望追踪的原因以及用户将获得的回报。一个撰写得当的预提示可以显著提升选择加入率。Apple不允许的是：预提示试图绕过系统提示、歪曲拒绝的后果，或将应用功能与追踪授权挂钩。审核员会因上述三种模式而拒绝应用，并对使用带有诱导性文案的预提示引导用户选择加入的行为越来越严格。

服务器端与SKAdNetwork作为备选方案

当ATT被拒绝或网页视图中的广告同意被拒绝时，发行商仍可退而采用SKAdNetwork进行归因——Apple的隐私保护网络在不暴露个人用户标识符的情况下提供转化数据。SKAdNetwork不受ATT约束，无论用户的同意决定如何均可正常工作，因此当个性化路径关闭时，它是测量的正确默认选项。从原生外壳到发行商自有身份服务的服务器到服务器回传也可填补测量缺口，前提是数据确为第一方数据，且未与其他运营商的数据合并以致重新落入Apple的追踪定义范畴。

引发拒绝或审计的常见错误

被下架或被罚款的混合应用往往以相同的几种方式失败。WKWebView内部的CMP横幅在ATT提示解析完成之前就触发，在Apple权限仍处于待定状态时向设备写入Cookie——这一发现可能导致App Store拒绝。ATT提示未附带预提示且在冷启动时显示，导致选择加入率低下并产生令人困惑的用户体验，进而增加流失率。原生外壳的分析SDK在CMP触发首个同意事件之前读取IDFA，在没有明确合法依据的情况下将个人数据传输出去。网页视图的同意状态与原生外壳的授权状态保存在各自独立的存储中，没有任何同步机制，导致用户虽在网页视图中拒绝了广告，但其原生广告SDK仍在运行。上述每一项都只需一到两个工程日加一轮回归测试即可修复——但每一项也都是审计员或审核员首先审查的模式。

结论

ATT和Cookie同意并非冗余的叠加层。ATT是针对特定iOS API的权限门槛，而Cookie同意是在任何浏览器类环境（包括WKWebView）中处理数据的合法依据。混合应用两者都需要，并需将它们连接在一起，让用户看到的是一个连贯的决策，而不是两个相互矛盾的提示，同时确保原生外壳和网页视图遵从同一个答案。做到这一点的发行商，其应用能够通过审核、稳定变现，且不会出现在监管机构的执法摘要中。而将ATT视为全部答案、或任由网页视图同意与原生外壳各自漂移的发行商，将在2026年的App Store审核会议与审计回应函件之间来回奔波。一次性搭好桥接，以CMP作为唯一可信来源，让ATT成为在已于网页层面保持一致的隐私立场之上的iOS特有锁定机制。