名词解释
ATT: 全称AppTrackingTransparency，应用跟踪透明，强制弹窗提醒用户是否允许广告推送，这意味着开发者需要获取iOS14以上的用户的同意才能获得用户的IDFA，根据历史经验，至少有60%的用户会选择禁止广告推荐。
IDFA：全称Identifier For Advertising，是苹果公司推出的用于追踪用户的广告标识符。
SKAdNetwork：简称SKAN，是Apple的归因解决方案之一，可帮助广告客户在保持用户隐私的同时衡量广告活动。使用 Apple的SKAdNetwork 后，即使 IDFA 不可用，广告网络也可以获得应用安装的归因结果。
iOS 14.5的推出和隐私新功能的上线带来的变化
苹果于2021年4月26日推出iOS 14.5并推出隐私新功能上线。iOS 14.5隐私政策新规的要求是：所有应用程序都必须使用ATT框架，如想要使用IDFA广告标识符跟踪不同应用的用户时，必须首先征求用户同意，用户可以自主选择是否接受个性化广告跟踪。如果用户不允许，设备的IDFA值将全是零，开发者将无法跟踪用户。
值得注意的是，首先IDFA没有消失，iOS 14.5 新规下不是说IDFA从此消失，而是开发者需要用户许可才能获取IDFA对用户进行追踪。苹果官方的态度是鼓励精准广告投放，但是需要用户有知情权以保障个人隐私。所以，在现行的 iOS 14.5 新规下，开发者的权限是建立在用户的知情权和选择权基础上的。
苹果方面是鼓励开发者寻求部署解决方案的，当然前提是解决方案要符合苹果的开发者协议、ATT框架等规则，与苹果隐私政策方向保持一致。苹果官方推出的SKAdNetwork是目前可行的解决方案之一，可以解决iOS 14.5 隐私政策下App推广下载类的归因，但无法用于精准广告场景。
首先，我们来介绍一下IDFA时代广告归因流程图
原先IDFA的广告归因流程图可以简化为上图所示：
- 当广告主把广告展示给用户的时候，用户点击广告，广告将IDFA上报给第三方。
- 用户点击广告跳转到苹果App Store，然后下载激活应用；
- 此时应用会将IDFA上报给移动归因平台；
- 在移动归因平台，会将用户点击广告时候的IDFA和应用上报的IDFA进行匹配，当双方一致时，就认为该广告产生了转化，否则就不是。
当然，苹果也给出了一种IDFA的替代方案，就是采用苹果提供的SKAdNetwork来进行归因，但是这种归因机制存在很多问题，具体的流程图如下（App A是显示广告的源应用程序，App B是用户安装的广告应用程序）：
此图来自于苹果官网
SKAdNetwork归因流程如下步骤：
- 对于APP来说，会存在一个签名标识来进行全程的标记；
- 当广告展示出去，并被用户点击，跳转到App Store，并进行安装激活的时候，会调用苹果的register API来进行上报；但是同时苹果还提供了其他转化值来记录其他行为，比如注册等；
- 在这里存在一个倒计时机制，当调用苹果API上报事件的时候，苹果会在24小时后的0-24小时时间内将结果告诉广告平台；如果在24小时内更新了新的事件的话，会重新进行24小时的倒计时，并在24小时后的0-24小时时间内将结果告诉广告平台；
- 如果有对接移动归因平台，苹果把结果告诉广告平台后，广告平台再把SKAdNetwork数据发给移动归因平台去处理。
SKAdNetwork的使用场景
如果您是以下情形的开发者，那你可以尝试去接入 SKAdNetwork 框架：
如果您有自主研发的应用，则需要到苹果官网注册成为广告网络。具体操作可以到苹果官网 developer.apple.com 学习如何采用 SKAdNetwork 框架，可查看 What’s new with in-app purchase[15] 了解详情。下面也有我们从苹果官网找到的广告网络操作步骤：
在苹果注册自己的广告网络ID，提供给开发者，相关操作可以查阅：https://developer.apple.com/documentation/storekit/skadnetwork/registering_an_ad_network?language=objc
为来源应用提供签名的广告，相关操作可以查阅：
通过注册时填写的URL接收安装验证通知验证回发，相关操作可以查阅：
以上情况是有自主研发应用的广告主或者开发者需要应对的，而作为网盟需要处理的核心问题是：网盟第三方平台Postback的接收以及Tracking数据的追踪问题。
Offerslook如何帮助用户解决核心问题
对于服务于网盟客户的第三方平台，主要核心是帮助用户解决Postback的接收以及Tracking数据的追踪问题。避免iOS 14.5的升级，影响到用户的对接，从而影响到业务流水以及对账、结账问题。
由于iOS 14.5的升级，Postback的参数不能归因到用户层级，将不会传递click_id的值。所以Offerslook平台只能把Destination URL、Postback URL和Tracking Link的{click_id}用其它参数做大概的归因。以下是参数对接流程说明对比：
正常情况下：
- 渠道会通过Tracking link送点击给我们的时候，会传一个点击唯一标识参数click_id值给我们，我们用{aff_sub1}参数来接渠道的click_id值。等我们通过Postback下发转化的时候，会将这个{aff_sub1}存的click_id值下发回给渠道，以便渠道归因。
- 我们接收渠道送过来的点击之后，会对该点击随机生成一个唯一click_id值，然后将 click_id值通过Destination url送给广告主，广告主通过Postback下发转化的时候会将他们收到点击时带的click_id值下发回给我们，以便我们归因。
iOS 14.5的升级后：
- {aff_sub1}就接不到渠道的click_id值，那么我们就只能用{offer_id}和{aff_id}进行大概的归因。
Tracking Link、Destination URL和Postback URL的iOS14参数:
Tracking Link
给渠道Tracking Link时，必须包含以下四个参数:
- {offer_id}
- {aff_id}
- {aff_sub1}:用来接渠道的click_id值，因为我们不能保证用户一定是用iOS 14进行操作，也要确保其他环境是可以使用的。
- {agent}
为了更方便跟子渠道对账，我们建议加上参数{source_id}。
举例：Tracking Link:
提醒：例如：aff_sub1={clickid}，等号左边是Offerslook的参数，右边是渠道系统的参数。
Destination URL
广告主给到我们Destination URL的时候必须包含这6个参数：
- {offer_id}
- {aff_id}
- {click_id}
- {agent}：我们系统标准是用参数{agent}去接广告主的agent值，假如您想用aff_sub1、aff_sub2或者其他拓展参数都是可以的。
- {ip}
- {accept_lan}
为了方便跟子渠道对账，我们建议Destination URL要包含{source_ id}
举例：Destination URL:
http://xx.xxx.com/offer?offer_id={offer_id}&aff_id={aff_id}&clickid=
{click_id}&agent={agent}&ip={ip}&accept_lan={accept_lan}&source_id={source_id}
提醒：例如：offer_id={offer_id}，等号左边是广告主系统的参数，右边是Offerslook的参数。
Postback URL
给广告主Postback URL时，必须包含以下四个参数:
- {offer_id}
- {adv_id}
- {aff_id}
- {click_id}
为了更方便跟子渠道对账，我们建议加上参数{source_id}
举例：Postback URL:
提醒：例如：offer_id={offer_id}，等号左边是Offerslook的参数，右边是广告主系统的参数。
