画像平台需要具备的常见功能模块

标签管理

提供从标签定义、开发、发布、更新到评估、下线的全生命周期管理。

• 标签增删改查：允许管理员或数据科学家创建、编辑、删除和查询标签。
• 标签分类：组织标签结构，便于管理和检索。
• 标签值管理：维护标签的可能取值，确保数据的一致性和准确性。

标签萃取

通过先进的算法和技术，从海量数据中提取有价值的标签信息。

• 统计类标签：基于历史数据分析得出的标签，如用户活跃度。
• 规则类标签：根据预定义规则生成的标签，如用户等级。
• 挖掘类标签：利用机器学习算法挖掘出的标签，如用户兴趣。
• 流式计算类标签：实时处理数据流生成的标签，如实时行为分析。

分群功能

用户分群功能主要是面向业务人员使用。产品经理、运营、客服等业务人员在应用标签时，可能不仅仅只查看某一个标签对应的人群情况，更多地可能需要组合多个标签来满足其在业务上对人群的定义。例如：组合“近30日购买次数”大于3次和“高活跃”“女性”用户这3个标签定义目标人群，查看该类人群覆盖的用户量，以及该部分人群的各维度特征。

根据业务特点，画像平台支持不同的分群实现方式，如基于用户标签的行为筛选、基于已有人群交并差计算的人群交并筛选等。分群功能帮助运营人员将用户分成不同的群体，以便进行针对性的营销活动或服务。

1. 人群创建

人群创建即找到满足条件的用户并构建人群，根据圈选方式的不同可以分为规则、导入、组合、行为明细圈选等多种方式。

基于规则圈选创建人群

画像平台底层存在大量的画像标签，可以直接基于标签间的交、并、差操作进行人群圈选，比如圈选出常住省是北京且性别为男性的用户；最近一个月送礼次数超过5次且爱好军事的用户；常住省是天津或者上海，且性别为男性但不喜欢军事的用户。规则人群圈选是一种最常见、简单且易理解的人群圈选方式。

通过导入方式创建人群

通过文件导入或者数据表导入的方式创建人群，其中数据表可以来自Hive、MySQL等各类数据源。基于规则的人群圈选可筛选的用户局限于底层标签数据所覆盖的用户范围，而导入人群可以支持任何用户，不再局限于标签数据中包含的用户，这无疑可以扩大人群所能覆盖的业务范围。

通过组合创建人群

基于已有人群进行交、并、差操作可以构建组合人群，比如对于已经构建成功的A、B两个人群可以通过交并差操作构建新的人群C。组合人群可以对各类人群进行上层组合，满足了更加多元的圈选需求。

基于行为明细的人群圈选

行为圈选是基于用户的行为明细数据进行圈选，其数据粒度较细且与时间紧密相关，基于这一特点，可以实现行为次数统计和行为序列圈选。行为数据的来源大部分是用户操作日志，其中记录了用户在什么时间点做了哪些事情，比如小明在2022-03-18 08:00:00给小红的视频进行了点赞。基于此类行为数据，可以统计出在指定时间范围内对指定视频点赞超过10次的所有用户，或者在该段时间内先后发生了点赞和评论行为的用户。

2. 人群附加功能

为了方便使用人群，需要在人群基础上添加一些附加功能，常见的功能包括人群编辑与重算、人群拆分、人群自动更新和下载等操作。

人群拆分与截取

当一个人群用户量较大而业务只需要其中一部分用户时，需要对人群进行拆分或者截取。拆分是在原来人群的基础上随机拆出一定比例的用户，比如100万量级的人群按20%随机拆分可以构建一个20万用户的子人群。当一个大的人群需要同时拆分成多个子人群时，各子人群之间需要保证互斥性，即不同子人群之间没有重叠用户。截取发生在人群生成的过程中，比如按照在线时长截取头部20万的用户，此时会在生成人群的过程中按照在线时长大小对用户排序后进行截取。

人群自动更新

