兼容 iOS 14 的精细数据级别归因

本篇博客已于 2020 年 7 月29 日进行更新，添加了 iOS 14 推出后 Adjust 将如何为客户和合作伙伴提供支持的更多细节、可靠设备本地归因方案的其他可应用场景以及我们对于归因哈希的看法。

上一篇博文中我们已经提到，针对 iOS14 即将推出的新规，Adjust 一直在积极探索既符合新的隐私规定，又能实现精确数据级别归因的应对方案。

Adjust 将使用三种不同的方法，为我们的客户和合作伙伴提供支持：

• 使用 AppTrackingTransparency 框架，在用户选择加入数据分享后进行准确归因
• 基于多种非决定性信息进行概率性数据监测
• 使用 SKAdNetwork 作为附加数据组

即便用户选择退出，我们的归因解决方案也完全符合 Apple 的规定。但是，无论归因与否，我们都支持并推荐应用开发者利用 Apple 在 WWDC2020 上推出的 AppTrackingTransparency 框架，在应用内建立许可请求流程，以便在供应和需求双方皆获得竞争优势。

本篇博文展示了我们的研究成果，详细阐述了我们提出的 "归因哈希" 解决方案。通过这篇博文，我们想率先发起讨论，收集反馈，了解设备本地归因的各种可能性。从长期来讲，我们希望能促使 Apple 认可一种可靠的设备本地解决方案，让全行业在遵守 Apple 规定的同时，受益于精准可靠的归因。

我们认为，遵照 iOS 14 对 "隐私" 的定义，Apple 应当是设备 ID 和设备内归因 API 的唯一控制方。我们希望未来的解决方案能朝着这个方向发展。

下文中我们列出了生态系统中各方须分别需要采取的必要步骤。

供应方 (The Supply Side)

我们先从广告发行商开始说起。所有通过广告变现产生收入的应用 (如社交媒体应用和游戏等)，以及帮助这些应用变现的广告渠道，都属于广告发行商范畴。

在 iOS 14 端，如果应用用户必须主动授予应用 IDFA 访问权限，那么应用发行商就要向消费者展示其应用能提供的价值或优势。至于如何向用户传达这些信息，Apple 并没有进行限制，这为发行商创造了新的机会。

比如，应用发行商可以为用户提供两个选择：一个是免费有广告的应用版本，另一个是付费无广告版本。

社交媒体应用可以直接将相关内容加进条款和条件中，用户只有在允许广告投放和同意分享 IDFA 后，才能享受完整的应用。

归根结底，只要有需求，供应方就有创新的动力。广告发行商越能证明应用的价值，就越能获得用户授权，进而得到更有价值的广告资源。

我们相信，需求促进供给，这一基本经济学原理会推动供应方创造新机遇。

需求方 (The Demand Side)

要继续在 iOS 14 中提供基于 IDFA 的归因，其最大的挑战在于，您需要获得所有已安装广告主应用 (即我们在上一篇博文中提到的目标应用) 设备的 IDFA，而且在用户打开应用的同时就要拿到该信息。

想要快速获得用户的许可有一定的难度，对于那些不依赖广告变现作为收入、而是通过订阅和应用内购买的应用来说更是如此。

这是 iOS 14 带来的归因核心问题，也是业内一些人认为 Apple 新规将是 "IDFA 之死" 的主要原因之一。

但在 AppTrackingTransparency 框架中，Apple 列出了一个重要的例外情况。

那么，如何才能不向设备外发送能识别用户或设备的数据，同时完成安装或再交互的归因呢？

我们研究出了一个可行的解决方案——归因哈希。

归因哈希的技术细节

归因哈希的原理并不复杂：应用打开后，广告主的应用会读取 IDFA 和 IDFV。

然后，应用会计算 IDFA 和 IDFV 的 SHA256 (安全哈希)，我们会将其称为 "归因哈希 (attribution hash)"。

例如，如果 IDFA 是 236A005B-700F-4889-B9CE-999EAB2B605D ，IDFV 是 C305F2DB-56FC-404F-B6C1-BC52E0B680D8, 那么归因哈希则是 a5a884a5dd3758ae7f0d333f56933df76d4a609a77e54ecc5db51ac8651fb5658。

那么，归因哈希的本质是什么？

