# 第4章 标签数据开发
标签数据开发是用户画像体系搭建中最主要的环节，
主要包括离线标签开发、实时类标签开发、用户特征库开发、人群计算、打通数据服务层等开发内容。
离线标签开发主要围绕第2章讲的数据指标体系开发统计类标签、规则类标签、挖掘类标签等展开；
实时类标签主要针对给用户展现实时性较强的场景开发相关数据，如首页新人弹窗、新人红包等场景；
用户特征库围绕用户的每次行为明细记录相关数据，如用户浏览、搜索、收藏、下单等行为明细，一般该特征库按日做时间分区；
人群计算应用在数据服务层之前，业务方需要组合用户的标签来筛选出对应人群，通过人群计算功能组合标签划分出对应的人群；
打通数据服务层将业务方根据业务规则圈定出来的用户人群推送到不同的业务系统中去。
# 4.1 统计类标签开发
统计类标签是指统计用户相关数值、客观描述用户状态的标签，
如用户的年龄、体重、累计购买金额、累计购买次数、近30日登录次数等。
# 4.1.1 近30日购买行为标签案例
对近30日购买行为这个二级类目进行拆解，可将其拆解为：
付款订单量（对应标签“ACTION_U_01_001”）、
总付款金额（对应标签“ACTION_U_01_002”）、
加入购物车次数（对应标签“ACTION_U_01_003”）这3个标签，
下面看如何将标签开发插入用户标签表中。
# 4.1.2 最近来访标签案例
最近一次来访距今天数从用户的访问日志表（ods.page_view_log）中抽取。
# 4.2 规则类标签开发
规则类标签一般是指根据业务运营上的需要，在业务层面制定规则的标签。
这类标签会带有一些人为主观判断的因素，所以在开发前需要先进行数据调研，
摸清本平台上业务数据的情况，然后再根据运营业务规则开发相关标签。
除了由数据开发人员写脚本开发标签外，还可以根据设定的规则，结合用户在平台上的行为进行自动打标签。
比如用户触发的50个行为记录中，有40个记录是3C类商品，我们会给用户打上“数码达人”的标签。
根据规则，自动化打标签重要的是结合本平台业务数据情况设定好规则，同时也需要建立测试账号来校验自动打标签的准确性。
# 4.2.1 用户价值类标签案例
- RFM模型
（1）最近一次消费（Recency），是指用户上一次购买时间；
（2）消费频率（Frequency），是指用户在一定时间段内的消费次数；
（3）消费金额（Money），是指用户在一定时间段内累计消费的金额。
3个基础指标进行组合可以划分出8类人群
在开发对应的标签前需要进行数据调研。
根据对数据仓库中拉取的用户消费相关数据进行分析后得出用户这3个维度的指标在数值上划分的界限。
根据累计用户量的占比，可按照二八比例进行划分，将最近一次交易时间距今0，到90日的用户划分为“近”，
将最近一次交易时间距今90日以上的用户划分为“远”。
根据累计用户量的占比，按二八比例进行划分，
将历史交易订单量在3单以下的用户划分为低频，将交易订单量在3单及以上的用户划分为高频。
根据用户近一年交易金额情况，将交易金额在300元以下的用户划分为“低额”，将交易金额大于300元的用户划分为“高额”。
经过上面从3个维度对用户的数据调研，对这3个维度进行交叉分析
（R≤90为“近”，R>90为“远”，F≤3为“低频次”，F>3为“高频次”，M≤300为“低额”，M>300为“高额”），
划分出以下8类人群
在对业务数据进行调研后开发相关标签。
首先从用户消费订单表（dw.user_consume_order_info）
里面获取用户最近一次消费距今天数、累计消费次数、累计消费金额这3个维度的数据，并注册视图“user_rfm_info”。
根据前面的数据调度得出的结论，按照最近一次购买距今天数90天、购买次数3次、消费金额500元来对用户3个维度的价值进行高低层次的划分。
最后将每个用户按3个维度的打分情况划分到8类人群中去，将结果插入到用户标签表中。
# 4.2.2 用户活跃度标签案例
在业务场景中，经常需要根据用户的活跃情况给用户打上高活跃、中活跃、低活跃、流失等标签，
如何划定时间范围，如将××天未访问的用户定义为流失用户，将××天内活跃×次的用户定义为高活跃用户，需要结合业务数据调研情况来确定数值。
首先需要划分用户的流失周期，在流失周期内，根据用户的活跃情况进一步将其划分为高活跃、中活跃、低活跃。
在业务上划分用户的流失周期时有多种方式。
1）根据用户回访率来划分
初始日期圈定的一批首次访问用户，观察后续时间内该批用户仍有访问行为的占初始用户的比例。
随着时间的推移，该比例逐渐降低。当曲线出现明显下降时可划分为流失周期（如图4-8所示）。
2）统计用户最后一次访问与倒数第二次访问之间的时间间隔，可认为大于这个时间间隔后用户基本不会再访问，即用户已经流失。
然后统计各时间段内用户人数的占比，累计占比达到一定比例时可认为大部分用户在这段时间后已经流失。
根据图4-8所示的用户回访率曲线图，可认为30日为用户的流失周期。
从图4-8可以看出，用户在第5周以后回访率下降速度减慢，回访率已经低于10%且后续趋势保持平稳。
第5周作为拐点即为用户流失周期，流失的关键指标是用户没有访问App的行为。
从图4-9还可以看出，用户最后一次访问与倒数第二次访问间隔30日以上的用户占比不足10%，
可认为大于这个访问时间间隔的用户已流失，即最后一次访问距今30日以上的用户可认为已流失。
根据上面介绍的划定用户流失周期的方法，这里假定在该公司的业务场景中30日为用户流失周期，近30日没有访问行为的用户划定为已流失用户。
在30日流失周期内，进一步根据用户访问天数来对用户活跃度进行划分。
经过对数据的调研分析，从图4-10可以看出，活跃10日以上的用户占近30日访问用户量的20%，
按照二八划分的方法把这批用户划为高活跃用户，进一步把活跃5~10日的用户划分为中活跃用户，把活跃1~5日的用户划分为低活跃用户。
另外，从GMV占比和客单价来看，占20%的高活跃用户贡献了近60%的GMV，客单价明细高于中活跃、低活跃用户群体。
根据数据调研分析的结果，以30日为界划分流失周期，
将最后一次访问距今大于30日的用户划定为已流失用户，30日内活跃10~30天的用户划定为高活跃用户，
30日内活跃5~10天的用户划定为中活跃用户，30日内活跃少于5天的用户划定为低活跃用户。
根据划分的口径开发相应的标签。
# 4.3 挖掘类标签开发
挖掘类标签需要应用算法挖掘用户相关特征，
一般用户相关的挖掘类标签可以包括预测用户男女性别、预测用户点击下单、判断用户已经流失或将要流失、判断用户购买品类偏好等。
由于挖掘类标签需要进行数据调研，找用户行为特征进行特征工程开发、算法参数调优以及上线工程化调度等多个开发环节，一般开发周期较长。
# 4.3.1 案例背景 - 给平台上文章打标签
目标网站上积累了大量与疾病主题相关的文章、帖子等文本数据。
由于历史原因，这些文章没有做内容归类，也没有打上相应的标签，不便于对内容进行管理。
现在为了对文章按主题进行分类，方便后期给阅读相关文章的用户打上对应的标签，
需要先对大量历史文章、帖子（图4-12）做分类整理，同时对每篇文章打上与其主题相关的标签。
对网站内的全部历史文章、帖子数据进行如下操作：
1）根据已经划定的文章内容类型，将这些未做过分类的文章自动划分到相应类型下。
2）为支持文章的集约化管理，根据文章内容自动为每篇文章打上与其主题相关的标签。
# 4.3.2 特征选取及开发
机器学习以统计理论为基础，通过算法对已知的训练数据做统计分析从而获得规律，再运用规律对未知数据做预测。
在文本分类问题上的基本思路是：
- 标注——人工对一批文档进行准确分类，作为训练集样本；
- 训练——计算机从标注好的文档集中挖掘出能够有效分类的规则，生成分类器；
- 分类——将生成的分类器应用在待分类的文档集中，从而获得文档的分类结果。
首先对待分类的文章做切词处理，将切好的词语写入指定的路径下。
对文本进行分类是需要基于特征的，拿到数据后怎么抽取具有区分度的特征使关键的一步。
本案例中使用Bunch方法构建文本特征。
文章分类并打标签的建模主要包括以下步骤：
1）对以划分好类型的文本集（训练集）和待划分类型的文本集（测试集）进行文本的分词处理，使文本长句划分为单个词组；
2）将步骤1中切好的词组放入词包中，扩展成链式结构，形成bag of word；
3）应用TF-IDF算法计算训练集文档中每篇文章的TF-IDF权重矩阵；
4）使用朴素贝叶斯分类方法对训练集数据进行训练，得到参数对测试集数据进行分类处理。
模型中用到的算法和数据处理技术包括文本分词、TF-IDF算法、朴素贝叶斯分类算法。
# 4.3.3 文本分词处理
# 4.3.4 数据结构处理
# 4.3.5 文本TF-IDF权重
# 4.3.6 朴素贝叶斯分类
# 4.4 流式计算标签开发
前面3节介绍的是离线标签的开发，即批次ETL任务，一般为T+1日的数据。本节内容介绍实时标签数据的开发。
在做实时订单分析，或者给首次登录App的新人用户弹窗推送、发放红包，
实时分析用户所处场景并进行推送中有广泛的应用，这里使用Spark Streaming开发相关的实时数据。
# 4.4.1 流式标签建模框架
Spark Streaming 是 Spark Core API的扩展，支持实时数据流的处理，并且有可扩展、高吞吐量、容错的特点。
数据可以从Kafka、Flume等多个来源获取，可以使用map、reduce、window等多个高级函数对业务逻辑进行处理。
最后，处理后的数据被推送到文件系统、数据库等。
在内部Spark Streaming接收实时数据流并将数据分成多个batch批次，然后由Spark引擎进行处理，批量生成结果流。
Spark Streaming提供了一个高层抽象，称为 Discretized Stream 或 Dstream，它表示连续的数据流。
Dstream 可以通过Kafka、Flume等来源的数据流创建，也可以通过在其他Dstream上应用高级操作来创建。
# 4.4.2 Kafka简介
Kafka的核心功能是作为分布式消息中间件。
Kafka集群由多个Broker server组成，其中，消息的发送者称为Producer；
消息的消费者称为Cousumer；
Broker是消息处理的节点，多个Broker组成Kafka集群；
Topic是数据主题，用来区分不同的业务系统，消费者通过订阅不同的Topic来消费不同主题的数据，
每个Topic又被分为多个Partition，Partition是topic的分组，每个Partition都是一个有序队列；
offset用于定位消费者在每个Partition中消费的位置。
# 4.4.3 Spark Streaming集成Kafka
Spark Streaming可以通过Receiver和Direct两种模式来集成Kafka。
# 4.4.4 标签开发及工程化
实时类标签的处理流程主要包括4个部分：
- 读取数据源，这里讲解消费Kafka中的数据；
- 解析数据，即解析消费的Kafka数据；
- 将解析后的数据存储到指定位置（如MySQL、HDFS、HBase等）；
- 存储消费的Offset，Direct模式下需要保存消费到的位置。
# 4.5 用户特征库开发
为进一步从多个维度丰富用户特征，挖掘用户的相关行为，除了开发用户标签体系外，一般还会开发用户的特征库。
一方面为个性化推荐、精准营销、商业分析等应用提供中间层数据，
另一方面也可以削减不同算法在特征构建时的冗余加工。
简单来说，用户特征库就是对用户每一次的不同行为（如浏览、收藏、搜索、购买等）
及该行为对应的标签（或商品品类）进行详细的记录，以便从用户的行为特征中挖掘用户的偏好。
与开发用户标签相比，用户特征库可以对数据进行汇总统计，从多个维度分析用户特征，而用户标签则“相对静态”地记录了用户当前的状态。
例如，
用户经常浏览或购买奶粉、尿不湿、婴儿车等商品，则她可能是一个孩子的妈妈；
用户经常浏览、收藏、点赞搞笑、段子类视频，可用于挖掘用户的内容喜爱偏好；
用户对女装、美甲等商品的浏览、购买、收藏等行为数据，在用户性别分类的挖掘中时会很有效。
在用户画像建模的过程中，为了高效挖掘用户特征，需要进行用户特征库的规划和开发。
# 4.5.1 特征库规划
# 4.5.2 数据开发
# 4.5.3 其他特征库规划
# 4.6 标签权重计算
# 4.6.1 TF-IDF词空间向量
# 4.6.2 时间衰减系数
# 4.6.3 标签权重配置
# 4.7 标签相似度计算
# 4.7.1 案例场景
# 4.7.2 数据开发
# 4.8 组合标签计算
# 4.8.1 应用场景
# 4.8.2 数据计算
# 4.9 数据服务层开发
数据最终的目的是走出数据仓库，应用到业务系统和营销场景中。
一般在开发完画像后，还需要打通标签数据和各业务系统之间的通路，通过产品化的方式将标签数据应用到业务中去。
这里需要打通的服务层包括离线服务层和在线服务层，其中离线服务层将ETL后的用户群数据推送到对应业务系统，
在线服务层以RESTful API方式提供接口服务，可支持个性化推荐、营销推送、在线特征库等场景。
几个典型的应用场景包括：
- 1）短信营销：
可以基于用户画像的自定义圈人服务，进行重点用户的广告/消息消息推送/短信/邮件营销。 - 2）邮件营销：
可以基于不同用户群体，进行个性化有效的会员营销，
同时在服务上也可以基于已经打通的用户数据，提供会员差异化的客服/物流/活动等服务。 - 3）风控系统：
可以根据用户级别，作为风控系统规则引擎或模型的输入。 - 4）数据分析：
可以分析不同群体的行为特征，提供分析和决策。 - 5）BI数据：
可以监控核心用户群体的变化，为上层决策提供数据基础支持。
下面以案例形式介绍四种常见的渠道运营系统，及如何将标签数据与这四种业务系统打通。
后文的7.4节中会讲述画像产品化的形态，本节内容主要讲解产品背后的工程化实现方式，在阅读本节内容时可结合第7章来看。
# 4.9.1 推送至营销系统
如果公司有统一的营销系统，则把需要应用到服务端的数据统一灌入服务层对应的数据库中。
一般来说，服务层会使用HBase、Elasticsearch等进行数据存储。
# 4.9.2 接口调用服务
# 4.10 GraphX图计算用户
# 4.10.1 图计算理论及应用场景
Spark GraphX是分布式图计算框架，基于Spark平台提供了对图计算的简单且丰富的接口，以满足对分布式图处理的需求。
对GraphX视图的所有计算，最终会转化为其关联的Table视图的RDD操作来完成。
在工程实践中，存在需要计算二度关系用户的场景，即用户与用户之间通过其共同的好友找到他们的二度关系熟人，这种对图的挖掘计算可借助Spark GraphX完成。
# 4.10.2 数据开发案例
# 4.11 本章小结
← 第3章 标签数据存储 第5章 开发性能调优 →