用户画像

用户画像,即用户信息标签化,是大数据精细化运营和精准营销服务的基础。

在大数据的时代下,用户的一切行为是可追溯和分析的。

用户画像是通过分析用户的基础信息、特征偏好、社会属性等各维度的数据,刻画出用户的信息全貌,从中挖掘用户价值。

它可以帮助数据“起死回生”,提供个性化推荐、精准营销、个性化服务。

用户画像

画像基础

1.1 标签类型

用户画像建模其实就是对用户“打标签”,一般分为三类:

● 统计类标签:最基础常见的标签,从用户注册数据、用户访问数据中统计得出。

● 规则类标签:基于用户行为及规则产生,通常由对业务更为熟悉的运营人员和数据人员共同协商确定。

● 机器学习挖掘类标签:通过机器学习挖掘产生,根据某些用户行为或熟悉进行预测判断。

例如,根据一个用户购买化妆品护肤品的次数权重更高,得出该用户的性别是女性。

标签

ps: 这里的统计类可以细化为基础属性+统计类。比如性别这种是不会变化的

1.2 数据结构

画像系统的基础设施包括Spark、Hive、HBase、Airflow、Redis、Elasticsearch。

下图是《用户画像》中的数据仓库架构。

数仓架构

(1)数据仓库ETL加工流程是对每日的业务数据、日志数据、埋点数据等数据经过ETL过程,加工到对应的原始数据层(ODS)、数据仓库(DW)、数据集市层(DM)中。

(2)用户画像不是产生数据的源头,是经过ODS层、DW层、DM层中的数据与用户相关数据的二次建模加工得到的数据。

在ETL过程将用户标签写入Hive,根据不同数据对应不同数据库的应用场景,再将数据同步到MySQL、HBase、Elasticsearch等数据库中。

Hive:存储用户标签、用户人群及用户特征库的计算结果

MySQL:存储标签元数据,监控相关数据,导出到业务系统的数据

HBase:存储线上实时数据

Elasticsearch:支持海量数据的实时查询分析

(3)用户标签在Hive中加工完成后,部分标签通过Sqoop同步到MySQL数据库,提供用于BI报表展示的数据、多为透视分析数据、圈人服务数据;另一部分标签同步到HBase数据库用于产品的线上个性化推荐。

1.3 用户画像模块

搭建用户画像方案整体考虑以下8个模块

用户画像模块

● 用户画像基础

了解和明确用户画像包含的模块,设计数据仓库架构、开发流程、表结构,及ETL的设计。主要就是明确大方向的规划。

● 数据指标体系

建立数据指标体系,根据业务线梳理,包括用户属性、用户行为、用户消费、风险控制等维度的指标体系。

● 标签数据存储

设计好数据指标体系后,考虑不同应用场景使用哪种存储方式。

● 标签数据开发

重点模块。标签数据开发包含统计类、规则雷、挖掘类、流式计算类标签的开发,以及人群计算功能的开发。

重点内容:数据调研、和业务方确认数据口径、标签开发上线。打通画像数据和各业务系统之间的路,提供接口服务

● 开发性能调优

标签数据开发上线后,为了缩短调度时间、保证数据稳定性,需要对标签脚本、调度脚本进行迭代重构、调优。梳理现有标签开发、调度、校验告警、同步到服务层等相关脚本、明确可以优化的地方,迭代优化。

重点内容:减少ETL调度时间,降低调度时的资源消耗。

● 作业流程调度

标签加工、人群计算、同步数据和业务系统、数据监控预警脚本开发完成后,需要调度工具把整套流程调度起来。

重点内容:满足定式调度、监控预警、失败重试,各调度任务之家的复杂依赖关系。

● 用户画像产品化

产品化的模块包括包括标签视图、用户标签查询、用户分群、透视分析等。

重点内容:满足业务方对用户精准营销的需求。

● 用户画像应用

应用场景包括用户特征分析、短信邮件、站内信、Push消息的精准推送,客户针对不同用户的话术、针对高价值用户的极速退款等高级服务应用等。

重点内容:帮助业务方理解和应用用户画像数据,提高用户活跃度和GMV。

1.4 开发上线流程

开发上线流程

数据指标体系

