《用户画像：平台构建与业务实践》阅读总结

AiryView

于 2025-02-09 14:20:48 发布

阅读量724

点赞数 8

分类专栏：用户运营文章标签：大数据用户运营用户画像 clickhouse hive flink

本文链接：https://blog.csdn.net/emttxdy/article/details/145519357

版权

用户运营专栏收录该内容

1 篇文章

订阅专栏

画像平台最主要的四个功能：标签管理、标签服务、分群功能和画像分析

1.标签管理

标签依赖底层源数据一般分为实时数据(其中实时数据一般是客户端实时上报或者服务端的实时日志)和离线数据(过往历史数据)

通过实时数据可以得到实时标签和行为明细数据，通过离线数据可以得到离线标签和挖掘类（借助算法模型挖掘）标签。

标签管理呈现给用户涉及到的数据主要有：标签元数据（比如创建者、创建时间、标签名称等等）、标签的标签值分布数据（比如性别标签的男女分布）、标签生产调度数据（比如用户当日购买金额这种标签需要每天调度一次，这里就需要设置生产调度数据）和标签分类数据（比如可以分为基础数据[例如性别、教育程度]、用户行为[例如每日评论数、当日被点赞数]和设备信息[例如设备操作系统、app版本]）

标签管理模块对外提供的功能：基于标签元数据的标签增删改查、基于标签值分布数据的标签分布查询、支持查询标签生产调度信息的标签生产管理、用于维护标签质量的标签数据监控。

总的来说标签管理的工程实现技术栈要点如下：

2.标签服务

标签服务主要分为标签查询服务、标签元数据查询服务以及标签实时预测

2.1.标签查询服务

标签查询服务简单来说就是给定实体id和标签id（以及时间）查询该实体的对应标签值

①首先依赖于底层的标签数据，例如用户常住省标签hive包含时间、用户id和常住省

②然后数据发现模块定时监测最新的标签数据是否就绪，就绪了就可以进行标签数据处理了

③标签数据处理主要包含数据清洗（去除无效数据）、数据裁剪（例如多值标签保留前几个，点赞数少于阈值可以忽略）、数据编码（字符串转为数字，降低资源消耗，例如十个省份转为0~9数字代替）以及数据压缩（压缩算法降低存储），经过这一系列处理后的数据存在另一个hive表中。

④处理后的标签数据被更新，就可以基于spark或者flink读取hive数据将其写入redis缓存中。

⑤最后前端发起请求，后端去redis里面取数据并返回。

2.2.标签元数据查询服务

标签元数据查询服务就是给定标签id查询其基本信息、分类信息、标签值信息等等。

①标签元数据主要是存在mysql中，如果标签的标签值选项非常多，那么可以将其存在Elasticsearch中提高检索效率。对于改动比较小的标签元数据存在redis中加快查询效率。

②前端请求，后端访问redis时，如果查不到，就要回查mysql并将结果写入缓存；元数据改变时直接删除缓存。

2.3.标签实时预测服务

标签实时预测服务本质是离线模型得到挖掘类标签的实时版。

对于挖掘类标签，比如用户是否已婚，本质是训练一个二分类模型，把训练好的模型用于线上实时推理，给定一个用户，得到用户实时特征作为模型输入，模型输出已婚/未婚预测结果。

ps：这里的实时特征需要依赖基于实时数据流构建的实时特征库。

3.分群功能

前面提到的标签查询，本质是基于用户查找标签，即正查，而分群功能，本质是基于标签查找用户，即反查。

分群功能主要分为三个部分：数据生成、人群创建和人群判存

3.1.数据生成

数据生成主要是生成两个结构：画像宽表和画像BitMap。

3.1.1画像宽表

画像宽表可以理解为是多个源标签数据表的一个集成封装表，比如将性别标签数据、常住省标签数据以及是否已婚标签数据整合后的画像宽表，里面就包含性别、常住省、是否已婚这几列，宽表顾名思义很宽，即列很多。

不过需要注意力的是有些标签会随着时间变化，所以画像宽表一般还有一列即日期用于分区。

那么画像宽表具体怎么生成呢？

常用技术手段：全量用户表左连接各种源标签数据表（通过用户id连接）。左连接保证全量用户行不变。

当标签很多时，可以将标签分组处理，最后各组的生成的中间宽表合并即可。

画像宽表存在两个问题？

①hive表查询速度较慢，因此可以将数据灌入clickhouse中作为“缓存”来高查询速度；

②有些标签与时间无关，日期分区导致数据冗余存储，可以将日期无关的标签单独放到另一张宽表中。