有些人群需要每日定时更新来满足业务需求，比如每天需要给昨日新增且有点赞行为的用户发红包，这就需要支持人群自动更新功能。自动更新可以支持每日更新、每周更新或者指定任意天数更新；也可以指定人群自动更新的时间范围，防止无限期的更新造成资源浪费。人群自动更新带来了人群版本的概念，需要记录当前人群版本信息，方便后续数据追溯。

人群下载

画像平台用户有时需要将人群下载成指定格式，比如TXT、Excel或者Hive表等格式。如果人群涉及权限控制，当数据导出时需要进行权限校验；数据导出到Hive表中也要考虑后续使用者的数据表权限问题。

人群抽样

人群创建完成之后，为了校验其中用户是否满足既定条件，可以对人群随机抽样然后人工校验。抽样功能需要支持在人群中快速随机找到一定数目的用户，并结合其他业务属性进行展示。

3. 人群判存

判断指定用户是否在给定的人群中即人群判存（或者叫判定）。业界判存的实现思路主要有两种：第一种是基于实际人群的判存，此时人群已经创建完成，通过判断给定用户是否在当前人群中即可实现判存，其实现逻辑比较简单；第二种是基于虚拟人群的判存，判存不再依赖实际产出的人群而只是一些简单的配置规则，比如判断用户是否属于北京市男性人群，只需要通过标签查询服务获取该用户的常住省和性别标签信息，如果标签数值是北京市和男性，那说明该用户在人群中。第一种方式比较通用，适用于任何类型的人群；第二种方式具有一定的局限性，仅限于规则人群的判存。

人群判存主要以接口服务的形式对外提供，画像平台功能层面可以提供人群判存配置入口，用户可申请使用人群判存服务并配置判存服务有效时间，系统在有效期内提供判存服务，过期后判存服务失效并释放判存服务所用资源。

以下是一些常见分群功能：

1. 人群圈选：指根据用户画像的标签或者特定的维度筛选出需要使用的人群包，然后对人群包中的用户做一些特定的操作。
2. 人群计算：对多个人群包进行交、差、并等操作。
3. 人群洞察：对特定的人群包基于用户的标签或者维度去分析其分布以及特点规律。透视分析、RFM分析、AIPL分析等。
4. 人群包管理：画像平台上能够清晰有效的管理创建出的人群包，进行体系化的管理和展示。
5. Look-alike：相似人群扩展，是基于种子用户，通过一定的算法评估模型，找到更多拥有潜在关联性的相似人群的技术。值得注意是，lookalike不是某一种特定的算法，而是一类方法的统称，这类方法综合运用多种技术，比如协同过滤、node2vec等，最终达到用户拓展目的。

画像分析

如果需要更深入地了解单个用户或者人群特征，需要借助标签数据进行画像分析。基于标签数据可以实现人群分布分析、指标分析、下钻分析和交叉分析等功能；基于用户行为明细数据可以实现事件分析、留存分析、漏斗分析等；针对单个用户最常见的功能是用户画像查询功能；人群投放效果可以通过投放分析功能展示出来。

行为明细分析

行为明细分析是基于用户行为数据的分析，目前业界比较主流的分析模型包括事件分析、漏斗分析和留存分析。

• 事件分析：是对用户行为中所涉及事件的分析。用户行为可以映射到具体的事件上，比如用户的登录行为对应到登录事件，用户浏览推荐商品列表可以对应到访问商品页面这一事件。事件分析可以筛选出满足条件的事件并统计其所涉及的各类指标数值，比如统计最近一周首页访问量；统计并分析最近一个月北京市有过购买行为的用户量等。
• 漏斗分析：即通过漏斗图的方式展示分析结果，主要用于对一个有多步骤的流程进行整体分析。比如用户在某电商平台的购买流程包含浏览商品、点击商品详情、发起拼单、立即支付、支付完成等步骤，漏斗分析可以将该流程视为一个整体，分析其中各重要步骤的转化率和随时间的变化情况。
• 留存分析：可以统计满足某初始条件的用户，在后续发生留存行为的数据分布情况。传统的留存分析主要是分析用户活跃情况，即新增用户后续是否继续使用产品功能，其实对于新增用户后续是否发生购买行为，是否发布评论等其他行为也可以纳入留存分析的范畴。借助留存分析可以了解用户的使用情况，从而反映产品对于用户的价值大小。

