用户画像:方法论与工程化解决方案

经过同事座位时,发现他桌上有本《用户画像:方法论与工程化解决方案》,拿起来翻了下,还挺新,2020年2月第一次版印。

顺手牵羊拿来研究研究。

从前言看,这本书的描述是一本从技术、产品和运营3个角度讲解如何从0到1借助数据仓库构建用户画像系统的一套解决方案。

首先我们要明确,什么是用户画像?

即用户信息标签化,通过收集用户各个维度的数据挖掘分析,从而抽象出一个用户的信息全貌。

用户画像有什么用?

帮助大数据“走出”数据仓库,针对用户进行个性化推荐、精准营销、个性化服务等多样化服务,为企业的精细化运营提供足够的数据基础,奠定了大数据时代的基石。

怎么构建?

这本书概述了一套完整的用户画像方案大致考虑8个模块的建设:

    1.框架大方向的规划

    2.数据指标体系

    3.标签数据存储

    4.标签数据开发

    5.开发性能调优

    6.作业流程调度

    7.用户画像产品化

    8.用户画像应用

本文也将通过一一阐述这8个模块来粗浅地讨论一下用户画像的搭建过程。

                                             框架大方向的规划

明确具体的方向,现存数据仓库的架构,开发流程,具体的产出这些大方向的把握,明白搭建用户画像系统需要覆盖的模块,形成一个整体化的思想,之后就可以进入数据指标体系环节。

数据来源:所有与用户相关的数据。

这些数据是从不同维度描述用户的,用户属性维度:姓名、性别、年龄等;用户行为维度:用户访问行为、购买行为等。

                                                  数据标签体系

作为建立用户画像的关键环节,在标签开发前要进行的工作,需要结合业务情况设定相关的指标。

如果从不同标签维度来看,可以将其分为用户属性维度、用户行为维度、用户消费维度、风险控制维度、社交属性维度等等。

用户属性维度的一些数据包含用户的基本信息,如年龄、性别、地址等;

用户行为维度刻画一些用户的行为特征,如用户订单相关行为,访问行为、活跃时间段、点击偏好等;

用户消费维度的标签如用户浏览商品的品类、某一时间段内购买的品类、收藏品类等;

风险控制维度构建的相关指标体系主要是为了监控平台的不良用户,如薅羊毛、恶意刷单、借贷欺诈等,减少这类用户给平台带来的损失和风险。相关的指标如账号风险、设备风险、借贷风险等;

社交属性维度通过了解用户的社交关系、社交偏好、社交活跃度等指标可以更好的为用户提供个性化服务。

当然,标签的划分也不止这些方式,从不同的的应用场景出发,选择对应的标签体系,有时候还需要规范化各个标签的命名体系,为每一个标签打上唯一的id。

                                          标签数据存储

建立用户画像首先需要建立数据仓库,用于存储用户标签数据。

数据存储的技术选型也是重要的一项内容,这个也要根据不同应用场景来选择相应的存储方式,这里有几个比较常用的数据库:Hive、MySQL 、HBase、Elasticsearch。

应用Hive作为数据仓库:

Hive作为基于hadoop的数据仓库工具,依赖于HDFS存储数据,提供的SQL语言可以查询存储在HDFS中的数据。适用于大数据量的批处理作业。

                                                                        (数据抽取到数据仓库流程)

应用mysql存储:

作为关系型数据库,在用户画像中可用于元数据管理、监控预警数据、结果集存储等。对于量级较少的数据,Mysql可以拥有更快的读写速度。

应用HBase存储:

高性能、列存储、可伸缩、实时读写的分布式存储系统,同样运行在HDFS之上,HBase与Hive不同的是它能够在数据库上实时运行,适合进行大数据的实时查询,用于线上实时应用的场景。

Elasticsearch存储:

一个开源的分布式全文检索引擎,可以近乎实时地存储、检索数据,可扩展性好,支持扩展上百台服务器,处理PB级别数据。是面向文档型数据库,通过索引(index)、类型(type)、文档(document)、字段来定位查找内容。

Hive存储数据相关标签表、人群计算表的表结构设计以及ID-Mapping的一种实现方式;Mysql存储标签元数据、监控数据以及结果集数据;Hbase存储线上接口实时调用的数据;Elasticsearch存储标签用于计算人权计算和人群多维透视分析。

                                           标签数据开发

用户画像体系搭建中最主要的环节,主要包括离线标签开发、实时类标签开发、用户特征库开发、人群计算、打通数据服务层等内容。