要理解归因哈希，我们要先复习一下什么是哈希。简单地说，哈希 (hash) 是一种单向函数，在此函数中，特定的输入值 (input) 总是产生相同的输出值 (output)，但反过来通过输出值却无法推导出输入值。

归因哈希的输入值同样具有极高的灵活性。也就是说，归因哈希的行为将与 IDFV 非常类似：除非同一个设备上的两个不同应用来自同一个应用发行商，否则两者的归因哈希绝不会相同，与 IDFV 一样。

就是说，您无法使用归因哈希在不同应用中进行再营销或用户分析。这也意味着，与 IDFV 一样，归因哈希无法用来识别单个用户或设备。

想象一下，现在有一个 MMP SDK 将提取的归因哈希和 IDFV 发送给了 MMP 的后端。

没有用户或设备标识符被发送至设备外，IDFA 仅被用于在设备本地计算哈希。

要使用这一哈希进行归因，MMP 需要检查供应方发来的所有 IDFA，查看是否有促成该应用活动的广告交互。而且重要的是，广告发行应用发送给 MMP 的所有 IDFA 都得到了用户的许可。

随后，MMP 会为所有收到的潜在 IDFA 和 IDFV 组合计算 SHA256 哈希。如果其中有哈希与设备的归因哈希相等，就能实现精确匹配，可以进行归因了，方法与现在 IDFA 匹配的方法高度相似。

这种解决方案拥有一个强大的优势：即便有了 IDFV 和归因哈希，在未获得任何IDFA的情况下，也无法逆向计算出 IDFA。前题是，您必需要先获得供应方的 IDFA，方能使用归因哈希。

由于归因哈希本身具有限制性，所以只适合 MMP 内部使用。

总结

Adjust 提议，在供应方获得 IDFA 授权的前提下，需求方应用在设备本地计算 IDFA 和 IDFV (或其他任意salt) 的哈希，进而实现归因目的。这种办法无需向设备外发送 IDFA，因而省去了请求相应用户许可的麻烦，解决了需求方的许可问题。

此外，归因哈希还有诸多优势：

• 隐私: 设备或用户 ID 不会被发送到设备以外的地方，收集 IDFA 需要用户许可，符合 Apple 的新规定。
• 透明: 对于行业内的技术人员来说，归因哈希的原理简单明了，容易理解传达及广泛使用。
• 准确: 归因哈希的匹配准确度足以与 IDFA 匹配媲美。考虑到 Apple 已经弃用了 LAT，且广告主应用中的 IDFA 始终能够读取，在有的情况下，哈希甚至比 IDFA 更胜一筹。
• 安全: 即便获知了哈希输入值的一半，也不可能强行破解 IDFA。
• 简便: 要使用归因哈希，MMP SDK 只需进行微调。所有 MMP 都能通过调整后端来使用这种匹配方法，无需投入大量精力和资源。

要进行设备本地归因，还有以下几种可能的方法：

• 类似安卓的 Google Referrer: 这种方法可以要求供应方获得用户许可，只有用户在供应方应用内选择加入数据跟踪时，需求方应用才会在安装时收到委托回传 (delegate callback)，供我们的 SDK 读取。负载 (payload) 可以是点击 ID (例如我们的内部 Adjust reftag)，也可以是推广活动信息或来源应用的 IDFV。
• 直接在设备上进行 ID 匹配: 改变之前 SDK 向 Adjust 服务器发送 IDFA 的做法，转而让 Adjust 服务器向 SDK 发送交互发生时收到的所有 IDFA 以及点击跟踪链接 (聚合数据点)。SDK 匹配 IDFA 后仅返回跟踪链接以作归因。
• Apple 生成归因哈希: 我们的 SDK 甚至不会读取 IDFA，只会收到 Apple 发来的哈希和 salt。

归根结底，有许多设备本地归因解决方案值得调研，其中一部分方案或许能在未来的 SKAdNetwork 优化中推出。

我们与 Apple、应用开发者和营销合作伙伴保持着紧密的联系，希望找到合适的解决方案，在保护用户隐私的前提下，推动全行业向前发展。

如果您希望与我们合作，或进一步了解如何为我们提供支持，请联系​ ios14@adjust.com。我们将非常高兴地与您分享见解，聆听行业的反馈！