以上是几种常见的行为分析模型，业界常见的分析模型还有页面分析、指标分布分析、行为跨度分析和商业价值分析等，其底层依赖的数据都是用户行为数据，只是上层构建的分析模型不同。

标签服务

标签服务主要以数据服务的形式存在，一般通过接口或者底层数据表的形式对外提供服务，其中接口服务主要包括标签查询和元数据查询。

• 标签查询服务：标签数据可以进行数据服务化并支持标签查询功能，比如给出用户ID可以返回该用户的性别、年龄等标签信息；给出设备ID可以返回设备操作系统、App版本等信息。标签查询服务最终可以通过微服务的形式对外提供，大部分场景下标签查询请求量较大且QPS较高，需要支持分布式和高并发场景。
• 元数据查询服务：标签元数据包括标签名称、创建人、标签准确率和覆盖率、标签存储信息、标签生成规则、标签值及其占比分布等信息。画像平台中涉及展示标签信息的功能模块都会调用标签元数据查询服务，比如在规则类标签生成、规则人群创建等页面上需要展示出标签的基本信息以及标签值选项；为了引导用户更合理地使用标签，需要增加标签注释信息，注释中的数据口径、标签准确率和覆盖率信息等都来自元数据查询服务。元数据查询服务使用场景较多但是大部分请求QPS并不高，需要严格保证元数据的准确性。

画像平台难点之：ID-Mapping

1. 概念介绍

什么是ID-Mapping

ID-Mapping从字面理解就是ID之间的映射，即不同ID之间能够映射关联到一起。业界一般期望通过唯一的ID来表达用户实体，最终实现物理世界的实体在网络世界中有唯一的ID标识。很多公司使用ID-Mapping来打通ID体系，比如阿里巴巴每个业务可以通过淘宝账号打通，腾讯可以借助微信号或者QQ号打通各业务数据，神策数据支持ID-Maping并通过唯一的神策ID来标识用户。

业务逻辑

现实存在的问题
在现实的日志数据中，由于用户可能使用各种各样的设备，有着各种各样的前端入口，甚至同一个用户拥有多个设备以及使用多种前端入口，就会导致日志数据中对同一个人，不同时间段所收集到的日志数据中，可能取到的标识个数、种类各不相同。

比如：用户可能使用各种各样的设备：手机、平板电脑；安卓手机、ios手机、winphone手机；安卓系统有各种版本（5.0 6.0 7.0 8.0 9.0）；ios系统也有各种版本（3.x 4.x 5.x 6.x 7.x … 12.x）。

产生问题：用户设备的标识，没办法轻易定制一个规则来取某个作为唯一标识：mac：手机网卡物理地址，若干早期版本的ios，winphone，android可取到imei(入网许可证序号)：安卓系统可取到，若干早期版本的ios，winphone可取到，运营商可取到imsi(手机SIM卡序号)：安卓系统可取到，若干早期版本的ios，winphone可取到，运营商可取到androidid：安卓系统idopenuuid(app自己生成的序号)：卸载重装app就会变更idfa（广告跟踪码）deviceid(app日志采集埋点开发人员自己定义一种逻辑id，可能取自android,imei,openudid等)：逻辑上的id。

从而导致：有一些数据中，用户有登录账号，而有些没有；有一些数据中，有imei码，mac地址；而有些则有mac地址和android；前一日的数据中，有uid，android，而后一日数据中有android，mac地址。在这些情况中，如果按照之前的方案来生成数据的唯一标识，显然错漏百出！

