由于安卓分发渠道很多，对于不同渠道需要评价转化率的时候，就需要追踪投放出去包的数据情况，也就是需要在上报用户启动和激活等环节同步上报渠道号信息

渠道号的上报如何埋点呢

以前的数据埋点都是说在用户触发某个交互时候，也就是说不区分渠道包，只要是指定的某个代码逻辑被触发就一并回调上报数据+1，但是此时要是还得考虑不同包，就变成了得在相同代码逻辑时候要上报不同的k及对应k的值

那么就会在不同的包中打上不同的配置文件，当这个包被激活或者被启动的时候，代码会自动先去获取配置文件中的id信息作为k然后在进行对应v的上报

但当app进行升级的时候，新的配置文件会将老的配置文件给覆盖，如果是从不同第一次下载的市场去升级app那么这个新的配置文件也会被覆盖，这样相对于第二个市场（渠道）的贡献就会虚高（其实这个用户已经有了app只不过升级时候把自己伪装成了新下载），所以要想解决这个问题，就要是的用户第一次下载使用时候把渠道信息存到不受升级影响的设备地方。然后每一次启动都不是从配置文件来获取而是通过这个秘密基地获取渠道信息，从而精确统计渠道数据

iOS的发行渠道则与安卓有很大的不同，除了少数越狱的机器之外，大部分用户的App都是从 App Store下载的。iOS的“渠道”其实通常是指那些在其它App或者网页内部，提供到AppStore的链接的页面。因此，在iOS中追踪发行渠道，主要是追踪进入App Store相关页面的渠道信息。

但iOS的渠道追踪面临着一道无法逾越的鸿沟。正因为iOS的渠道分发都有跳转到App Store这一步，而Apple本身是不会提供太多信息给开发者，所以，对于整个流程的三个步骤：在某个渠道点击下载链接并跳转到App Store ---> App Store内下载App --->用户激活App，这其中的第二步，开发者无法获取相关信息，所以，没有办法精确地追踪一个用户在这三个步骤中的完整轨迹，也即没有办法精确地衡量渠道的具体推广效果。同时，安卓渠道效果分析中，常见的对于不同渠道打不同包的方案，在iOS分发时也是不可行的。

通过IDFA进行追踪：这个方案一般用在App里面打开下载链接这种推广方式。基本的方案是，推广渠道的App（例如微信），会详细记录哪个IDFA点击了待推广App（例如聚美）的链接（或是在微信中嵌入SDK去记录），而聚美本身，也会记录具体的哪个IDFA激活了聚美App，两者都将记录下来的IDFA上传至指定的服务器，进行对比，即可确定下载来源。在用户不重置系统，不还原广告的情况下，这种方式精准度比较高。

通过模糊特征匹配的方式来进行追踪：点击下载链接，会跳转到appstore页面，这个过程会触发一个服务端的请求，服务器来记录这次点击的设备信息，包括ip地址、机型等。同时，被推广App这边，也可以记录用户激活App时机器的一些基本信息，并上传至服务器。结合下载和激活的时间差，再结合设备的IP地址和机型等信息，大概可以模糊地识别出同一个用户先点击了下载链接，再激活了App，从而确定下载渠道。这种方式的精确度较低。

通过SFSafariViewController进行追踪：iOS

9中新增的SFSafariViewController，这个类的API允许在app内打开一个safari浏览器，而不是一个app内部的webview。这个app内的safari和外面系统的safari是同一个，共享同一个沙盒，可以操作同一个Cookie，也就是说它可以跨App与Safari实现共享Cookie。

 基于SFSafariViewController控件，当用户在App中通过它打开渠道页面时，我们可以将渠道信息写入Cookie中，并设置生效时间。当用户安装并激活 App后，再次使用SFSafariViewController上报激活信息，同时将Cookie中的渠道信息上传，通过匹配，便可确定下载来源。由于渠道信息保存在设备本地，因此匹配是100%准确的。

但是基于SFSafariViewController这种方式也有一定的弊端。首先，这个方案只能支持iOS9及以上版本的设备，大约占全部苹果设备的85%左右，覆盖了绝大部分用户，已经具有很好的分析价值了。但对于剩余的15%的用户，该方案无法满足。此外，对于目前业界主流的一些推广渠道，如微信、朋友圈，它们尚未在App中使用SFSafariViewController控件访问网页，因此这部分渠道也无法使用精准匹配的方案。