今天好好聊一聊iOS的SKAdNetwork。聊它怎么来的？它能干什么？怎么用它？

SKAdNetwork的出现，其实也是有归因这个概念的功劳。苹果在一开始发布iOS设备的时候，并没有考虑到归因，甚至用户隐私这些层面的问题，因为苹果那时候还是一个Baby。刚开始的时候也仅仅就是它自己的App Store，开发者在上面发布应用，用户去下载安装。这也算是一个闭环生态。

后来出现了归因以及用户跟踪的概念，这时候在苹果设备上生成了一个ID叫IDFA，这是苹果手机上的唯一识别码，有了这个ID，就能轻松实现对用户的追踪，也就是行业内称之为归因。

2018年开始，全球对用户隐私越来越重视，特别是欧洲GDPR出现以后，互联网行业对用户隐私的话题可谓谈虎色变，也被这个国际规范整的头破血流。所有的努力都是为了合规，不敢逾越半步，否则后果很严重。这个政策的核心意义是什么呢？就是任何手机厂商，任何App开发者，任何第三方机构，在未经用户同意的情况下，不允许对用户进行追踪。

苹果面对这一政策，不可能不做出调整。一方面是用户隐私，一方面是广告主的利益，怎么平衡这两者之间的关系？这时候SKAdNetwork出现了。

SkadNetwork采用了一个弹窗的形式来提示用户是否允许跟踪

重点来了

·如果用户同意跟踪，那我们可以拿到设备的IDFA信息，走正常的归因流程；

·如果用户不同意跟踪，我们拿不到设备的IDFA信息，在归因信息里面是没有IDFA这一重要信息的

不管用户是否同意跟踪，都会走SKAdNetwork。只不过会有不同的归因结果。(千万不要想着，全部数据-有IDFA的数据=为获取IDFA的数据，这是错误的思想)

SKAdNetwork有什么特点呢？就是你啥也捞不到。

我们就拿这个流程图来看，过程其实很清晰。

客户是怎么在我们的面板上看到SKAN数据的呢？如果客户有跑SKAN的Campaign，首先他得在我们的面板上做一个映射，形成一个Map关系。（这里多解释一下，SKAN规定了64个Value值0～63，其中0默认为Install事件，其他值可以映射成你的其他事件。多余的就不多说了，头大）。如果某个事件发生了，Branch会收到这个事件，然后通过事先设定好的Map关系把这个事件发给SKAN。SKAN收到这个事件之后并不会马上把数据发给渠道比如FB，而是有24～48小时延迟。如果一切顺利，最后渠道会把数据给Branch，这样客户就在面板上看到数据了。

所以说理论上我们面板数据完全取决于渠道，他们给多少我们就显示多少。

这里面有两个坑要注意下：

·我怎么知道Branch有没有给SKAN发数据？-不知道

·我怎么知道苹果有没有给渠道发数据？-不知道

紧接着SKAdNetwork的特点，我们可以总结出几点：

·数据延迟

·无归因逻辑

·无归因信息（从苹果返回的字段你可以看到就那么几个字段）

·只能看到聚合数据

因此，SKAN存在的意义似乎不大，只能说有比没有好。据不可靠消息，自从有了SKAN，市场上似乎对它反响平平，用它的人也不算多。只能说苹果的市场比较大，很多开发者不得不在其上面做点文章。站在苹果的角度，为了应对当今市场对用户隐私层面的考虑，没有其他更好的方案。

说到数据上，上面说了，理论上我们跟渠道那边的数据是一致的。如果客户提出来数据有差异，一般都是跟渠道那边对比的。

但是从iOS15开始，我们可以代表客户直接从苹果那边拿数据，很简单，只需要几个步骤。详细步骤可以参见https://help.branch.io/using-branch/docs/skadnetwork-direct-postback这么一来，有一个好处，数据上产生差距的可能性会大大减少，因为我们不用依赖于渠道给我们数据，谁知道渠道那边是否会做什么手脚。

目前中国这个的客户还是没有修改，依然是走的老一套，我们的数据还是从渠道那边过来的。有可能因为跑SKAN的客户本身就很少，而且数据量也不是很大。

最后一个问题，如何倒出SKAN的原始数据？（暂且称之为原始数据吧，毕竟SKAN能提供的字段并不多）

·目前需要通过Custom Export API来请求，面板上Custom Export还不支持。