数据指标体系是建立用户画像的基础,也是在进入开发前的关键环节,是需要结合业务场景制定的数据指标。

建立用户画像一般从2个维度:

  1. 用户维度(userid):基于当前用户账号相关数据推送内容。

  2. 设备维度(cookie):当用户没有登陆账户而访问设备时,基于用户在设备的行为对该设备推送相关内容。

用户标签从标签类型可分为:统计类、规则类、机器学习挖掘类。

从建立的维度来看,可分为:用户属性类、用户行为类、用户消费类、风险控制类。

至于标签如何分类,没有严格的规定,符合业务场景和使用者使用即可。

标签维度

1、用户属性类

一般是与用户自带属性相关,例如性别、年龄、地域、注册日期、会员类型等。

对于相同的一级标签诶些,需要判断多个标签之间的关系是互斥还是非互斥关系。

例如,在判断性别时,不能既是男、又是女,这就是互斥关系。

对于传统企业来说,更多的是从用户属性类维度去丰富指标体系。而对于互联网企业来说,其拥有海量的用户访问日志数据,所以更容易从用户行为类数据分析用户的行为特性。

2、用户行为类

常见用户行为维度指标包括订单相关行为、下单/访问相关行为、用户近30天行为指标、高频活跃时间段、用户购买类、点击偏好、营销敏感度等相关行为。

3、用户消费类

用户消费维度指标体系建设从用户搜索、流量、加购、收藏、下单商品对应的品类入手。品类越精细,给用户推荐的准确性越高。

例如品类细分到:手机-手机配件-数据线。

4、风险控制类

风控维度主要是预防薅羊毛、恶意刷单、借贷欺诈行为的用户,未防止这类用户给平台带来损失,所以专门设置风控类维度。

结合业务场景,可从账号风险、设备风险、借贷风险等维度考虑指标体系。

5、社交属性维度

该维度主要是了解用户的社交范围,如家庭成员、社交偏好、社交活跃度等等。以此来提供个性化推荐和精准营销。

例如在朋友圈收到的广告,也是基于用户的社交属性进行的推送。

下面是整理的上述5个维度的画像主题:

标签维度

其他常见标签维度

用户标签体系不限于划分维度,通过应用场景对标签进行归类也是常用手段。

从业务场景出发,可分为:用户属性、用户行为、营销场景、地域细分、偏好细分、用户分层等维度。

每个维度再分成二级标签、三级标签等。

其他常见标签维度

标签命名方式

在确定好标签后,需要对标签进行命名,以便于管理。

对一个标签,可从多个角度来确定唯一名称。

标签命名方式

1、标签主题

标明属于哪个类型的标签,如人口属性(ATTRITUBE),行为属性(ACTION),用户消费(CONSUME),风险控制(RISKMANAGE)等。

2、用户维度

表明该标签来源,是用户唯一标识(userid),还是用户设备(cookie),一般用U和C区分。

3、标签类型

标签分类,统计型(01)、规则型(02)、算法型(03)。

4、一级归类

在每个标签大类下面,进一步细分的标签类型。

参照上面的命名方式,举例用户的性别标签:

命名规则:标签主题_用户维度_标签类型_一级归类

【男】:ATTRITUBE_U_01_001

【女】:ATTRITUBE_U_01_002

ps: 实际应该全部显示文本,只有背后实现是字母数字。

元数据管理

标签完成梳理和命名后,需要维护一张码表用例记录标签id名称、标签含义及标签口径等主要信息,方便元数据的维护与管理。

标签数据存储

用户画像的数据存储的技术选型有多种,不同存储方式适用于不同场景。主要有Hive、MySQL、HBase、Elasticsearch。

Hive数据仓库

Hive是基于Hadoop的一个数据仓库工具,依赖于HDFS存储数据,可以将结构化的数据文件映射为一张数据库表,提供SQL语言查询存储在HDFS中的数据。

一般使用Hive作为数据仓库用来存储标签、用户特征库等相关数据。

主要用来做离线数据分析,比直接用MapReduce开发效率更高。

数据仓库

在数仓建模过程中,主要是设计事实表和维度表的建模开发。

在画像系统中主要使用Hive作为数据仓库,开发相应的事实表和维度表来存储标签、人群、应用到服务层的相关数据。

