增长黑客知识库

# 第1章 用户画像基础

# 1.1　用户画像是什么

用户的一切行为在企业面前是可“追溯”“分析”的。
企业内保存了大量的原始数据和各种业务数据，这是企业经营活动的真实记录，
如何更加有效地利用这些数据进行分析和评估，成为企业基于更大数据量背景的问题所在。

随着大数据技术的深入研究与应用，企业的关注点日益聚焦在如何利用大数据来为精细化运营和精准营销服务，
而要做精细化运营，首先要建立本企业的用户画像。

# 1.2 数据架构

用户画像是对基于数据仓库ODS层、DW层、DM层中与用户相关数据的二次建模加工。
在ETL过程中将用户标签计算结果写入Hive，由于不同数据库有不同的应用场景，
后续需要进一步将数据同步到MySQL、HBase、Elasticsearch等数据库中。

  • Hive
    存储用户标签计算结果、用户人群计算结果、用户特征库计算结果。

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

  • HBase
    存储线上接口实时调用类数据。

  • Elasticserch
    支持海量数据的实时查询分析，用于存储用户人群计算、用户群透视分析所需的用户标签数据
    （由于用户人群计算、用户群透视分析的条件转化成的SQL语句多条件嵌套较为复杂，使用Impala执行也需花费大量时间）。

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

# 1.3 主要覆盖模块

搭建一套用户画像方案整体来说需要考虑8个模块的建设。

  • 用户画像基础
    需要了解、明确用户画像是什么，包含哪些模块，数据仓库架构是什么样子，开发流程，表结构设计，ETL设计等。
    这些都是框架，大方向的规划，只有明确了方向后续才能做好项目的排期和人员投入预算。
    这对于评估每个开发阶段重要指标和关键产出非常重要，重点可看1.4节。

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

  • 标签数据存储
    标签相关数据可存储在Hive、MySQL、HBase、Elasticsearch等数据库中，不同存储方式适用于不同的应用场景。

  • 标签数据开发
    用户画像工程化的重点模块，包含统计类、规则类、挖掘类、流式计算类标签的开发，
    以及人群计算功能的开发，打通画像数据和各业务系统之间的通路，提供接口服务等开发内容。

  • 开发性能调优
    标签加工、人群计算等脚本上线调度后，为了缩短调度时间、保障数据的稳定性等，需要对开发的脚本进行迭代重构、调优。

  • 作业流程调度
    标签加工、人群计算、同步数据到业务系统、数据监控预警等脚本开发完成后，需要调度工具把整套流程调度起来。
    本书讲解了Airflow这款开源ETL工具在调度画像相关任务脚本上的应用。

  • 用户画像产品化
    为了能让用户数据更好地服务于业务方，需要以产品化的形态应用在业务上。
    产品化的模块主要包括标签视图、用户标签查询、用户分群、透视分析等。

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

# 1.4 开发阶段流程

# 1.4.1 开发上线流程

  • 第一阶段：目标解读
    在建立用户画像前，首先需要明确用户画像服务于企业的对象，再根据业务方需求，明确未来产品建设目标和用户画像分析之后的预期效果。

一般而言，用户画像的服务对象包括运营人员和数据分析人员。
不同业务方对用户画像的需求有不同的侧重点，就运营人员来说，他们需要分析用户的特征、定位用户行为偏好，
做商品或内容的个性化推送以提高点击转化率，所以画像的侧重点就落在了用户个人行为偏好上；
就数据分析人员来说，他们需要分析用户行为特征，做好用户的流失预警工作，还可根据用户的消费偏好做更有针对性的精准营销。

  • 第二阶段：任务分解与需求调研

经过第一阶段的需求调研和目标解读，我们已经明确了用户画像的服务对象与应用场景，
接下来需要针对服务对象的需求侧重点，结合产品现有业务体系和“数据字典”规约实体和标签之间的关联关系，明确分析维度。
就后文将要介绍的案例而言，需要从用户属性画像、用户行为画像、用户偏好画像、用户群体偏好画像等角度去进行业务建模。

  • 第三阶段：需求场景讨论与明确

在本阶段，数据运营人员需要根据与需求方的沟通结果，输出产品用户画像需求文档，
在该文档中明确画像应用场景、最终开发出的标签内容与应用方式，并就该文档与需求方反复沟通并确认无误。

  • 第四阶段：应用场景与数据口径确认

经过第三个阶段明确了需求场景与最终实现的标签维度、标签类型后，
数据运营人员需要结合业务与数据仓库中已有的相关表，明确与各业务场景相关的数据口径。
在该阶段中，数据运营方需要输出产品用户画像开发文档，该文档需要明确应用场景、标签开发的模型、涉及的数据库与表以及应用实施流程。
该文档不需要再与运营方讨论，只需面向数据运营团队内部就开发实施流程达成一致意见即可。

  • 第五阶段：特征选取与模型数据落表

