基于用户的归因模式——通用ID方案

People-Based Attribution，简称PBA，表示基于用户的归因，基于用户的归因可以实现跨渠道、跨平台、跨设备，告别数据孤岛、洞悉用户全路径。

其实基于用户的归因实现的背后是使用自有的ID体系，也叫通用ID方案。通用ID方案已经使用很久了，最早是应用在归因领域。

如国外的Branch的基于用户的模式，一直以来Branch以用户归因作为一个亮点、卖点；AppFlyer的基于用户的归因，近一两年也在这一块发力；国外归因三巨头中就只有Adjust没有推出用户归因，而且创始人明确表示不会推出类似的功能，奈何抵不过现实，直到IDFA后面不能用，Adjust推出了一个归因哈希的东西。

什么是通用ID方案

通用ID方案大体思路是终端采集一些信息通过一些规则或算法生成一个唯一，稳定的ID，存储到设备本地。

设备唯一标识的难点不在于唯一，而在于稳定，要生成一个唯一的ID是非常容易的，你随便拿一两个信息去md5运算就可以得到一个唯一的ID，但如何确保这个设备或这个用户一直使用这个ID才是重点，需要稳定，为了确保ID的稳定性，会尽量减少生成的次数，只生成1次，然后采用如下做法保持ID的稳定性：

• 一种将ID写到设备中不易被清除的位置，如ios的 keychain中
• 一种是找回，生成ID的时候建立和设备其他各种ID映射关系（imei，mac ,imsi ,android_id等），这种映射关系有些叫设备图谱 (Device Graph)/数据图谱(Identity Graph)/关系库/ID管理中心，不同的厂家对这个关系会有不同的名字。

这个ID要系统级别的，系统级别的意思是ID不随应用不同而改变，移动设备标识分为两类，应用级别和系统级别，要作为唯一标识需要的是系统级别的，详细可以看一文详解设备ID的那些事儿。

通用ID生成方式

通用ID方案的目的都是为了生成一个持久稳定的ID，根据生成位置的不同有两种方式，一种是客户端生成，一种是服务端生成

客户端生成

客户端生成也叫本地生成，直接获取设备上的一些信息生产ID，将ID写入到不易被删除地方，同时将映射关系上传。这种方式可以重置ID，也可以将新旧的ID关系通过钥匙链缓存机制关联起来。

这种方式缺点是，客户端会涉及到多次的数据上传和交互，不推荐使用。

服务端生成

服务端生成就是在服务器上生成ID，然后下发，生成ID所使用的设备信息与ID的映射，这个关系会在存储在服务端，大多数逻辑可在服务器端调整，使用的具体流程如下：

先会获取设备上的信息，通常会拿很多的信息，不同的厂家对信息会有不同的划分，如可变和不可变，硬件信息和系统信息……这里不做细分，如信息A、B、C……上传到服务端，服务端会先去设备图谱里找：

• 如果有，就下发已经生成的ID
• 如果没有，就生成一个ID下发，同时将设备信息与ID的关系存储到设备图谱里面

注意：这里是下发ID，即是自己生成的ID，其实还可以下发已有的ID，如IMEI/IDFA。

市面上大部分厂家使用这种方式的时候的表达都比较模糊的，有两个原因：第一个是知道这种方式会侵犯用户的隐私，低调做；另一种是以这个作为商业化的了，需要把自己包装更高大上一些，不要问，问就是什么高深算法，确保*唯一。

通用ID与用户隐私

可以细看腾讯的和Branch的，基本的思路是采集信息，然后再生成ID，然后下发ID，在自己的数据库存储了设备图谱，即使你删除了APP，这个设备图谱仍然存在，甚至还会将这个设备图谱用于其他的精准跟踪，发现没？这些操作明显是违反了GDPR的用户删除权利，如用户删除了你的软件，但有关用户的设备关系依然存在监测工具云端的设备图谱里。当然有些产品说是提供了用户删除权利，可以删除它的信息，但我觉得在国内的环境，这种类似营销短信后面“回复T退订”，你退订的嘛？

甚至国内有通用ID方案直接拿用户的手机号用于生产ID或构建设备图谱，还宣称不侵犯用户隐私，你在开玩笑吗？手机号难道不属于PII信息嘛？PII的全称是Personal Identifiable Information，个人身份信息，虽然各国法律会有所差异，但个人身份信息包括但不限于电子邮件地址、个人手机号码和社会保障号等信息，国内对这些信息定位是C3等级，C3类信息敏感度最高。

现在一些公司的处理方式都是加密、隐藏用户信息，如将你的信息加密收集到第三方工具云端设备图谱中，而具备找回功能的通用ID，一定存在映射关系，在找回的时候就会用到这个映射关系，但用户完全不知情的，在没有通知或经用户允许的情况下，将用户数据出售给陌生的第三方使用，虽然这个加密，但我觉的是不妥吧。

国外目前一些公司采用组团的形式，如Adobe的cross-device功能，要用设备图谱，先加入组织，然后设备仅于组织内的公司使用，而且公司不能将设备图谱给其他公司使用，由于涉及到多方数据的存储和处理，还有法律法规的问题，目前该功能仅限于南美地区。

通用ID都有面临被屏蔽的风险的，如Web端的，IAB推的DigiTrust，LiveRamp、The Trade Desk的通用ID方案，但2019年底的时候FireFox将其屏蔽了；移动端的取决于系统平台，安卓和IOS，前期因为IDFA不能用，国内有公司曾就通用ID的方案取代IDFA咨询过苹果公司，苹果的回复是不允许，后面会考虑屏蔽，拭目以待，看看后续会不会屏蔽。