3.1.2画像BitMap

画像BitMap一般是以标签值为k，用户id映射到bit位的bit数组为v进行存储的，因为bitmap可以进行交集并集和差集操作，所以可以很方便进行多标签人群筛选。由于相同用户id会映射到同一个bit位，所以其也天生具备去重能力，其次通过用户id映射和bit位记录可以实现快速判存。

值得注意的是，由于画像BitMap是以标签值为k的，所以只有标签值可枚举且数量较小的标签才适合使用。

那么画像Bitmap具体怎么生成呢？

读取底层标签数据，基于标签的标签值进行聚合，得到各标签值下的用户id列表，然后标签值为k，用户id列表映射到bit数组上即可。

3.2.人群创建

3.2.1规则圈选

规则圈选一般就是前端指定条件，比如性别男常住省杭州的人群。对于画像宽表，可以基于where条件筛选查询得到用户id集合；对于画像BitMap可以将男的BitMap和杭州的BitMap做交集得到结果。得到的人群一份存在hive里备份和离线数据分析，一份存在oss里提供接口获取人群服务。

3.2.2导入人群

一般有文件导入，Hive导入和SQL导入。

文件导入一般是导入带有一列用户id的csv/txt文件，服务端解析遍历得到用户id集合，写入bitmap存到oss中，后续落盘到hive表中。

Hive导入和SQL导入本质都差不多，都是转为sql导入语句（只是前者是从hive表中读数据），最终生成的人群数据存在hive中，后续基于生成的hive将数据转为bitmap存在oss中对外提供获取人群服务。

3.2.3组合人群

组合人群本质是基于已有人群做交集、并集、差集运算。

前面也提到了，基于画像Bitmap实现组合人群操作很方便；对于画像宽表，交集用inner join，并集用crow_id in (人群1id、人群2id)配合distinct去重，差集用left join配合where筛选右表用户id为空。

3.2.4行为明细

离线计算出来的画像标签往往是一个代表性数据，其不够详细，忽略了一些明细信息，比如who、when、where、how和what五要素，用户a（who）在2025年2月9日10：01（when）点赞（how）了首页（when）的电影解说视频（what）。只有把这些明细数据都记录了（存在clickhouse中提高查询速度），才能实现更详细的条件人群筛选，例如在2025年2月9日10：00到2025年2月9日11：00点赞了某个视频的用户，基于明细数据表，where加上时间筛选和视频id筛选即可得到人群结果。

那么明细数据表具体怎么生成呢？

两种方式：找到hive中的离线行为明细数据然后整理写入clickhouse；或者通过kafka+flink实时消费行为数据写入clickhouse中。

3.2.5人群Lookalike

给定种子人群，找到相似的用户群体。

常用的三种方式：

①基于用户向量：挖掘用户特征向量，基于欧氏距离/曼哈顿距离等等计算种子人群中每个用户的topN相似用户组成目标人群；

②基于种子人群分布特征：比如种子人群年龄基本在20~25岁，兴趣爱好动漫偏多，那么就可以把非种子任务中所有年龄在20~25岁，兴趣爱好为动漫的圈选出来作为目标人群；

③基于分类算法：训练二分类模型，将种子人群当作正样本，非种子人群当作负样本。最后基于训练好的模型来筛选目标人群。

3.2.6挖掘人群

实现思路与人群Lookalike类似，不同的是挖掘的结果可以包含种子人群中的用户，更像一种基于种子人群的扩量。

3.2.7LBS人群

即基于地理位置圈选人群。

①首先要记录用户每日上报的经纬度以及时间戳；

②如果要圈选某个四边形区域的人群，得到四边形四个点的经纬度然后使用clickhouse中支持geo函数pointlnPolygon筛选处在该区域的人群。

3.3.人群判存

判定用户是否在指定的人群中。

:基于redis：

①人群id+用户id拼接作为k，v设为1，如果查不到就代表不存在，缺点是key数量的量级是所有人群下的用户总和量级。

②用户id为k，v用哈希结构存储其所在人群id，缺点是可能存在热key问题。

基于BitMap：

通过人群bitmap，用户id映射的bit位是否为1即可判断。

基于规则：

不同于前两者，基于现有人群判存，其主要依赖标签查询服务实现，比如查询用户的常住省和性别标签值，发现符合要求，那么判存就为真。

4.画像分析

画像分析主要分为人群画像分析、人群即席分析、行为明细分析和单用户分析

4.1.人群画像分析

主要是基于人群结果表进行分析，以此挖掘人群的特点