离线标签开发主要围绕统计类标签开发、规则类标签开发和挖掘类标签开发展开。

  • 统计类标签开发:一般指统计用户相关数值、客观描述用户。如用户累计购买金额、累计购买次数。

  • 规则类标签开发:一般根据业务运营上的需要,在业务层面制定规则的标签,会带有一些人为主观判断的因素。如用户价值类标签、用户活跃度标签等。RFM模型可用于衡量用户价值类标签开发,由3个基础指标组成:(1)最近一次消费(Recency) (2)消费频率(frequency)(3)消费金额(money)。用户活跃度标签、

  • 挖掘类标签开发:需要应用算法挖掘用户相关特征。进行数据调研,找用户行为特征进行特征工程开发、算法参数调优以及上线工程化调度等多个开发环节,一般开发周期较长。

流式计算标签开发

运用spark streaming开发相关的实时数据,Kafka作为分布式消息中间件。Spark streaming可以通过receiver和direct两种模式来集成kafka.

                                                                        (Spark streaming计算框架)

实时类标签处理流程包括大致如下:

1.读取数据源

2.解析数据,解析kafka中的数据

3.将解析后的数据存储到指定位置

4.存储消费的offset,direct模式下需要保存消费到的位置。

用户特征库开发

开发用户的特征库可以进一步从多个维度丰富用户特征,挖掘用户的相关行为。简而言之,用户特征库就是对用户每一次的不同行为(如浏览、收藏、搜索、购买等)及该行为对应的标签进行详细的记录。

相比于开发用户标签,用户特征库可以对数据进行汇总统计,从多个维度分析特征。为个性化推荐、精准营销等提供中间层信息,也可以削减不同算法在特征构建时的冗余加工。

标签权重计算

用户标签权重 = 行为类型权重 × 时间衰减 × 用户行为次数 × TF-IDF计算标签权重

用户在平台上的不同行为具体到用户标签层面有着不同的行为权重,用户画像建模人员需要和运营人员结合业务场景给不同类型定权重,具有一定的主观性(基本思想是复杂程度越高的行为价值越大)。

标签相似度计算

好的标签可以为我们后期分析数据提供很大的便利,标签之间的相关关系进行聚类也是画像开发中要考虑的问题。基于用户特征库我们要进行标签权重计算。

常用的标签相似度计算算法有编辑距离(Edit Distance)算法,又称Levenshtein距离。编辑距离越小,两个字符串的相似度越大。余弦相似度算法可计算文本的相似度、CF算法计算商品之间的相似度等。

数据服务层开发

画像开发完后,还需要打通标签数据和各业务之间的通路,这样才能帮助数据走出数据仓库,要打通的服务层包括离线服务层和在线服务层。离线服务层将ETL后的用户群数据推送到对应业务系统,在线服务层以API的方式提供接口服务,可支持个性化推荐、营销推送等场景。

                                            开发性能调优

列举一些在数据开发过程中可能遇到的需要调优场景并给出解决方案。

数据倾斜调优

当进行分布式计算时,由于某些节点需要计算的数据较多,导致其他节点的reduce阶段任务执行完成时,该节点没完成,致使其他节点等待该节点的执行情况。

  • 方案一:过滤掉倾斜数据

    当少量key重复次数特别多,如果这种key不是业务需要的key,可以直接过滤掉。

  • 方案二:引入随机数

    加入随机数,将原来的一组key强制拆分为多组进行聚合。

缓存中间数据

数据持久化缓存是spark的一个重要能力,在画像标签每天ETL的时候,对于一些中间计算结果可以不落磁盘,只需把数据缓存在内存中。

而使用hive进行ETL时需要将一些中间计算结果落在临时表中,使用完临时表后再将其删除。

开发中间表

在用户画像开发过程中,初期开发标签后,通过对标签加工作业的血缘图整理,可以找到使用相同数据源的标签,对这部分标签,可以通过加工中间表缩减每日画像调度作业时间。

                                        作业流程调度

开发完每一个画像标签对应的脚本后,需要将该脚本提上调度流,每天定时作业刷新昨天产生的新标签。

在刚开始的时候,会使用crontab命令调度开发任务定时执行,如果调度任务规模增大就需要使用一些工具来进行辅助,可有效提高集群工作效率,当调度出现异常时,也可快速定位出现问题的位置。

Crontab命令调度

画像开发初期,为了数据尽快上线迭代时使用。Shell脚本、python脚本和crontab调度命令即可完成简单的ETL任务。