要从这些纷繁复杂的各类id中，分辨出哪些id属于同一个受众（设备），用普通的“where x=y”这种简单条件逻辑很难实现。

2. 常见用于标识用户的id

2.1 user_id

• 适用平台：ALL
• 说明：各个应用在用户注册后给用户生成的唯一登录用户id
• 使用条件：用户必须处于登录状态，用户行为数据中才能取到user_id

2.2 cookie

• 适用平台：Web&H5
• 说明：Cookie是当你浏览某网站时，网站存储在你机器上的一个小文本文件，它记录了你的用户ID，密码、浏览过的网页、停留的时间等信息，当你再次来到该网站时，网站通过读取Cookie，得知你的相关信息，就可以做出相应的动作，如在页面显示欢迎你的标语，或者让你不用输入ID、密码就直接登录等等
• 使用条件：cookie有过期时间，过期后cookie会重新生成

2.3 IDFA

• 适用平台：Apple 设备
• 说明：全称广告标识符（Identifier For Advertising）苹果在iOS 6 推出了IDFA，每一台苹果设备拥有一个IDFA，除非用户都对IDFA进行重置，否则IDFA保持不变并独一无二
• 使用条件：iOS 14 之后，App在访问用户设备的IDFA之前，必须明确请求用户许可，每个APP都要，简单理解就是以后IDFA的获取需要用户授权，可能会获取不到

2.4 IDFV

• 适用平台：Apple 设备
• 说明：全称应用开发商标识符（Identifier For Vendor）同一开发商下的不同app信息共享。也就是说它只保证每个设备在所属同一个Vender的应用里，具有相同的值
• 使用条件：重装或升级系统后都会重新产生；如果用户将属于此Vender的所有App卸载，则idfv的值会被重置，即再重装此Vender的App，idfv的值和之前不同

2.5 IMEI

• 适用平台：Android 设备
• 说明：手机序列号，所有使用移动网络的设备都应该有IMEI
• 使用条件：在Android 6.0以上获取IMEI码是需要动态申请用户权限的，一旦用户拒绝了该权限就获取不到了。在Android 10中官方已经明确说明第三方应用无法获取到IMEI码

2.6 Android_ID

• 适用平台：Android 设备
• 说明：是设备的系统首次启动时随机生成的一串字符
• 使用条件：容易变化，root、刷机或恢复出厂设置都会导致设备的ANDROID_ID发生改变

2.7 MAC地址

• 适用平台：Android 设备
• 说明：mac地址只由设备的网卡决定，每个网卡都会有一个唯一的mac地址
• 使用条件：MAC地址是可修改的，并且不能确定以后会不会限制

2.8 OAID

• 适用平台：Android 设备
• 说明：OAID全称匿名设备标识符(Open Anonymous Device Identifier)。OAID 字段是由中国信通院联合华为、小米、OPPO、VIVO 等厂商共同推出的设备识别字段。
• 使用条件：OAID 也有获取不到的时候，在恢复出厂设置后会重置，并提供给用户关闭和重置的权利，重置后 OAID 值也会改变

2.8 OpenID

• 适用平台：微信
• 说明：OpenID = 用户微信号&公众平台APPID（两个数据加密得到的字符串）
• 使用条件：同一个用户多个微信应用中，id不同

2.8 unionID

• 适用平台：微信
• 说明：如果开发者拥有多个移动应用、网站应用和公众帐号，可通过获取用户基本信息中的unionid来区分用户的唯一性，因为同一用户，对同一个微信开放平台下的不同应用（移动应用、网站应用和公众帐号），unionid是相同的
• 使用条件：必须拿到用户授权

3. 业务ID分类

业务ID
在不同业务阶段的不同触点，都有不同ID来标识用户，例如设备ID、邮箱地址、微信的 OpenID 和 UnionID，用户登录标识等，这些ID统称为业务ID，业务ID可以大致分为User_ID、设备ID、特定生态的ID三类：

