iOS专题|iOS14.5上Branch广告分析的变化
次
iOS 14.5 及更高版本的发布，也意味着 iOS 移动营销面临颠覆。为更好地服务 Branch 用户，本图文将详细阐述，这一变化如何影响您的 Branch 数据，以及要对 Branch App 的配置进行哪些更新。
我们先来理清今天讨论的内容会带来什么大的影响：
左侧展示了到目前为止您 Branch 归因数据的样子：单个合并数据集，其转化记录在所有渠道上均已去重。和任何归因系统一样，总会有一堆“未知”的转化。该存储桶有时也称为“自然”或“未归因”，但所有这些术语含义都相同：系统转化未归因于任何市场营销活动。
右侧展示了在执行 Apple 的新 iOS 14 隐私政策后，您 Branch 数据的样子：在您惯常看到的单个合并报告中，之前归因于广告渠道的所有转化现在都将显示为“未知”。通过 Apple 的新 SKAdNetwork 框架，您的广告将会有一个单独的归因数据池。
由于 SKAdNetwork 的设计，只有当前某些常见广告活动类型能提供该广告数据。因为不是设备级别的数据，所以比往常的粒度要少得多，并且不能与任何其他营销渠道进行数据去重。
好在还有办法可以在合并的去重报表中赢回一些细粒度的设备级广告数据：您可以通过 Apple 的新 ATT 框架让用户授权：
我们从一开始就应该明白：没有一劳永逸的解决方案，一切不可能维持原样。从 MMP 到广告平台，从发行商再到像类似您的广告商，生态系统中的每个人都必须清楚如何应对 Apple 的变化。
iOS 14.5 发布后，iOS 广告归因将更为复杂。本文将介绍 Branch 产品更新，这些更新旨在帮您解决问题。
#您的 Branch 数据将如何变化#
我们从一个简单的流程图开始，该流程图说明了哪些 Branch 客户将受到这些变化影响：
如果您正在使用 Branch 进行广告归因，并计划向用户展示 ATT 提示，则这些产品变化会影响您。
为什么 Branch 需要更新？最关键的是，ATT 授权过程会带来时间上的问题。这里是一个典型的用户转化过程：单击广告，从 App 商店下载该 app，然后打开该 app。到目前为止都不难。
接下来才会遇到问题：首次打开 app 后，Branch SDK 会被触发，接着就该进行安装归因了……但您还没向用户展示 ATT 授权申请：
在时间上会存在问题：在您获得授权之前 (可能用户在首次打开 app 后的某个时间才会授权)，您将不会获得 IDFA（广告主ID），也无权归因设备级广告转化。
Branch 正在研发的分析产品变化旨在帮助找回此流程中安装相关的广告归因。我们构建的解决方案反映了一些重要的需求，值得展开谈谈：
新方式必须完全遵守 Apple 的 ATT 政策。我们听说其他一些 MMP 计划通过概率匹配在后台“作弊”，即使没有用户 ATT 授权也仍旧这么做。我们认为 Apple 会严厉打击这种行为，并且我们非常重视要确保客户不会因违反政策而被 App 商店禁止。
Branch 不得通过更改已报告的事件来“重写历史记录”。追溯数据更新会带来问题，并使您的工作流程更加复杂。
Branch SDK 仍需要在 App 被首次打开时触发。自有和自然渠道的深度链接和归因都依赖于此，而这两种渠道均不受 Apple ATT 政策的影响。
您可能还在了解这些新的复杂情况，并在思考“努力让我的用户授权 ATT 是否值得？”
Branch 认为，在大多数情况下是值得的。Apple 所做的更改将降低您对广告归因的了解。这是不可避免的，并且是移动生态系统中每个广告客户都需要应对的令人不快的现实。
您仍有两个选择：拥有一些 数据或什么数据也没有。即使是有限的设备级信息，也仍然可以帮助您在广告活动优化和客户终生价值 (LTV) 等方面更好地做决策。
# 新数据流示例 #
简而言之，这是我们所做的改变。
首先，我们正在做什么
我们在追踪另一个分析事件，我们将其称之为“二次安装”。处理二次安装与处理普通安装方式相同，二次安装时还会产生数据参数，从而可以进行数据去重。用户授权 ATT 之后，二次安装将触发广告驱动的安装。此更改将为 Branch iOS SDK 所有版本自动更新，并且您不需要更新 SDK。
另外，虽然不强制，您也可以更新至 iOS SDK v1.39.2 +，从而可以将授权或拒绝 ATT 视为新的专门事件进行捕捉，并上报所有事件发生时 ATT 的状态。
现在，我们不会做的是
如果用户未授权 ATT，我们便不会对广告驱动的安装进行任何形式的设备级归因。同样，这是为了确保我们遵守 Apple 的政策，并保护您。
用户授权后，我们也不会在首次安装事件上重写任何日志级别的数据。这是为了让您的数据工作流更简化和可预测。
最后，我们不会为非付费来源的授权触发“二次安装”，因为在这种情况下，我们已经能在用户未授权 ATT 的情况下进行设备级归因了。
通过实践示例，我们能更好地了解背后的原理。这些示例演示了 iOS 14.5 及更高版本上您 Branch 数据的情况。
# 立即授权流程 #
第一个示例展示了最简单的流程：用户点击广告链接，安装您的 app 并在安装后立即授权 ATT。在此流程中，假定用户已经授权了发布者 app 中的 ATT，也因此能在交易第一端获取 IDFA（广告主ID）：
由于用户先前授权了 ATT，因此他们在发布商 app 中的广告点击将包含 IDFA（广告主ID）：
接下来，用户安装您的 app。此安装事件无法归于广告点击次数，因为用户尚未授权 ATT，这意味着归因数据将“不全面”，并上报为未归因：
在这种情况下，用户会在安装后立即授权 ATT，然后再进行其他 app 内活动。授权会触发“二次安装”，可将其归因于广告点击次数：
此后用户进行倒漏斗转化（例如购买）时，该转化也可以归因于广告点击：
现在，假设用户随后单击了另一个 Branch 链接，例如电子邮件链接。值得一提的是，在这种情况下，即使用户已经授权 ATT 也没必要，因为根据 Apple 的政策，从技术层面上看，您的电子邮件是自有渠道：
点击电子邮件后，所有的转化事件自然都将归因于电子邮件广告活动，而不是广告点击。这与 iOS 14 之前的情况是一样的：
总而言之，在这种情况下，首次安装事件将被报告为未归因或自然。用户授权 ATT 时触发的“二次安装”将正确归因于广告点击。
在另一个符合条件的链接被点击之前，购买之类的转化事件将归因于广告点击，点击另一链接后才归因于该后续事件：
Install is unattributed/ Organic.
Second install is attributed to Ad Click.
Purchase 1 is attributed to Ad Click.
Purchase 2 is attributed to Email Click.
# 延迟授权流程 #
现在，我们来看一个稍微复杂点的例子。在这种情况下，用户点击广告，安装，但一开始没有授权 ATT，直到安装后过了一段时间才授权。如果您决定直到向用户展示价值后再显示 ATT 提示，从而更多用户可能会授权，那就可能会发生这种情况。
和之前一样，此流程假设用户已经授权了发布者 app 中的 ATT， 交易第一端有了 IDFA（广告主ID）：
由于用户先前授权了 ATT，因此他们在发布商 app 中的广告点击将包含 IDFA（广告主ID）：
但在这种情况下，用户不会立即授权 ATT。这意味着用户的早期倒漏斗转化事件也将被报告为未归因：
用户最终选择授权时将触发“二次安装”，并将正确归因于广告点击次数：
授权后，随后的转化事件也将正确归因于广告点击：
总而言之，这种情况下的首次安装事件将被报告为未归因。并且直到用户授权 ATT 之前，转化事件都将报告为未归因。
用户授权 ATT 后，将触发二次安装，并将正确归因于广告点击。之后的转化事件也将正确归因于广告点击。
Install is unattributed/ Organic.
Purchase 1 is unattributed/ Organic.
Second install is attributed to Ad Click.
Purchase 2 is attributed to Ad Click.
# Branch 产品变化 #
我们已经看了一些示例用户流，让我们看一下整个 Branch 平台如何更新以反映原始数据。更新可分为两大类：
1. 预汇总的报告。由于此数据是在浏览或请求时生成的，因此当用户在安装后相继授权时，Branch 可以动态地“修复”数据。这些产品包括：
Branch 操作后台。
查询 API。
2. 原始数据产品。这会返回日志级别的事件数据，Branch 将不会追溯重写这些数据。但根据您的用例，您可以选择自己执行数据去重。我们将在本文后半部分描述执行此操作的逻辑。我们的原始数据产品包括：
Webhooks。
广告平台回传。
自定义 export API。
数据集成。
# Branch 操作后台+查询 API “刚刚好能解决问题”#
好消息是，如果您像我们的许多客户一样，主要依靠 Branch 操作后台和我们的查询 API 运作，那这两项结合“刚刚好能解决问题”，您无需采取任何其他步骤。这意味着我们将自动对首次和二次安装事件进行数据去重，从而保证在用户授权后，最终数字仍是准确的：
我们会自动对首次安装后，最多7天内发生的“二次安装”事件进行数据去重。对发生在此窗口之外的二次安装不会进行数据去重。
需要提醒的是，如果付费广告驱动的用户从未授权，则他们将不会产生二次安装数据。因此，我们将无法从未归因的数据中删除相关数据。
# “自然复选框” #
Branch 操作后台的另一个功能值得特别一提：“自然复选框”。
默认情况下，Branch 操作后台上的大多数报告仅显示归因数据。这是有道理的，因为如果您正在查看有关广告活动效果之类的报告，通常只希望查看归因于广告活动的转化。
过去，选中“自然”复选框后，报告将显示单独细分的未归因 (或“自然”) 转化：
iOS 14.5 发布后，此功能将无法正常运行，因为该未归因的部分里会包含付费广告转化，而用户授权 ATT 尚未全部完成：
这意味着“自然”复选框在许多报告中没有什么用，因此我们在某些操作后台页面上删除了自然”复选框，以免造成混淆。
自然复选框将在何处被删除：
摘要页面
Journeys（网站向 App 引流解决方案）标签
快速链接标签
Universal Email（通用电子邮件）标签
Journeys (网站向 App 引流解决方案）→ 活动标签 (Activity tab)
电子邮件→ 活动标签
自然复选框在何处仍被保留：
摘要页面
所有数据标签
Universal Ads（通用广告）标签
广告分析→活动标签
大多数客户会使用“自然”复选框来将广告活动效果与非广告活动基准作比较。作为替代方案，我们将在操作后台报告中添加一个名为“显示 app 总流量”的新复选框。报告中会附加展示所有流量 (归因和未归因) ，为效果比较提供相似的基准。
# 原始数据产品 #
有了这些变化后，需要注意数据架构更新：
首次安装和二次安装事件均会报告为安装，并且每个事件上都有两个新字段：user_data_opted_in 和 days_from_install_to_opt_in 。
user_data_opted_in 字段反映用户授权 ATT 的状态，首次安装为 false，二次安装为 true。days_from_install_to_opt_in 字段反映首次和二次安装事件之间间隔的天数。
timestamp 字段反映各事件发生的时间 (首次安装是安装本身返回系统的时间；二次安装是用户授权的时间)。此外，二次安装中的 event_timestamp 字段反映了相对应的首次安装发生于何时。
下表展示了广告驱动安装的流程，按 Branch 产品细分：
# 您需要做什么 #
若您仅使用Branch后台
那么事情就非常简单了：您无需做任何事，只需注意，随着更多用户授权 app 追踪，您的报表数据可能每天都会略有变化
若您使用查询API提取预先汇总的数据
则需要明白，如果查询时用户尚未授权，则您报告里的归因数据可能不全面。为解决这个问题，如果用户在初次请求后可能授权的话，则应从前几天开始重新拉取数据。
例如：如果是4月15日，并且您在4月1日至14日调用查询 API，但您的 app 可能会在安装之后最多6天才向用户显示 ATT 提示，建议您在4月21日再次提取数据，以便获得“最终版”数字。
若您使用自定义 export API
则需要注意的是，如果返回二次安装记录，则您数据中的某个位置已经包含该用户不全面 (也就是未归因或“自然”) 的首次安装的数据。您可以使用下述的数据去重逻辑来解决此问题。
您还应提取安装后七天内的数据。这是因为 Branch 在7天后会在原始数据中对设备标识符进行哈希处理。
若您使用Webhook
我们建议在 Webhook 正文中包含 IDFV 字段，因为某些 IDFA（广告主ID）无法获取。您还可以选择实现下述数据去重逻辑。
对于广告合作伙伴回传和数据记成
如果设置为仅发送归因事件，则无需做任何更改。如果配置为发送所有事件，则需要与合作伙伴一起决定转发路径。
若想单独捕获ATT授权和拒绝作为分析事件
请将 Branch iOS SDK 集成更新到 v1.4 或更高版本。如果您不想衡量这些专门的分析事件，而只需要“二次安装”追踪，那么此时就不需要更新 SDK。
# 如何删除首次安装和二次安装的重复数据 #
Branch 操作后台和查询 API 将自动删除重复事件，从而持续提供准确报告。但如果您使用我们的原始数据产品 (包括 webhook、数据集成、自定义 export API，或广告平台回传发送所有事件，而不仅仅是归因安装)，那您可能需要更新系统。
为此，您应该在 API pull 或 webhook 中引用 event_timestamp 字段和其他设备标识符 (例如 IDFV)。对两个事件来说，这两个字段都一样，您可以用相应的“二次安装”覆盖未归因的“安装”。
您还可以选择使用 IDFV 来重新分配首次安装和二次安装之间的所有倒漏斗事件。
