牺牲一个比特位值不值得？单一来源 iOS 14.5+ 归因的真相

对于移动营销人员和广告主来说，当前 iOS 14.5+ 端的监测工作变得愈发复杂了。自 2020 年 4 月 Apple 宣布更新以来，为帮助客户化繁为简，各大移动监测合作伙伴 (MMP) 和数据分析平台都在紧锣密鼓地研发解决方案。在拥抱各种变化的同时，Adjust 也在努力打造新一代解决方案，帮助客户在保护数据隐私的前提下推动增长。

我们的解决方案通过参考设备层级和 SKAdNetwork (SKAN) 数据，以高精准度的列表形式打造综合报告。而市面上的另一些解决方案则采用了 "一体化" 或 "单一来源" 的方法。从本质上讲，这种方法试图估算通过 SKAN 框架归因的安装与通过 App Tracking Transparency (ATT) 框架归因的安装之间的重叠部分。这在理论上看似可行，但实际上存在重大缺陷，最重要的是，这种方法要占用整整一个比特位。

从理论上来说，通过估算 SKAN 和 ATT 之间的重叠安装，就能够看到哪些 SKAN 安装已经被 ATT 框架归因了。也就是说，营销人员可以从聚合层面上确认SKAN 安装总量 = 付费 MMP 安装总量，从而确认两个数据集之间的意外偏差。然而，这种排错式流程缺乏必要的后续步骤，相当于您浪费了一个宝贵的比特位来证明数字不匹配。

举例说明

1. 第一个例子中，一些营销人员会对数据抱有 不切实际的希望：

   时间范围：2022 年 7 月

   MMP 付费安装：80,000

   MMP 自然安装：40,000

   SKAN 安装：100,000；使用比特值查看归因状态，有 80,000 次安装返回 "1"，即已经归因

   看到这些数字，UA 经理可能会认为所有 SKAN 安装都已归因，MMP 的付费安装数量相同，所报告的数字也没有错误。但事实并非如此！从整体层面来看，这些数字的确对得上，但让我们更进一步仔细检查。假设在 80,000 次 SKAN 已归因安装中，有 40,000 次归因给了 Facebook，另外 40,000 次归因至 Google，推广活动信息很少；而 MMP 数据显示，Facebook、Google 和 AppLovin 分别获得了 20,000 次安装归因，还有 20,000 次被归因给了某次网页推广活动 (注意：当前无法通过 SKAN 开展网页推广活动)。虽然总量匹配，但获得归因的合作伙伴却不一样。当然，您可以通过 MMP 交叉检查归因窗口，但因为 SKAN 窗口不可见，所以您无法正确比较不同数据集。总数匹配并不意味着您离单一真实数据来源更近了一步。

2. 在第二个更常见的例子中，营销人员则被带入了 死胡同：

   时间范围：2022 年 7 月

   MMP 付费安装：80,000

   MMP 自然安装：40,000

   SKAN 安装：60,000；使用比特值查看归因状态，有 40,000 次安装返回 "1"，即已经归因

   UA 经理看到，MMP 的付费安装中仅有一半体现在了 SKAN 安装总量中。下一步，UA 经理可以检查 "缺失" 的 40,000 次安装是否来自 SKAN 不支持的推广活动，例如网页、电子邮件、网络红人推广等。假设 MMP 将 50,000 次安装归因给了各类网页推广活动，20,000 次给了 Google，10,000 次给了 Facebook。SKAN 安装被归因至 Google 和 Facebook，即分别为 30,000。那么应该如何统一这些数字呢？SKAN 缺失的 40,000 次安装与来自网页推广活动的 50,000 次安装不匹配。此外，SKAN 和 MMP 的 Google 和 Facebook 归因数字为何存在如此大的不同？从理论上来说，您可以深入了解 MMP 方面的归因情况，但在 SKAN 中就做不到了。换言之，到此，您就走进了 "死胡同"。

理论上说，从单一来源可以推算出的效果 KPI 有整体 eCPI*、* CPE 和 ROAS，但由于数据准确性方面的固有局限性，我们非常不建议根据预估表现的计算结果优化推广活动 (如暂停、终止或扩大推广活动)。对于准确性方面的局限性，我们会在下文详细说明。

简言之，单一来源模型能够从高层面预估来自 SKAN 和 ATT 框架的 iOS 安装总量，但需要付出 1 个比特位的代价。

在单一来源模型中，第 6 个 (即最高的) 比特位会被指定为 TRUE/FALSE 标记。这也就意味着，在可用于事件映射和/或收入范围条件的 63 个转化值中，有一半不可用。用二进制形式表示如下：

在一个以 "精准度" 为支柱的生态中，单一来源等模型太过依赖估算。下面，让我们分别列出此类模型的四个关键估算过程，逐一解释其内在问题。