a. 事实表

事务事实表:用于描述业务过程,按业务过程的单一或多业务过程可进一步分为单事务事实表和多事务事实表。

周期快照事实表:在一个确定的时间段内对业务状态进行度量。例如:查看一个用户近1年的付款金额、近1年购物次数、近30天登录天数等。

累计快照事实表:对不同的事件之间的时间间隔进行度量。例如:用户从购买到支付的时长、从下单到订单完结的时长。一般用于统计时间周期明显的业务过程。

b. 维度表

维度表是对事实属性的各个维度的描述。

例如,商标维度包括:价格、折扣、品牌、原厂家、型号等方面的信息。维度表的开发中,经常遇到维度缓慢变化的情况,对于缓慢变化维,一般采用:

① 重写维度值,对历史数据进行覆盖;

② 保留多条数据,通过插入维度列字段区分;

③ 开发日期分区表,每日分区数据积累当日维度的属性;

④ 开发拉链表,按时间变化进行全量存储等方式处理。

ID-MAP

开发用户标签的时候,需要把用户不同来源的身份通过数据手段识别为同一主体,即ID-Mapping。

用户的属性、行为相关数据分散在不同来源中,通过ID-Mapping能够把不同场景下的数据联系到一起,消除数据孤岛。

即通过ID-Mapping打通userid和cookieid的对应关系。

串联同一用户在不同平台的行为

在设计ID-Mapping表时,由于一个用户可在多个设备登录,一个设备也可以被多个用户登录,所以考虑用缓慢变化维表来记录不同时间点的状态变化。

① 从埋点表和访问日志表获取到cookieid和userid同时出现的访问记录;

② 将获取到的userid和cookieid插入cookieid-userid关系表;

③ 创建ID-Map拉链表,将每天新增到cookie表的数据与拉链表历史数据做笔记,若有变化或新增,则更新拉链表;

④ 创建完成后,每天ETL调度将数据更新到ID-Mapping拉链表中。

⑤ 对于拉链表,可查看某日的快照数据,以查看某个用户在某天关联到的设备id。

对于实际开发中,还需要考虑用户在不同平台间(如Web端和App端)的打通情况。

MySQL

MySQL是关系型数据库,在用户画像系统中可用于元数据管理、监控预警数据、结果集存储等应用中。

1、元数据管理

Hive适用于大数据量的批处理工作。而小量级的数据会存储在MySQL中,因为MySQL有更快的读写速度。

平台标签视图中的标签元数据可存储在MySQL关系数据库中,便于便签编辑、查询、管理。

标签管理页面原型

2、监控预警数据

MySQL还可以用于存储每日对ETL结果的监控信息。

从标签计算数据的监控,到服务层同步数据的监控。

① 标签计算数据监控

监控每天标签ETL的数据量,若有异常则发送警告通知,同时暂停后续任务。

② 服务层同步数据监控

即将标签相关数据从Hive数仓像服务层同步数据的监控。

服务层一般采用HBase、Elasticsearchzuo作为数据库存储标签数据供线上调用。

当相关数据在Hive中的数量不等于同步到服务层后的数量,则会触发警告。

结果集存储

在打通画像业务与业务系统时,考虑将hive中的用户标签同步到各个业务系统中,此时MySQL可以用户存储结果集。

Sqoop是一个用来将Hadoop和关系型数据库中的数据相关迁移的工具,它可以将关系型数据库中的数据导入Hadoop的HDFS中,也可将HDFS中的数据导入关系型数据库中。

HBase

HBase是存储线上接口实时调用的数据,是高性能、列存储、可伸缩、实时读写的分布式存储系统,运行在HDFS上。

Hive是跑MapReduce任务离线查询,适合用来对一段时间内的数据进行分析查询,例如,用来计算趋势或者网站的日志。

HBase 则适合用来进行大数据的实时查询,例如 Facebook 用 HBase 进行消息和实时的分析。

画像系统中每天在Hive里跑出的结果集数据可同步到HBase数据库,用于线上实时应用的场景。

HBase

1、应用场景

某渠道运营人员为促进未注册的新安装用户注册、下单,计划通过App首页弹窗发放红包或优惠券的方式进行引导注册。

