AppsFlyer 移动归因与 Cookie 同意：2026 年应用发行商集成指南
对于应用开发商而言，移动测量与网页测量是性质截然不同的问题。网页发行商担心的 Cookie 在原生应用内并不存在，但取而代之的标识符——IDFA、GAID、IDFV、安装 ID、哈希邮箱、IP 衍生设备指纹——同样引发相同的法律问题，并受相同的监管机构管辖。AppsFlyer 是移动游戏、金融科技及消费类应用中部署最广的移动测量合作伙伴，处于整个数据管道的核心位置。其 SDK 采集归因级标识符，服务器将这些标识符与广告网络的回传数据关联，最终的归因结果为各大渠道的用户获取预算提供依据。上述所有处理均须具备合法依据，而 GDPR 和 ePrivacy 指令真正要求的合法依据是同意——须在 SDK 初始化之前采集，须作为证据留存，并须传播至每一个下游集成。本指南将介绍 AppsFlyer 采集的数据内容、如何在 iOS、Android 及移动网页端将其与同意管理框架集成，以及平台自身的隐私原语（Start SDK API、ATT 信号和数据隐私框架）在整体方案中的定位。
AppsFlyer 采集的数据
AppsFlyer SDK 在宿主应用启动时即初始化会话，并默认采集一组标识符和上下文信号：设备级广告标识符（iOS 上的 IDFA、Android 上的 GAID）、iOS 上的供应商范围 IDFV、跨会话持久存在的 AppsFlyer 安装 ID、IP 地址（用于地理 IP 和概率性指纹匹配）、用户代理、设备型号、操作系统版本、运营商及时区。安装后，SDK 将安装事件上报至 AppsFlyer 服务器，与广告网络转发的点击数据进行匹配。后续应用内事件——Purchase、RegistrationComplete、Tutorial Complete、Custom——均通过同一 SDK 触发，并继承相同的标识符集合。
监管机构已明确指出，上述处理属于 GDPR 定义下的个人数据处理。IDFA 和 GAID 是个人数据，因为它们是持久的设备级标识符。与之并行运行的概率性指纹匹配在无同意情况下更难辩护，因为其本质就是在未经用户明确配合的情况下尝试识别用户身份。CNIL、意大利 Garante 和西班牙 AEPD 均已对在获取同意前触发归因堆栈的发行商展开调查。
AppsFlyer 的原生隐私控制
AppsFlyer 提供了一套有意义的原生隐私原语。它们无法替代真正的同意框架，但理解这些原语至关重要，因为它们正是 CMP 用来控制 SDK 行为的操作杆。
Start SDK API
SDK 支持一种初始化模式：完成配置但在显式调用 start() 之前不传输任何数据。这是同意门控最重要的单一钩子——默认情况下 SDK 在应用启动时自动启动，而这对任何有事先同意要求的司法管辖区而言都是错误行为。在初始化时将 isStopped 设为 true，或使用延迟启动 API，并仅在同意信号已记录时调用 start()。
Stop API
若在会话中途撤回同意，调用 stop() 将停止所有后续传输。此操作不会追溯删除已发送的数据。如需完全删除，须通过 AppsFlyer 隐私门户提交数据主体删除请求——集成团队应通过 AppsFlyer API 自动化处理，而非走人工流程。
setSharingFilter
该方法用于过滤哪些下游广告网络可接收回传数据，是实现细粒度逐合作方同意的正确原语——例如，允许总体归因但屏蔽向用户已拒绝的特定网络转发数据。
Apple App Tracking Transparency 集成
在 iOS 上，AppsFlyer 自动读取 ATT 授权状态并相应调整行为——若用户拒绝 ATT，则不传输 IDFA。ATT 独立于 GDPR 同意，许多发行商将二者混为一谈。ATT 控制的是单一 iOS 级信号，GDPR 同意控制的是其他所有内容。
iOS 集成
iOS 上可靠的做法是安装 AppsFlyer SDK 但推迟初始化，直至 ATT 和应用内同意流程均已完成。最简流程为：应用启动，SDK 以 isStopped = true 完成配置，应用内同意横幅展示，用户接受相关类别，清除 SDK 的 isStopped 标志并调用 start()。若应用还需要 ATT（对任何需要 IDFA 的用户均如此），ATT 提示与应用内横幅同步或在其后展示。大多数支持移动端的 CMP 提供基于回调的 API 来传递同意决策，该回调正是调用 start() 的正确位置。
Android 集成
Android 实现与 iOS 基本一致，但有两处差异。其一，Android 没有 ATT 的对应机制——除非用户主动调用设备级"删除广告 ID"设置（大多数用户不会这样做），否则 GAID 始终可用。其二，Android 的生命周期对后台处理更为激进，因此 SDK 初始化需要绑定到持久存储的同意状态。在应用启动时从本地存储读取同意状态，据此配置 SDK，并在恢复时重新检查，以防用户在应用处于后台时更改了选择。
移动网页集成
AppsFlyer 还通过其智能横幅和 OneLink 产品在移动网页端运作。这些本质上是网页端的分析和深度链接工具，会在浏览器中设置 Cookie 并调用 AppsFlyer 服务器。它们遵循与其他网页追踪场景相同的规则：将其置于 CMP 的营销类别门控之后，不允许智能横幅脚本在获得同意前运行，并确保来自电子邮件或推送活动的 OneLink 触发事件遵循用户的同意状态。
常见陷阱
AppsFlyer 部署审计中反复出现四类集成错误。
将 ATT 视为 GDPR 同意
ATT 与 GDPR 同意是范围不同的两种信号。接受 ATT 的用户授权了 IDFA 用于跨应用追踪，但并未授权 SDK 执行的所有其他操作。对于 EU 和 UK 流量，两种信号均须具备，其中应用内横幅是约束性信号，ATT 是其之上的 iOS 特定层。
允许 SDK 在启动时初始化
这是最常见的单一缺陷。默认集成方式会立即调用 start()，在用户看到同意横幅之前就携带完整标识符负载触发安装事件。修复方式很直接：在集成时配置 isStopped = true，仅从同意回调中调用 start()。
遗忘撤回处理
若用户先接受后撤销，须通知 SDK 停止传输。使用 stop() API 并更新持久化的同意状态，以便下次应用启动时遵循新决策。
忽略服务器端回传
AppsFlyer 通过服务器端回传将转化事件转发给大量集成的广告网络。每次转发均携带个人数据，并继承原始事件的同意范围。使用 setSharingFilter 确保转发仅发送给用户同意所涵盖的合作方，而非 AppsFlyer 控制台中的所有合作方。
审计清单
针对涉及 EU、UK 或加州流量的任何 AppsFlyer 部署，需回答六个具体问题。
- SDK 是否等待同意？在 EU 地区测试设备上全新安装，确认在用户接受横幅之前 AppsFlyer 端点未收到任何请求。
- ATT 是否与应用内同意分离？确认应用内横幅是控制性同意信号，ATT 作为额外的 iOS 特定层处理。
- 合作方转发是否限定于同意范围？确认 setSharingFilter 已配置为排除用户未授权的合作方。
- 撤回是否停止 SDK？确认同意撤销时调用 stop() 有效，且新状态在启动间持久保存。
- 服务器端回传是否已审计？确认 AppsFlyer 控制台中"已配置集成"列表与横幅中披露的营销合作方完全对应。
- 数据删除是否已自动化？确认 DSAR 请求会触发 AppsFlyer 的删除 API，而非人工工单。
AppsFlyer 在同意优先技术栈中的定位
移动归因是营销技术栈中标识符密度最高的场景之一，AppsFlyer SDK 是其中影响最深远的单一集成之一。好消息是，平台本身提供了使同意执行变得清晰可验证所需的原语——Start SDK、Stop、共享过滤器、删除 API。对发行商而言，工作在于将这些原语对接至拥有约束性同意决策的 CMP，将 ATT 视为补充信号而非替代品，并确保服务器端合作方转发无法逃脱横幅所记录的同意范围。正确实施后，结果是一个在满足监管要求的同时保留用户获取团队所依赖的安装和事件数据的归因技术栈。