时至今日，大数据已经兴起多年，许多公司也在大数据的建设上投入很多，但是最终的数据赋能仿佛除了
数据仓库就是
报表，或者口头上的
支持高策的数据决策，然后实际带来的更多也是所谓的原始数据，抓不住关键且缺少洞见的数据反而是常态，那如何走出这样的数据困境呢？
用户画像就是一个不错的大数据应用方向，在
用户画像的基础上实施的个性化推荐和搜索，精准营销，个性化服务等，都让大数据的应用有了更多的延展。今天就和大家一起聊一聊
用户画像系统的构建。
1. 数据集成与治理
构建用户画像的前提是需要先了解自己公司的私域有什么数据，私域里面哪些数据是自己可控的，哪些是需要沟通与协作才能获取的，公域中又有什么数据能赋能自己。
1.1 私域
私域需要盘点自己企业内的所有触点或者系统，弄清楚这些系统及触点的职能和有什么数据等，但是因为系统分布问题，有些系统虽然是私域的，但是本身集成在公司集团侧，甚至在Global侧，这些数据虽然在私域，但是却需要一定的沟通与协助才能集成，如图1.1.1。
- toC系统：App，小程序，官网，微信公众号……
- toB系统：门店管理系统，活动管理系统……
- CRM系统：用户信息系统，会员俱乐部系统……
- 主数据系统：产品主数据，IoT数据……
- 其他：用户行为埋点系统……
图 1.1.1 私域系统数据梳理
1.2 公域
这方面的数据主要来源于第三方的DMP(Data Management Platform)数据管理平台（如阿里瓴羊，字节火山引擎，腾讯企点等）；以及咱们公司行业的垂媒（如汽车行业的汽车之家，易车，懂车帝；电商行业的淘宝，天猫，京东，拼多多等）。但是这些公域的数据由于法律法规隐私的问题，往往是不支持直接导出给到咱们的，一般支持在这些公域平台的上直接集成应用，通过应用（广告，活动，发券等）形式将第三方的用户引流到私域来。
1.3 私域和公域数据对比及应用
1.3.1 数据对比
主要从数据丰富度和API开放程度对比公域和私域的数据，数据丰富度体现数据应用的可能性，API开放度体现定制化数需求的落地实现的可能性，具体如图1.3.1。
1.3.2 数据治理与打通
目前私域和公域的数据打通主要还是比较依赖用户的手机号及邮箱，围绕手机号为中心构建内部的OneID，如果特殊的生态圈如微信生态圈，则支持同一个开发者账号下的微信生态圈下UnionID能唯一标识用户，具体如图1.3.2所示。
1.3.3 数据应用链路
先将私域/公域平台的数据进行集成和治理，打破各渠道间的数据壁垒，构建用户在全渠道上的行为链路，为营销自动化和个性化数据服务等功能提供数据支持，具体链路如图1.3.3。
2. 用户画像概念和类别
2.1 用户画像核心技术和应用场景
用户画像的核心技术重在解决以下几个方面：
数据指标体系：分析用户从游客，注册用户，潜客，高潜，线上进店或门店，体验产品，购买，售后等关键节点的User Journal的数据指标，从而构建完整的数据指标体系，为全貌的用户画像打下基础。标签数据的存储：标签的元数据（标签的类别，Comment，Description，etc等描述标签介绍的数据），本身数据量不大，适合关系型数据库的存储；根据用户ID查询用户画像标签则适合Key/Value的数据库，以及根据标签圈选人群的需求时，标签的组合对索引性能的要求比较高，一般会适合存在具有搜索引擎功能的数据库内。标签数据开发：进入用户画像的底层表及产品化的开发；开发性能调优：针对标签计算，存储侧遇到的一些负载不均衡或瓶颈进行相应的优化迭代。用户画像系统和其他系统的打通：针对标签的具体应用场景与下游系统的自动化集成，如和终端触点的个性化推荐，微信朋友圈、抖音，百度广告的个性化营销投放等。
图2.1.1 用户画像核心技术举例
用户画像的核心应用场景如下：
全渠道用户运营用户生命周期运营个性化MA（Marketing Automation）及Promotion用户特征库筛人A/B群效果测试人群CJA（Customer Journal Analysis）用户个性化服务全渠道用户运营
2.2 用户画像和用户标签的关系
用户画像=标签的集合。
-
用户标签：化整为零，每个标签规定了观察，认识，描述用户的一个角度； -
用户画像：化零为整，用户画像是一个整体，各维度不孤立，标签之间有联系。
2.3 定量画像Profile和定性画像Persona
用户画像总体可以分为定量（Profile）的画像和定性（Persona）的画像，定量的画像主要来源于在线触点和系统，通过大数据沉淀出来的画像规律；定性的画像更多是通过和客户的线上和线下交流，得到的用户反馈，具体如图2.3.1。
2.4 用户标签的类型
用户标签的分类依据有很多，通常根据标签的产生原理可以分为统计类标签，规则类标签和机器学习挖掘类（算法类）标签，具体如图2.4.1。
3. 标签的设计与实现
3.1 标签元数据表
标签的元数据（metadata），就是解释现有标签的类别，描述，计算逻辑等标签介绍的数据，每次新增，修改，删除，编辑标签都需要先来该表内完成注册及更改，具体如表3.1.1。
| label_id | label_name | label_weight_example | label_logic | label_type |
|---|---|---|---|---|
| REG_USER | 注册用户 | 360 | 用户注册日期起到目前的天数 | 统计类标签 |
| LAST_VISIT_USER | 最近几天访问用户App | 12 | 用户最近几天访问了App | 规则类标签 |
| FAVOR_SPORT_PRODUCT | 最喜欢的体用商品 | 篮球 | 用户最喜欢的体育用品 | 算法类标签 |
3.2 用户标签明细表
标签明细表记录每个用户的user_id和现在有标签id的之间的关系，为了方便数据的更新，采用user_id和label_id之间一对多的关系存储，具体如表3.2.1。
| user_id | label_id | label_weight |
|---|---|---|
| Zp7Gzh0ExCSnD | REG_USER | 360 |
| VP90Vq-8PN | LAST_VISIT_USER | 12 |
| Zp7Gzh0ExCSnD | FAVOR_SPORT_PRODUCT | 篮球 |
3.3 用户标签汇总表
用户标签汇总表则以user_id为聚合依据，将该user_id下所有的标签聚合成key，value的键值对的map结构如表3.3.1。
select ul.user_id
,str_to_map(concat_ws(',',collect_set(concat(ul.label_id,':',ul.label_weight)))) as tags_map_id
,str_to_map(concat_ws(',',collect_set(concat(ul.label_name,':',ul.label_weight)))) as tags_map_name
from dwd.dwd_user_label ul
inner join dim.dim_label_dic ld
on ul.label_id=ld.id
where ul.dt='2024-07-13'
group by ul.user_id
;
| user_id | tags_map_id | tags_map_name |
|---|---|---|
| Zp7Gzh0ExCSnD | {“REG_USER”:“360”,“FAVOR_SPORT_PRODUCT”:“篮球”} | {“注册用户”:“360”,“最喜欢的体用商品”:“篮球”} |
| VP90Vq-8PN | {“LAST_VISIT_USER”:“12”} | {“用户最近几天访问了App”:“12”} |
3.4 User ID Mapping 及 Merge
由于标签的源数据可能来源不同的触点或终端，但是各个终端之间的用户ID未必又是一致的，为了更好的统计各个用户在不同终端的标签表现，因此需要针对此类情况构建一张User ID Mapping 及融合表，即User ID的映射与融合表如表3.4.1
| UserID | 私域OneID | 手机号加密ID | 游客ID |
|---|---|---|---|
| Zp7Gzh0ExCSnD | AAA | ||
| VP90Vq-8PN | c1c2 | ||
| shakVq987N | sjdgqwbwiewdhb |
如表3.4.1，当一开始就是注册用户拥有私域OneID （即公司内容的注册ID），则利用该ID生成的UserID具有最高优先权，后续哪怕得知了该用户的手机号，游客ID等，都只能将相关的手机号，游客ID更新到该私域OneID下；反之，如果该用户还未注册私域OneID，则先依据手机号加密的ID或者游客ID先分配一个UserID，如果有一天注册了私域OneID，则更新出OneID，如果用户提供的手机端注册OneID（假如为A）手机号已存在，但是在另一个终端如Web端未注册却用手机号做个咨询，则Web端根据手机号生成的UserID应该合并到注册的OneID=A这条记录中，原来Web端的UserID则去掉。
3.5 应用场景
根据场景来圈选标签即可，据体的操作依据如表3.5.1，其中1表示勾选此标签用户进行应用，如投放触达或产品弹窗推荐。
| 场景值\标签 | 注册用户 | 访问用户 | 最喜欢的体育产品 |
|---|---|---|---|
| 体育产品打折 | 1 | ||
| 注册用户发券 | 1 |
4. 后续标签内容的丰富
后续标签的丰富，博主在此举一些例子，不完善出可以大家一起留言补充
- 用户属性
-
基础属性标签
- 姓名：First Name，Last Name，Full Name；
- 昵称
- 称呼语
- 头像
- 性别
- 生日
- 地址
- One ID
- 手机
- 邮箱
- Union ID
- Open ID
- 学历
- 注册城市
- 爱好
- 收入
- 职业
- ……
-
产品标签
- 是否已购买某产品
- 最喜欢的产品
- ……
-
社区标签
- 用户社区身份
- 社区勋章数
- 社区发帖数
- 社区内容消费数
- 社区内容分享数
- 社区内容点赞数
- 连续签到活跃天数
- 当前积分数
- 当前勋章数
- 当前粉丝数
- 当前关注数
- 社区参与活动数
- 社区感兴趣内容类型
- ……
-
活动标签
- 线上、线下活动报名次数
- 近期Top 3参与的活动类型
- ……
-
用户线上C端触点行为
- 小程序行为
- 近X天访问过小程序
- 近X天注册
- 近X天停留时长
- 近X天连续活跃天数
- 近X天留存率
- 近X天咨询过商品
- 近X天成交过商品
- 近X天领取X优惠券的次数
- 近X天搜索过的关键词topN
- 近X天访问过X页面
- 近X天点击过X按钮
- ……
- App行为
- 近X天登录过App
- 近X天注册
- 近X天停留时长
- 近X天连续活跃天数
- 近X天留存率
- 近X天咨询过商品
- 近X天成交过商品
- 近X天领取X优惠券的次数
- 近X天搜索过的关键词topN
- 近X天访问过X页面
- 近X天点击过X按钮
- ……
- 公众号行为
- 近X天访问过
- 近X天注册
- 近X天查看、点赞，喜欢，转发过内容
- ……
- 小程序行为
-
用户到店标签
- 近X天被接待
- 近X天成交
- ……
-
第三方标签
-
用户实际性别
-
用户购买性别
-
家里是否有娃
-
职业情况
-
收入情况
-
学历
-
用户常驻城市
-
用户引流来源
-
……
-
-
5. 标签系统产品化
用户标签产品，即针对各种用户表标签集合构建一个用户画像系统，也就是业内通常的CDP(Customer Data Platform)系统，如图5.1.0。
5.1 标签元数据
标签元数据主要包含标签视图与标签查询和标签覆盖人群功能。
-
标签视图与标签查询：主要面向业务人员使用。在标签视图模块中，层级化地展示了全部标签。用户可以层级化地通过点击标签，查看每个标签的详细介绍，具体如图5.1.1。
图5.1.1 标签视图与标签查询 -
标签覆盖人群: 在标签详情页中可以查看标签类目下具体标签的人群覆盖情况。每天通过对标签的覆盖用户量进行监控，可以作为预警使用，具体如图5.1.2。
标签元数据管理:标签编辑工作主要面向数据开发人员。标签的编辑管理也就是对标签做元数据管理，将编辑的标签数据存储到MySQL数据库中，具体如图5.1.3。
5.2 用户标签查询
用户标签查询主要包含离线标签查询和实时日志标签查询，在标签查询模块可以通过输入用户对应的UserID或者CookieID，查看该用户的属性信息，行为信息，风控属性等，多个维度信息，多方位了解一个用户的特征。
离线用户查询如图5.2.1所示。
实时日志标签查询则可以调取到该用户实时动态，具体如图5.2.2。
5.3 用户圈人
用户圈人功能主要面向业务人员使用。业务人员通过组合多个标签来透视分析人群、圈定人群，并选择推送到的业务系统，如图5.3.1。
6. 后续标签系统架构设计
结合标签系统产品化的主要实现标签的元数据，用户UserID来查询标签，用户圈人等功能，则具体的架构体系建议如图6.0.1。
以上就是关于用户画像/用户标签的构建的一些心得，也欢迎大家一起交流学习。
扫一扫
1万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