本阶段中数据分析挖掘人员需要根据前面明确的需求场景进行业务建模，
写好HQL逻辑，将相应的模型逻辑写入临时表中，并抽取数据校验是否符合业务场景需求。

  • 第六阶段：线下模型数据验收与测试

数据仓库团队的人员将相关数据落表后，设置定时调度任务，定期增量更新数据。
数据运营人员需要验收数仓加工的HQL逻辑是否符合需求，根据业务需求抽取表中数据查看其是否在合理范围内，
如果发现问题要及时反馈给数据仓库人员调整代码逻辑和行为权重的数值。

  • 第七阶段：线上模型发布与效果追踪

经过第六阶段，数据通过验收之后，会通过Git进行版本管理，部署上线。
使用Git进行版本管理，上线后通过持续追踪标签应用效果及业务方反馈，调整优化模型及相关权重配置。

# 1.4.2 各阶段关键产出

为保证程序上线的准时性和稳定性，需要规划好各阶段的任务排期和关键产出。
画像体系的开发分为几个主要阶段，包括前期指标体系梳理、用户标签开发、ETL调度开发、打通数据服务层、
画像产品端开发、面向业务方推广应用、为业务方提供营销策略的解决方案等。


  • 标签开发
    根据业务需求和应用场景梳理标签指标体系，调研业务上定义的数据口径，确认数据来源，开发相应的标签。
    标签开发在整个画像项目周期中占有较大比重。

  • ETL调度开发
    梳理需要调度的各任务之间的依赖关系，开发调度脚本及调度监控告警脚本，上线调度系统。

  • 打通服务层接口
    为了让画像数据走出数据仓库，应用到用户身上，需要打通数据仓库和各业务系统的接口。

  • 画像产品化
    需要产品经理与业务人员、技术开发人员一起对接业务需求点和产品功能实现形式，画产品原型，确定工作排期。
    Java Web端开发完成后，需要数据开发人员向对应的库表中灌入数据。

  • 开发调优
    在画像的数据和产品端搭建好架构、能提供稳定服务的基础上，
    为了让调度任务执行起来更加高效、提供服务更加稳健，需要对标签计算脚本、调度脚本、数据同步脚本等相关计算任务进行重构优化。

  • 面向业务方推广应用
    用户画像最终的价值产出点是业务方应用画像数据进行用户分析，多渠道触达运营用户，分析ROI，提升用户活跃度或营收。
    因此，面向业务人员推广画像系统的使用方式、提供针对具体业务场景的解决方案显得尤为重要。
    在该阶段，相关人员需要撰写画像的使用文档，提供业务支持。

# 1.5 画像应用的落地

用户画像最终的价值还是要落地运行，为业务带来实际价值。

# 1.6 某用户画像案例

# 1.6.1 案例背景介绍

某图书电商网站拥有超过千万的网购用户群体，所售各品类图书100余万种。
用户在平台上可进行浏览、搜索、收藏、下单、购买等行为。

商城的运营需要解决两个问题：

一方面在企业产品线逐渐扩张、信息资源过载的背景下，如何在兼顾自身商业目标的同时更好地满足消费者的需求，
为用户带来更个性化的购物体验，通过内容的精准推荐，更好地提高用户的点击转化率；

另一方面在用户规模不断增长的背景下，运营方考虑建立用户流失预警机制，
及时识别将要流失的用户群体，采取运营措施挽回用户。

商城自建立以来，数据仓库中积累着大量的业务数据、日志数据及埋点数据。
如何充分挖掘沉淀在数据仓库中的数据的价值，有效支持用户画像的建设，成为当前的重要工作。

# 1.6.2 相关元数据

可以获取的数据按其类型分为： 业务类数据和用户行为数据。

其中业务类数据是指用户在平台上下单、购买、收藏物品、货物配送等与业务相关的数据；
用户行为数据是指用户搜索某条信息、访问某个页面、点击某个按钮、提交某个表单等通过操作行为产生（在解析日志的埋点表中）的数据。

涉及数据仓库中的表主要包括用户信息表、商品订单表、图书信息表、图书类目表、App端日志表、Web端日志表、商品评论表等。

  • 1.用户信息表

  • 2.商品订单表

  • 3.埋点日志表

存放用户访问App时点击相关控件的打点记录。
通过在客户端做埋点，从日志数据中解析出来。

  • 4.访问日志表

存放用户访问App的相关信息及用户的LBS相关信息，通过在客户端埋点，从日志数据中解析出来。

  • 5.商品评论表

  • 6.搜索日志表

  • 7.用户收藏表

  • 8.购物车信息表

# 1.6.3 画像表结构设计

表结构设计的重点是要考虑存储哪些信息、如何存储（数据分区）、如何应用（如何抽取标签）这3个方面的问题。