① 通过组合用户标签(如【未注册用户】【按照据今天数小于7天】)筛选出对应用户群,然后将对于人群推送到“广告系统”,这样每天画像系统的ETL调度完成后对应的人群数据会推送到HBase数据库进行存储。

② 当满足条件的新用户来访App时,由在线接口读取HBase数据库,查询到该用户时就会为其推送该弹窗。

Elasticsearch

Elasticsearch存储标签用于人群计算和人群多维透视分析,是一个开源的分布式全文检索引擎,开源近乎实时地存储、检索数据。

而且扩展性很好,可以扩展到上百台服务器,处理PB级别的数据。

对于用户标签查询、用户分群计算、用户群多维透视分析这类时间响应要求极高的场景适用。

Elasticsearch 是面向文档型数据库,一条数据在这里就是一个文档,用json作为文档格式。

Elasticsearch

1、应用场景

① 在每天的ETL调度中,将Hive计算的标签数据导入Elasticsearch中。

② 在标签调度完成且通过校验后(标签监控预警完成),将标签数据同步到Elasticsearch中。

应用场景

③ 在与elasticsearch数据同步完成并通过校验后,向在MySQL维护的状态表中插入一条状态记录,表示当日数据可用,线上计算用户人群的接口则读取最近的数据。

④ 如果当天因为调度延迟或其他原因没有及时将当日数据导入Elasticsearch,接口也能读取最近一天对于的数据。如当日数据产出正常时,state字段=0,异常=1,。图1月20日异常时,线上接口扫描该状态记录后不读取1月20日的数据,而是读取前一天的数据。

③ 为避免从Hive到Elasticsearch中灌入数据时发生数据缺失,在像MySQL状态表更新状态位前需要校验elasticsearch与Hive中的数据是否一致。

④ Hive中的用户标签灌入Elasticsearch中后,业务人员在画像产品端计算人群或分析人群时,通过RESTful API访问Elasticsearch进行计算。

标签数据开发

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

标签开发主要涵盖模块

ps: 这里某种程度而言还是一个规则引擎

统计类标签开发

统计类标签是指用户年龄、性别、购买金额、累计购买次数、近x日登陆次数等描述用户状态的标签。

▷ 案例:近30日购买行为标签

① 拆解二级标签。近30日购买行为拆解为:付款订单量(ACTION_U_01_001)、总付款金额(ACTION_U_01_002)、加入购物车次数(ACTION_U_01_003)

② 将需要计算的标签从目标表中抽出来(ACTION_U_01_001、ACTION_U_01_002、ACTION_U_01_003)

③ 增量获取用户最新状态,做全连接关联。即通过全连接(full outer join)方式,当有最新状态时获取最细状态,否则保留原来的状态标签;

④ 任务执行完后,将数据插入Hive数据表中;

规则类标签开发

一般是根据业务场景,在 业务层面上指定的规则标签。这类标签受主观判断因素的影响,在开发前需要做数据调研,结合运营业务规则开发。

除了写脚本开发标签外,还可自动打标签。比如用户触发的行为中,有超过80%的记录是3C商品,那么自动打上“数码达人”的标签。

▷ 案例:用户价值类标签

RFM模型是衡量用户价值的重要工具,包含3个指标,8类人群:

(1)Recency:最近一次消费。指上一次购买的时候。

(2)Frequency:消费频率。消费频率是顾客在限定的期间内所购买的次数。

(3)Money:消费金额。消费金额是所有数据库报告的支柱,也可以验证“帕雷托法则”(Pareto’s Law)——公司80%的收入来自20%的顾客。

RFM 模型

RFM分层模型

在开发对应标签前需要进行数据调研。

结合业务场景对3个维度的指标在时间定义或数值上进行确定和划分。

① 得到用户最近一次交易时间的分布。例如按照二八比例,将最近一次交易时间距今<90天的,定义为“近”,>90天的定义为“远”

② 得到用户近一年交易订单量分布。将历史订单<=3单的的划分为“低频”,>3单的划分为“高频”

③ 得到将一年交易额分布。将交易金额<300的,定义为“低额”;>300的,定义为“高频”

