产品需求
由于双十一期间要开展多渠道推广，市场运营部要求，对每个渠道下用户的安装来源做详细判断，获取每个用户的安装来源渠道，如官网、推广页面、地推人员、广告跳转、应用商店下载等多个渠道，并且追踪每个渠道用户安装后的注册、购买情况。
需求分析
总结起来无非两点：
1、用户是从哪个渠道下载App
2、用户安装后首次打开传递值到App内
具体做法：我们需要在下载前对目标用户做一个标记，用户经过安装打开等操作后，注册App时比对这个标记，确定这个下载源并进行一些操作。简单来说，要在安装过程中实现参数携带。
实现方案
以下方案是目前市场上主流的一些方法，尝试分析这些方案和局限性，找出最佳实现思路。
1、安卓方案
（1）渠道包
渠道包统计的主要做法，是开发者先给每个应用商店生成不同的安装包，将事先定义好的 Channel ID（渠道标识号）参数写入其中，然后上架各大应用商店，当用户通过应用商店下载并激活App时，该渠道号也会同时被读取到，从而实现应用商店下载量统计。
但是做邀请、分销、地推时，渠道数量太大，打包并不灵活，或者我想看不同素材的效果，我想看不同定向的效果，想看不同创意计划的效果……如果都分包会带来极大的管理成本。另外分包的作弊空间也比较大。
（2）设备号匹配
用户点击广告时，获取设备的各种ID和渠道信息，用户安装激活App后，再次上传ID匹配，即可得知渠道信息，安卓常用的ID有IMEI、Android ID等。
方法限制：
IMEI：国际移动设备标识码，曾经最靠谱的IMEI，在Android 10后禁止获取。
Android ID：一种半永久标识符，缺点是系统重置或刷机后会发生变化。并且在 Android 8.0 以后，签名不同的App所获取的Android ID是不一样的，而如果在CPI广告等场景下，就需要唯一标识一台设备，此方案也就不那么有效。
OAID：匿名设备标识符，移动安全联盟用于替代IMEI的方案，目前只有华为、小米、OPPO、vivo、中兴、努比亚、魅族、联想、三星等设备厂商在逐步支持，缺点是一些旧版本设备没有更新，并且不仅需要第三方工具能够支持，还需要广告投放平台能够支持回传ID信息才有效。
同时，H5渠道推广是获取不到设备号的。
2、iOS方案
（1）App Store Connect 来源分析
登陆开发者Connect 中心-App 分析-来源分析，设置营销活动链接，就能获取下载来源。
“营销活动”： 通过设置营销活动的链接，当用户点击带有该链接的广告时，他们将被带到该 App 的 App Store 页面。会被针对性收集和统计，相当于自定义的来源统计。
设置完链接参数拿去推广，开发者中心就能获取到统计和数据，这个确实可以满足大规模多渠道推广。但是苹果的特点就是只做下载统计，后续打开的App以及用户在App内的操作，就无法获取，因为获取不到相应的 Value，并且统计到的下载数据延时比较大，不适用于结算投放。
（2）通过 SFSafariViewController 传递 cookie
当用户通过 Safari 浏览器来跳转到 App Store 下载应用时，可以让营销链接设置cookie 并强制通过 Safari 来跳转到 App Store，然后在打开 app 后通过共享 cookie 来获取营销链接配置的参数。
实现方法：在用户打开App时调用 SFAuthenticationSession 方法访问指定 url 会话，当前会话获取 cookie 并存储在 location.href 中，以 url 形式在 completionHandler 回调中返回。
方法限制:
SFAuthenticationSession 方法需要在iOS 11以上版本实现
SFAuthenticationSession 方法需要弹窗提醒用户授权允许获取 cookie 用作登陆
只能在Safari和App共享cookie，如微信等第三方App的内置浏览器就不能获取相关数据
（3）IDFA
IDFA属于iOS的设备号，作为唯一标识号，基本上是开发者首选的方案。但苹果一直在对IDFA做各种使用限制，iOS 10提供了Limit Ad Tracking，用户可以在设备设置里主动关闭IDFA，误差就基于有多少用户关闭了这个按钮。
iOS14以后，App在访问用户设备的IDFA之前，会弹出授权框给用户，必须获取用户授权才能使用，增加了用户拒绝的风险，以后IDFA方案准确度会更低。
3、设备通用方案
（1）IP+UA
在用户点击广告页面时收集IP、 UA，提取用户的IP地址、操作系统、版本号、手机型号等信息，再拿用户安装激活App时的IP、UA关联匹配，实现模糊匹配。
模糊匹配的精准度严重依赖两次收集的时间差、信息等，会随着推广环境的变化而变化，如多个用户使用同一个网络IP等情况下，精准度就会降低。
（2）剪贴板
当用户在打开H5或点击WAP广告时，向剪贴板写入唯一标识，同时上传服务器，用户下载激活App后，App会读取符合条件的信息上报服务端，服务器再将两者唯一标识进行关联，即可归因判断用户来源。
剪贴板的优势在于标识的唯一性和灵活性，标识内容可以按照任意规则生成，只要能区分其他剪贴板内容即可，可以获取渠道来源、用户访问内容等信息。
方法限制：
Android Q 增加了对剪贴板的访问控制，除非应用是默认输入法编辑器（IME）或具有焦点的应用程序，否则无法获取剪贴板内容。
在最新推出的 iOS 14 版本里，苹果就增加剪贴板读取提醒，如果有应用想要悄悄读取剪切板的话系统会弹出提醒，让用户知道你在截取信息。
小结
综上所述，目前没有完美的方案，想单独使用某个方案完成需求是不可能的。但经过这么多方案的启发，也可以总结出一些麻烦点的做法，大致可以满足需求，主要就是将以上方案做两两配对，模拟一个最接近实际准确率的方案。
比如在用户点击链接或广告时，将设备号、剪贴板、渠道包、IP+UA等因素一并获取，然后存储在服务端等待匹配。用户激活App后，再次获取必要信息进行对比，并返回所需参数。
说是这么说，实际做起来算法准确度却很有限，没有那么多时间去磨。但也有一些成熟的第三方工具。
4、第三方工具
大致实现方案：先配置好带参数的url，再进行对于渠道投放，用户点击url跳转到下载页（JS落地页）时，获取必要的数据并跳转到应用商店，用户激活后再根据设备从服务端对比获取之前的参数。
优点：
很匹配需求，能够满足安装来源统计，并实现参数还原，获取后续注册、购买等数据
集成简单，安卓iOS都能实现，无需太多人员配合部署
算法准确度高
问题是用户一些复杂操作也有可能导致统计不到，并且这个功能属于收费功能。
实际上由于操作系统、推广渠道、浏览器的各种限制，没有哪个方案能达到完美无缺。如果需求合适就根据需求来选择吧。
参考
App Store Connect 来源分析：https://itunesconnect.apple.com
SFSafariViewController：https://itunesconnect.apple.com/login
openinstall：https://www.openinstall.io