市面上的通用ID体系有哪些？

随着手机系统对用户隐私的收紧，Android Q为加强用户的隐私保护，对系统标识符进行了限制。而iOS 14，不同APP使用IDFA的需要用户的授权，iOS 14系统下除非用户明确允许应用，否则就不能将其数据用于定向广告，不能与广告商共享其位置数据，不能与第三方共享其广告ID或任何其他标识，IMEI和IDFA的跟踪变得越来越鸡肋，通用ID方案成为一种潜在的解决方案,  使用或提供通用ID服务的公司也越来越多。

Branch

Web和APP的SDK会结合用户浏览器内的cookie和设备ID，给该用户生成ID，这些用户ID最终形成数据库，从而实现用户在没有登录移动网页端的情况下，跨平台判定APP下载的渠道归属。

Adjust归因哈希

归因哈希， IDFA 和 IDFV 的 SHA256 (安全哈希)

应用打开后，广告主的应用会读取 IDFA 和 IDFV。

然后，应用会计算 IDFA 和 IDFV 的 SHA256 (安全哈希)，我们会将其称为 “归因哈希 (attribution hash)”。

例如，如果 IDFA 是 236A005B-700F-4889-B9CE-999EAB2B605D ，IDFV 是 C305F2DB-56FC-404F-B6C1-BC52E0B680D8, 那么归因哈希则是 a5a884a5dd3758ae7f0d333f56933df76d4a609a77e54ecc5db51ac8651fb5658。

注意上面提到“应用会计算”，这个生成过程是在客户端。

腾讯

腾讯GUID体系

GUID主要是MIG内的三大产品在使用，QQ浏览器，应用宝，手机管家，均有自建guid体系，大体思路是服务器端根据终端采集上报的IMEI，IMSI，MAC，Android_ID等基础ID生成一个唯一ID，同时服务端也具备简单的找回能力。

腾讯灯塔QIMEI

QIMEI是灯塔推出的终端ID精准识别体系，包含Android/iOS两类主流终端的识别。其主要思想为：SDK将各种ID采集上报，后台利用的ID关系库、山寨库和校准算法，实时生成/找回终端唯一ID并下发。

GUID与灯塔Qimei方案思路是一致的， QIMEI可补充GUID的找回能力，提升GUID稳定性。
GUID和QIMEI由服务器生成下发，并建立和设备其他各种ID映射关系（imei，mac ,imsi ,android_id等）, 用于丢失后的找回。
主要区别在于Qimei基于全业务范围的积累找回，GUID基本单业务范围的积累找回以及终端对于基础ID的采集，QIMEI/GUID的存储共享能力上的区别。

注：QIMIE目前已经向其他产品提供通用ID服务。

百度CUID

CUID系使用百度算法形成的设备唯一标识符。

阿里UTDID 

UTDID 的设计目标是给每一台物理设备提供一个唯一且独立的设备 ID。在理想状况下，不同的 APP 在同一台设备上可以获取到相同的 UTDID；同一个App在同一个设备上卸载重装后，可以获取到相同的UTDID；不同的设备的 UTDID 不一样。但是随着设备变化和隐私权限控制增强，UTDID 在同一台物理设备上可能会发生变化。因此 UTDID 不提供强一致性的保证，所以不要把 UTDID 应用到有强一致性保证需求的业务中。

官方说utdid 是一个 App 级别的设备标识 ID，不能保证绝对的唯一性，会有重复的概率。在对标识唯一性要求高的场景中不建议使用。

有点前后矛盾的节奏。

TalkingData

TDID是基于SDK获取的设备信息以及常量参数并结合TD的加密方案生成一台设备的标识，以便持久化来保持设备的唯一性。

热云数据CAID

CAID全称是China Anonymization ID，中文名是专为移动营销行业定制的匿名化标识方案，是热云数据联合多家业内知名合作方共同推出独立于苹果IDFA的CAID方案。

可*ID

该ID由88位数字、字母、符号本体码组成，可以唯一标识设备，这由数**盟提供，公司名字是这样，不是联盟、协会，这是一家商业公司提供设备唯一ID的服务，通过派发不易被篡改的更稳定终端唯一标识，为APP开发者提供更可信来的唯一ID 作为数据运营统计基准。

推送

提供推送服务的产品都会一个唯一设备标识用于推送，如控制频次，或精准推送，你手机里的应用一定会使用推送服务，所以做推送的最容易实现高覆盖度，可以说所有的移动设备都覆盖。

极光RegistrationID 

关于 RegistrationID 极光官方文档有如下的定义：

集成了 JPush SDK 的应用程序在第一次 App 启动后，成功注册到 JPush 服务器时，JPush 服务器会给客户端返回唯一的该设备的标识 – RegistrationID。JPush SDK 会以广播的形式发送 RegistrationID 到应用程序。
有了这个标识，App 编程可以把这个 RegistrationID 保存到自己的应用服务器上，然后就可以根据 RegistrationID 来向设备推送消息或者通知。

个推ClientID 

个推 ClientID 生成规则

• 安卓：CID 是 imei+随机数+时间戳的md5 值；
• iOS：个推注册ID regid的md5值，保证 CID 唯一性。

Oracle ID Graph

……