④ 根据以上3个维度,进行交叉分析(R≤90=“近”,R>90=“远”;F≤3=“低频次”,F>3=“高频次”;M≤300=“低额”,M>300=”高额”),划分为以下8类人群

频率

⑤ 从用户消费订单表(dw.user_consume_order_info)里面读取用户最近一次消费距今天数、累计消费次数、累计消费金额这3个维度的数据,并注册视图user_rfm

⑥ 按照最近一次购买距今天90天、购买次数3次、消费500元来对用户3个维度进行高低划分。划分后的结果注册到视图user_rfm中

⑦ 将最终结果划分到8类人群中去,再将结果插入用户标签表中。

⑧ 执行完任务后查询得到结果

三、挖掘类标签开发

挖掘类标签即算法类标签,需要用算法挖掘用户相关特征。

ps: 这里更加倾向于 NLP 相关的处理。

一般用户相关的挖掘标签可包括根据购买商品预测用户男女性别、预测用户点击下单、判断用户已流失或即将流失。

挖掘类标签开发环节包括:①用户行为特征工程开发、②算法调优、③上线工程化调度等环节,开发周期较长。

▷ 案例:对大量未打标签的文章、帖子等文本数据自动分类,自动打标签。

1、特征选取及开发

① 标注:对一批文章进行人工准确分类,作为训练样本;

② 训练:计算机从标注好的文档集中挖掘出能够有效分类的规则,生成分类器。模型中用到的算法和数据处理技术包括文本分词、TF-IDF算法、朴素贝叶斯分类算法;

③ 分类:将生成的分类器应用在待分类的文档集中,从而获得文档的分类结果。

2、文本分词处理

将连续的字序按照一定规范重新组合成次序列的过程,中文分词是讲一个个汉字序列切分重一个个独立的单词。

3、数据结构处理

为了便于后续生成词向量空间模型,这些分词后的文本信息需要转换成文本向量信息并对象化。

4、文本TF-IDF权重

该步骤中将上一步存储的结构化数据构建成一个TF-IDF词向量空间,空间中的词均来自该训练集,各个词的权重矩阵也都一并保存下来。

5、朴素贝叶斯分类

至此,文本分类打标签流程中各模块的数据处理方式就介绍完了,文件结构图如下:

四、流式计算标签开发

离线标签的开发,即批次ETL任务,一般为T+1日的数据。

流式计算标签主要是实时数据,比如实时订单分析,或者给首次登录App的新人用户弹窗推送、发放红包,实时分析用户场景并进行推送。

五、用户特征库开发

特征库是对用户每一次行为(浏览、首次、搜索、购买等)及该行为对应的标签(或商品类)进行详细的记录,以便挖掘用户喜好。

是为个性化推荐、精准营销、商业分析提供中间层数据。

▪ 用户标签:静态记录当前状态

▪ 用户特征库:多维度汇总。例如:一个用户经常浏览、购买奶粉等婴儿用品,则她可能是个妈妈;用户经常收藏、点赞搞笑视频,可用于挖掘用户偏好;用户经常搜索美妆美容类商品,可能用户是女性。

① 特征库规划

用户与商品相关的行为日志数据保护了用户对商品行为的明细。

根据应用需要,创建表dw.cookie_feature_event_append来构建用户特征。

构建用户特征表(dw.cookie_feature_event_append)

② 数据开发

数据开发过程中,主要从订单表、访问日志表、打点日志表中对用户当日的行为(加购、点击、浏览、点赞等)抽取数据,然后清洗加载到用户特征库对应表(dw.cookie_feature_event_append)

用户行为特征库开发逻辑

③ 其他特征库规划

除了用户特征库,还有围绕本公司的产品进行特征库的规划与开发。

六、标签权重计算

用户行为对应不同的权重,比如用户购买的权重肯定比加到购物车重,加入购物车的权重大于收藏,收藏大于浏览。

1、TF-IDF算法

TF-IDF是一种统计方法,用以评估一字词对于一个文件集或一个语料库中的其中一份文件的重要程度。字词的重要性随着它在文件中出现的次数成正比增加,但同时会随着它在语料库中出现的频率成反比下降。TF-IDF加权的各种形式常被搜索引擎应用,作为文件与用户查询之间相关程度的度量或评级。

2、时间衰减系数