• 1-User_ID：User_ID 主要是实际业务系统中的用户 ID，比如用户登录 ID，通常是业务数据库里中用户表的主键。相比于特定生态的 ID，这类 ID 主要是由业务系统生成，稳定性更高，生命周期更长。
• 2-设备ID：设备 ID 指的是客户端 SDK 在首次初始化后，默认生成的设备 ID，例如 Web 端的 cookie_id，iOS 端的 IDFV。这类业务 ID 的特征是不稳定、生命周期也比较短。例如 Web 端的 Cookies 有可能被清空（比如各种安全卫士），iOS 端的 IDFV 在 App 卸载重新安装后会发生变化等。
• 3-特定生态ID：特定生态 ID 指的是各生态中标识用户的 ID，例如微信生态的 OpenID、UnionID，企业微信生态的外部联系人 ID。这类业务 ID 相比于设备 ID，稳定性会大大提高，生命周期也相对较长，但是仍然会存在变化的可能。例如 App 注册登录后，绑定了微信号，后续可能因为各种原因，解绑之前的微信号，重新绑定一个新的微信号。

4. 微信（个人微信）的ID体系

微信的ID体系可以算是所有巨头中最为复杂的。皆因微信本身体系的庞大：订阅号、服务号、小程序、企业号，以及在这些体系上跑的H5。不仅如此，微信与其他各个巨头的平台相比，也具有最好的开放性，因此，它又可能糅杂了很多外部生态的ID。

不过，虽然看起来挺复杂，但只要你梳理清楚了逻辑，微信的ID体系其实还是很简单的。并且，由于微信的开放性，你会发现微信的ID实际上也是“最好用”的。

先从它的公众号开始。

微信公众号的ID：OpenID和UnionID的前世今生

微信公众号，无论是订阅号还是服务号，ID体系是完全一致的。分为两种，OpenID和UnionID。

简单讲，同一个人，他follow公众号时，将会被自动分配一个OpenID。而他follow另一个公众号，则将被分配另一个OpenID。两个OpenID都是很随机的代码，并且毫无关联。一个人follow了多少个公众号，就会有多少个互相毫不相干的OpenID。

同样，一个公众号有多少个follower，也就会有多少个OpenID被生成。

OpenID是随着微信发布朋友圈和公众平台（公众号的后台）而诞生的，时间是2012年。

2014年，微信应公众号用户和开发者的要求，开始提供UnionID。这个要求是什么呢？原来，同一个用户，在不同公众号，有不同的OpenID，这给很多公众号运营者带来了麻烦。

比如，我手上有三个公众号，同一个用户在三个公众号中必然有三个不同的OpenID。这导致我并不知道他是同一个人，对他的针对性运营（例如不同公众号之间的信息通信、用户状态同步、针对性推送以及后来出现的营销自动化等等）就无法实现。

对订阅号而言，这个问题不大，但对服务号，这种具有非常好的互动性和运营潜力的平台而言，仅仅只有OpenID就显然跟不上情势的发展了。

于是UnionID被设计出来并被采用。看起来像是权宜之计，但也不啻为一个可行的办法。

UnionID最初的规则是这样：同一个用户，如果follow了同一个主体下的多个公众号，那么他在这些公众号内都只有一个UnionID。所谓同一个主体，一般而言，指一个营业执照或者组织机构代码证所指的一个组织。

但是在2018年年底，微信宣布，一个企业主体，从过去能够注册很多个公众号，变为只能注册两个公众号。那么，对于那些有多个营业执照或组织机构代码证的集团而言，它们的公众号又将变得无法打通了。

于是UnionID的规则也做了修改，不再强调必须是一个主体的公众号才能拥有共通的UnionID，而可以通过微信开放平台后台的绑定，实现不同主体公众号拥有共同的UnionID。

而要绑定不同的公众号，有一个前提条件，那就是这些公众号必须都在一个微信开放平台的账号之下。

公众号的OpenID和UnionID如何获取

