背景

对于一款产品来说，收集每个渠道的推广效果，安装量，活动参与量，对于App来说是比较重要的，因为这样我们就能够分析用户的喜好，解析出用户的行为特征，这种时候能做的事情就很多，对于iOS来说，如果用户通过三方跳转过来的，假如已经安装App的情况下，不管是用Universal Link还是用URL Scheme的方式通过夹带参数，都可以用来解决问题。但是如果用户期初没有安装的话，那就比较困难了，最终我们使用了ShareTrace来收集来源渠道，活动参与途径等这些辅助信息。

一. ShareTrace 架构

ShareTrace架构.png

从官方图上我们可以看出来他的架构大概是这样的，Web端和App端都需要部署ShareTrace的SDK，当用户访问某个页面触发了某项操作，比如点击了参与活动、下载App，H5页面的ShareTrace web sdk将收集该设备的信息和自定义参数，上传至ShareTrace服务器， 待用户安装完应用后，首次打开 APP 时，客户端 SDK 会从 ShareTrace 服务器中取回 web sdk 上报的自定义参数。

二、使用途径

2.1 获取携带安装参数

刚才也提到了，对于之前没有安装App的用户，你要想知道来源是比较困难的，使用ShareTrace之后，可以比较好的去解决这个问题，不过这里需要注意的是，获取信息后，服务端仍存在该记录，也就是说，当你下一次启动，初始化了SDK去ShareTrace服务器询问的时候，他依旧会把上次的信息返回给你，因此对于不需要重复上报的操作，需要做一下去重操作。

2.2 一键调起APP

ShareTrace本身使用了Universal Link + URL Scheme组合的方式来调起App，对于已经安装App的用户，当从三方跳转到App时，可以直接唤醒App，并接收到对应的来源信息。(ps: 偶尔会出现不能唤醒的情况，但是唤醒率90%+还是有的)

思考：

之前官方说、当用户卸载App后，重新安装的话，就不会查询到当前App对应的来源信息，实际上经过测试是有一定几率会再次收到信息，因此猜测官方架构图说的设备信息+用户自定义参数其实仅仅只是信息的一部分，后续询问官方，他们给出的答复是会使用设备信息加上其他辅助信息多维度匹配一个用户，是不是之前点击了某个活动页、从某个渠道安装了App，这样来看的话，卸载后会再次收到，也就不奇怪了。