在用户画像的应用中,用户的某些行为会随时间衰减,而某些行为不会随时间衰减。时间衰减是指随着时间的推移,用户的历史行为和当前行为的相关性不断减弱。

3、标签权重配置

用户标签的权重最终还是需要进一步结合标签所处的业务场景、距离当前时间、用户行为产生该标签的行为次数等因素,最终得到用户标签权重的综合打分公式:

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

七、标签相似度计算

标签相似度计算主要是对标签进行有效聚类,通过对用户身上的标签构建“同现矩阵”的方式对标签进行聚类。

例如最经典的“啤酒和尿布”的营销场景,就是一种相关性。即这里的同现是指标签同时出现,即一个用户被打上A标签的同时被打上B标签。

如果有很多用户同时被打上A、B标签,那么A、B标签之间可能潜在某种相关性。

八、标签组合计算

当业务方根据业务规则应用标签时,是需要组合多个标签来创建对应的用户群体的,此时需要应用到组合标签计算。

▷ 应用案例:用户A、B、C、D、E已经被打上了符合自己特征的标签,业务人员想给“高价值用户群组”分发消费券。

根据运营经验定义了“高价值用户群组”,其特征为:①女性;②25~35岁;③累计消费>5次;④累计消费>500元;⑤活跃度在中活跃以上的用户。

组合标签计算的任务就是根据业务人员筛选的规则,给出符合上述条件的用户群组。

1、从MySQL读取不同组合标签的计算规则;

2、将上述规则拼接成接口传入参数的查询命令,通过接口方式进行查询;

3、通过Elasticsearch查询符合这些条件的用户id,返回id作为rowkey去HBase中查询用户身上的标签。

九、数据服务层开发

数据的主要目的是应用到业务系统和营销场景中,需要打通标签数据和业务系统,通过产品化的方式将标签数据应用到业务系统。

数据服务层开发就包括了离线服务层和在线服务层。

离线服务层:将ETL后的用户群数据推送到对应业务系统。

在线服务层:以RESTful API方式提供接口服务,可支持个性化推荐、营销推送(站内广告系统的个性化弹窗、App的消息push和轮播广告、短信等)、在线特征库等场景。

几个典型的应用场景包括:

1)短信营销:可以基于用户画像的自定义圈人服务,进行重点用户的广告/消息消息推送/短信/邮件营销。

2)邮件营销:可以基于不同用户群体,进行个性化有效的会员营销,同时在服务上也可以基于已经打通的用户数据,提供会员差异化的客服/物流/活动等服务。

3)风控系统:可以根据用户级别,作为风控系统规则引擎或模型的输入。

4)数据分析:可以分析不同群体的行为特征,提供分析和决策。

5)BI数据:可以监控核心用户群体的变化,为上层决策提供数据基础支持。

十、GraphX图计算用户

Spark GraphX是分布式图计算框架,基于Spark平台提供了对图计算的简单且丰富的接口,以满足对分布式图处理的需求。

Spark GraphX由于底层是基于Spark来处理的,所以天然就是一个分布式的图处理系统。

在工程实践中,存在需要计算二度关系用户的场景,即用户与用户之间通过其共同的好友找到他们的二度关系熟人,这种对图的挖掘计算可借助Spark GraphX完成。

GraphX提供顶点(Vertex)、边(Edge)、三元组(Triple)三种视图,GraphX图计算也在这三种视图上完成。

顶点包括顶点id和顶点属性;边包括源顶点(srcid),目标顶点(dstid)和属性(property);三元组是对顶点和边的扩展,将顶点和边的属性保存为一个RDD[EdgeTriplet[VD,ED]]

GraphX 边属性

▷ 应用案例:多个用户(如下111、222、333)登录同一个手机上的某App(如下C),也存在同一个用户(111)在多个手机上(A、C)登录该App的情况,这里初步认为在同一个手机上登录的用户之间是熟人关系,基于这种熟人关系需要进一步挖掘用户的二度熟人。

用户登录手机关系分布图

个人收获

规则引擎在各个领域都是要被使用的,值得深入学习。

元数据管理控台

NLP 分析

精准营销

参考资料

用户画像1:用户画像基础

《用户画像:方法论与工程化解决方案》赵宏田 著