简单讲，公众号的开发者，基于腾讯提供的“微信开放平台”就可以获得follow公众号的用户的OpenID。具体技术细节我就不讲了，对于开发者而言，这非常简单。

UnionID的获取，比OpenID多一个要求，即，多个公众号要在微信开放平台中做绑定，之后的获取方法与OpenID的获取其实没有区别。

讲到这里，要啰嗦一下微信提供的数据传输接口，即OpenAPI，通过这个接口，可以返回很多微信中各种应用（例如公众号、小程序等都是微信中的应用）的用户的基础信息。OpenID和UnionID就是通过这个接口获取的。

此外，借助OpenAPI，也能帮助微信中被打开的H5，或是利用微信共享登录的网站和app等，获取到企业自己的微信用户的相关信息（包括OpenID和UnionID）。这一点对于利用微信生态进行用户的数据打通，至关重要。

微信小程序所用的ID

微信小程序所用的ID，其实仍然是OpenID和UnionID。本质上，如同前面所说的，微信对所有在其上跑的应用，无论是公众号，还是小程序，或者其他的H5，以及利用微信号登录的网站和app等，都提供OpenID和UnionID。

微信小程序OpenID和UnionID的获取方式，与在公众号上相似，开发者通过官方文档就能搞定，不再赘述。

企业微信所用的ID

与微信相关的ID麻烦的地方在于，腾讯还有一个企业微信，而企业微信，既独立，又跟微信有千丝万缕的关系，因此它的ID体系，跟个人微信有关联，但又不一样。

要搞清楚企业微信所用的ID，首先要搞清楚一个逻辑，即企业微信中的几种用户或好友的类别。

企业微信的用户，分为两种，一种是企业微信成员，就是这个企业的员工，另外一种是企业客户，也就是企业微信的好友。这些好友又分为两种，一种用的是他们的企业微信成为你的企业微信的好友，另外一种更常见的，则是用的他们自己的个人微信，成为了你的企业微信的好友。

有点儿拗口，用下面这个图表示：

而上面的这些用户的不同类别，在企业微信中，他们被赋予的ID也是不同的。简单讲，企业微信成员的ID，是UserID。

而企业客户的ID，无论他使用的是自己的企业微信加的好友，还是用的个人微信，他在这个企业的企业微信中都会被赋予一个新的ID，即External_UserID。

而企业要获取这些ID，企业微信同样也提供了类似微信开放平台的API，企业微信相关应用的开发者可以获取。

企业微信用户的ID和个人微信的ID的打通

这是一个比较复杂的问题，可能关注的朋友们还不多，但如果企业微信用户越来越多，这样的问题就可能会常常遇到。

企业微信用户的ID和个人微信的ID打通，要分为不同的场景。一种场景，是同一个人在你的企业微信中，以及在他的个人微信群聊中，分别点开了你的小程序。

我们能知道分别两次点开你的小程序的这个用户，是同一个人吗？

答案是，他在首次进入这个小程序的时候，小程序会赋予他一个OpenID和UnionID（如果做了微信开放平台绑定的话，能获得UnionID），之后无论他以何种方式再进入这个小程序，他的ID都不会再发生变化。因此，显然我们都能知道这个用户是同一个人，而无论他是从自己的微信群中进入你的小程序，还是从你的企业微信中进入。

这种场景，如果不是小程序，而换成你的做好了绑定的app或者网页（H5）也没有区别。但另外一种场景，情况就不同，我们必须打通数据才能知道是同一个人。

例如如下的这个场景。同一个用户，在我的企业微信内有互动，比如参与了群直播，此外，他在我的公众号内也有互动，比如在服务号中完成了一次裂变。

我希望将该用户的这些行为数据能够打通，如果不能打通，那么这个客户的数据就会被分别记录为两个不同的人，这对运营工作十分不利。能做到吗？

答案是，能做到。方法有多种，最官方的方式，是企业微信也获取该用户的UnionID。然后，公众号和企业微信中该用户的UnionID是同一个，这样数据就能够打通了。

