用户增长之数据打通的常见手段（技术篇）
提起用户增长，我们常会提到《增长黑客》中的AARRR增长模型（Acquisition 拉新，Activation 活跃，Retention 留存， Revenue营销，Referral 传播），用户增长不仅仅只是增加用户，而是基于数据分析实现业绩增长的综合策略。
前言
在用户增长中，我们常说让数据来说话。让数据说话的前提是有准确连续的数据，但在有些场景下准确且连续的数据并没有那么简单能够获取。举个例子，在产品的拉新阶段中，常常会在不同渠道投放引导下载链接，但由于渠道引流到下载安装到注册使用，整个链路比较长，存在数据无法连续打通的情况，原因是没有一个统一不变的唯一值（可以类比身份证，可以针对一个人，也可以针对渠道）作为身份传递。
例如从h5下载页到用户安装，h5无法直接拿到设备的身份证(ios: IDFA, android: IMEI)，导致无法通过设备号去打通数据，或许会想到使用用户id如uin，但是对于新用户来讲，h5页无登录态是常态。那么我们应该如何获取用户设备的身份证去传递并打通链路上的数据呢？下面来介绍下业界常用的几种方式。
常用手段
1、用户主动传递
用户主动传递身份的方式通常有两种，一个是手机号，一个是邀请码，手机号相对来讲更精细化一些，原因是在手机号大部分情况下可以对应一个人，但邀请码一般可以对应多人。但是这两者都可以作为身份证（手机号是个人，邀请码是群体）去拉通数据。
手机号流程：用户输入手机号下载 =》 使用手机号注册登录
邀请码流程：用户获取邀请码 =》 注册登录后输入邀请码
优势：准确，无平台兼容性
劣势：用户体验不好，多的操作步骤让用户更易流失
2、用户无感知(推荐)
设备唯一值
常见的有
Android: imei(一批出货山寨机重复)、sim卡信息: IMSI、ICCID(双卡双待机，或获取卡槽顺序不一致，导致两次获取卡槽不同)、mac地址(模拟器可生成)、ANDROID_ID（刷机、root、恢复出厂设置可改变）
iOS: MAC(iOS7已封杀)、IDFA-identifierForIdentifier(>=iOS6 有效，且用户可关闭)、IDFV-identifierForVendor(重装或升级系统可改变)、OpenUdid(重装或升级系统可改变)
对于Android和iOS来讲都有可以拿到的唯一值，足以满足大部分场景去识别设备。
也有将这些设备值聚合后生成唯一设备值（灯塔qimei）
但是仍然存在场景无法拿到，比如H5推广页中，如果是在自家产品中，可以通过app为h5赋能，比如将设备唯一值，种入cookie等等，在这种情况下，通过都是h5通过能获取到的设备信息（屏幕宽高比、GPU、UA等 + 指纹算法）生成设备指纹，上报到服务器，app在安装后也按同样算法生成指纹，然后匹配对应指纹行为（例如来自哪个渠道下载等）。这里也可以借助fingerprintjs2去生成。
优势：聚合后适用场景广
劣势：准确率取决于算法
动态打包
动态打包是根据Android可以在应用商店外自主下载apk安装的特性可以根据不同渠道（不同人）生成不同的apk。在apk中写入身份信息，在安装后app直接读取即可完成匹配。
那么该如何动态打包，将信息写入apk，而且不影响签名校验和安装呢？
在Andorid中签名一共有三种方案V1、V2（Android7）、V3（Android9）。
在V1中，签名信息是放在META_INFO文件夹下的三个文件中（MANIFEST.MF、CERT.SF、CERT.RSA），此方案不会保护apk内所有文件，比如修改META_INFO下内容，是不会导致签名失效的，所以在META_INFO文件夹中加入其他文件（身份信息），是不会影响签名校验的。
在V2中，签名信息是写入V2的分块中，它比V1验证的更广，是检查整个apk，但是可以在V2签名块是一个Key-Value的结构，可以向其插入数据而不破坏签名，故我们这里可以往里加入身份信息。
在V3中，签名分块格式与V2相同，也是键值对，其中V3的键为0xf05368c0，所以实现与V2类似。
签名校验流程
优势：准确
劣势：适用范围小，仅限于android非应用商店场景
剪贴板
利用h5可以操作剪贴板，app能读取剪贴板特性传递身份信息。
写入方式：document.execCommand('copy') 或 Clipboard API
如何让用户无感知剪贴板信息？
将身份信息（业务参数）传入服务器加密，获取凭证（md5值等），然后往剪贴板写入text/html类型值，text中写入凭证，这样用户粘贴出来也无法看到内容。app读取剪切板获取凭证便可以通过请求获取身份信息。
兼容性
优势：准确，跨平台
劣势：用户可以操作剪贴板，有兼容性问题
全局cookie
在iOS9后，推出了新的控件SFSafariViewController，利用的特性是可以跨app与safari共享cookie。
使用safari打开下载地址时候，将身份信息写入到cookie。当用户下载安装app，启动app的时候，在app里面使用SFSafariViewController访问同一地址，app就可以读取cookie中的身份信息。
优势：准确，用户无感知
劣势：适用范围小（iOS9+, safari）
对比
| 用户主动传递 | 用户无感知 | 用户无感知 | 用户无感知 | 用户无感知 | |
|---|---|---|---|---|---|
| 方案 | 手机号、注册码 | 设备唯一值 | 动态打包 | 剪贴板 | 全局cookie |
| 优势 | 准确 | 聚合后适用场景广 | 准确 | 准确，跨平台 | 准确，用户无感知 |
| 劣势 | 触达路径长，用户易流失 | 准确率取决于算法 | 适用范围小，仅限于android非应用商店场景 | 用户可以操作剪贴板，有兼容性问题 | 适用范围小（iOS9+, safari） |
最后
每个方案都有自己的限制，就像我们常说的没有银弹，更好的策略应该是将其聚合起来，在不同场景下用不同方案权重判断后去决定使用那一套。
