-
{{item.corpname[0]}}
成员
微信扫码，关注“企微云”公众号完成申请
恭喜你，申请成功
扫码加专属顾问企业微信，我们将协助您进行线上体验！
微信扫码，关注“企微云”公众号完成申请
扫码加专属顾问企业微信，我们将协助您进行线上体验！
我要投稿
时至今日，大数据已经兴起多年，许多公司也在大数据的建设上投入很多，但是最终的数据赋能仿佛除了数据仓库就是报表，或者口头上的支持高策的数据决策，然后实际带来的更多也是所谓的原始数据，抓不住关键且缺少洞见的数据反而是常态，那如何走出这样的数据困境呢？用户画像就是一个不错的大数据应用方向，在用户画像的基础上实施的个性化推荐和搜索，精准营销，个性化服务等，都让大数据的应用有了更多的延展。今天就和大家一起聊一聊用户画像系统的构建。
构建用户画像的前提是需要先了解自己公司的私域有什么数据，私域里面哪些数据是自己可控的，哪些是需要沟通与协作才能获取的，公域中又有什么数据能赋能自己。
私域需要盘点自己企业内的所有触点或者系统，弄清楚这些系统及触点的职能和有什么数据等，但是因为系统分布问题，有些系统虽然是私域的，但是本身集成在公司集团侧，甚至在Global侧，这些数据虽然在私域，但是却需要一定的沟通与协助才能集成，如图1.1.1。
这方面的数据主要来源于第三方的DMP(Data Management Platform)数据管理平台（如阿里瓴羊，字节火山引擎，腾讯企点等）；以及咱们公司行业的垂媒（如汽车行业的汽车之家，易车，懂车帝；电商行业的淘宝，天猫，京东，拼多多等），但是这些公域的数据由于法律法规隐私的问题，往往是不支持直接导出给到咱们的，一般支持在这些公域平台的上直接集成应用，通过应用（广告，活动，发券等）形式将第三方的用户引流到私域来。
目前私域和公域的数据打通主要还是比较依赖用户的手机号及邮箱，围绕手机号为中心构建内部的OneID，如果特殊的生态圈如微信生态圈，则支持同一个开发者账号下的微信生态圈下UnionID能唯一标识用户，具体如图1.3.2所示。
先将私域/公域平台的数据进行集成和治理，打破各渠道间的数据壁垒，构建用户在全渠道上的行为链路，为营销自动化和个性化数据服务等功能提供数据支持，具体链路如图1.3.3。
用户画像的核心技术重在解决以下几个方面：
数据指标体系：分析用户从游客，注册用户，潜客，高潜，线上进店或门店，体验产品，购买，售后等关键节点的User Journal的数据指标，从而构建完整的数据指标体系，为全貌的用户画像打下基础。标签数据的存储：标签的元数据（标签的类别，Comment，Description，etc等描述标签介绍的数据），本身数据量不大，适合关系型数据库的存储；根据用户ID查询用户画像标签则适合Key/Value的数据库，以及根据标签圈选人群的需求时，标签的组合对索引性能的要求比较高，一般会适合存在具有搜索引擎功能的数据库内。标签数据开发：进入用户画像的底层表及产品化的开发；开发性能调优：针对标签计算，存储侧遇到的一些负载不均衡或瓶颈进行相应的优化迭代。用户画像系统和其他系统的打通：针对标签的具体应用场景与下游系统的自动化集成，如和终端触点的个性化推荐，微信朋友圈、抖音，百度广告的个性化营销投放等。用户画像的核心应用场景如下：
全渠道用户运营用户生命周期运营个性化MA（Marketing Automation）及Promotion用户特征库筛人A/B群效果测试人群CJA（Customer Journal Analysis）用户个性化服务全渠道用户运营用户画像=标签的集合。
用户标签：化整为零，每个标签规定了观察，认识，描述用户的一个角度；用户画像：化零为整，用户画像是一个整体，各维度不孤立，标签之间有联系。标签的元数据（metadata），就是解释现有标签的类别，描述，计算逻辑等标签介绍的数据，每次新增，修改，删除，编辑标签都需要先来该表内完成注册及更改，具体如表3.1.1。
标签明细表记录每个用户的user_id和现在有标签id的之间的关系，为了方便数据的更新，采用user_id和label_id之间一对多的关系存储，具体如表3.2.1。
用户标签汇总表则以user_id为聚合依据，将该user_id下所有的标签聚合成key，value的键值对的map结构如表3.3.1。
selectul.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_namefrom dwd.dwd_user_label ulinner join dim.dim_label_dic ldon ul.label_id =ld.idwhere ul.dt = '2024-07-13'group by ul.user_id;
由于标签的源数据可能来源不同的触点或终端，但是各个终端之间的用户ID未必又是一致的，为了更好的统计各个用户在不同终端的标签表现，因此需要针对此类情况构建一张User ID Mapping 及融合表，即User ID的映射与融合表如表3.4.1
ID的映射和融合方式参考：如表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.1，其中1表示勾选此标签用户进行应用，如投放触达或产品弹窗推荐。
后续标签的丰富，博主在此举一些例子，不完善出可以大家一起留言补充
标签元数据主要包含标签视图与标签查询和标签覆盖人群功能。
标签视图与标签查询：主要面向业务人员使用。在标签视图模块中，层级化地展示了全部标签。用户可以层级化地通过点击标签，查看每个标签的详细介绍，具体如图5.1.1。标签覆盖人群: 在标签详情页中可以查看标签类目下具体标签的人群覆盖情况。每天通过对标签的覆盖用户量进行监控，可以作为预警使用，具体如图5.1.2。标签元数据管理:标签编辑工作主要面向数据开发人员。标签的编辑管理也就是对标签做元数据管理，将编辑的标签数据存储到MySQL数据库中，具体如图5.1.3。 用户标签查询主要包含离线标签查询和实时日志标签查询，在标签查询模块可以通过输入用户对应的UserID或者CookieID，查看该用户的属性信息，行为信息，风控属性等，多个维度信息，多方位了解一个用户的特征。
离线用户查询如图5.2.1所示。 实时日志标签查询则可以调取到该用户实时动态，具体如图5.2.2。用户圈人功能主要面向业务人员使用。业务人员通过组合多个标签来透视分析人群、圈定人群，并选择推送到的业务系统，如图5.3.1。结合标签系统产品化的主要实现标签的元数据，用户UserID来查询标签，用户圈人等功能，则具体的架构体系建议如图6.0.1。
以上就是关于用户画像/用户标签的构建的一些心得，当然具体实操的时候还是会遇到不少的挑战和优化，也欢迎大家一起交流学习。
WeSCRM专注2B场景的SCRM系统
产品：企微SCRM系统+微信机器人+私域陪跑服务
承诺：产品免费试用七天，验证效果再签署服务协议。零风险落地企微SCRM，已交付6000+ 2B企业
2025-05-07
2025-01-07
2024-10-30
2024-10-30
2025-01-23
2024-10-30
2025-02-20
2025-02-07
2025-05-08
2024-10-30
联系顾问
联系企微云
了解更多信息
返回顶部