这种方法不困难，因为企业微信支持在管理后台客户联系处绑定与企业微信主体一致的公众号或小程序。而一旦绑定完成，就可以通过接口获取微信联系人所对应的微信UnionID。

这实际上也说明了，企业微信，对于个人微信而言，也被认为是一种微信应用，与公众号、小程序等本质上是同类。

APP、网站获取微信的ID

其实前面已经介绍了，除了公众号和小程序，在微信开放平台中做了绑定的app和网站等，也可以获得微信用户的UnionID。当然，前提是这些用户得用他们的微信号登录app和网站（联合登录）。

这样，这些用户在app和网站上的行为数据，也就能够跟公众号和小程序上的行为数据打通。App和网站与微信上的用户数据打通的另外一种方式，是透过user ID，这里的user ID，不是企业号的User_ID，是用户自己注册的user ID。这一方式对于服务号（企业自建H5页面）和小程序是可用的。即，同一个用户在app、网站，以及微信的服务号和小程序都用同样的user ID登录，然后数据也能得以打通。

这种方式看似麻烦（用户比较麻烦），但是最为可靠。

微信体系的ID存在个人隐私侵犯的风险吗

有段子传说在个人信息隐私保护法律的内部会议上，有过尖锐的争论，一部分大佬们认为微信体系的ID要纳入隐私监管的范围。我认为这只是一个段子。

但微信体系的ID，确实更类似于一个假名ID。换一个公众号，OpenID就变了，UnionID也可能就变了，但如果你取关一个公众号，然后重新加入进去，OpenID和UnionID是不变的。因此，你其实并没有能够手动更新这些ID的能力。这一点与上篇我介绍的IDFA或者OAID有显著的不同。

从这个角度看，这个ID已经有些类似于user ID之类的东西，确实存在一定的隐私风险。

但目前没有法律规定这一领域，在实际的营销工作中，都将微信体系的这些ID，视同为不侵犯用户隐私的ID。

5. 常见ID-Mapping方案

方案一：通过全局唯一ID建立联系，ID关联的方式。

1. 仅使用DeviceId

图4-16展示了只使用DeviceId标识用户的示意图。部分工具类应用，比如杀毒、文件管理和解压缩工具等用户登录率较低，比较适合通过DeviceId来唯一标识用户。只要用户DeviceId不变就可以认为是同一个用户，用户登录前后的数据也可以使用DeviceId实现打通。

只使用DeviceId标识用户的实现方式比较简单，但是其缺点也比较明显。不同用户使用同一个设备会被标识为同一个用户，而同一个用户使用不同设备会被识别成不同用户。如果多用户使用同一设备或者同一个用户使用不同设备的概率较小，仅使用DeviceId标识用户也是可行的。

2. 一个DeviceId关联到一个UserId

图4-17展示了一个DeviceId绑定到一个UserId的示意图。同一个设备登录前的DeviceId可以与登录后的UserId进行绑定，且DeviceId只可以绑定到一个UserId。当用户切换设备并登录后，其数据可以与老设备上的数据贯通。

方案二相对方案一可以更精确的标识用户，登录到同一个设备的不同用户数据可以进行有效区分，同一个用户即使登录到不同设备也会准确识别为同一用户。但是一个DeviceId只能关联到一个UserId的方式也存在问题，因为现实中同一个设备上可能有多个登录用户使用，一个登录账号也会使用到多个设备上面。所以这种一对一的关联，存在如下问题：

• 一个未被绑定的设备登录前的用户和登录后的用户不同，这个时候会被错误地识别为同一个用户。
• 一个被绑定的设备后续被其他用户在未登录状态下使用，也会被错误地识别为之前被绑定的用户。
• 一个被绑定了的用户使用其他设备时，未登录状态下的数据不会标识为该用户数据。

3. 多个DeviceId关联到一个UserId