Airflow工作平台

一个工作流管理平台,调度依赖于crontab命令,可以查看任务执行状况。主要的功能模块包括:

DAG模块:可以查看当前DAG的任务列表,包括当前有哪些DAG调度任务、哪些运行成功、哪些失败、哪些正在运行中。

Tree View模块:可查看当前DAG每个task任务的调度状态,便于快速定位到执行失败的任务,重新调启执行。

Graph View模块:可查看当前DAG中各task任务之间的依赖关系,以及各任务的执行状态。

Gantt模块:可查看DAG调度的甘特图。

Code模块:可查看当前DAG任务的执行脚本。

一个正常运行的Airflow系统一般由几个服务构成:

1.webserver

2.worker(celery模式)

3.scheduler

4.flower(celery模式)

数据监控预警

  • 标签监控预警

    用于监控每个标签当日的ETL是否产生问题,当数据量超出正常范围时,发出报警邮件。

  • 服务层数据监控预警

    数据从数据仓库走出提供到服务层时,该过程中是否正常进行,一般通过对比数据仓库中个业务线的数量和各业务系统中对应的业务线的数量进行监控。

    数据稳定性有了保障,提供到服务层的数据的质量才有保障,所以在日常的数据开发中,运用调度工具维护调度流的稳定是相对重要的工作。

                                       用户画像产品化

开发画像后的标签数据,我们还要将它产品化,才能更便于业务方使用。画像产品按常见的功能来看,主要包括标签视图与即时查询,用户分群,用户人群透视分析,对用户从事件、留存、漏斗、分布等多维度展开的深入交互式分析等模块。

下面介绍的是一些用户画像产品化主要涵盖的功能模块及应用场景。

标签视图与标签查询

主要面向业务人员,在此板块中,层级化地展示了目前已经上线使用的全部用户标签。用户可以层级化地通过点击标签,查看每个标签的详细介绍。

元数据管理

标签编辑管理功能,主要面向数据开发人员。在开发完标签后,需要将标签录入元数据进行管理。

用户分群功能

主要面向业务人员使用,在应用标签时,可能不仅仅只查看某一个标签对应人权的情况,更多地可能需要组合多个标签来满足其在业务上定对人群的定义。

人群分析功能

数据分析、业务、产品经理皆可使用。提供现有标签圈定用户群的功能,可以从多个维度分析该批用户群的特征,为精细化运营提供支持。

                                          用户画像应用

用户画像产品化后可成为触达用户的有效工具,接下来描述用户画像的应用场景。

经营分析

销量分析:快速定位爆款品类,进一步分析各个维度上的特征。

用户分析:借助画像产品可了解各维度特征的用户量分布。

渠道分析:根据增长黑客理论模型(AARRR),将产品的营收路径拆分为激活——注册——留存——下单(营收)——传播。激活主要是流量运营在负责,用户运营会贯穿接下来的流程;内容运营主要负责生产优质内容来提高用户的黏度,从而提高留存;主线运营主要负责主营业务的产品路径,优化转化节点,提高转化率。

漏斗分析:用于分析产品流程或关键节点的转化效果,可以直观的追踪产品的整体流程、追踪业务的转化路径、追踪不同生命周期阶段下的用户群体表现。

客服话术:客服人员可以根据来点用户的画像针对性地提出解决办法,以及对于高价值用户提供专项服务等。

人群特征分析

做人群分析时一定要去做对比,单纯看单个人权分布没有太多含金量。

借助画像产品形态,可以分析圈定的用户群在各个维度上的特征情况。

精准营销

短信/邮件营销:当画像做成产品后,业务人员可以根据业务规则组合标签圈定相应人群,将该批人群推送到对应地业务系统中进行运营。

效果分析,可分为流量提升导向和GMV提升导向两种情况,ROI地转化。

对目标人群精准消息推送带来流量提升,对目标人群进行短信营销带来营收增长等等。

个性化推荐与服务

在用户画像的开发过程中不仅会开发用户标签维度的数据,同时也会开发用户行为特征库、商品特征库、商家特征库等相关数据。为算法开发人员做用户相关商品、内容的个性化推荐提供底层数据支持。

其他

至此,整套用户画像方案粗略的过了一遍,具体的流程细节书中也举了相应的例子,总体来说还是通俗易懂的。通过阅读本书,我也获得了新的知识,感谢作者!向那些不舍昼夜奔腾向前的日子致敬!

猜你喜欢

转载自blog.csdn.net/qq_41127332/article/details/107182678