People-Based Attribution，简称PBA，表示基于用户的归因，就是用一个通用ID标记用户，实现跨渠道、跨平台、跨设备打通，告别数据孤岛、洞悉用户全路径。

通用ID方案已经使用很久了，如各大互联网公司的内部用户ID体系，更多的是局限于内部自身产品的使用，比较公开的商业化应用在归因领域，如国外的Branch的基于用户的模式，一直以来Branch以用户归因作为一个亮点、卖点；AppFlyer的基于用户的归因，近一两年也在这一块发力；国外归因三巨头中就只有Adjust没有推出用户归因，而且创始人明确表示不会推出类似的功能，奈何抵不过现实，直到苹果推出ATT，IDFA后面不能用，Adjust推出了一个归因哈希的东西。

什么是通用ID方案

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

通用ID方案有两种思路，根据生成ID的时候是否用到终端属性，也就是用户的信息：

一种是先会获取设备上的信息，通常会拿很多的信息，不同的厂家对信息会有不同的划分，如可变和不可变，硬件信息和系统信息……这里不做细分，如信息A、B、C……上传到服务端，然后通过一些规则或算法生成一个尽可能唯一，稳定的ID，ID生成与终端硬件属性有关联关系。
一种是后台直接通过算法生成唯一的ID，ID生成与终端硬件属性没有依赖关系，然后ID和设备信息绑定，如关联设备属性、IMEI、MAC、账号等信息。

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

客户端生成

客户端生成也叫本地生成，直接获取设备上的一些信息生产ID，将ID写入到不易被删除地方，同时将映射关系上传。

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

服务端生成

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

接下来看如果已经有ID和没有ID的时候的大概流程：

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

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

至于在客户端生成还是服务端生成ID，为了在低速网络环境下也能够正常使用，往往是同时使用的，但以服务端为核心，服务端方便调整逻辑或和一些规则的阈值。

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

随着iOS 14中IDFA的权限级别降低到应用级别，APP每次想要使用IDFA都需要先获得用户的授权，IDFA的跟踪变得越来越鸡肋，很多的公司和组织纷纷看到一个商业机遇，推出一个通用ID去替代IDFA，抢占市场，通用ID方案成为一种潜在的解决方案。

目前市面上潜在的通用ID方案主要有两个类型：

一种是作为独立第三方只提供ID服务，希望被行业普遍接受使用，如一些组织和商业化公司都在推
一种是媒体或工具提供，如超级APP或普及度很高的一些工具，它的ID体系具有很高价值，但一般限于内部或小范围使用

第三方提供

作为独立第三方提供ID服务，希望自己的方案被行业普遍采用，不仅一些行业组织在推，一些商业化公司也在推，大家的原理基本一致的，都会通过收费提供ID服务。

中广协 CAID

CAID全称是CAA Advertising ID，叫中国广告协会互联网广告标识，加成广告标识。

是中国广告协会与中国信息通信研究院联合研究机构、广告产业链各方推出，这个是背靠行业协会推出的，类似安卓的OAID。

中国信息通信研究院这个组织很有意思，它自己在iOS端已经推出卓信ID，早就在一些公司做测试了，现在又跟中国广告协会在iOS端推出 CAID。

CAID基本原理是：APP采集具有一定识别能力的非用户隐私数据，发送到中心化服务器，由服务器生成广告标识ID，再下发给APP端，对于一台终端而言，其广告标识ID具有唯一性，这相当于给每一台终端新发了一张“身份证”。

更多内容请看：中国广告协会的CAID方案

需要跟热云的CAID区别，这是两个不同的东西。

中信通卓信ID

卓信ID是中国信息通信研究院泰尔终端实验室推出的，比中广协推出的更早，去年就在一些公司测试。

原理是：采集终端设备信息上传到中国信通院服务端，生成（匿名化）根ID，再将根ID过匿名化生成卓信ID，中信通再将卓信ID同步至各服务商（APP公司），服务商再将卓信ID下发到APP。

这种思路有点意思，但在后面的CAID中没有借鉴，估计这种模式是遇到问题。

数盟可信ID

可信ID是北京数字联盟网络科技有限公司推出，这是一家商业公司推出的ID服务。

官方说是：可信ID是基于移动设备物理层和协议层的信息，结合数字联盟独有的算法生成的设备ID，为移动设备颁发唯一不变的“身份证”，其实还是采集一些设备信息，在服务端通过算法生成ID，映射关系存储起来。

热云数据 CAID

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

CAID方案采集少量设备非隐私参数按规则加密生成CAID。

媒体/工具提供

一些媒体，如拥有超级APP的媒体，和一些装机量很高的工具，如归因类、推送类、分析类工具，由于覆盖面广，它们内部的ID体系也是很有价值的，不少头部互联网公司前几年都在搞全域，就是打通内部的数据，打通数据肯定要用到ID，但最近什么消息了。其实很多外部的公司是很希望它们能够提供ID服务，但一般都没提供，基本是内部使用或小范围内使用。

腾讯

腾讯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的存储共享能力上的区别。

但发现腾讯的一些Marketing API服务器里面优先使用一个MD5（IMEI/IDFA）的ID，根本就没用上述两个ID，估计它里面想要统一也蛮困难的。

百度CUID

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

阿里UTDID

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

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

有点前后矛盾的节奏。

Branch

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

Adjust归因哈希

归因哈希 (attribution hash)， IDFA 和 IDFV 的 SHA256 (安全哈希)，APP打开后会读取 IDFA 和 IDFV生成一个SHA256 (安全哈希)。

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

TalkingData

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

TDID 采用 TalkingData 自有的 ID 生成逻辑及加密算法来生成，具体规则是：版本号＋加密算法 F(设备 ID 因子 1,设备 ID 因子 2,设备 ID 因子 N, Salt)。

通过 SDK 在 App 第一次使用过程中所生成的 TDID，会保留在应用沙盒中（IOS 平台，对应存储于该应用自身的 Key Chain 中；Android 平台上，存储于应用自己的沙盒之中），从而确保 TDID 在设备端存储的安全性。

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

极光RegistrationID

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

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

个推ClientID

个推 ClientID 生成规则：

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

通用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，安卓的对权限控制越来越严格，在挤压着通用ID的生存空间；前期因为IDFA不能用，国内有公司曾就通用ID的方案取代IDFA咨询过苹果公司，苹果的回复是不允许，后面会考虑屏蔽，拭目以待，看看后续会不会屏蔽。

注意：各家产品可能会更改ID生成规则，毕竟需要跟灰产对抗，生成规则必须要与时俱进。