其又分为：人群分布分析、人群指标分析、人群下钻分析、人群交叉分析和人群对比分析。

4.1.1人群分布分析

计算人群在画像标签上的分布占比数据，适用于标签值可枚举且数量有限的标签。一般先人群结果表和画像宽表inner join然后基于标签值分组聚合数量得到分布。

4.1.2人群指标分析

计算人群在某些指标类标签上的数值以及变化趋势。适用于可以量化进行聚合运算的标签。一般先人群结果表和画像宽表inner join然后对相应标签列做聚合运算，常见的比如求平均在线时长来表征人群活跃度，用avg(online_time)即可。

4.1.3人群下钻分析

本质是在指定标签值的基础上进一步深入分析，例如对于人群A，在男性用户的基础上对常住省进行下钻分析，具体为分析男性用户在不同省的数量。其实现本质就是在画像宽表中加上性别男的筛选条件后再与人群结果表inner join以省分组聚合求数量。

4.1.4人群交叉分析

可以选择多个画像指标维度，通过交叉计算不同标签值组合下的人群指标数据。更偏向于多维度的全面分析。例如实现性别+常住省的交叉分析并计算平均在线时长，将人群结果表与画像宽表inner join后基于性别、常住省进行group by分组（这里分组涉及两个字段），最后聚合运算求平均值，即avg(online_time)

4.1.5人群对比分析

比较两个人群画像分析结果，找出人群间差异。一般用TGI指数表示人群画像分布差距，即目标人群中具有某个特征的人群比例x100/对比人群中具有该特征的人群比例，越接近100则差异越小。

4.2.人群即席分析

和人群画像分析的内容差不多，不同的是，讲究实时性，其分析配置（一般是标签规则筛选）不存储在服务端，直接将配置转为sql语句去clickhouse中的画像宽表执行并返回结果。

4.3.行为明细分析

行为明细分析设计四种类型的分析模型，即明细统计、用户分析、流程转化和价值分析。

4.3.1明细统计

明细统计包含页面分析和事件分析。

4.3.1.1页面分析

页面分析主要针对各功能页面及页面元素（比如页面某按钮使用数据）进行统计分析。例如统计某页的uv，基于page和日期筛选，然后依赖distinct对用户id去重，并使用count计数。

4.3.1.2事件分析

事件分析就是筛选出满足条件的事件并统计其指标数据趋势、与事件相关主体的属性分布等。例如统计不同渠道下的新增用户数，按渠道分组count聚合计算即可。

4.3.2用户分析

用户分析包含留存分析和指标分布分析。

4.3.2.1留存分析

结合用户的初始行为和留存行为进行分析，本质就是计算指定时间范围内发生了初始行为的用户最终产生留存行为的占比。一般分为三步：

①筛选满足条件且发生了初始行为的用户；

②按指定时间范围统计该批用户在后续发生留存行为的用户数量；

③根据不同的留存跨度计算出1、3、7日留存率。

4.3.2.2指标分布分析

统计某个事件指标在不同取值范围下的用户量分布情况，比如直播电商卖货下，不同消费金额下的用户数量分布统计，以此来判断该直播的观众购买力分布。

4.3.3流程转化

流程转化包含漏斗分析和行为跨度分析

4.3.3.1漏斗分析

针对多步骤的流程并统计各步骤间的转化和流失数据。比如电商购买商品有浏览、点击、加购、立即支付、支付完成这几个步骤：

①首先需要明确一个完整流程的时间窗口，例如1个小时，那么第一个行为发生后一个小时内的其他行为才会被统计进去；

②基于用户行为序列数据，找到所有发生了流程中第一个行为的用户；

③然后分析该批用户在1个小时内的所有行为序列数据，找到满足流程中各步骤先后顺序的行为模式；

④再统计完成第一个行为的用户完成后续各步骤的用户数量。

4.3.3.2行为跨度分析

统计先后发生的两个行为之间的时间间隔。换句话说就是指定初始行为、目标行为和分析的时间范围，得到每一天发生初始行为的用户在后续发生目标行为的平均时间跨度。用得比较多的场景就是新用户从注册到第一次发生指定行为的时间跨度。当然如果初始行为与目标行为相同，就演变为了用户对某个操作的频繁程度。实现流程一般如下：

①首先找出所有用户的行为序列并筛选出包含指定初始行为和目标行为的用户行为序列；

②其次计算所有满足条件的用户行为序列中两个行为发生的时间间隔；

③最后汇总数据聚合计算，例如求平均值。