1. 不同和未知的估算模型：安装总量计算方法本身会假定带有 ATT 标记的 SKAN 归因付费安装数量与 ATT 框架中归因的付费安装总量相同。从我们的经验来看，这种假定是错误的，原因包括以下几点：

• 您的合作伙伴需要同时支持 SKAN 和 ATT 框架，数据才能匹配。但当前网络红人 (influencer) 和网页流量无法同时支持这两个框架。
• 由于未得到用户许可，SAN 可能无法在 ATT 框架中认领安装。但在 SKAN 框架中，无论用户是否授权，归因都会发生，因此，同样一部分用户很可能会在 SKAN 框架中被归因给 SAN。
• 来自 SKAN 框架的交互信息有限，归因瀑布也不够清晰，因此，您无从得知安装是如何归因给特定合作伙伴的。
• SKAN 与 ATT 的归因窗口不同。

2. 不同框架中的合作伙伴归因：单一来源模型计算方法假定，如果 SKAN 已经将某次安装归因给了特定合作伙伴，那么 MMP 也进行了同样的归因。我们已经在上文中提到，用于确认安装是否通过 ATT 框架归因的比特值并不包含合作伙伴来源信息。我们无法验证此信息的真伪，因此不能据此开展营销。当然，从总量上来看，您可以认为两个框架的安装数量可以相互弥补，但前提是两个框架中的合作伙伴完全相同。这也就意味着，如果出现不同的合作伙伴，那么问题就会变得更加复杂。考虑到 SKAN 的运作原理，上述情况并不少见。在 ATT 框架中，广告主只能开展内部营销活动，如交叉推广、电子邮件营销、网络红人和移动网页推广活动等。但是，在单一来源模型中，这些安装会带有 "TRUE" 归因标记。假设由于广告位重叠，SKAN 会将同样的设备归因到某个广告渠道中，那么这些安装就会被计入带 ATT 标记的 SKAN 安装。换言之，您不能认为 ATT 付费安装 = SKAN 付费安装 (带 ATT 标记)，否则，任何基于此逻辑的总体 eCPI 或 ROAS 都会有误差。

3. 安装日期：SKAN 回调中并不包含确切的时间戳，因此安装日期也属 SKAN 估算。估算基于所使用的转化值窗口，以及回调是否包含非 0 转化值。但关键问题在于 Google 与其他合作伙伴不同，SKAN 时间戳并不代表其收到回调的日期，而是估算的交互日期，而这个交互时间本身已经是 Google 的估算。也就是说，您需要根据 Google 估算的交互时间估计 SKAN 安装日期，精准度堪忧。

4. 隐私阈值 (privacy threshold)：由于 Apple 的隐私阈值，单一来源计算会遇到更多的困难。SKAN 发送给合作伙伴的部分回调包含 null 转化值，也就是说，回调中没有您需要的信息，也无法回答 "SKAN 安装是否已在 ATT 框架中归因" 的问题。在不同的合作伙伴和推广活动中，带 null 转化值回调的占比差异很大 (~10% - 40%)。我们有时并无法了解为什么某个推广活动 null 转化值多，而另一个推广活动少。只有 Apple 能准确回答哪些情况达到或未达到隐私阈值。对于 SKAN 付费安装 (不带 ATT 标记)，我们无法借助倍数因子进行估算，因为隐私阈值的应用方法不够清晰。与之前提到的一样，任何计算都只能是 "估算"。

单一来源或 "一体化" iOS 推广活动数据模型包含太多估算。当前市面上旨在结合 SKAN 和 ATT 数据的诸多解决方案都建立在多层估算的基础之上，且会牺牲掉一半的转化值。占用一个比特位，换来的是不精确也不实用的数据——这笔交易并不划算。如果您希望获得质量最高的数据来推动增长，就绝不能依赖漏洞百出的粗劣方法，如何分配预算？应该暂停或扩大哪些推广活动？哪些推广渠道值得重点关注？进行这一系列重要战略决策时，精准实用的数据都是必不可少的。

考虑到 SKAN 的种种局限，Adjust 推荐您采用我们的数据分析解决方案 Datascape，在同一处查看所有数据。Datascape 中的数据稳扎稳打，不走捷径，用清晰易懂的形式呈现所有数据，是真正值得信赖的单一数据来源解决方案。借助 Datascape 的多种 SKAN 相关 KPI，如转化、收入和事件等，您可以打造综合全面的 SKAN 报告，同时查看正常 Adjust 归因数据。这是确保数据准确的最佳方法。

在复杂的 iOS 生态中，最有效的监测方法是借助机器学习和预测，获得精准 eCPI、CPE 和 ROAS——这也正是 Adjust 新一代解决方案的研发方向。归根结底，营销人员的需求很简单，那就是一款能清晰展示推广活动收益的工具，并借助这一工具快速做出决策，自信地暂停或扩大推广活动。

要了解更多信息，欢迎与您的 Adjust 代表联系。