不同业务背景有不同的设计方式，这里提供两种设计思路：
一是每日全量数据的表结构；
二是每日增量数据的表结构。

Hive需要对输入进行全盘扫描来满足查询条件，通过使用分区可以优化查询。
对于用户标签这种日加工数据，随着时间的推移，分区数量的变动也是均匀的。

  • 每日全量数据

即该表的日期分区中记录着截止到当天的全量用户数据。
例如，
“select count（*）from userprofile where data='20180701'”
这条语句查询的是userprofile表截止到2018年7月1日的全量用户数据。
日全量数据的优势是方便查询，缺点是不便于探查更细粒度的用户行为。

  • 每日增量数据
    即该表的日期分区中记录着当日的用户行为数据。
    例如，同样是“select count（*）from userprofile where data='20180701'”，
    这条语句查询的是userprofile表在2018年7月1日记录的当日用户行为数据。
    日增量数据可视为ODS层的用户行为画像，在应用时还需要基于该增量数据做进一步的建模加工。

  • 两种表结构的设计方法

    • 1.日全量数据

日全量数据表中，在每天对应的日期分区中插入截止到当天为止的全量数据，用户进行查询时，只需查询最近一天的数据即可获得最新全量数据。
下面以一个具体的日全量表结构的例子来进行说明。

CREATE TABLE `dw.userprofile_attritube_all `(
    `userid` string COMMENT 'userid', 
    `labelweight` string COMMENT '标签权重',)
COMMENT 'userid 用户画像数据'
PARTITIONED BY ( `data_date` string COMMENT '数据日期', `theme` string COMMENT '二级主题', `labelid` string COMMENT '标签id')

userid表示用户id，
labelweight表示标签权重，
theme表示标签归属的二级主题，
labelid表示一个标签id。

通过“日期+标签归属的二级主题+标签id”的方式进行分区，设置三个分区字段更便于开发和查询数据。

该表结构下的标签权重仅考虑统计类型标签的权重，
如：
历史购买金额标签对应的权重为金额数量，
用户近30日访问天数为对应的天数，该权重值的计算未考虑较为复杂的用户行为次数、行为类型、行为距今时间等复杂情况。

通过表名末尾追加“_all”的规范化命名形式，可直观看出这是一张日全量表。

例如，
对于主题类型为“会员”的标签，插入“20190101”日的全量数据，
可通过语句：

insert overwrite table dw.userprofile_userlabel_all   
partition（data_date='20190101'，theme='member'，labelid='ATTRITUBE_U_05_001'）

来实现。

查询截止到“20190101”日的被打上会员标签的用户量，可通过语句：

select count（distinct userid）from dw.userprofile_userlabel_all where data_date='20190101'

来实现。

具体的开发过程在4.1节中详细讲解。

    • 2.日增量数据

日增量数据表，即在每天的日期分区中插入当天业务运行产生的数据，
用户进行查询时通过限制查询的日期范围，就可以找出在特定时间范围内被打上特定标签的用户。

CREATE TABLE dw.userprofile_act_feature_append (  
  labelid STRING COMMENT '标签id',   
  cookieid STRING COMMENT '用户id',   
  act_cnt int COMMENT '行为次数',
  tag_type_id int COMMENT '标签类型编码'，
  act_type_id int COMMENT '行为类型编码') 
comment '用户画像-用户行为标签表'
PARTITIONED BY (data_date STRING COMMENT '数据日期')

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为收藏行为等，
在行为标签表中以数值定义用户行为类型，在维度表中维护每个数值对应的具体含义。

    • 3.关于宽表设计

用户画像表结构如何设计，没有一定要遵循的固定的格式，符合业务需要、能满足应用即可。
下面通过两个宽表设计的案例，提供另一种解决方案的思路。

用户属性宽表设计
用户属性宽表设计

用户日活跃宽表设计

# 1.7 定性类画像

本书重点讲解如何运用大数据定量刻画用户画像，然而对于用户的刻画除了定量维度外，定性刻画也是常见手段。

定性类画像多见于用户研究等运营类岗位，
通过电话调研、网络调研问卷、当面深入访谈、网上第三方权威数据等方式收集用户信息，帮助其理解用户。
这种定性类调研相比大数据定量刻画用户来说，可以更精确地了解用户需求和行为特征，
但这个样本量是有限的，得出的结论也不一定能代表大部分用户的观点。

通过制定调研问卷表，我们可以收集用户基本信息以及设置一个或多个场景，
专访用户或网络回收调研问卷，在分析问卷数据后获取用户的画像特征。

目前市场上“问卷星”等第三方问卷调查平台可提供用户问卷设计、链接发放、采集数据和信息、调研结果分析等一系列功能。

根据回收的调研问卷，可结合统计数据进一步分析用户画像特征。

# 1.8 本章小结

本书后面的章节将围绕1.3节中画像系统覆盖的8个模块依次展开。

← 第2章 数据指标体系 →