Update：2021-03
上一节介绍了APP来源追踪方式（归因）——iOS篇，这一节来介绍Android的。
这一节来讲讲APP流量来源的跟踪方式，其实就是APP的渠道跟踪，因为在过去的一年里OAID的逐步推广应用、即将在秋季发布的iOS 14里隐私政策有巨大的调整，APP流量来源的追踪方式说会有翻天覆地的变化也不为过。
这一块会分两节来讲，今天主要讲解Android的。
Android 是Google在2008年12月23日发布的移动操作系统，广泛应用于手机和平板电脑上，是目前手机出货量最多的操作系统，Android 里有上百万的APP，怎样才可以知道你的APP是从哪里下载的呢？目前安卓的来源跟踪主要有以下几种，根据归因实现的方式可以分成两种类型：
- 一种是匹配式，用从媒体平台获取的数据和激活（first_open）时回传的数据做匹配，一般拿特定的ID或用户设备信息
- 一种是传递式，在用户设备/应用市场上存在一个能够传递渠道标签的机制，应用激活（first_open）能够获取渠道标签，从而实现渠道信息的传递
还有另外一种分类方法是分为确定性归因和概率性归因。
匹配式（Matching）
精准匹配（Deterministic Matching）
精准匹配也叫设备号匹配，就是通过各种ID去匹配，用户在点击广告的的时候就获取ID和渠道信息，用户下载安装打开时再次上传ID，然后通过ID匹配就可以知道渠道信息，常用的ID有IMEI、Android ID、GAID等。
精准匹配的过程如下：
这个过程需要注意的是，用户点击的广告链接是第三方平台（监测平台）生成，然后在步骤2上传ID信息是需要广告平台的支持，所以你会看到有一些监测工具将所有的投放平台都列出来了，表示这些平台支持ID信息上传。
精准匹配是需要通过一些ID实现， 可能用到的ID有：
- 具有Google Play服务的Android设备： GAID
- 没有Google Play服务的Android设备： OAID，IMEI，Android ID、MAC等
GAID在国内不能使用，不同工具的内部归因使用的ID逻辑可能会不一样的，下面是两个产品的示例：
- A工具的归因逻辑为：OAID>IMEI> Android ID>MAC，
- B工具的归因逻辑为的为：muid（muid是IMEI的MD5）>OAID>Android ID >mac >IP+UA。
常用的ID有如下：
- IMEI：国际移动设备设备码，是运营商识别入网设备信息的代码，一种不可重置的永久标识符，但Android 10后禁止获取。
- GAID：谷歌广告 ID， 是一种可由用户重置的标识符，适用于广告用例，依赖Google Play，国内不适用。
- OAID：匿名设备标识符，由于Android 10后获取不到IMEI，国内 App 和广告跟踪服务急需一种替代方案以避免广告流量的损失，所以国内的移动安全联盟（MSA）联合华为，小米，oppo，vivo等终端厂商推出了OAID，用于逐步取代移动设备原有IMEI码，OAID只有国内在用的一个ID标识，目前魅族、中兴、华硕，华为、小米、oppo、vivo、三星、一加都已经提供OAID。
- Android ID： 是 Android 设备里不依赖于硬件的一种“半永久标识符”，在系统生命周期内不会改变，但系统重置或刷机后会发生变化，在 Android 8.0 以后，签名不同的 App 所获取的 Android ID是不一样的。
综上，现在国内最推荐就是OAID，可以看到很多的手机厂商都逐步已经提供OAID，但实际上要实现能够通过OAID匹配，不仅需要第三方工具能够支持，还需要广告投放平台能够支持，因为在精准匹配的过程中是需要广告平台回传ID信息，目前还属于过渡阶段。
在实际的使用过程中，可以使用MD5或SH1对ID做加密处理，如B工具里用到的muid就是IMEI的MD5。
模糊匹配（Probabilistic / Fingerprinting）
实际过程中，有部分用户设备由于种种原因无法获取硬件设备等信息，同时由 于 Android Q 系统版本发布后无法获取设备信息的情况越来越严重，这将导致无法精确回传，容易造成GAP。
模糊匹配，也叫IP+UA，是指通过将用户点击广告时的 IP、User-Agent（简称 UA，用来提取用户的操作系统、版本号、手机型号等信息）信息与激活时的 IP、UA 进行关联匹配实现归因分析。
模糊匹配的实现方式如下：
模糊匹配与精准匹配的差别在于收集的信息不同和是否需要和第三方渠道配置，也就是广告平台的支持，由于模糊匹配不需要广告平台的支持，所以比较方便。
这的很多厂商都在使用的一种方式，都强调很高识别率，但是这个严重更依赖于两次收集的信息、时间差和算法，一般来讲，短期内 匹配(24 小时)最精确，随后其精确度开始下降，匹配成功率在70%~80%。对于大部分人来说，算法个是黑匣子的，即使第三方工具只是做了一个简单的优先级去匹配，如匹配的优先级为 IDFA/IMEI > Android ID > IP + UA，优先使用IMEI号进行精准激活匹配，没有IMEI的情况下采用Android ID匹配，如果也没有获取到Android ID，则采用IP+UA的方式模糊匹配，然后对完宣称通过大数据，人工智能的方式去匹配，你也不知道的。
由于IP和UA会可能会重复，如多个用户使用同一个IP等情况普遍，所以准确率没那么高，这是一种兜底的匹配方式。
自归因渠道（SAN / SRN）
自归因，也称自归因渠道，自归因广告平台，全称是Self -Attributing Networks ，简称SANs，或Self-Reporting Networks，简称SRNs。
这种归因方式有比较大的局限性，是一些具有归因功能大广告平台才提供的归因机制，通常是一些科技巨头提供，应为它们建立起了强大的解决方案并在市场中奠定了强势地位，往往需要下加入到广告平台的移动监测合作伙伴计划（MMP）或获得认证，才可以使用广告平台的API。可以从广告平台发给第三方归因平台，也可以从第三方归因平台发给广告平台，我们这里关注前者。
通常国外的广告平台会采用这种方式，广告平台可以通过MMP去管理合作伙伴/第三方归因工具，这样能更好保护数据隐私。
原理是： APP需要集成广告平台的自归因SDK，用户首次打开的时候先会检查是不是从自归因渠道，如果是的话，就通过API用设备ID去匹配，根据返回的结果，将激活归因给响应的SANs，从而实现渠道归因，如果不是，就用其他的归因则。
目前提供自归因的广告平台有：
- Apple Search Ads
- Google Ads
- Snapchat
- 腾讯社交广告
- Verizon Media
- Yahoo Japan Search
国内分析工具，在不能满足MMP要求的时候，会采用通过第三方归因工具通过转发的形式，如导入Appflyer，Adust，Branch的归因。
传递式（Passing-based）
渠道包（多包机制）
众所周知 Google Play 无法在中国使用，催生了国内安卓生态中大量第三方应用内市场，目前国内 Android 应用市场被数十家应用商店占领，应用市场可以分成两个阵营：
- 一类是大型互联网公司，如腾讯的应用宝，百度的手机助手，360的360应用市场……
- 一类是是手机厂商的，如华为、小米、oppo、vivo、魅族……
渠道追踪主要围绕上述应用市场展开。
渠道包的具体实现方式就是开发者为每一个渠道生成一个渠道安装包，不同渠道包用不同的 Channel ID （渠道标识）来标识，这个id一直跟app绑定；当用户下载了 App 之后，ID会随相关的数据发送回来，从而实现渠道的识别。
这种方式完全是为了适应我们大陆的情形的，如果要上传的应用市场多的，意味着需要打很多的包，还催生一些专业打包工具，一键生成所有渠道的包。
这种方法有个天然的缺点，就是只能定位到应用市场，不能做更细的广告系列划分。还会被被手机应用厂商拦截的情况，也容易被不良的渠道方拿来进行数据作弊，从而无法有效评估真实的线上推广效果。
剪贴归因（已被禁止）
如果精准归因拿不到ID，模糊归因精准度不高，那么还可以使用剪贴归因。
思路是：用户在广告页面点击下载的时候同时将唯一标识写入剪贴板，用户下载激活后，APP会读取剪贴板的内容，然后将信息上报，实现归因。
由于剪贴板上的信息是用户的隐私信息来的，所以这种方式其实是在侵犯用户的隐私，网信办的禁止的，这种方式严格说是违法的，所以并不是主流方式，但也有不少知名互联网公司在使用。
Install Referrer （旧版机制）
Install Referral是Google Play提供的广播机制，具体原理如下：
在投放链接上添加UTM参数（类似网页UTM的用饭一样），如：
https://play.google.com/store/apps/details?id=com.ichdata&referrer=utm_source%3Dtest1%26utm_medium%3Dtest2%26utm_campaign%3Dtest3
Google Play商店在用户安装完App后，会向App发送一个广播（Broadcast），其中包含了名为 referrer 的字符串。例如：
referrer=utm_source%3Dtest1%26utm_medium%3Dtest2%26utm_campaign%3Dtest3
App在安装后第一次启动时，就可以从广播中读取这个referrer，用于广告归因、判断下载渠道等。
这种方式有不少缺点（导致被废弃的原因）
- 容易被篡改（可被拦截或伪造）
- 不稳定，不保证送达
- 安全性低
- 在某些 Android 版本行为不一致
- 无法精准反作弊
因此Google在2020年3月正式宣布停止支持。
Install Referrer API（现行标准）
虽然Install Referral 这个机制很好，但是可以作弊，Install Referrer会出现很多归因欺诈，很多工具应用都在主动通过INSTALL_REFERRER 广播机制发送广播去抢归因，每年都会看过很多国内的应用因为归因欺诈被Google Play下架，其中不乏很多在美股上市的公司。
为了解决于归因欺诈问题，谷歌在2017年推出了Play Install Referrer API，Install Referrer API是Install Referrer的升级版，在2020年更新了V2版本，提供更多的参数可以用于归因欺诈检测，而且从 2020 年 3 月起， Google 弃用了 INSTALL_REFERRER广播机制， 要求改用Play Install Referrer API。
目前只有Google Play和华为的应用市场支持Install Referrer API，如果国内的其他应用市场也提供Install Referrer API，那么国内的安卓应用的跟踪就不会那么混乱了。真心希望国内的其他应用市场也支持这个API机制 。
Google Play
为了提供更精准、可靠、安全的安装来源追踪，Google 推出了 Play Install Referrer API。
这一API是主流归因平台（AppsFlyer、Adjust、Kochava）普遍使用的方式，并在行业中被视为唯一可靠的Android安装来源标准。
与早期广播方式相比，它的优势非常明显：
- 精准可靠：数据由Google Play官方API返回，不会出现莫名丢失。
- 安全性高：不容易被篡改，能防止“假归因”。
- 支持反作弊：可用于识别异常安装、快速安装等欺诈行为。
- 被全球主流归因平台采用：包括Adjust、AppsFlyer、Kochava等。
Play Install Referrer API的逻辑跟：用户点击推广链接到Google Play安装APP，Google Play就会获取推广参数传递，APP安装后，首次打开的时APP就会主动通过Google Play的API去查询获取渠道信息，然后上传。
使用这个API，可以获取如下信息：
有几个字段是时间戳的，就可以用于验证、计算CTIT（点击安装时间 ，Click to Install Time）等，用于归因欺诈检测。
延伸阅读：Google Play广告归因原理解析：从Install Referrer到Install Referrer API的演进
Huawei AppGallery
华为的是叫智能分包参数 (Install Referrer) ，开发者可以通过华为开放的API获取APP智能分包参数，可以看一下华为文档里智能分包参数整体的交互：
Huawei AppGallery
通过 HUAWEI 提供的智能分包参数（Install Referrer），广告主可以全链条（曝光、点 击、下载、安装、激活、注册、下单等）分析下载类广告的转化效果：
- 1. 广告主 APP 集成 SDK 或者 API 接口获取智能分包参数能力并上架应用市场。
- 2. 广告主在华为广告平台投放 APP 下载类广告，并设置智能分包参数。
- 3. 媒体 APP 请求并展示广告主投放的广告。
- 4. 用户在媒体 APP 上点击广告主投放的广告，用户可以选择并下载安装广告主 APP。
- 5. 应用市场(APP Market)将智能分包参数写入 Huawei Ads Kit。
- 6. 用户在端侧激活广告主 APP 时，App 从 HMS 获取智能分包参数。
- 7. 广告主 APP 上报激活事件，可使用智能分包参数分析 APP 转化效果
总结
总结一下，各种匹配方式的优缺点如下：
一般来说是渠道包或采用先精准后模糊的匹配方式，精准里面会有不同的优先级顺序，如OIAD>SSAID>**ID，先拿OAID，OIAD拿不到可能会拿SSAID或其他ID，这里面也有一些是采用自有ID体系，这个ID是基于硬件设备等信息生成唯一的标识符，属于用了也不会告诉你的，最后才采用模糊匹配。
再来看一下目前市场上一些工具的匹配方式：
主流产品匹配方式
上述信息是基于各家官方文档信息，但由于有些文档未及时更新或不方便公布具体匹配规则，有些产品的官方文档演示图挂了也没人维护的节奏，或年久不更新，可能与实际真实的情况有差异，上图仅供了解，具体以官方为准。
