用户画像系统实战:从ID-Mapping到标签体系的架构全解析
做用户画像这个项目,最早其实就是一个名为“up”的内部代号——全称是 User Profile,我们团队习惯叫它“UP 系统”。当时业务方给的需求只有一句话:“我要能随时知道一个用户是谁、喜欢什么、下一步会干什么。”这句话听着没什么,真正落地上来,你会发现背后牵扯的是一整套从数据采集、加工、建模到服务的完整链路。这篇就把我们当时搭建 UP 用户画像系统的思路、踩过的坑、以及最终跑通的具体方案捋一遍,内容会偏实操,所有关键环节都能直接参考。
1. 整体设计与思路拆解
1.1 画像系统的本质:把数据变成可执行标签
先说一个容易被忽略的点:用户画像不是“用户列表”,也不是简单的数据报表。它的核心产物是标签,而标签的本质是“对用户在某个业务场景下的状态或行为作出的可计算、可更新、可消费的判断”。换句话说,画像系统的输入是原始数据,输出是一组可以直接被业务系统查询、圈选、触达的标签集合。
举个例子,业务方问“这个用户高价值吗?”你直接拉SQL查“近30天消费金额 > 5000”,这是报表;但如果你有一个“高价值用户”标签,服务端只需要查一个标签表就能拿到结果,而且这个标签背后可以叠加消费频率、品类广度、活跃天数、客单价稳定性等多个维度,业务方完全不需要关心计算逻辑。这就是画像系统存在的价值:把复杂的计算逻辑封装成稳定的业务语义。
在设计 UP 系统时,我们最开始就明确了几个原则:
- 标签必须分层,不能所有标签平铺,否则维护成本会爆炸
- 标签值必须有生命周期,过期数据不能一直占着位置
- 标签要可解释,运营人员需要知道这个标签为什么打给用户,否则不敢拿来决策
- 实时与离线分离,高时效性标签走实时链路,非时效性标签走离线批处理
这套原则决定了后面的整体架构和技术选型。
1.2 标签体系的四层模型
UP 系统的标签模型我们参考了行业内比较成熟的分层思路,最终落成四层:
第一层:基础属性标签
这是用户主动提供或由业务系统直接记录的数据,比如性别、年龄、注册城市、会员等级、设备型号。这些标签的特点是:变化频率低,但准确性要求高。性别和年龄这类信息在部分业务里可能缺失,就需要用模型做推断,但我们默认的第一优先级永远是用户自填数据,模型推断只能作为兜底。
第二层:统计类标签
这是最常见的画像标签,来自用户行为数据的聚合计算。典型例子包括:“近7天活跃天数”“近30天订单数”“累计消费金额”“最近一次登录距今天数”“近90天浏览商品类目Top3”。这些标签的特点是:逻辑简单清晰,基本都是 count、sum、max、min、distinct 这类常规聚合,性能瓶颈主要在于数据量和计算窗口。
第三层:规则类标签
在统计类标签的基础上,叠加业务规则生成。比如“沉睡用户”的定义是“近 30 天未活跃且已注册超过 90 天”;“高潜付费用户”的定义是“近 30 天浏览了 3 次以上付费课程但未下单”。这类标签的关键在于规则配置化,不能把规则写死在代码里,否则业务调整一次就要发一次版。我们用的是决策表 + 表达式引擎的方式,运营可以通过后台界面修改阈值和条件。
第四层:算法类标签
这类标签需要机器学习模型的参与,比如购买意愿预测、流失风险概率、用户兴趣偏好聚类。算法标签不能直接给业务一个“0.73”的分数就完事,必须映射成业务可理解的层级,比如把预测概率分成“高、中、低”三档,并且附上模型版本号和预测时间,方便溯源。
这个四层模型的好处是:每一层对上一层的依赖关系非常明确,统计层出了问题不会影响规则层和算法层的顶层语义,排查问题的时候也能快速定位。
2. 核心细节解析与实操要点
2.1 ID-Mapping:画像系统的地基工程
做画像系统,第一个绕不开的硬骨头就是 ID-Mapping。同一个用户在你的业务里可能有着五