第1章 用户画像基础
1.1 用户画像是什么
1.1 用户画像是什么
用户画像，即用户信息标签化，通过收集用户的社会属性、消费习惯、偏好特征等各个维度的数据，进而对用户或者产品特征属性进行刻画，并对这些特征进行分析、统计，挖掘潜在价值信息，从而抽象出用户的信息全貌。
1.1.2 标签类型
用户画像建模其实就是对用户“打标签”，从对用户打标签的方式来看，一般分为3种类型（如图1-3所示）：
①统计类标签；②规则类标签；③机器学习挖掘类标签。
1.统计类标签
这类标签是最为基础也最为常见的标签类型，例如，对于某个用户来说，其性别、年龄、城市、星座、近7日活跃时长、近7日活跃天数、近7日活跃次数等字段可以从用户注册数据、用户访问、消费数据中统计得出。该类标签构成了用户画像的基础。
2.规则类标签
该类标签基于用户行为及确定的规则产生。例如，对平台上“消费活跃”用户这一口径的定义为“近30天交易次数≥2”。在实际开发画像的过程中，由于运营人员对业务更为熟悉，而数据人员对数据的结构、分布、特征更为熟悉，因此规则类标签的规则由运营人员和数据人员共同协商确定；
3.机器学习挖掘类标签
该类标签通过机器学习挖掘产生，用于对用户的某些属性或某些行为进行预测判断。例如，根据一个用户的行为习惯判断该用户是男性还是女性、根据一个用户的消费习惯判断其对某商品的偏好程度。该类标签需要通过算法挖掘产生。
1.2 数据架构
在整个工程化方案中，系统依赖的基础设施包括Spark、Hive、HBase、Airflow、MySQL、Redis、Elasticsearch。除去基础设施外，系统主体还包括SparkStreaming、ETL、产品端3个重要组成部分。图1-4所示是用户画像数仓架构图，下面对其进行详细介绍。
❑Hive：存储用户标签计算结果、用户人群计算结果、用户特征库计算结果。
❑MySQL：存储标签元数据，监控相关数据，导出到业务系统的数据。
❑HBase：存储线上接口实时调用类数据。
❑Elasticserch：支持海量数据的实时查询分析，用于存储用户人群计算、用户群透视分析所需的用户标签数据（由于用户人群计算、用户群透视分析的条件转化成的SQL语句多条件嵌套较为复杂，使用Impala执行也需花费大量时间）。
用户标签数据在Hive中加工完成后，部分标签通过Sqoop同步到MySQL数据库，提供用于BI报表展示的数据、多维透视分析数据、圈人服务数据；另一部分标签同步到HBase数据库用于产品的线上个性化推荐。
1.3 主要覆盖模块
搭建一套用户画像方案整体来说需要考虑8个模块的建设，如图1-5所示。
1.4 开发阶段流程
1.4.1 开发上线流程
用户画像建设项目流程，如图1-6所示。
1.4.2 各阶段关键产出
表1-1 用户画像项目各阶段关键产出
❑标签开发：根据业务需求和应用场景梳理标签指标体系，调研业务上定义的数据口径，确认数据来源，开发相应的标签。标签开发在整个画像项目周期中占有较大比重。
❑ETL调度开发：梳理需要调度的各任务之间的依赖关系，开发调度脚本及调度监控告警脚本，上线调度系统。
❑打通服务层接口：为了让画像数据走出数据仓库，应用到用户身上，需要打通数据仓库和各业务系统的接口。
❑画像产品化：需要产品经理与业务人员、技术开发人员一起对接业务需求点和产品功能实现形式，画产品原型，确定工作排期。Java Web端开发完成后，需要数据开发人员向对应的库表中灌入数据。
❑开发调优：在画像的数据和产品端搭建好架构、能提供稳定服务的基础上，为了让调度任务执行起来更加高效、提供服务更加稳健，需要对标签计算脚本、调度脚本、数据同步脚本等相关计算任务进行重构优化。
❑面向业务方推广应用：用户画像最终的价值产出点是业务方应用画像数据进行用户分析，多渠道触达运营用户，分析ROI，提升用户活跃度或营收。因此，面向业务人员推广画像系统的使用方式、提供针对具体业务场景的解决方案显得尤为重要。在该阶段，相关人员需要撰写画像的使用文档，提供业务支持。
1.5 画像应用的落地
画像开发过程中，还需要开发人员组织数据分析、运营、客服等团队的人员进行画像应用上的推广。对于数据分析人员来说，可能会关注用户画像开发了哪些表、哪些字段以及字段的口径定义；对运营、客服等业务人员来说，可能更关注用户标签定义的口径，如何在Web端使用画像产品进行分析、圈定用户进行定向营销，以及应用在业务上数据的准确性和及时性。
1.6 某用户画像案例
1.6.1 案例背景介绍
某图书电商网站拥有超过千万的网购用户群体，所售各品类图书100余万种。用户在平台上可进行浏览、搜索、收藏、下单、购买等行为。商城的运营需要解决两个问题：一方面在企业产品线逐渐扩张、信息资源过载的背景下，如何在兼顾自身商业目标的同时更好地满足消费者的需求，为用户带来更个性化的购物体验，通过内容的精准推荐，更好地提高用户的点击转化率；另一方面在用户规模不断增长的背景下，运营方考虑建立用户流失预警机制，及时识别将要流失的用户群体，采取运营措施挽回用户。商城自建立以来，数据仓库中积累着大量的业务数据、日志数据及埋点数据。如何充分挖掘沉淀在数据仓库中的数据的价值，有效支持用户画像的建设，成为当前的重要工作。
1.6.2 相关元数据
在本案例中，可以获取的数据按其类型分为：业务类数据和用户行为数据。其中业务类数据是指用户在平台上下单、购买、收藏物品、货物配送等与业务相关的数据；用户行为数据是指用户搜索某条信息、访问某个页面、点击某个按钮、提交某个表单等通过操作行为产生（在解析日志的埋点表中）的数据。
涉及数据仓库中的表主要包括用户信息表、商品订单表、图书信息表、图书类目表、App端日志表、Web端日志表、商品评论表等。下面就用户画像建模过程中会用到的一些数据表做详细介绍。
1.用户信息表
用户信息表（见表1-2）存放有关用户的各种信息，如用户姓名、年龄、性别、电话号码、归属地等信息。
2.商品订单表
商品订单表（见表1-3）存放商品订单的各类信息，包括订单编号、用户id、用户姓名、订单生成时间、订单状态等信息。
3.埋点日志表
埋点日志表（见表1-4）存放用户访问App时点击相关控件的打点记录。通过在客户端做埋点，从日志数据中解析出来。
4.访问日志表
访问日志表（见表1-5）存放用户访问App的相关信息及用户的LBS相关信息，通过在客户端埋点，从日志数据中解析出来。
5.商品评论表
商品评论表（见表1-6）存放用户对商品的评论信息。
6.搜索日志表
搜索日志表（见表1-7）存放用户在App端搜索相关的日志数据。
7.用户收藏表
用户收藏表（见表1-8）记录用户收藏图书的数据。
8.购物车信息表
购物车信息表（见表1-9）记录用户将图书加入购物车的数据。
1.6.3 画像表结构设计
不同业务背景有不同的设计方式，这里提供两种设计思路：一是每日全量数据的表结构；二是每日增量数据的表结构。
1.日全量数据
日全量数据表中，在每天对应的日期分区中插入截止到当天为止的全量数据，用户进行查询时，只需查询最近一天的数据即可获得最新全量数据。下面以一个具体的日全量表结构的例子来进行说明。
Hive语法说明
（1）在Hive 中进行查询的时候 Select 语句 查询一般会扫描整个表内容，会消耗很多时间去扫描一些不需要的字段。有时候我们只需要扫描表中关心的一部分数据，因此建表时引入了partition概念。 分区表指的是在创建表时指定的partition的分区空间。 如果需要创建有分区的表，需要在create表的时候调用可选参数partitioned by，详见表创建的语法结构。 （2）分区的实现
- 一个表可以拥有一个或者多个分区，每个分区以文件夹的形式单独存在表文件夹的目录下。 2.表和列名不区分大小写。 3.分区是以字段的形式在表结构中存在，通过describe table命令可以查看到字段存在，但是该字段不存放实际的数据内容，仅仅是分区的表示。 4.建表的语法（建分区可参见PARTITIONED BY参数）：
CREATE [EXTERNAL]
TABLE
[IF NOT EXISTS] table_name
[(col_name data_type [COMMENT col_comment], ...)]
[COMMENT table_comment]
[PARTITIONED BY (col_name data_type [COMMENT col_comment], ...)] [CLUSTERED BY (col_name, col_name, ...)
[SORTED BY (col_name [ASC|DESC], ...)] INTO num_buckets BUCKETS]
[ROW FORMAT row_format]
[STORED AS file_format]
[LOCATION hdfs_path]
- 分区建表分为2种，一种是单分区，也就是说在表文件夹目录下只有一级文件夹目录。另外一种是多分区，表文件夹下出现多文件夹嵌套模式。 5.1 单分区建表语句：create table day_table (id int, content string) partitioned by (dt string);单分区表，按天分区，在表结构中存在id，content，dt三列。 5.2 双分区建表语句：create table day_hour_table (id int, content string) partitioned by (dt string, hour string);双分区表，按天和小时分区，在表结构中新增加了dt和hour两列。
(3) 内部表与外部表的 区别
1.创建外部表需要添加 external 字段。而内部表不需要
2.外部表删除表时，HDFS中的数据文件不会一起被删除。而内部表删除表时，表数据及HDFS中的数据文件都会被删除。
日全量表格说明
这里userid表示用户id，labelweight表示标签权重，theme表示标签归属的二级主题，labelid表示一个标签id。通过“日期+标签归属的二级主题+标签id”的方式进行分区，设置三个分区字段更便于开发和查询数据。该表结构下的标签权重仅考虑统计类型标签的权重，如：历史购买金额标签对应的权重为金额数量，用户近30日访问天数为对应的天数，该权重值的计算未考虑较为复杂的用户行为次数、行为类型、行为距今时间等复杂情况。
通过表名末尾追加“_all”的规范化命名形式，可直观看出这是一张日全量表。
2.日增量数据
日增量数据表，即在每天的日期分区中插入当天业务运行产生的数据，用户进行查询时通过限制查询的日期范围，就可以找出在特定时间范围内被打上特定标签的用户。下面以一个具体的日增量表结构的例子来说明。
这里，labelid表示标签名称；cookieid表示用户id；act_cnt表示用户当日行为次数，如用户当日浏览某三级品类商品3次，则打上次数为3；tag_type_id为标签类型，如母婴、3C、数码等不同类型；act_type_id表示行为类型，如浏览、搜索、收藏、下单等行为。分区方式为按日期分区，插入当日数据。
通过表名末尾追加“_append”的规范化命名形式，可直观看出这是一张日增量表。
例如，某用户在“20180701”日浏览某3C电子商品4次（act_cnt），即给该用户（userid）打上商品对应的三级品类标签（tagid），标签类型（tag_type_id）为3C电子商品，行为类型（act_type_id）为浏览。这里可以通过对标签类型和行为类型两个字段配置维度表的方式，对数据进行管理。例如对于行为类型（act_type_id）字段，可以设定1为购买行为、2为浏览行为、3为收藏行为等，在行为标签表中以数值定义用户行为类型，在维度表中维护每个数值对应的具体含义。
该日增量数据表可视为ODS层用户行为标签明细。在查询过程中，例如对于某用户id为001的用户，查询其在“20180701”日到“20180707”日被打上的标签，可通过命令：select*from dw.userprofile_act_feature_append whereuserid='001'and data_date>='20180701'and data_date<='20180707'查询。该日增量的表结构记录了用户每天的行为带来的标签，但未计算打在用户身上标签的权重，计算权重时还需做进一步建模加工。标签权重算法详见4.6节的内容。
3.关于宽表设计
用户画像表结构如何设计，没有一定要遵循的固定的格式，符合业务需要、能满足应用即可。下面通过两个宽表设计的案例，提供另一种解决方案的思路。用户属性宽表设计（见表1-10），主要记录用户基本属性信息。
用户日活跃宽表设计（见表1-11），主要记录用户每天访问的信息。
1.7 定性类画像
度外，定性刻画也是常见手段。定性类画像多见于用户研究等运营类岗位，通过电话调研、网络调研问卷、当面深入访谈、网上第三方权威数据等方式收集用户信息，帮助其理解用户。
第2章 数据指标体系
数据指标体系是建立用户画像的关键环节，也是在标签开发前要进行的工作，具体来说就是需要结合企业的业务情况设定相关的指标。
互联网相关企业在建立用户画像时一般除了基于用户维度（userid）建立一套用户标签体系外，还会基于用户使用设备维度（cookieid）建立相应的标签体系。基于cookieid维度的标签应用也很容易理解，当用户没有登录账户而访问设备时，也可以基于用户在设备上的行为对该设备推送相关的广告、产品和服务。
建立的用户标签按标签类型可以分为统计类、规则类和机器学习挖掘类，相关内容在1.1.2节中有详细介绍。从建立的标签维度来看，可以将其分为用户属性类、用户行为类、用户消费类和风险控制类等常见类型。下面详细介绍用户标签体系的构成及应用场景。
2.1 用户属性维度
2.1.1 常见用户属性
用户属性是刻画用户的基础。常见用户属性指标包括：用户的年龄、性别、安装时间、注册状态、城市、省份、活跃登录地、历史购买状态、历史购买金额等。
用户属性维度的标签建成后可以提供客服电话服务，为运营人员了解用户基本情况提供帮助。用户属性标签包含统计类、规则类、机器学习挖掘类等类型。统计类标签的开发较为简单，机器学习挖掘类标签将在4.3节中通过具体案例进行讲解。本节主要介绍常见用户属性标签主要包括的维度。表2-1给出了常用的用户属性维度标签。
2.1.2 用户性别
用户性别可细分为自然性别和购物性别两种。自然性别是指用户的实际性别，一般可通过用户注册信息、填写调查问卷表单等途径获得。该标签只需要从相应的表中抽取数据即可，加工起来较为方便。用户购物性别是指用户购买物品时的性别取向。例如，一位实际性别为男性的用户，可能经常给妻子购买女性的衣物、包等商品，那么这位用户的购物性别则是女性。
2.2 用户行为维度
用户行为是另一种刻画用户的常见维度，通过用户行为可以挖掘其偏好和特征。常见用户行为维度指标（见表2-2）包括：用户订单相关行为、下单/访问行为、用户近30天行为类型指标、用户高频活跃时间段、用户购买品类、点击偏好、营销敏感度等相关行为。
2.3 用户消费维度
对于用户消费维度指标体系的建设，可从用户浏览、加购、下单、收藏、搜索商品对应的品类入手，品类越细越精确，给用户推荐或营销商品的准确性越高。如图2-1所示，根据用户相关行为对应商品品类建设指标体系，本案例精确到商品三级品类。
表2-3为用户消费维度的标签设计。
这里通过一个场景来介绍构建用户消费维度的标签的应用。某女装大促活动期间，渠道运营人员需要筛选出平台上的优质用户，并通过短信、邮件、Push等渠道进行营销，可以通过圈选“浏览”“收藏”“加购”“购买”“搜索”与该女装相关品类”的标签来筛选出可能对该女装感兴趣的潜在用户，进一步组合其他标签（如“性别”“消费金额”“活跃度”等）筛选出对应的高质量用户群，推送到对应渠道。因此将商品品类抽象成标签后，可通过品类+行为的组合应用方式找到目标潜在用户人群。
2.4 风险控制维度
互联网企业的用户可能会遇到薅羊毛、恶意刷单、借贷欺诈等行为的用户，为了防止这类用户给平台带来损失和风险，互联网公司需要在风险控制维度构建起相关的指标体系，有效监控平台的不良用户。结合公司业务方向，例如可从账号风险、设备风险、借贷风险等维度入手构建风控维度标签体系。下面详细介绍一些常见的风险控制维度的标签示例，如表2-4所示。
2.5 社交属性维度
社交属性用于了解用户的家庭成员、社交关系、社交偏好、社交活跃程度等方面，通过这些信息可以更好地为用户提供个性化服务。表2-5是常用的社交属性维度标签示例。
2.6 其他常见标签划分方式
本章前5节从用户属性、用户行为、用户消费、风险控制、社交属性共五大维度划分归类了用户标签指标体系。但对用户标签体系的归类并不局限于此，通过应用场景对标签进行归类也是常见的标签划分方式。图2-4展示了具体的画像标签应用场景划分。
2.7 标签命名方式
无参考价值。
2.8 本章小结
本章主要介绍了如何结合业务场景去搭建刻画用户的数据指标体系。其中2.1节到2.5节介绍了一种从用户属性、用户行为、用户消费、风险控制和社交属性5个维度建立用户标签体系的思路，2.6节提供了一种基于应用场景搭建指标体系的思路。
本文为读书笔记，更多精彩内容请自行购买书籍。