为了解决方案二中存在的一些问题，还可以采用多个DeviceId关联一个UserId的方式，只要登录后的UserId相同，其多个设备上登录前后的数据都可以贯通起来。图4-18展示了其示意图。

与方案二相比，方案三可以解决一个用户不能绑定多个设备的问题。但是因为一个DeviceId只能绑定到一个用户，当其他用户使用同一个已被绑定的设备时，其登录前数据还是会被识别成已绑定到该设备的用户。

4. 多个应用间的不同ID进行关联

以上方案都是针对单个应用的ID-Mapping方案，当存在多个应用并想实现应用间ID映射和数据打通时，可以采用不同应用间的ID关联方案。如图4-19所示，通过将不同应用间的业务ID进行关联，可以实现不同应用之间的打通，其中Phone、UserId和Email最终可以指向同一个用户。

基于用户各个业务线之间点和边的关系，我们会将用户在不同业务线中的信息全部抽取出来，放入一张大表里面进行 Union All 操作。这张表包含了手机号、体系 A 用户 ID、体系 B 用户 ID、身份证号和 Open ID 关键信息。OneID 的构建流程如下：

• 首先，利用 Doris 提供的 row number 窗口函数生成完整的全局行顺序。然后对所有 ID 关系数据进行 Union All 操作。
• 接着，使用窗口函数 dense rank 和 row number 的复数生成为空/不为空时的首列 Rank 值。
• 最后，通过循环迭代计算每一列最小距离，并不断迭代 Rank 值，直到当前列与上一迭代结果全局匹配。当所有数据连续匹配满 5 次后，就以最终 Rank 值为准进行用户分组，从而得用户唯一标识 OneID。

结合上图以及构建流程，可以得出结论：1 - 4 行是用户 1，5 - 6 行是用户 2。

以上介绍了4种常见的ID-Mapping方案，随着对用户识别准确度要求的提高，其工程实现复杂度也会提升。业务需要平衡好准确度和工程复杂度，根据自身业务特点选择合适的ID-Mapping方案。

方案二：借助外部存储Redis

(1) HBase数据表结构设计

安卓端表映射表结构(android_id_mapping)，其他端类似：

本地id 和 OneId映射表结构(local_id_mapping)：

(2) 为了应对高并发场景，将HBase提前预热至Redis缓存，redis表设计

(3) ID-Mapping 映射流程

票选服务：根据客户端上报的参数信息去redis 里面匹配OneID，核心权重设置

如上，就实现了同一个对象在不同端的ID-Mapping，将多端数据串起来，可以做更多的分析了。

方案三：借助图计算（spark-graphx）

采用图计算手段，来找到各种id标识之间的关联关系，从而识别出哪些id标识属于同一个人。

图计算的核心思想：将数据表达成“点”，点和点之间可以通过某种业务含义建立“边”。然后，我们就可以从点、边上找出各种类型的数据关系：比如连通性；比如最短路径规划。

id_mapping(id打通)的最后目标，就是形成一个id映射字典：

整体流程：

1. 将当日数据中的所有用户标识字段，及标志字段之间的关联，生成点集合 、边集合。
2. 将上一日的ids->guid的映射关系，也生成点集合、边集合。
3. 将上面两类点集合、边集合合并到一起生成一个图。
4. 再对上述的图执行“最大连通子图”算法，得到一个连通子图结果。
5. 在从结果图中取到哪些id属于同一组，并生成一个唯一标识。
6. 将上面步骤生成的唯一标识去比对前日的ids->guid映射表（如果一个人已经存在guid，则沿用原来的guid）。

方案四：图数据库nebula-algorithm/neo4j-algorithm

读取测试数据代码

import com.vesoft.nebula.connector.connector.{NebulaDataFrameReader}  
import com.vesoft.nebula.connector.{NebulaConnectionConfig, ReadNebulaConfig}  
import org.apache.spark.sql.{DataFrame, Row, SparkSession}  
import org.apache.spark.sql.types.{StringType, StructField, StructType}  

object ReadData {  
  /**  
    * 
end