前言

本文介绍我们在推荐系统领域的大规模参数学习研究. 问题的起源是探究给每一个用户学习一个 ID 层级的表征, 而在千万量级的业务上, 学习如此特征将会牵涉到超十亿规模的参数学习. 对此我们根据推荐算法的特点, 实现了一个无需使用参数服务器, 在普通 Spark 能够运行的支持大规模参数学习的 FM 算法, 我们称之为 Elastic Factorization Machines (EFM). 从理论上, EFM 算法能够支持千亿规模的参数训练. 在实践中, 限于资源我们实现了一个十亿级的 EFM 算法, 并在线上对比 FM 取得 PV 点击率 5.0% 的提升.

效果说明

[ QQ 动漫某场景的三天 PV 点击率对比 ]

用户 ID 层级的表征学习

推荐系统中, 用户的表征是一个非常重要的课题, 表征的粒度通常影响推荐算法的个性化程度. 当我们只能用性别的男/女来表征用户的时候, 算法能够给出的只是分群热度推荐. 而当我们能够刻画用户在每一个物品分类的兴趣的时候, 算法的便能够给不同的兴趣群体给出不一样的推荐. 越精细的用户表征, 推荐系统的个性化程度越高.

[ 越精细的用户表征, 推荐系统就越个性化 ]

而最精细的用户表征, 是用户 ID. 对每一个用户学习用户兴趣, 能够做到真正的千人千面. 但在实现上, 学习用户 ID 层级的表征通常会遇到计算量的问题, 这里主要的原因是用户 ID 层级特征量级与用户量直接相关, 以千万级用户的业务为例, 如果使用 FM 算法学习用户 ID 特征, 对每一个用户学习维度为 100 维的隐向量, 则整体参数量将会增加到 10亿级. 而如果这个业务的物品更新不快, 物品数能控制在数万规模, 则即便是用 “用户对物品兴趣” 这个用户表征也只需要训练百万级别的参数.

[ 各级别用户表征的特征量级对比 ]

无参数服务器实现大规模参数学习

业界在大规模参数学习的解决方案是使用参数服务器. 背后的核心是分布式训练. 而市面上各个参数服务器在并行策略上也有不一样的划分, 包括下面两种情况:

• 数据并行

o 这种方法是把模型分发到每一个节点做训练, 但如果模型参数量本来就非常大, 将无法支持.

• 数据并行 + 模型按需并行

o 这种方法的初衷是考虑到并不是每一个训练数据块都需要所有的参数, 因此可以统计当前训练数据所需的参数, 并只向参数服务器请求这些参数. 但因为训练数据是随机分布的, 因而可能一个参数会被多个数据块请求, 这会导致较大的网络开销.

而当我们需要给每一个用户 ID 训练表征的时候, 同一个用户 ID 的参数, 应当仅被这个用户创造的样本所需要, 这个参数对应的梯度也只能从这些样本产生. 这意味着我们只需要让训练数据和模型同时做划分(分桶), 就能够让每个用户 ID 参数仅被一个数据块请求. 在这个思想下, 用户 ID 层级的参数可以分布式存储, 从而也不需要一个单点的参数服务器, 可以在普通的 Spark 上实现.

[ 不同类型的大规模参数训练方案对比 ]

整体的实现步骤如下, 用户 ID 层级的参数和训练数据都按照用户 ID 哈希分桶, 每一个参数块都被分发到对应的数据块上做训练. 与此同时其他特征也会被分发到每一个训练数据块上. 因为除开用户 ID 层级参数外, 其他参数(例如 Item ID)量级能够控制在百万以内, 从而可以分发到各个子结点的内存中. 从参数和训练数据中我们可以算得每一个参数的梯度, 而用户 ID 层级参数的梯度也只由这个训练数据块中产生, 从而可以做一个一一对应的分发把梯度推送到对应的参数块. 而其他参数因为量级较小, 可以做一个递归合并然后在内存更新.

[ 无参数服务器实现大规模参数训练方案 ]

实现细节

规模上限

这个实现从理论上能够支持任意量级的用户 ID 层级训练. 但受限于业务资源, 我们最高只测试过十亿级别的模型训练.

算法选择

按理只要是梯度下降法的优化算法都能够利用类似的方法去实现. 这里我们实现了 SGD 和 ADAM 两种方法, 发现 ADAM 算法作为一个自适应学习率的方法, 效果更好. 这两个算法的具体原理, 可以参见文献1.

Spark 大规模参数学习的工程实现

为了训练亿万级别的模型参数, 我们做了大量的优化工作. 其中部分经验来自于作者曾经在图计算上的实践经验, 例如在多次迭代之后应当实现使用 checkpoint 功能进行 RDD 断链保证系统鲁棒性.

线上模型实现

线上服务在实现上与传统的 FM 算法相似, 除了用户 ID 层级外的模型参数都可以存储在共享内存中. 而每一个用户的 ID 层级特征可以写在 K-V 系统中, 为一个用户提供服务的时候只需要请求一次就能够得到对应的参数值. 从而对比起传统的 FM 算法, EFM 算法只额外多一次 K-V 系统请求的开销.

异步更新问题

每天例行模型训练完成之后, EFM 算法在同步模型参数到线上的时候将会遇到异步更新问题. 因为用户 ID 层级特征的参数和其他参数分别存储在不一样的平台, 更新耗时有较大差异, 从而导致在更新途中有些用户的特征将完全无法和其他特征的隐向量有匹配.

为了解决这个问题, 我们引入增量学习技术, 每天例行训练使用前一天的历史参数做热启动, 使得新一天的模型参数与前一天模型的参数在一个类似的向量空间中. 这样当其他特征更新了, 线上使用的旧模型将仍可以与其他特征有相似度匹配.

[ 两类参数的异步更新会导致部分用户的参数无法与其他特征匹配 ]

总结与展望

本文实现了一个支持亿级参数训练的算法, Elastic Factorization Machines (EFM) 算法. 而我们认为可以在 EFM 算法的基础上做更多的事情, 这里列举我们考虑到的点.

• 向量召回

o 可以分别学习出用户和物品的 Embedding, 做向量相似度的召回.

• Model Ensemble:

o 可以在用户 Embedding 的基础上, 用 DNN 做进一步的学习, 增加非线性表达.

参考文献

[1] https://zhuanlan.zhihu.com/p/22252270

来源：腾讯QQ大数据

背景

随着神盾推荐业务场景的不断深入，传统的离线训练+线上计算的模式可以说是推荐系统1代框架，已经不能完全满足部分业务场景的需求，如短视频、文本等快消费场景。下面先简单介绍下传统模式以及其在不断变化的场景需求中的不足点。

传统模式简单介绍
传统模式下，整个推荐流程粗略可分为，数据上报、样本及特征构造，离线训练评测，线上实时计算，abtest等。

• 优点：
系统架构简单
普适性较强，能满足大多数业务场景。

• 缺点：
数据及时性不够。
模型实时性不强。

下面举一个简单例子，来说明这样的问题：

小明同学在微视上看了一个视频，那么在推荐场景下，可能会遇到以上四类需求，并且每种需求对于数据的实时性要求并不一样。从推荐系统功能来看，可以概括为已阅实时过滤、用户行为实时反馈、物品池子更新等。所以如果要满足业务需求，从代码层面来看，这样的需求并不复杂，但是从架构层面或者可扩展性来说，神盾作为一个面向不同业务的通用推荐平台，就需要提供一个能满足大多数业务，对于快速据消费的通用平台。
针对不同业务、不同场景需求，神盾希望构建一个快数据处理系统，旨在满足更多业务场景的快速据消费场景。

需求调研

任何系统的搭建及开发离不开特定的业务场景需求调查，神盾根据多年业务经验，收集归纳了相关快数据处理的相关需求，具体如下：

我们深入调研、讨论，结合业界实践以及神盾的实际情况，总结为两类系统需求：

• 1、 近线系统。满足业务对于物品、特征、及其他数据类服务的准实时更新。

• 2、 在线学习。满足业务对于模型的准实时迭代更新。

基于以上调研，神盾推出Quicksilver（快数据计算）系统，解决推荐场景下快数据计算及更新问题。

系统设计

Quicksilver系统是一个集近线及在线学习能力为一体的通用架构系统，我们设计之初，从收、算、存、用四个维度来进行设计，如下：

• 收：数据的收集。目前主要支持基于DC、TDBank数据通道上报。

• 算：计算层。针对不同的数据类型，定义不同的计算模块。不同的计算模块，采样不同的技术方案来实现。例如对于物品池子此类分钟级更新要求的数据，我们采用sparkstreaming，而对于用户行为实时反馈等类数据，我们采用spp实时处理类服务器框架。设计中屏蔽掉用户对于底层实现的细节。

• 存：存储层。针对不同的数据规模及访问频率，神盾采用不同的存储介质来满足数据存储的要求及对线上服务延迟的要求。例如对于物品类特征、池子类数据，神盾采用自研的SSM系统，而对于用户类特征，数据量较大、存储访问实时性要求也较高，我们选型为公司的grocery存储组件。

• 用：使用对接层。通过Quicksilver计算得到的数据，我们均通过神盾产品化来配置管理，降低对于数据使用的门槛，最终可以通过配置，直接与线上的召回、精排、重排、规则等计算单元进行打通使用。

架构实现

以上为Quicksilver整体架构实现图，主要分为近线系统及在线学习系统。下面详细介绍。

近线系统

近线系统主要为了满足以下几类细分需求：

• 实时召回：
Quicksilver处理物料，经过各通道后到线上 （要求秒级，实际分钟级）

• 实时因子：
Quicksilver统计计算，经过各通道后到线上（分钟级）

• 实时特征：
统计型（物料、行为、场景）：Quicksilver计算，经过各通道后到线上（分钟级）
实时特征（用户）：实时特征构造引擎构造，构造后直接对接线上（秒级）

于是，在选型上，我们针对不同的数据计算模式，选择不同的计算平台，对于统计类型数据，我们选择sparkstreaming来作为我们的计算平台，对于实时性要求较高的数据，如实时反馈类，我们采用spp来进行平台型封装。

数据批处理

数据批处理是基于sparkstreaming实现，如上，有几点说明：
1、对于使用者来说，采用api接口封装，下层通信等均透明化处理。用户只需在处理不同的数据时，选择不同的接口即可，如物品池子接口，特征接口等。使用PB协议进行下层数据通信。

2、底层数据生成后，使用kafka进行缓存。
3、数据线上使用时，统一在神盾产品化上进行配置管理，降低运维成本。

数据实时处理

数据实时处理是基于spp server实现，如上，有几点说明：
1、对于用户来说，希望一次转发，多次使用。Quicksilver通过接入层interface来实现，业务只需要转发到统一的对外L5，即可实现数据一次转发，多次使用，如部分业务可能想即进行特征构造，有可以将数据转发到样本构造，在此即可实现。而所有的这些配置，也通过神盾产品化进行配置管理。
2、对于不同的业务，由于数据上报标准不一样，那么如何实现不同的数据上报标准都可以在Quicksilver上使用，这是实际中遇到的挺头疼的一件事。我们将这样的问题拆解成不同的数据标准，转化成神盾统一的上报标准的问题。于是，在实际代码开发中，只需要留出这样的转化接口，不同的业务实现不同的接口，并可以根据配置选择不同的接口，那么即可解决这一的问题，在这里，反射即可以很好解决这一的问题。

在线学习

在线学习有两方面优点，一是充分利用数据时效性，实时跟踪用户对物品的偏好，比如10点钟上线的新游，在11点的推荐结果中就可以反馈出不同用户对新游偏好情况，使得在尽快适应用户偏好同时，提升了apps转化率；二是在线学习前提是标记数据和特征在线拼接，该操作可以在一定程度上缓解模型离线训练资源不足瓶颈。

以某apps推荐为例，面临效果提升瓶颈，我们分析有两方面原因导致，一是数据源红利降低(新增数据源成本越来越高)；二是高维线性模型遭遇瓶颈，暴力式特征交叉是LR模型提升特征维数的主要手段，它存在两个问题，一方面，做不同特征之间交叉组合需要一定成本，另一方面，无法穷尽所有交叉组合方式。

面对推荐效果提升瓶颈问题，有三种解决方案，一是继续想办法引入新数据源构建特征；二是充分利用现有数据源，尝试更好特征工程方法，比如Stacking集成或者特征工程自动化；三是考虑充分利用数据时效性，引入在线学习方案，实时跟踪用户对apps偏好变化。

Quicksilver在线学习架构设计如下：

整个系统主要细分为5个小模块：

• 样本采样：根据模型的优化目标支持自定义采样方法，同时在后期也需要将场景特征考虑进来，采样的结果作为实时拼接的输入

• 实时拼接：将实时样本的userid 、itemid的全量特征进行拼接，拼接的结果一方面可以作为离线平台的输入，另外一方面也可以作为特征引擎的输入；

• 特征工程引擎：根据各个在线训练算法的特征配置，从拼接好特征的样本中进行特征选择、特征交叉等操作，并将处理的结果写入kafka消息队列，模型训练和模型评估模块消费消息队列里面的数据进行训练和评估；

• 流式训练：消费kafka里面的样本数据，采用onepass或者minibatch的形式进行模型参数更新；

• 模型评估：对模型训练出来的模型实例，从kafka消费实时样本数据对模型进行auc评估。

下面关于几个较重要模块进行较详细介绍：

样本采样

• 使用spp server实现类map、reduce操作，采样的结果支持存储到kafka或者下一个实时拼接模块。

• 采样规则引擎基于flex/yacc设计实现。

• 所有采样的配置信息，均通过神盾产品化实现管理。

特征拼接

实时拼接服务主要是将样本中包含的物品和用户的“全量”基础特征拼接到一起，为下一步实时特征提供原料。 特征来源有是三个不同的地方：

• 用户特征（包括实时用户特征)：目前主要是来自grocery

• 物品特征（包括实时物品特征): 目前主要从SSM中读取

• 场景特征：是在采样的过程中生成。

实时特征拼接后，下一步便是特征工程引擎的环节，目前主要支持内积、外积、笛卡尔积三种模式，在此不详细介绍。

模型训练

• 目前主要实现基于FTRL的lr及fm算法实现，正在调研参数服务器大规模生产环境使用的路上。

• 动态采样：有的算法算法需要控制正负样本的比例，但线上的流式训练与离线的batch不同，不能再训练之前就知道本次训练总样本量是多少，以及正负样本的比例，故需要根据设置的正负样本比例值，根据时间的推移来动态控制，即在训练的过程中动态采样。

• 低特征覆盖：为了提高模型的可靠性，其中方法之一就是在模型中结合场景特征屏蔽掉低覆盖度特征，与动态采样一样，流式训练时，在训练前无法统计提前统计出每个出现的频率，故也需要动态过滤低频特征，此方法不仅可以用在模型启动时，对于新加入的特征同样适用

模型训练后，即效果评估及上线环节，目前主要支持AUC、MAE等主要评估指标，在此不再详细赘述。

写在最后

对于任何系统设计来说，都不应该脱离实际的应用场景，这是神盾推荐系统一直贯彻的原则。Quicksilver系统也是神盾这么长时间来从实际的业务场景中收集需求、设计、实现的，已经在空间、电竞、手游、动漫、京东等多个业务场景中上线使用，并取得了不错的效果。神盾也不断在实际场景中继续完善、优化其中的相关能力，给业务带来更高的效果提升。

来源：腾讯QQ大数据

查阅了部分资料，笔者拙见，打标签问题无论是文本、图像和视频，涉及到较多对内容的“理解”，目前没有解决得很好。主要原因有以下一些方面，标签具有多样性，有背景内容标签，细节内容标签，内容属性标签，风格标签等等；一些标签的样本的实际表现方式多种多样，样本的规律不明显则不利于模型学习；标签问题没有唯一的标准答案，也存在一定的主观性，不好评估的问题则更不利于模型学习。

依然笔者拙见，视频打标签问题目前还没有很好的解决办法，也处于探索阶段。方法上主要有以下一些思路：可以从视频角度出发，可以从图像角度出发；可以利用caption生成的思路，可以转化为多分类问题。

直接从视频角度出发，即从视频整体的角度出发，提取图像帧，甚至字幕或者语音信息，进一步处理得出视频标签的结果。Deep Learning YouTube Video Tags，这篇文章提出一个hybrid CNN-RNN结构，将视频的图像特征，以及利用LSTM模型对标签考虑标签相关性和依赖性的word embeddings，联合起来，网络结构如下图。

Large-scale Video Classification with Convolutional Neural Networks提出了几种应用于视频分类的卷积神经网络结构，在网络中体现时空信息。single frame：就是把一帧帧的图像分别输入到CNN中去，和普通的处理图像的CNN没有区别；late fution：把相聚L的两帧图像分别输入到两个CNN中去，然后在最后一层连接到同一个full connect的softmax层上去；early fution：把连续L帧的图像叠在一起输入到一个CNN中去；

slow fution：通过在时间和空间维度增加卷积层，从而提供更多的时空全局信息。如下图所示：

另一方面，为了提高训练速度，这篇文章还提出Multiresolution CNNs，分别将截取中间部分的图像和缩放的图像作为网络的输入，如下图所示：

这篇文章主要研究了卷积神经网络在大规模视频分类中的应用和表现。通过实验，文章总结网络细节对于卷积神经网络的效果并不非常敏感。但总的来说，slow fusion网络结构的效果更好。

从图像角度出发，即从视频中提取一些帧，通过对帧图像的分析，进一步得出视频标签的结果。对图像的分析，也可以转化为图像打标签或者图像描述问题。Visual-Tex: Video Tagging using Frame Captions，先从视频中提取固定数量的帧，用训练好的image to caption模型对图像生成描述。然后将文本描述组合起来，提取文本特征并用分类方法进行分类，得到tag结果。这篇文章对生成的描述，对比了多种不同的特征和多种不同的分类方法。可见，图像打标签对视频打标签有较大的借鉴意义。另一种思路，CNN-RNN: A Unified Framework for Multi-label Image Classification可以看作将图像打标签问题转化为多分类问题。将卷积神经网络应用到多标签分类问题中的一个常用方法是转化为多个单标签的分类问题，利用ranking loss或者cross-entropy loss进行训练。但这种方法往往忽略了标签之间的联系或者标签之间语义重复的问题。这篇文章设计了CNN-RNN的网络结构里，并利用attention机制，更好地体现标签间的相关性、标签间的冗余信息、图像中的物体细节等。网络结构主要如下图所示，主要包括两个部分：CNN部分提取图像的语义表达，RNN部分主要获取图像和标签之间的关系和标签之间的依赖信息。

针对空间部分短视频数据，笔者设计了一个简单的视频打标签的方案，并进行了实验。由于预处理和算法细节的很多进一步改进和完善工作还没有进行，在此只是提出一种思路和把实验结果简单地做个分享。

方法介绍：

整体思路：图片打标签 => 视频打标签

也就是说，对视频提取帧，得到视频中的图片；然后对图片进行打标签；最后将视频中帧图片的标签进行整合，得到视频标签。

1、从图片描述说起：

图片描述典型框架：利用deep convolutional neural network来encode 输入图像，然后利用Long Short Term Memory(LSTM) RNN decoder来生成输出文本描述。

2、在打标签任务中，我们把标签或类别组合，构造成“描述”:

一级类别+二级类别+标签（重复的词语进行去重）

3、利用预训练和强化学习，对训练样本图片和标签构造模型映射。

《Self-critical Sequence Training for Image Captioning》

网络模型有三种：fc model；topdown model；att2in model；模型细节见论文。

一般地，给定输入图像和输出文本target，,模型训练的过程为最小化cross entropy loss（maximum-likelihood training objective）:

利用self-critical policy gradient training algorithm：

其中，是reward funtion

通过根据每一个decoding time step的概率分布进行采样获得，是baseline output，通过最大化每一个decoding time step的概率分布输出获得，也就是a greedy search。论文里提到，利用CIDEr metric作为reward function，效果最好。

4、根据视频帧图片的标签，对视频打标签。具体有两种思路：

记录视频提取的所有帧图片中每一个出现的标签，以及标签出现的次数（有多少帧图片

被打上了这个标签）。按照出现次数排序。

1.将帧图片的最多前n个标签，输出为视频标签。

2.将帧图片中，出现次数大于阈值c的标签，，输出为视频标签。

数据示例：

其中1class表示一级类别，2class表示二级类别。

实验结果示例：

截取一些实验结果展示如下，其中output指模型输出的结果，reference指人工标定的参考结果。

总的来说，游戏类视频的数据量最大，效果较好；但具体不同英雄的视频数据如果不平衡，也会影响算法结果。其他类型视频数据不算太稀疏的效果也不错，长尾视频的效果不行。

总结：

数据预处理、模型结构、损失函数、优化方法等各方面，都还有很多值得根据视频打标签应用的实际情况进行调整的地方。后续再不断优化。方法和实验都还粗糙，希望大家多批评指导。

来源：腾讯QQ大数据

背景

“尊敬的XXX用户，您的话费已不足10元。为了您的正常使用，请及时充值。”

——移动公司

“温馨提示：XXX先生/小姐，您的住房贷款将于11月5日扣款，请在此账号中存足款项。”

——家银行

就算是在尊敬的称谓，就算是再温馨的话语，还是感觉有些冷冰事故，千里追债。

通信和金融业务，算是每个现代人的“刚性”需求。收到催费通知尚且不爽，何况是偏向娱乐的互联网业务催费通知。如何能让人觉得不突兀，稍微有点打动人心的感觉？以3年前某业务合作案例为例，抛砖引玉，与各位一起讨论从数据角度发现数据规律，同样是让用户付费场景，通过挖掘出不同用户的付费G点，以不同群体推送不同文案与图片的方式实现个性化催费，推动业务增长。

数据探索过程中12个字感悟：大胆想象，敢于尝试，小心验证

7步骤完成整个流程

行动

Step 1：大胆想象

和“传统”垄断行业相比，我们有哪些优势？

有数字化的用户数据。以计算机和网络为框架的服务模式，天然将用户属性和行为数字化并记录下来，变成和营收一样，公司最大的资产。

哪种服务是温度的，能打动人心的？

唯有高端私人定制。不管是葛大爷、白百何电影中的“圆梦方案”，还是大众辉腾使馆区的线下定制中心，均体现出浓浓的顶级个性化的感觉，红尘万千，只为伊人。这不正是互联网服务的终极吗？个性服务，千人千面。然而圆梦方案终究灯亮散场，低调辉腾亦低调隐退。

为什么？粒度太细，难以形成规模效益，导致每一单的成本太高，整体盈利太少。催费如果要做到真正千人千面，投入太高，收益暂时难以评估。所以初期尝试，我们化“点”为“面”，粒度不是每个人，而是某类人。

Step 2：数据发现挖掘点

算法+数据 => 增长点

如何化“点”为“面”，识别人群，在事先没有预期目标的情况下，称手的工具就是聚类算法了。

• 1 算法

聚类算法简单来讲，就是把全部对象按照其特征的距离远近，划分成若干簇。这些簇满足以下条件：

1）一个簇内部对象距离近

2）不同簇对象的距离远

类似于上图显示的效果，中心点为集群的核心，围绕中心点近的一批就是同一个簇。很容易分出来不同类别，不同业务特性的群体。分群体运营，比较容易获得更好的效果。

举个例子，比如某个业务的特征包括以下几类，具体应该如何应用聚类算法呢？

• 2 特征标准化

收集完上述行为数据后，需要对数据做“标准化”处理。标准化方式方法很多，这里做一个简单举例。

为什么要做标准化处理？这涉及到聚类算法K-means的实现原理。K-means是一种基于距离的迭代式算法，它将n个观察实例分类到k个聚类中，以使得每个观察实例距离它所在的聚类的中心点比其他的聚类中心点的距离更小。其中，距离的计算方式可以是欧式距离（2-norm distance），或者是曼哈顿距离（Manhattan distance,1-norm distance）或者其他。以我们初中学的欧式距离为例

其中为两个对象的对应特征量，比如都是播放时长，单位为秒。同理为周播放天数。秒的量纲远远大于周播放天数，一首2分钟的歌曲有120秒的播放时长，一周无休播放，也只有7天的播放天数。最终导致播放天数对距离计算影响小，聚类特性偏向播放时长。其他常用的计算距离方法同样存在类似问题，比如：

曼哈顿距离：

闽科夫斯基距离：

解决思路在于无量纲化，方法就是标准化。

我们这次采用的是Z-score标准化，公式如下：

其中x为某一具体分数，μ为平均数，σ为标准差。

标准分数可以回答这样一个问题：”一个给定分数距离平均数多少个标准差?”在平均数之上的分数会得到一个正的标准分数，在平均数之下的分数会得到一个负的标准分数。

• 3 聚类结果输出与解释

得到三个有业务意义的簇，在三维空间上的投影如下：（由于业务敏感性，忽略具体描述）

可以看到，每种类别在空间中的位置和集中程度都有区别，我们就根据这些差异总结出上面三种类型的不同特点。接下来依据不同特点做不同的催费方式。

Step 3：产品沟通

与产品沟通，推动方案落地。由于业务关系，这里不做累述

说服产品经验技巧：

• 深知运营痛点，瓶颈点

• 成功案例举证（首个案例，靠个人或团队影响力）

• 算法初探举例

Step 4：线上测试

我们需要一种快速的，低成本的验证方法。在整体流程不变，后台接口不变的约束下，有什么替换图片与文档的方法更快速，风险和成本更低呢？通过多次迭代优化，所以最终效果如下：通过改变紫色框中的图片与红色框中的文案，对不同用户群体进行不同图片与文案触达

Step 5：效果跟踪与评估

7天流量灰度测试的结果如下：

• 1 常规的线上实际转化效果对比

衡量指标：成功发送催费消息到支付成功转化率均值

炫耀型：x1%    享受型：x2%    扮酷型：x3%    参照组：c1%

x2 > x1 > x3 > c1

• 2 因素影响显著性论证

好了，看到实验组的均值高于参照组，说明有效果。扩大灰度、发邮件、收工了？那么问题来了，如何知道上述效果是个性化文案导致的，还是环绕周围的随机性造成的？

将这个问题转换为统计学的问题，实验组和参照组的均值差异是显著的？

我们可以使用方差分析来尝试解答。方差分析(Analysis of Variance，简称ANOVA)，又称“变异数分析 ”，是R.A.Fisher发明的，用于两个及两个以上样本 均数差别的显著性检验 。

工具我们使用喜闻乐见的R，套路如下：

由此我们可以大致认为，不同组的均值差异受不可控随机因素影响的可能性小，差异来自可控因素，基于用户行为的个性化文本的影响。

Step 6：自动化运营

用户数据+模型例行化，各接口联调，部署上线

Step 7：效果监控

通过邮件，短信，QQ，微信等各种形式对效果进行长期监控，关注变化情况及时优化。

参考文献

[1]. Z-score

http://baike.baidu.com/link?url=n2HbtKxAC_wAyGEJMN-D7wwZNg2B3-dFa-0W9W8sAFJWf5BTry5hIAG6RlFWl-zlWNUUJht85XhoLIy4Hg9Gj_

[2]. 归一化

http://baike.baidu.com/link?url=egN4K40qIsxRxknS6uvOlL63MFGx5LCUq12ojBI-3caMRCYAM5WihO_o2t6vHP0rQKfyei-LKVuN7kbg4HExRK

[3]. K-means

http://www.cnblogs.com/bourneli/p/3645049.html

[4]. 方差分析

http://baike.baidu.com/link?url=-OkUo0mu0bfo9-F9PjvVXR5rdk02I16lJT3UHXDy0I66je4e0t2s-8dpAHW6FxYWf8m36hP-Bs69CJMH-MUJ-lyrRtqbKB9nFQZ0qregXmNvqO0deQNEOT4w_RJ9EaNw

场景分析：

推荐场景一般可以抽象为：内容（Item）和受众（User），其中内容主要是指要推荐的Item，在购物场景中Item就是商品，歌曲推荐中Item就是歌曲，受众是访问当前场景的用户，一般是自然行为人；推荐模型一般是计算不同的User-Item对的得分，这个得分反映的是用户点击当前物品的概率，获取得分最高的Top n的Item推荐给用户，所以整个特征关联模型可以抽象为如下图-1所示：

图-1 推荐系统关系模型

其中，可以分解为如下几部分：User-Item特征、User特征、Item特征、User-Item属性分布特征，下面具体阐述每种特征的构造方法。

User-Item特征：

User-Item特征主要从三个维度来刻画User对Item的“兴趣”，如图-2所示：

图-2  User-Item类型的特征构造

1）时间序列上的统计特征：

统计特征从四个角度（绝对值，相对值，是否感兴趣和深度感兴趣）来刻画User对Item的“兴趣”。比如，时间序列中User累积对某个Item的行为次数就是User对Item的绝对兴趣值：如果时间序列分为：一天、三天、一周（实际中时间还需要继续拉长一点来刻画用户长期的兴趣），行为是“点击”。那么这一个特征构造语句就可以翻译成三个不同的特征：分别是最近一天，三天和七天用户对每个Item的点击次数；时间序列上User对Item是否有重复的行为用来刻画和区分哪些Item是对User有深度吸引力的，如果在一段时间上只发生了一次行为，那么很可能User对这个Item并没有兴趣，只是随便看看；时间序列上User对Item是否有行为，用来刻画User过去某一段时间用户的关注点在哪里，对哪些是可能喜欢的，和上面的一条特征的区别在于可以涵盖用户可能比较感兴趣的Item并且这样用户兴趣特征也会更加丰富。

2）时间特征：

时间特征从三个角度（最近时间，行为频度，行为稳定性）来刻画用户对于Item的兴趣在不同时间上的活跃度。比如，User对Item的最后行为时间，可以翻译成一个时间特征，可以将这个时间进行归一化为一个0—1的标量，越接近于1表示User对这个Item具有越强的新鲜度；User对某个Item的平均行为时间间隔用来刻画User对Item的活跃频率，时间间隔越小说明对用户的吸引力越大。User对Item的行为时间间隔方差可以用来刻画User对Item的喜好的稳定性。

3）趋势特征：

趋势特征主要刻画用户对某个Item的兴趣趋势。比如，User一天对Item的行为次数/User三天对Item的行为次数的均值，表示短期User对Item的热度趋势，大于1表示活跃逐渐在提高；三天User对Item的行为次数的均值/七天User对Item的行为次数的均值表示中期User对Item的活跃度的变化情况；七天User对Item的行为次数的均值/ 两周User对Item的行为次数的均值表示“长期”（相对）User对Item的活跃度的变化情况。

User特征：

User特征主要包括用户的属性特征以及从多个方面刻画用户的“活跃度”，User类型的特征构造方法如图-3所示：

图-3  User类型的特征构造

时间序列的统计特征：

主要从三个维度（User总活跃，用户深度活跃，用户对于Item的覆盖度）来刻画用户的活跃。比如，时间序列上User行为次数总和，在划分成三个时间细粒度的情况下，可以翻译成三个特征，分别是一天，三天和七天User的行为总和，来表示User在当前时间段上的活跃。时间序列上User重复行为次数用来刻画用户真实的活跃深度。时间序列上User有行为的Item的数量，可以用来刻画用户的活跃广度，来表示用户是否有足够的意愿尝试新的Item。

1）时间特征：

主要从三个角度（最近时间，行为频度，行为稳定性）来刻画用户的活跃度。比如，User最后行为时间，时间越接近当前时间说明User的活跃度越强；User的平均行为时间间隔用来刻画User的活跃度，时间间隔越小说明User的活跃度越强。User的行为时间间隔方差可以用来刻画User活跃的稳定性。

2）趋势特征：

趋势特征用来刻画User的活跃趋势。比如，User一天的行为次数/User三天的行为次数的均值，表示短期User活跃趋势，大于1表示活跃逐渐在提高；三天User的行为次数的均值/七天User的行为次数的均值表示中期User的活跃趋势；七天User的行为次数的均值/ 两周User的行为次数的均值表示“长期”（相对）User的活跃趋势。

3）属性特征：

主要用来刻画用户的一些属性特征包括性别、年龄、学历以及使用机型等。

Item特征

Item特征主要包括Item的属性特征以及从多个方面刻画Item的“热度”，Item类型的特征构造方法如图-4所示：

图-4  Item类型特征构造

1）时间序列的统计特征：

从三个维度（Item的行为热度，热度趋势和时间间隔）来刻画Item的热度。比如，时间序列上Item行为次数总和，在划分成三个时间细粒度的情况下，可以翻译成三个特征，分别是一天，三天和七天Item的行为总和，来表示Item在当前时间段上的热度。时间序列上Item被重复点击次数用来刻画Item真实的热度深度，尤其在APP的推荐上，重复的使用或者点击说明当前APP对用户的吸引力越强。时间序列上和当前Item发生行为的User的数量（去重）刻画了Item的热度的广度。时间序列上Item的点击和曝光的比值（User不去重）—CTR，刻画了Item在相同曝光下被点击的概率。时间序列上Item的点击和曝光的比值（User去重）—CTR，刻画了Item在相同曝光下被点击的概率，剔除了某些特殊情况某个User对某个Item的行为过于集中的情况。

2）时间特征：

主要从三个角度（最近时间，行为频度，行为稳定性）来刻画Item的热度。比如，Item最后行为时间，表示Item的最近活跃；Item的平均行为时间间隔用来刻画Item的热度，时间间隔越小说明的热度越高。Item的行为时间间隔方差可以用来刻画Item热度的稳定性。

3）趋势特征：

主要刻画Item的热度和CTR的趋势。比如，Item一天的行为次数/Item三天的行为次数的均值，表示短期Item的热度趋势，大于1表示热度逐渐在提高；三天Item的行为次数的均值/七天Item的行为次数的均值表示中期Item的热度趋势；七天Item的行为次数的均值/ 两周Item的行为次数的均值表示“长期”（相对）Item的热度趋势。另外一种特征表示CTR的趋势：其中一天的Item的CTR / 三天Item的CTR表示“短期”Item的CTR趋势信息。

4）属性特征：

主要用来刻画Item的一些属性特征主要包括所属的类别。

User和Item之间的属性分布特征：

主要通过计算在不同时间段上User和Item之间的行为的统计特征：如果当前的User的属性包括：性别、年龄和Device，Item的属性包括：Item_id和类别，那么特征构造方法如图-5所示：

图-5  User和Item之间属性分布特征构造

1）时间序列上Item在Age的分布特征：

通过计算Item在年龄段上的行为数量（User不去重和不去重）来刻画Item在不同年龄段上的热度；Item在年龄段上的行为数量/Item总的行为数量来表示User在年龄上的热度分布；Item在不同年龄段上的点击和Item在相应的年龄段上的曝光之间的比值来刻画Item在不同的年龄段上的CTR。

2）时间序列上Item在Gender的分布特征：

通过计算Item在性别上的行为数量（User不去重和不去重）来刻画Item在不同性别上的热度；Item在性别上的行为数量/Item总的行为数量来表示User在性别上的热度分布；Item在不同性别上的点击和Item在相应的性别上的曝光之间的比值来刻画Item在不同的性别上的CTR。

3）时间序列上Item在Device的分布特征：

通过计算Item在不同Device上的行为数量（User不去重和不去重）来刻画Item在不同Device上的热度；Item在不同Device上的行为数量/Item总的行为数量来表示User在Device上的热度分布；Item在不同Device上的点击和Item在相应的Device上的曝光之间的比值来刻画Item在不同的Device上的CTR。

4）时间序列上User在ItemType上的分布特征：

通过计算User在不同的ItemType上的行为数量来刻画Use对不同的ItemType的喜好，计算User在不同的ItemType上是否有行为来刻画在时间段上User是否对当前的Item的类型感兴趣，计算User的行为在不同的Item上的分布来刻画对不同的ItemType的喜好程度。User在一段时间内，是否在ItemType上有重复行为，来刻画用户是否对当前ItemType深度感兴趣。

5）时间序列上ItemType在Age上的分布特征：

通过计算ItemType在不同年龄段上的行为数量（User不去重和不去重）来刻画ItemType在不同年龄段上的热度；ItemType在不同年龄段上的行为数量/ItemType在年龄段上的用户数量来刻画当前ItemType对这个年龄段的User的吸引程度；ItemType在不同年龄段上的点击和ItemType在相应的年龄段上的曝光之间的比值来刻画ItemType在不同的年龄段上的CTR。

6）时间序列上ItemType在Gender上的分布特征：

通过计算ItemType在不同性别上的行为数量（User不去重和不去重）来刻画ItemType在不同性别上的热度；ItemType在不同性别上的行为数量/ItemType在当前性别上的行为用户数量来刻画当前ItemType对这个性别的User的吸引程度；ItemType在不同性别上的点击和ItemType在相应的性别上的曝光之间的比值来刻画ItemType在不同的性别上的CTR。

上面列举了一些常见属性之间的分布特征，都是User针对Item或者Item针对User的统计分布，这些只是大部分场景中会出现的场景，在具体的业务中可以根据实际可以获取到的属性结合和样本之间的相关性来进行建模。

特征选择：

在实际的业务中，首先需要思考的是如何正确的构建样本对，在恰当的样本对构造的基础上思考和样本标签具有相关性的因素，这些因素包括用户和物品侧，找到这些因素之后才是特征构建，不同的场景和算法情况下需要不同的特征选择：比如说游戏推荐中活跃时长、付费意愿很重要，而弱化了在性别上的分布，因为游戏属于用户粘性比较大的类型，在商品推荐中性别分布和浏览、加购物车行为则同等重要，因为用户的性别和用户之间的兴趣有很强的相关性；对于不同的算法同样也需要不同的特征体系，对于逻辑回归这种解释性很强的线性模型，通常需要根据建模场景选择特征的细粒度，然后生成和样本具有相关性的特征，获取相关性最直接的方法是对特征进行特征交叉，而对于树模型或者FM模型，理论上则不需要进行特征交叉，因为模型本身就具有了特征的交叉能力。总之，合适模型加上适配的特征特征体系才能获得较好的效果。

小结：

特征工程通常在算法调优中占据了大部分的时间，本文旨在通过梳理推荐系统中常用的特征构造方法，实现快速的特征构造。本文主要是面向初涉推荐系统的同学，可以快速构造一些简单有效的特征，同时，本文提到的一些特征构造方法在某些场景下是冗余的，并不能带来新的信息，所以在实际的应用场景中还需要根据需求进行选择。

附录：

整体特征构造框架如图-6所示：

图6 特征构造框架

1 问题 

1.1 某业务拉新场景—冷启动决策问题

拉新场景是指在大流量业务场景中投放拉新业务的相关优质内容，从而吸引用户访问，快速增加用户量。这个拉新场景需要从4千+专辑池(每日会加入一些新的物品)中挑选出两个专辑投放给用户，使用这两个专辑来吸引新用户，从而达到拉新的目的。由于是投放给新用户，所以没有历史行为数据作为依据去推测该用户喜欢什么。能够依赖的数据包含专辑本身的特征，如：分类信息、更新时间等，用户的画像数据(达芬奇画像维护和挖掘了用户的基本画像数据)，如：年龄、性别、地域等。开始时，我们使用传统的机器学习模型，如LR、FM等，将每日拉新用户量做到了5千-1.1万。这里存在的问题是，传统机器学习非常依赖正负样本的标注。对于某些新物品，如果它从来没有被曝光，那么它永远也不可能被标记为正样本，这对于新物品来讲是不公平的，也是推荐领域不愿看到的现象。一种比较直接的做法是，保留一股流量专门用来做新物品的探索，但是这里又会有一些新的问题产生，如：这股流量用多大？探索的时机该怎么把握？新物品中每一个物品曝光多少次、曝光给谁是最合适的？如何保证整体收益是最大的， 等等一系列问题，而MAB(Multi-armed bandit problem，多臂老虎机)方法正是解决这类决策问题的。所以我们尝试使用MAB的思想来解决新用户和新物品的推荐问题。事实证明，该方法是可靠的，使用MAB中的UCB算法之后，该拉新场景每日拉新量提高到最初base的2.3倍。

1.2 短视频推荐结果多样性控制

短视频推荐场景的特点是在保质的前提下，需要向用户推荐有创意、多样的、新鲜、热点等不明确讨厌的短视频。从直观的体验结合相关流水统计分析来看，用户非常反感连续推荐同一主题的短视频，所以需要使用一定的策略来对多样性进行控制，提高用户体验，尽可能把用户留下来。在腾讯内部某短视频推荐场景中，我们使用MAB中的Exp3算法来进行多样性控制。事实证明，Exp3用在探索新用户的兴趣场景下，与随机、Thompson sampling等方法对比，视频平均观看时长提升了10%，对于老用户增加了推荐结果的多样性，视频平均观看时长略有提升。

2 神盾如何解决拉新场景的冷启动问题

2.1 MAB如何解决决策问题

在说明神盾如何解决冷启动问题前，这里先对MAB问题做一个综述性的介绍。

什么是MAB问题？

MAB的定义非常有意思，它来源于赌徒去赌场赌博，摇老虎机的场景。一个赌徒打算去摇老虎机，走进赌场一看，一排排老虎机，外表一模一样，但是每个老虎机吐钱的概率可不一样，他不知道每个老虎机吐钱的概率分布是什么，那么想最大化收益该怎么办？这就是MAB(多臂赌博机)问题。怎么解决这个问题呢？最好的办法是有策略的试一试，越快越好，这些策略就是MAB算法。

推荐领域的很多问题可以转化为MAB问题，例如：

1. 假设一个用户对不同类别的内容感兴趣程度不同，那么我们的推荐系统初次见到这个用户时，怎么快速地知道他对每类内容的感兴趣程度？这就是推荐系统的用户冷启动问题。

2. 在推荐场景中，往往会有多个算法或模型在线上做A/B Test，一般情况下我们会把流量按照一定比率来进行分配，而在不同的时间点，不同的算法线上效果往往是不一致。我们期望每时每刻都能把占比大的流量分配给效果最好的算法。有没有比A/B Test更合适的流量分配方法来让业务的收益最大化？

可以看到全部都属于选择问题。只要是关于选择的问题，都可以转化成MAB问题。在计算广告和推荐系统领域，这个问题又被称为EE问题（Exploit-Explore问题）。Exploit意思是，用户比较确定的兴趣，要尽可能的使用。Explore意思是，要不断探索用户新的兴趣，否则很快就会越推越窄。

MAB的数学表述：

• A．设共有k个手柄（对应拉新场景中的k个专辑）
• B．k个手柄的回报分布<D1,D2,D3……Dk>（对应拉新中，专辑推荐带来的新用户量的分布情况）
• C．回报均值 u1,u2……uk（对应每一个专辑在以前的实验的平均收益）
• D．回报方差 v1,v2……vk（对应每一个专辑每一次实验收益的稳定性）
• E．最佳手柄平均收益

• F．T轮之后的Regret值 ，使用一定的算法策略使得其T轮之后最小

Rt是后悔值，T表示实验轮数，u*最佳手柄平均收益，ut表示t时刻，所选手柄的收益

MAB问题目前常用算法：

1. 朴素选择算法：其思想是对于每个手柄都进行k次实验，选择出平均收益最高的手柄。在之后的所有手柄选择中都选择这个最好的。

2. Epsilon-Greedy算法(小量贪婪算法)：每一轮在选择手柄的时候按概率p选择Explore（探索），按概率1-p选择Exploit（历史经验）。对于Explore，随机的从所有手柄中选择一个；对于Exploit，从所有手柄中选择平均收益最大的那个。

3. Softmax算法：该算法是在Epsilon-Greedy算法的基础上改进的，同样是先选择是Explore（探索）还是Exploit（原有）。对于Exploit阶段，与Epsilon-Greedy算法一致。对于Explore，并不是随机选择手柄，而是使用Softmax函数计算每一个手柄被选中的概率。armi表示手柄i，ui表示手柄i的平均收益，k是手柄总数。

4. UCB(Upper Confidence Bound)算法：通过实验观察，统计得到的手柄平均收益，根据中心极限定理，实验的次数越多，统计概率越接近真实概率。换句话说当实验次数足够多时，平均收益就代表了真实收益。UCB算法使用每一个手柄的统计平均收益来代替真实收益。根据手柄的收益置信区间的上界，进行排序，选择置信区间上界最大的手柄。随着尝试的次数越来越多，置信区间会不断缩窄，上界会逐渐逼近真实值。这个算法的好处是，将统计值的不确定因素，考虑进了算法决策中，并且不需要设定参数。在选择手柄时，一般使用如下两个公式进行选择：

t表示t时刻或者t轮实验，arm(t)表示t时刻选择的手柄， ui均值表示手柄i在以前实验中的平均收益，ni表示手柄i在以前实验中被选中的次数。α是(0,1)为超参数，用以控制探索部分的影响程度。

“选择置信区间上界最大的手柄”这句话反映了几个意思：

如果手柄置信区间很宽（被选次数很少，还不确定），那么它会倾向于被多次选择，这个是算法冒风险的部分。

如果手柄置信区间很窄（被选次数很多，比较好确定其好坏了），那么均值大的倾向于被多次选择，这个是算法保守稳妥的部分。

UCB是一种乐观的算法，选择置信区间上界排序。如果是悲观保守的做法，是选择置信区间下界排序。

5. Thompson sampling：该算法跟UCB类似，Thompson sampling算法根据手柄的真实收益的概率分布来确定所选手柄。假设每个臂是否产生收益，其背后有一个概率分布，产生收益的概率为p。不断地试验，去估计出一个置信度较高的概率p的概率分布就能近似解决这个问题了。 假设概率p的概率分布符合beta(wins, lose)分布，它有两个参数: wins, lose。每个臂都维护一个beta分布的参数。每次试验后，选中一个臂，摇一下，有收益则该臂的wins增加1，否则该臂的lose增加1。每次选择臂的方式是：用每个臂现有的beta分布产生一个随机数b，选择所有臂产生的随机数中最大的那个臂去摇。

以上算法优缺点：

1. 朴素选择算法需要为每一个手柄准备合适次数的实验，用以计算每个手柄的平均收益，并不适合物品快速迭代的场景，同时会浪费大量流量。

2. Epsilon-Greedy算法与Softmax算法有一个很明显的缺陷是它们只关心回报是多少，并不关心每个手柄被拉下了多少次。这就意味着，这些算法不再会选中初始回报特别低的手柄，即使这个手柄的只被测试了一次。而UCB算法，不仅关注回报，同样会关注每个手柄被探索的次数。Epsilon-Greedy and Softmax的特点，默认选择当前已知的回报率最高的手柄，偶尔选择那些没有最高回报的手柄。

3. Thompson sampling。UCB算法部分使用概率分布（仅置信区间上界）来量化不确定性。而Thompson sampling基于贝叶斯思想，全部用概率分布来表达不确定性。相比于UCB算法，Thompson sampling，UCB采用确定的选择策略，可能导致每次返回结果相同（不是推荐想要的），Thompson Sampling则是随机化策略。Thompson sampling实现相对更简单，UCB计算量更大（可能需要离线/异步计算）。在计算机广告、文章推荐领域，效果与UCB不相上下。

LinUCB算法：

以上介绍的MAB算法都没有充分利用上下文信息，这里所说的上下文信息包括用户、物品以及其他相关环境相关的特征。而LinUCB算法是在UCB算法的基础上使用用户、物品以及其他相关环境相关的特征来进行UCB打分。LinUCB算法做了一个假设：一个Item被选择后推送给一个User，其回报和相关Feature成线性关系，这里的“相关Feature”就是上下文信息。于是预测过程就变成：用User和Item的特征预估回报及其置信区间，选择置信区间上界最大的Item推荐，然后依据实际回报来更新线性关系的参数。

相关论文中(见附件)提出两种计算办法，这里将论文中算法伪代码贴出来，方便大家阅读，详情请查阅附件论文。

 

 

2.2 神盾推荐如何使用UCB来解决拉新场景推荐问题

神盾在UCB算法的基础上，尝试为其添加上下文环境信息，该环境信息主要包括用户画像、物品画像、环境信息（时刻，节假日，网络环境）等，因此将其命名为PUCB(Portrait Upper Confidence Bound)。该算法包括两部分，第一部分使用用户已有的行为数据生成物品在某些画像特征下的UCB得分(该分数综合考虑物品的历史平均收益和潜在收益)。第二部分使用预训练好的分类器，在对user-item pair打分时，将原有特征值替换为UCB打分，然后计算最终的打分。

UCB打分

数据准备阶段

图 1 神盾PUCB-数据准备阶段示意图

该阶段的目的是确保使用用户行为数据和画像特征数据生成所需时间窗口下的【画像，物品ID，行为统计数】。这部分神盾在实现时，考虑了一些容错机制，如：当历史时刻数据不存在时，是否可以根据已有时刻的行为数据和已有时刻的【画像，物品ID，行为统计数】统计数据来重新生成等等。

统计打分阶段

使用公式6，基于时间窗口内的数据，采用一定的衰减策略来计算ucb分。对某一物品某种画像进行ucb打分。其中i表示物品ID，j表示画像特征MD5编码，cij 表示t时刻j特征编码的物品i的点击量，Cij 表示历史时刻j特征编码的物品i的点击量，λ表示新行为对得分的影响程度，λ越大表示最新行为越大，反之亦然，eij表示t时刻j特征编码的物品i的曝光量，Eij表示历史时刻j特征编码的物品i的曝光量，e为无意义初始值防止分母为0，Thj表示当前时刻j特征编码的物品总的曝光次数，Taj表示历史时刻和当前时刻所有专辑j特征编码的物品总的曝光数，α表示bonus项用于探索物品的权重，α越大越容易出新物品。

 

是否需要对Cij，Eij，Taj全部进行衰减，如下公式为计算历史数据的公式。d(t)表示t时刻的统计量，d’(i)表示i时刻的实际统计量，f(|t-i|)表示时间衰减函数，θ表示时间衰减参数，新时刻行为的影响越大，就应该跳大θ，反之亦然。

伪代码如下：

doStatistic()

Input: 历史时刻物品-画像曝光点击统计数据hisFirstItemPortraitStatis

(t-w+1, t)时刻物品-画像曝光点击统计数据otherItemPortraitStatis

isUseDefaultValue历史时刻数据是否使用默认值

toolItemID池子所有物品ID

Output: itemPortraitUCBScore  ItemID，画像MD5的ucb得分

1 if  isUseDefaultValue  then

2 向hisFirstItemPortraitStatis补充缺失的物品曝光和点击数据（使用默认值）

3 hisRDD，realRDD←对hisFirstItemPortraitStatis，otherItemPortraitStatis分组合并统计

4 itemPortraitUCBScore  ← 使用上述公式计算ucb得分

5 return itemPortraitUCBScore

分类器糅合UCB打分

经过上述处理之后，我们会得到图2所示信息，其中owner列为特征值，primary_key为历史实时行为标记，secondary_key为物品ID，value为统计到的次数。

图 2 PUCB算法中间统计结果-示例图

 

换句话说，经过上述处理，我们将原始的特征抽象为UCB得分，接下来需要做的事情是使用一定的策略将不同维度的信息糅合起来。论文中使用了岭回归的方式来为每一个特征维度计算权重，神盾这里设计的比较灵活，可以使用任意一种分类器（如:LR、FM等）来糅合最终的结果，需要注意的是该分类器所使用的特征应该跟计算UCB打分的特征体系一致。

3

神盾如何保证短视频推荐场景中的多样性

 

3.1 exp3多样性保证

Exp3(Exponential-weight algorithm for Exploration and Exploitation)算法是2001年提出来的一种解决MAB问题的算法。它的核心思想是维护一组臂的权重信息，然后使用数学方法得到一组臂的概率分布，接着每次掷骰子去选择臂，根据选择后观察到的收益情况去调整臂的权重，如此迭代下去。论文中证明了使用这种策略能够保证后悔值的在一定可以接受的范围内，从而保证了结果不会是最坏的一种情况。

Exp3算法伪代码如下：

ϒ是一个超参数，值域为[0,1]，可以采用固定值，在实验轮数确定的情况下，建议使用公式9来计算ϒ，其中K为臂的个数，T为实验的轮数。

 

首先为每一个臂初始化权重为1，然后使用算法1步骤中的公式计算每一个臂的概率，该公式保证了所有臂的概率和为1，接着随机出一个[0,1]之间的值，观察该值落在哪个臂中，选择之后观察该臂的收益情况，使用公式11计算其预估收益。

使用公式12来更新权重。

该算法在计算臂的概率时，虽然有可能趋向于0，但是不会等于0，所以对于任意一个臂，都有机会被选中，只是收益高的臂更容易被选中，收益低的臂更不容易被选中。

3.2 神盾推荐如何应用exp3来做多样性控制

图 3 神盾Exp3算法流程

1. 首先规划Exp3的臂策略，最简单的臂策略为不同的召回策略，复杂一些可以按照一定的业务规则来对物品进行重分桶，如：在短视频推荐中按照物品类别信息（游戏、风景、美女等）构建了20+个臂。

2. 在tesla(腾讯内部集群任务调度系统)上配置Spark Streaming任务，这个任务的目的是分钟级消费TDBank业务数据，按照业务规则构建正负反馈数据，然后使用一定的更新策略来更新权重。神盾推荐在这里设计了三种权重更新策略。

a.原版算法更新策略，使用每条反馈数据来更新。这里存在的问题是由于TDBank数据收集，近线训练和线上服务链条较长，近线训练的结果不能非常实时的推送到线上去，存在一定的误差。

b.小batch更新策略，收集一段时间的数据（神盾使用1分钟的数据）对每个臂的收益值做归一化，然后更新算法参数。与a相比，优点是权重更新更加稳定，缺点是收敛速度相对比a缓慢。

c.在b的基础上引入窗口概念，会周期性的使用初始值来重置算法参数。

其他：在实际推荐业务场景中可以依照实际的应用情况，对正负反馈构建，权重更新策略，为每位用户构建Exp3选择器等。

3. 推送计算参数到Kafka Server，更新R2线上算法参数。

4. 神盾推荐在短视频推荐上应用Exp3的结构如下图所示，可以看到exp3被应用在ReRank层，每一个臂都可能被摇到，同时从数学角度保证整体选择的收益肯定远高于最坏情况，进而在保证多样性的同时，整体收益高于最坏收益。

图 4 神盾推荐短视频推荐上Exp3算法结构示意图

 4 总结

综合上述场景的实际应用情况，说明在面临用户或物品冷启动的情况时，值得使用PUCB的方法进行尝试，而内容类对多样性有要求的场景，可以尝试使用Exp3来解决。

本文所述MAB方法的经验来自组内所有同事在实际业务中的总结。欢迎大家交流讨论！

参考资料：

exp3数学推导： https://jeremykun.com/2013/11/08/adversarial-bandits-and-the-exp3-algorithm/

Python版demo：https://github.com/j2kun/exp3

https://zhuanlan.zhihu.com/p/21388070

http://blog.csdn.net/scythe666/article/details/74857425

http://x-algo.cn/index.php/2016/12/15/ee-problem-and-bandit-algorithm-for-recommender-systems/

Adversarial Bandits and the Exp3 Algorithm

来源：腾讯QQ大数据

写在前面

本文介绍了神盾推荐系统中基于热传导模型的相关推荐模块. 神盾推荐系统是 SNG 数据中心立身 QQ 大数据构建的通用化推荐平台. 服务于应用宝, 手Q手游推荐, 企鹅 FM 等多个应用场景, 为业务方提升收入, 提高用户体验做出巨大贡献.

代号说明

神盾的基于热传导模型的相关推荐模块的代号是 “反浩克装甲” (Hulk Buster), 来源于”复仇者联盟2” 中钢铁侠开发用来对抗绿巨人浩克的专用装备. 其以模块化思路设计, 平时运行在近地轨道中, 有需要的时候可以分散投射到战场组合使用.

反浩克装甲

神盾推荐的反浩克装甲起步于应用宝的推荐场景, 其后在企鹅 FM 的相关推荐场景上进行了快速的迭代升级. 最终取得对比原始 ItemCF 超过 25% 的效果提升.

什么是相关推荐？

在推荐系统发挥用武之处的各个场景中, 相关类的推荐是一个比较常见的场景. 其要面对的场景可以定义为：用户在找到自己喜欢的东西并进行消费的时候或者消费行为完成之后, 对用户展示一些相关的物品以便用户继续消费.

这可以是电台 app 里面的 “收听过这个电台的用户还听过…”, 也可以是书城里面的 “看了又看”, 也可以是视频网站里面的 “相关视频”. 通过相关推荐, 我们可以为用户提供更好的浏览体验, 并把用户和更多的服务连接起来.

应用宝和企鹅 FM 的相关推荐场景

怎么推荐相关物品

本文讨论的问题是基于物品相关的解决方案：针对每一个待推荐的物品计算一个相似物品列表, 然后在用户访问的时候, 拉取相似度最高的几个物品用于展示.

这种方法的特点是每个用户的推荐结果是一样的, 是一种非个性化的解决方案. 由于所需存储资源和内容库里面的物品数量相关, 因此好处在于能够节省资源, 避免用户增长带来的成本问题. 而且只要物品相似度模型建好了, 用户体验都能够达到令人比较满意的程度. 但这种方法只适合物品数量不会爆发式增长的场景, 例如应用宝的应用推荐, 或者视频网站的视频推荐. 另外, 其毕竟是一个非个性化推荐算法, 每个用户看到的内容都是一样的, 从而推荐效果存在较低的天花板.

神盾的相关推荐方法

1 以图计算的思维做推荐系统

物品相关算法最经典的应该是 ItemCF 算法. 但在神盾的相关推荐场景中, 我们大量使用了周涛1提出的热传导算法, 因为其在我们大量线上实验中获得了更好的推荐效果.
但在此我们更想强调算法背后的复杂网络思维. 这个算法把推荐实例中的用户和待推荐物品的关系类比为二分图, 当用户对物品的行为有操作的时候, 我们就可以在中间连一条线. 通过构建用户 – 物品二分图, 我们可以认为被同一个用户操作过的物品是相互关联的. 这种把问题看做一个图的研究视角, 给我们之后的进一步优化提供了便利.

通过把用户和物品当作网络上的节点的形式, 我们可以更直观的思考推荐

2 离线训练先行，在线a/b test验证

ItemCF 等物品相关算法, 大多都是根据用户的行为利用统计方法计算得到, 并不是根据某个目标函数朝着最优解优化. 在实际的推荐场景中实现某个优化项的时候, 我们通常会面临许多超参数的选择. 例如, 要选择多长时间的用户行为去构建二分图, 或者热传导算法参数的选择. 有时候囿于流量我们可能没有办法把每一个候选集合都试一遍, 因此在实际操作中我们会构建一个离线训练场景, 用于调试新的算法特性, 然后推到线上用 a/b test 去验证.

至于离线场景的构建, 一般是利用用户的实际流水, 看相关推荐的结果是否能够预测用户的下一步行动. 这里的技巧在于, 构建离线训练场景之后需要依此在线上投放几次 a/b test, 以验证线下场景的有效性.

神盾的反浩克装甲

为了获得更精准的推荐结果, 神盾推荐团队在热传导模型的基础上做了大量的努力, 最终得到现在的代号为反浩克装甲的相关推荐模块. 下面介绍该模块的主要特性:

1 热传导算法 — 均衡长尾与热门的桥梁

▲  引入热传导, 调整热门和冷门物品的权重, 平衡推荐的精确度和多样性.

在热传导算法的论文中, 作者强调该算法能够平衡推荐的精确度和多样性, 能够在保证精确度的情况下, 让长尾物品的相关度靠前. 在实际操作中, 我们可以利用算法的参数, 调整 “冷门” 和 “热门” 物品的权重, 从而适应不一样的场景. 例如, 我们发现相比应用宝的 app 推荐, 企鹅 FM 的电台相关推荐应该要用一个更加偏向冷门的权重.

热传导算法1实际上是两种能量传递模式的组合, 一个倾向于推荐流行物品, 另一个倾向于推荐冷门物品. 图片来源2

2 用户和物品的有效链接 — 避免错进错出

 

▲  用户和物品的链接, 应该是建立在用户真正喜欢这个物品的基础上

在用户 – 物品的二分图上, 边的定义是第一步, 也是最重要的一步. 因为有一些用户操作可能并不代表用户真正喜欢这个物品, 盲目投入用户对物品的所有操作行为, 可能会出现 “Garbage In Garbage Out” 的情况. 因此神盾团队在构建推荐算法时, 会分析先行, 用数据确定什么情况下用户和物品才能够有一条链接.

以企鹅 FM 为例, 我们统计企鹅 FM 用户收听比例 (收听时长/节目总时长) 的分布, 发现用户收听行为主要集中在两类, 一类是收听比例<10%, 一类是收听比例>90%. 我们可以认为, 如果用户收听一个节目不足总时长的 10% 就停止播放了, 那么很有可能他们并不喜欢这个节目, 把这些数据投入算法可能会造成不好的影响, 因此在构建二分图前去掉.

3 物品度过滤 — 工欲善其事必先利其器

▲  过滤用户数较低的物品, 让推荐更有把握, 多阈值融合, 保证覆盖率.

如果一个物品只被一个用户喜欢, 按照热传导的逻辑, 这个用户喜欢的其他物品会出现在这个物品的相关列表中. 但这样实际上很容易把不相关的东西联系在一起, 因为一个用户的兴趣可能非常广泛. 因此, 有必要过滤掉一部分用户数较少的物品.

度小于一定阈值的节点将会被被隔离在训练之外, 取阈值为2, Item3 会在训练前被舍去

以用户 – 物品二分图的视角来看, 喜欢某个物品的用户数量, 就是这个物品的度, 在我们看来, 这个度的越大意味着它的推荐结果越有把握. 对物品的过滤, 实际上就是把度较低的物品进行一次过滤.

支持度过滤阈值越大, 对推荐结果的把握也越大, 但是能够获得推荐结果的物品的数量就会越少. 为了保证覆盖率, 可以分别用两个阈值训练出两个模型, 然后用低阈值的结果给高阈值的结果做补充.

4 多特征融合 — 尺有所短, 寸有所长

▲  融合用户和物品的属性及不同行为的行为特征, 能提高推荐的覆盖率, 解决冷启动问题, 充分发挥不同特征的数据价值.

在推荐中, 一般除了用户在应用内的行为数据之外, 我们还能够获得其他的一些信息. 例如用户的基础画像, 或者物品的基础信息. 但热传导算法的作者并没有提出如何把多种特征融合到模型中.

这里我们采用了大特征的概念3, 把特征本身当作一个节点加入到二分图中. 例如, 我们可以把企鹅 FM 里面的专辑分类当作一个 “用户”, 专辑对某个分类的隶属关系, 在二分图中可以看做某个分类 “喜欢” 这个专辑. 用户的属性依然, 我们能够把性别(男/女)当作一个物品, 引入到二分图中.

用户的特征被当做一个物品加入到二分图中, 物品的特征则看做一个用户, 此时冷门 Item4 也能获得关联

这样做有一个好处, 就是能够提高推荐的覆盖率, 让一些没有用户操作过的冷门物品(或者新物品)也能够通过物品的基础属性(例如分类)连接起来. 从而能够解决冷启动问题. 但通过简单的推导可以发现, 如果有一个物品没有用户操作行为数据, 只有一个”分类”属性, 那么在热传导算法的推荐结果中, 它会给出同分类最冷门的物品, 也就是另一个没有用户操作行为的物品. 这实际上不怎么合理. 这里的解决办法有二, 一个是引入更多的物品信息, 让物品尽可能多维度的连接起来, 另一个是做物品度过滤.

5 引入时间因素 — 世事常变，变幻即永恒

▲  利用时间因素, 去掉时间间隔较大的两次用户行为生成的链接.

现有的模型在选定了训练时长后, 会将用户该时间段内形成有效链接的所有物品关联在一起, 这样可能会把一些具有时效性的内容关联在一起. 以企鹅 FM 为例, 用户白天听的 DJ 摇滚和晚上的轻音乐, 躺在床上听的《鬼吹灯》和车上听的交通电台, 都有可能被链接起来.

为了解决这个问题, 我们把用户对物品的操作时间引入到推荐中, 从而让两个物品不再因为时间跨度较大的行为而联系在一起, 这里我们采用的方法是把处在不同时间窗口的用户看做多个节点, 从而强化同一个时间窗口内被操作的两个物品的联系.

用户根据操作日期被看做成多个节点, 从而只有同一天的操作行为会把物品关联起来, 这里 User1 被分割成 9月9日的 User1 和 9月12日的 User1

 

6 引入CTR重排序 — 他山之石, 可以攻玉

▲  可以利用用户对推荐结果的反馈信息, 修正推荐结果.

虽然特征的丰富和模型的优化能够很大的提高推荐的效果, 但我们认为推出看起来不怎么准确的结果仍是很难避免的. 对此我们的一个做法是: 把推荐的结果推给用户, 看看用户是否有点击, 对于用户喜欢点击的物品, 提高它的权重; 对于没有点击的物品, 则降低它在推荐列表中的排序.

为了利用用户的实际行为修正推荐结果, 我们计算了每一个待推荐物品和相关物品的转化率, 然后用转化率对权重进行调整. 而这里需要考虑的是有些相关物品限于槽位并不会被用户看到, 从而无法计算转化率, 这里我们利用了神盾实现的点击转化率平滑4模块, 对点击量过小的物品赋予一个预估的转化率.

7 分群热传导 — 物以类聚, 人以群分

▲  按用户属性分群, 各群分别构建热传导, 开创个性化的相关推荐模型.

在服务资源有限的情况下, 非个性化物品相关推荐能够用较少的资源为海量用户提供服务. 但当资源充足的时候, 我们可以考虑把用户的因素考虑进去. 在神盾推荐系统中, 我们实现了按照用户的基础信息和画像分群投放热传导的推荐逻辑. 具体的思路是针对每个群体训练一个热传导模型, 当用户发起推荐请求的时候, 给出对应群体的推荐结果. 为了发挥 QQ 海量用户画像的价值, 神盾对用户展现的推荐结果, 可以由用户所属不同群的推荐结果进行加权获得

不止是相关推荐

本文介绍了神盾推荐团队这几个月内在相关推荐这个场景下的工作成果. 我们在一个简单的网络的基础上, 构建了一个多层次, 能利用多种数据源的推荐策略. 经过线上数据检验, 这个方法能够获得对比传统 ItemCF 算法超过 25% 的性能提升.

但是相关推荐并不是我们努力把物品更准确的链接起来的唯一目的. 计算物品关联还有其他的用处:

1、物品相关的结果可以直接或者间接的被用于个性化推荐，可以根据用户的历史行为, 找出跟用户历史最为相似的物品, 推荐给用户;也可以把物品相似度看做一个特征, 融入到其他模型中;

2、通过把物品关联起来, 我们可以构建一个物品网络, 对物品网络的分析, 能够让我们更加的了解每一个物品. 例如, 我们尝试把企鹅 FM 的电台通过物品相关构建一个电台网络,在分析中我们发现相似的电台会形成社团, 我们认为这隐含了物品的基础特征.

对企鹅 FM 的音乐分类的物品关联网络进行可视化, 节点大小与被关联次数相关, 颜色为社区发现结果

这两个应用场景, 我们认为将可以有效提升推荐效率以至于我们对用户的理解, 因此非常值得我们进一步探索和研究.

附录：推荐系统中的热传导算法简介

热传导算法是一个利用了复杂系统中热扩散思路计算物品相似度的推荐算法. 该算法的把用户和物品看做两类不同的点, 并把用户和物品的操作看做一条边连起来, 从而生成一个二分图. 算法假定每一个物品都分配了一定的能量, 然后沿着二分图的边, 进行能量的传递, 传递后的能量状态揭示了物品的相关程度.

算法原文探讨了两种能量传递的方法, 可以导出两种不同的物品相似度计算方式:

这里 α和 β是两个物品, aαi=1代表用户 i与物品 α有一条边, aαi=0表示没有. 而 ki=∑αaαi是用户的度, 即连接到用户的边的数目, 类似的 kα为物品的度.

可以看到两个相似度计算方式的差异主要在系数上. kα实际上计算了该物品被多少人操作过, 一定程度上代表了物品的热度. 因此 WαβP的计算方式很好的抑制了物品 α和热门物品的相似程度. 从而会让冷门的物品获得更高的关联得分.而真正的热传导模型, 则是通过引入控制参数 λ来实现兼顾精确度和多样性:

参考文献：

1、Zhou T, Kuscsik Z, Liu J G, et al. Solving the apparent diversity-accuracy dilemma of recommender systems[J]. Proceedings of the National Academy of Sciences, 2010, 107(10): 4511-4515. :leftwards_arrow_with_hook:

2、https://www.zybuluo.com/chanvee/note/21053 :leftwards_arrow_with_hook:

What is指标体系

百度百科的专业定义“评价指标体系是指由表征评价对象各方面特性及其相互联系的多个指标，所构成的具有内在结构的有机整体。”简单来说，就是将统计指标系统性的组织起来。指标体系是由指标和体系两部分组成。指标主要包括：用户数、次数、人均次数、时长、点击率、转换率、渗透率、留存率、成功率等；体系是由不同的维度组成，而维度是指人们观察、思考与表述某事物的“思维角度”，比如：区分不同模块来看用户数，这个模块就是维度。维度是指标体系的核心，没有维度，单纯说指标是没有任何意义的。根据产品灰度和上线的节奏来规划指标体系，如下图指标体系框架。

Why 指标体系

在没有指标体系的情况下，产品看数据遇到很多问题，这些问题都可以通过指标体系来解决：

How to规划指标体系

前期重要准备工作：不断体验产品，熟知产品的基本功能，明确产品的KPI目标和战略重点。按照以下三个步骤来规划整个指标体系：

其中“确认指标和目标是否匹配”也就是确认指标能否100%反映评估目标的变化，如果不完全匹配，则需要反过来修正评估指标，使其完全匹配；下面重点从产品规模质量、健康度、用户属性等6个方面来介绍如何“设计合适的评估指标”：

产品规模和质量

1、整体规模和实时数据监控

整体概况：依赖产品的核心功能以及KPI目标来制定，是对产品整体的监控，后面所有的指标均依赖此项展开。

关键漏斗：对关键概况指标做模块或者路径上的拆分。

实时数据监控：从整体概况中抽取最关键的1~2个指标来做按小时、按分钟监控。主要作用：在新版本发布后监控核心指标变化，便于及时发现版本问题回滚；某类重要活动上线之后的实时效果监控。之所以选择1~2个指标，是因为实时数据的统计对计算资源要求很高，通常选择最关键的指标来做监控，其他指标按天监控即可。

2、产品质量

这部分内容是从14年开始逐渐被产品重视起来，发现产品质量本身也会严重影响用户体验，质量差的产品容易被卸载/取关。质量监控是由各种成功率组成，基础指标包括：crash率、启动耗时、页面加载速度等，这些是每个产品必备的，另外根据产品功能会有其他成功率指标，如直播产品会有播放成功率、直播加载速度等；产品质量与用户自身的网络类型、运营商、机型强相关，所以以上指标的维度通常需要细分这三个维度来看。

用户健康度

1、留存和活跃度

通过留存率、活跃度(活跃天数/次数等分布)来监控产品的健康度，不同产品的监控周期不同，对于高频产品，留存率监控次留、3留、7留，活跃度按周来监控，如果按月来监控，当发现指标下降的时候用户已经流失了，错过了最佳挽留时机；对于低频产品，按月监控即可；可通过看用户的周活跃天数来判断该产品是高频还是低频，通常周活跃天数大于3，是高频产品，反之属低频产品。

2、成长体系

这部分内容仅适用于有增值包月功能的业务。包括vip到期天数分布、vip等级分布、特权使用度以及年费相关；

3、用户流动模型

结合用户生命周期，从新增、留存、回流、流失的角色转化来定义用户在产品中的流动，称之为流动模型；当产品运营到一定的规模，必然要做精细化运营，即用户生命周期管理(CLM)，基于用户当前的行为状态，通过各类预测模型，对其进行精细化运营，来拉长用户生命周期。

渠道质量

这部分内容仅适用于独立app产品，因为独立app需要通过不同渠道去推广引导用户下载安装，不同渠道的用户质量差异比较大，所以需要分渠道来监控；平台资源产品不需要关注这块，如：手Q动态里面的平台资源产品。

监控方式主要是在上面讲到的概况和留存指标上扩展渠道维度。

资源触达

梳理清楚产品的资源位，每个资源位的评价指标类似，即活动效果评估，包含两部分：

a）活动自身的pv、uv和点击率，以及渠道侧的发送、到达、点击整个链条数据；

b）活动给产品带来的价值，从新增、回流、留存上来评估;

用户属性

画像和终端数据是用来详细描述用户本身的属性，明确使用产品的用户是什么样的人群，一方面可以指导产品的设计方向，如：产品设计的目标是针对25岁以上的成熟用户，但实际画像出来发现用户年龄主要集中在20岁以下，与设计理念不符，就得考虑功能设计是不是有问题，得改变方向；另一方面可以作为精细化推荐重要特征。画像的重要性不言而喻，但目前只有社交产品在这块建设相对完善；终端信息通过系统接口均可以获取到。

竞品数据

没有竞争就没有前进的动力。寻找自己的假想敌，对标规模和留存指标，以便评估产品的优势和劣势，不过这部分数据通常不易获取到。

规划完成后必须用以下四个准则来检验指标体系的合理性：

1、完备性：通过指标体系能够对产品的经营状况一目了然；比如产品现在增速如何，现状是否健康等；

2、系统性：通过指标体系能够粗略定位到数据波动的原因；比如活跃用户下降，通过指标体系能够拆解到大概原因；

3、可执行性：指标体系是可量化并实现的；

4、可解释性：所有指标的统计逻辑都是可解释的，容易被用户理解的；经验证明那些复杂不可解释的指标最终都会被淘汰；

Just do it指标体系可视化

在指标体系可视化过程中有几点需求注意：

1、数据上报环节要保证准确性和扩展性强。数据上报不准确，后面的链条做的再好都是无用功，需要开发和测试多方验证保证上报准确性；扩展性强是为了产品扩展功能的时候数据上报框架依旧可用，只需增加某些id即可。另外尽可能把用户的所有操作都做上报，包括操作成功和失败。

2、计算框架最好能够包括中间表建设。一方面使的指标计算逻辑很清晰，且由于中间表的复用性很强，指标计算可以节省大量计算资源；另一方面在后续问题分析过程中，使用中间表要比直接从原始流水简单很多。

来源：腾讯QQ大数据

一、 什么是数据体系

完整的数据体系应该是包含数据系统/数据产品/数据服务等若干个相互联系且基于数据所组成的有机体 —— 本文作者

二、 腾讯的数据架构

也许大家对这金字塔并不陌生，它集成了N多数据同仁的智慧，最终总结出这六层结构。

1. 数据基础平台

笔者所在的数据团队用的数据处理平台是腾讯分布式数据仓库（TDW），它集成了数据存储、计算、机器学习等功能。

2. 数据体系和可视化

有了数据处理平台，那我们统计好的数据需要有系统来呈现给用户，当前笔者用的平台是SNG-数据中心的“腾讯罗盘”。业务的数据体系可以帮助产品经理和分析师更好的理解数据，这块将在后续的文章做重点介绍。

3. 产品与运营分析

当业务发展到一定阶段，单纯的数据监控和统计已经不能支撑其业务发展。这就需要数据分析同学分析产品的用户画像、用户的行为、收入构成等，以便运营同学发现运营中的问题，挖掘潜在的机会点。

4. 精细化运营平台

如果说分析结论是一个指南针，那么精细化运营平台就是一个狙击步枪。它可以准确的帮助运营同学把目标用户提取出来做精细化运营，目前笔者常用的内部工具有：神盾推荐系统、数据提取平台、用户生命周期管理系统。从字面上就能看出来，推荐系统解决了业务千人千面的个性化推荐，数据提取平台给产品经理提供清洗数据、交叉分析的平台，用户生命周期管理系统是产品经理的用户运营平台。

5. 数据产品

市场上有很多的数据产品，比如百度的百度指数、阿里的数据魔方，像SNG有社交指数、宜出行等（感兴趣的可以自行关注公众号）。

6. 战略分析与决策

数据的作用除了帮助提升业务运营效果外，还可以成为领导层做战略规划的依据。比如每到年底，我们会对明年的业务活跃用户数、付费用户数做预测，预测在后续会有详细介绍（见《社交大盘关键指标预测》、《某包月用户数预测》）

三、 SNG数据中心的数据发展历程

笔者所在的数据中心几经变革，从早期的单机收集数据、开发报表到现在的在线实时计算和机器学习，不断的完善数据基础功能、扩展数据的应用场景，进而把数据的价值最大化。

四、 业务的数据体系建设

1. 为什么要有业务的数据体系

先问几个问题：有没有入职一年多了，还不知道部门业务架构？有没有作为骨干员工，还只清楚自己的一亩三分地？有没有做了leader，还不了解业务大盘趋势？

显而易见，业务的数据体系既可以让产品同学了解所在组织的业务架构，也可以让运营同学了解过去一段时间的运营详情，同时为下阶段的运营提前做出规划。

2. 业务数据体系建设的方法论

2.1 “业务体系”

这里更多指的是业务构成。无论是作为一个运营产品经理、数据产品还是BI同学，不了解业务数据体系就像有一本武林秘籍却没有内功心法。想要把数据发挥更大的作用，就需要了解团队里或者部门中其他人在做些什么？有没有可以合作的地方？是否可以把成功的案例拿来套用？

我们先来看看几年前为某包月做的业务体系，详细内容涉及到敏感数据就不展开，有兴趣的同学可以在评论区留言交流

是不是还算清晰？可以很快的了解到包月的业务的模块构成。任何一个增值业务都可以在上图的二级节点里找到自己的位置。

这么构建的两个优点：

a) 即便是多元化和产品更新迭代速度快的产品，也能清晰的了解业务结构

b) 把各个业务从逻辑上划分5大块，如果有一部分出问题，能快速定位

2.1.1 “数据体系”的四要素

这个增值业务的数据体系为什么要这么设计？

a) 业务洞察

这是一个应该问自己的问题，有的同学只关注自己的一亩三分地，很少抬头望望团队在做什么，兄弟团队在做什么，部门在做什么。这是一个组织架构和内容的划分，比如13年的SNG增值产品部（那时候还叫会员产品部）。

从业务角度来划分，她包含了会员、靓号、QQ旋风、QQ游戏加速器、钻皇、MP活动；

从组织架构划分，她有体系运营中心（负责营收、VIP关怀和成长）、个性化中心（气泡、表情、主题等个性化特权）、功能特权中心（手Q阅读、动漫、炫耀类特权）、游戏增值中心（端游、手游、会员的游戏特权）、个人形象中心（QQ秀、购物号等）。

从运营渠道来划分，她有tips、小钱包、邮件、红点、公众号等。

从用户角度来划分，她有VIP等级、成长值、积分等。

b) 数据分类

对一个业务团队来说，用户数和收入是必然关注的两块指标。

活跃：各个业务的DAU、特权活跃、平台活跃、各渠道流量、页面漏斗转化等

付费：收入金额、ARPU、付费转化率、支付渠道、支付入口、ROI等等

用户研究：她有各种页面转化率、生命周期管理、留存率、用户画像和各种业务重合度、用户等级体系

c) 逻辑抽象 —— 脑洞大开，你的能力超乎你的想象

根据以上2块内容，可以把会员业务抽象成五大模块：营收体系、活跃体系、成长体系、关怀体系、用户研究。

d) 绘图软件

常用的绘制软件有MindManager、Xmind，软件提供了各种场景，选一个合适的Map。

常遇到的问题：数据分类和业务架构怎么结合?

解答：每个业务都有活跃付费、以及它的留存等相关数据结构，但这里的增值业务数据体系更多是让我们了解整个大的业务数据体系。如果想要详细的看数据，那么就需要把它转化为“指标体系”。

2.2 指标体系

做社交互联网的数据分析指标体系和其它行业的指标体系不同，有做交易支付为目标的，也有做用户流量的。所以了解业务形态，是首要任务。大到方向，小到细节。

step 1 走出去，先和运营的产品同学聊聊。看看他们都关注什么，他们对业务的理解是什么。他们平时都看什么指标。例如业务今年KPI是年收入80亿，而你只关注大盘趋势忽略各平台入口的流量和付费转化。所以指标体系不是大而全，需要有侧重点。

step 2 看看不同层次的人对这个业务的理解。业务leader和运营同学具体看的维度和思考的维度会有不同，了解不同的思考维度和声音，对建立不同的数据体系有重要的意义。

step 3 了解用户的声音，往往用户的声音才是对一个产品和平台最真实的反馈，这些需要数据指标体系来量化。

step 4  结合数据分析师的视角，最终构成了指标体系。

我们来看看某年某月某日为某手游做的指标体系：

这么设计的优点：

结合了业务洞察和数据分类，抽象成直观可量化的指标，进而监控业务的运营状况；帮助运营同学和开发同学快速拆解定位；能够快速复制到其它业务。

对于指标体系的构建，后续有专门介绍的文章：《指标体系如何搭建》

2.3 报表体系

有了数据体系、指标体系，那么就需要把这些结构化的业务划分、维度和指标转化成可视化的数据结构，并通过可视化的平台来呈现，目前SNG大部分业务用的是腾讯罗盘系统。

报表设计的几大要点：

a) 不是所有的数据都要放到一张报表里看。曾见过一张报表，有超过40个指标，后来产品同学自己都忘了怎么看报表。设计报表就像对着ppt演讲一样，一张图表只讲一个故事。

b) 多问问自己设计这个报表的目的是什么，要解决什么问题。是常规营收监控？平台渠道的转化？切忌随意，小心黑砖

c) 准备好数据源，了解统计口径。数据源是外部的还是内部的？存放在哪里？怎么获取？统计口径是如何的？口径变动的周期是多久？只有这些都确定了，开发效率才能提供，维护成本也会降低。报表开发流程规范：

2.4 分析体系

如果说单张报表是让你了解某块数据的“点”，那么报表体系就是把这些点组在一起的“线”。然而怎么综合评估某业务/产品的运营状况是否健康、未来的机会点以及风险呢？那么需要我们把这些“线”织成一张网。

对于业务来说，评估业务内部优劣势、外部机会与挑战最合适的方法莫过于SWOT：

那么如何判断此增值业务的S、W、O、T呢?

S: 通过分析用户属性与营收贡献判断我们的用户主要构成与优势的渠道/平台

W：通过分析用户健康度、特权活跃来看我们还有哪些空白领域未填补，以及哪些功能是占据大量资源但收益较低

O：通过分析用户属性和平台流量的转化比，发现潜在的机会、挖掘新的内容进而扩大业务盘子

T: 通过分析用户规模、竞品对比、平台和市场前景等角度发现业务可能遇到的挑战

现在，我们再来看看某增值业务的分析月报框架。

详细内容因涉及到业务具体情况就不展开。但通过框架可以很清晰的反映近期此增值业务的发展趋势、业务的优劣势以及可能面对的机会与挑战。类似的增值业务可以根据实际的业务情况再拆分。

最终，把SWOT的内容整合到一张报告里，每月固定输出给运营同学！

五、 结语

总之，互联网产品的数据体系需要产品经理、产品运营人员、开发人员和数据分析师共同合作完成，并不是业务同学或BI单方面就能完成的事情。为了更好的建设符合大数据时代的产品运营的数据体系，我们需要充分理解数据体系的商业目标，设计科学严谨的产品数据体系，做好数据上报的规范，结合大数据存储和计算的能力，搭建具有大数据技术能力的数据分析和数据挖掘体系，并在这些基础上形成数据体系设计、数据上报采集、数据存储计算和数据分析挖掘的良性循环。

也期待下一阶段能在用户生命周期管理、精准推荐等领域帮助业务有新的突破。

这不是结束，而是另一段“风花雪月”的开始……

来源：腾讯QQ大数据

对于增长黑客（Growth Hacker），行业里有一个很清晰的定义就是数据驱动营销，以市场指导产品，通过技术化手段贯彻增长目标的人。所以这里有一个很核心的理念就是数据驱动营销和增长，这个也是数据团队的核心价值所在。经过多年的实战经验积累，我们沉淀了一套适用于自身业务的数据驱动方法，希望能够拿出来跟大家做个分享，欢迎大家关注。

1. 背景

近两年来，随着“增长黑客”的概念从大洋彼岸的硅谷传入国内，相关的理念和方法开始在互联网技术圈流行起来。2015年，《增长黑客》一书的出版和流行更是把“增长黑客”这个名词正式带入了大众的视野。“增长黑客”近年来兴起于美国互联网创业圈，指的是一种新型的职业或团队角色，主要是依靠技术和数据的力量来达成营销目标，而非传统意义上靠砸钱来获取用户的市场推广角色。因此，增长黑客有一个很重要的理念就是“数据驱动”，也就是通过对数据的分析挖掘来发现有价值的数据洞察，并推动线上的落地应用，再通过A/B test来不断的迭代优化，最后找到最有效的策略方案，帮助业务实现持续增长。

作为公司历史最悠久的数据团队之一，SNG数据中心早在2008年就开始建设专门的数据团队，9年来一直致力于大数据的分析和挖掘，通过数据来支持SNG业务的发展。在这个过程中，我们也积累了不少的理论方法和实战经验，希望能够拿出来跟大家做个分享。我们的分享计划分批展开，涉及的内容包括数据基础能力建设、大盘指标预测、用户增长分析、营收增长分析、产品优化分析等。后面我们会有相关系列文章陆续发出，这篇文章算是一篇开篇的综述，旨在让大家能够对我们的经验方法有个整体的了解。当然，数据涉及到的知识体系和领域太过庞大，我们的分享也只是冰山一角，希望能够给大家带来一些启发，欢迎大家关注。

2. 基础能力建设

问渠那得清如许，为有源头活水来。数据行当里面有一句老话叫做“Garbage in，garbage out（垃圾进，垃圾出）”，指的就是要从源头上确保数据的及时和准确，以保证上层的分析和挖掘能够得出正确的、有价值的结论。SNG的数据异构现象突出，业务上包含了即时通讯（QQ）、社交平台（QQ空间）、增值产品（QQ会员、黄钻等）、游戏（手Q游戏、空间页游）等庞杂的业务体系，而且个个都是海量的数据，不仅如此，随着公司组织架构的调整我们还经历过大范围的PC数据和移动端数据的整合，有大量的历史遗留问题要解决，复杂程度可想而知。这一节将为大家介绍我们为了管理和维护这么多纷繁复杂的业务数据是如何建设基础的数据能力的。

2.1 数据上报通道建设

对于大部分的数据挖掘工程师来说，对数据的理解和应用都是从数据仓库开始的，殊不知，用户在产品上的每一次操作行为要上报到数据仓库成为某个库表中的一行记录都要经过Agent部署、埋点、上报、转发、清洗、调度入库等多个步骤，每一个步骤都需要严格保证数据的一致和稳定。在数据量小、数据结构简单的情况下，这或许不是一件太难的事情，但是面对SNG海量异构的复杂数据环境，要保证好数据的一致、稳定、实时，绝不是一项容易的工作。为了更好的应对海量复杂的数据上报问题，早在2012年，我们就开始了新一代数据上报通道DataCollector（简称DC）的建设。经过4年多的持续迭代优化，DC现在每天要支持1P+大小，1万亿+记录条数的数据的稳定上报，为SNG的底层数据建设立下了汗马功劳。DC通道的架构可以参考图1：

图1：DC数据上报通道架构图

按照DC数据上报通道的架构，我们只需要六步即可完成一次新的数据上报：

第一步：安装及检查DCAgent版本

第二步：按照API文档进行数据上报埋点

第三步：创建新的数据接口

第四步：检查上报通道

第五步：查询流水数据

第六步：查看入库情况

2.2 数据体系建设

完善的数据上报通道的建设解决了数据来源的问题，但是海量的数据在上报到数据仓库的过程中以及上报之后如果没有科学有效的治理，后果将是灾难性的，就像洪水来袭时没有防洪工程，任由洪水泛滥一样恐怖。比如在日常的数据工作中，我们经常遇到这样的情况：数据库表没有说明文档，字段定义和统计逻辑不清晰，业务核心指标口径不统一，库表搜索难度大，等等。这些问题都是由于缺乏科学合理的元数据管理和数据体系导致的。SNG在多年的数据工作中也是深受这些问题的困扰。痛定思痛，我们通过规范数据上报、建立标准化接口、规范数据字典等一系列优化措施的执行，针对即时通讯、社交平台、包月增值等业务，沉淀了一套适合SNG业务特点的数据体系建设的方法。

以社交平台为例，我们总结了一套适用于社交产品用户写操作行为的数据体系如表1以及写操作维表如表2：

写操作时间	QQ号码	写操作来源	一级操作ID	二级操作ID	写操作次数
20170313	123456	1(PC)	5	822	5
20170313	123456	2(iOS)	5	823	10
20170313	123456	3(Android)	5	36	15

表1：社交平台写操作行为数据体系示例

 

一级操作ID	一级操作名	二级操作ID	二级操作名
5	UGC操作	822	原创
5	UGC操作	823	转发
5	UGC操作	36	评论回复

表2：社交平台写操作维表示例

该数据体系及维表体系建设起来之后，纵使业务变幻，万变不离其宗，有新的写操作功能特性发布之后，只需要按照约定好的数据体系进行埋点上报，同时在维表里添加新的写操作ID的映射关系，报表即可自动生成，不需要数据分析师再额外开发，可见一个科学的数据体系的重要性，可以大大减少人力成本，提升开发效率。

       2.3 指标体系建设

曾经听一个从鹅厂出去创业的同事讲过他自己亲身经历的一个创业故事。在他们的产品上线初期，公司最大的目标就是获取更多的安装用户。为了达成这个目标，他组建了一个庞大的线下团队在各个网点做地推，同时线上也在购买各种渠道和广告，进行品牌宣传。一段时间的运营下来，成效显著，安装用户数每天都在成倍甚至十几倍的增长。就在整个公司上下都在为安装用户数的大涨而欢呼雀跃的时候，他自己却陷入了极大的恐慌之中。因为他发现，在庞大的安装用户里，日均活跃用户数（DAU）非常少，也就是说公司花费了巨大的精力和成本获取来的用户，最终却没有在产品中留存下来。在接下来的时间里，他迅速调整了公司目标，开始以提升DAU为导向指导运营思路，最终成功的提高了用户的留存，DAU也随之改变了之前的颓势，开始稳步上涨。

同样的故事在硅谷也发生过。早在 Facebook 成立之前，美国社交网络的老大是MySpace。MySpace 历史久，用户多，还有东家加大金主新闻集团撑腰，从任何一个角度看都应该可以轻易碾压由几个大学辍学生创办的 Facebook，最终却输得一败涂地。其中的原因当然不只一个，但是有一个有趣的区别是：MySpace 公司运营的主要指标是注册“用户数”，而 Facebook 在 Mark 的指引下，在成立的早期就把“月活跃用户数”作为对外汇报和内部运营的主要指标。

相比之下，从“用户数”到“月活跃用户数”，看起来只是多了三个字，却确保了 Facebook 内部的任何决策都是指向真实持续的活跃用户增长。

这样的故事背后，其实考验的是一家公司或者一个产品的指标体系规划和建设能力。在“增长黑客”的理念当中，有一个“北极星指标（North Star Metric）”的概念，指的就是有一个唯一重要的的指标，像北极星一样挂在天空中，指引着全公司上上下下，向着同一个方向迈进。当然，不同的产品形态会有不同的北极星指标，平台产品关注的是活跃用户数、活跃留存率这类指标，营收产品关注的是付费用户数、付费渗透率等等。在不同的产品发展阶段，指标体系的规划也会有所不同。我们对不同的产品形态及产品发展阶段的指标体系进行多年的研究之后，针对产品从灰度上线到稳定期的各个阶段总结了一套适用于大多数产品的不同发展阶段的指标体系，如图3：

图3：产品各发展阶段的指标体系规划

3. 用户增长分析

前面介绍了我们在数据上报、数据体系、指标体系等方面做的基础建设工作。面对每天上报的1P+大小，1万亿+记录条数的海量数据，我们当然不会止步于报表开发层面，更加不会让这些有巨大价值的数据躺在仓库里面睡大觉。特别是在人口红利衰减，业务增长乏力的大环境下，如何从海量的数据中挖掘出对用户、对产品有价值的信息助力业务增长，成了我们数据团队每天都在思考的问题，这也是“增长黑客”的核心使命。在本节中，我将通过用户生命周期管理（CLM）和用户分群两个在数据精细化运营中经常用到的方法来介绍我们是如何通过数据来驱动业务增长的。

       3.1 用户生命周期管理（CLM）

任何一名产品运营人员，每天思考的无非是这三个哲学上的终极问题：用户是谁，用户从哪里来，用户要到哪里去。为了解决好这三个问题，用户生命周期管理（Customer Life-Cycle Management）方法应运而生。传统的用户生命周期管理基本上包含五个阶段：获取、提升、成熟、衰退、离网，用户在不同的生命周期阶段会有不同的诉求，产品运营上也会有不同的方案和侧重点：

图4：用户生命周期

这里有很多数据可以发挥巨大价值的地方，以新用户获取为例，通过对历史新进用户的特征进行分析和数据建模，我们能够建立一个预测用户转化概率的精准拉新模型，在推广资源有限的情况下，锁定高转化概率的潜在用户进行资源投放，大大提升投放效率。从我们实际应用的情况来看，通过模型筛选出来的潜在用户，在转化率上往往比通过人工经验判断筛选出来的用户有20%-60%的提升，比随机筛选出来的用户更是有成倍甚至几倍的提升。

我们对CLM方法的研究和应用，最早始于2012年，当时跟麦肯锡的驻场团队一起封闭开发，以新用户获取为切入点，整理了8亿用户的近千个特征字段，进行了详细的数据分析，近十轮的模型迭代，在多个渠道进行了200多次的活动投放试点，试验用户群+渠道+文案+活动形式的各种组合，期间还陆陆续续邀请了近百个QQ用户参加深度访谈调研，验证我们的数据结论，最终使得实验组的点击率比对照组的提升稳定在40%-110%以上。随后，我们又把在新用户获取项目中沉淀下来的经验和方法复用到了活跃用户流失预警以及流失用户拉回的运营活动中，效果都有了显著的提升，数据在增长分析中的价值得到了有利的验证。自此，整套的用户生命周期管理方法就此打磨成型。接下来，我们把这套方法先后在QQ会员游戏联运项目、空间页游项目、手Q游戏运营项目中进行了推广和复用，进一步放大了数据的价值。到今天，CLM的方法和理念已经渗透到了SNG的多个重要业务中，并且还在持续的探索和优化。以手Q游戏运营为例，我们每天都会通过QQ手游公众号投放数以亿计的精准拉新、拉付费、关怀等类型的CLM消息，并且能够自动采集数据进行效果监控，彻底改变了以前“产品经理提号码包需求->数据团队提包（排期）->产品经理上传号码包->投放->产品经理提效果统计监控需求->数据团队开发报表（排期）”的传统而又痛苦的模式，不仅大大提高了资源使用效率，也帮助业务大大减少了运营成本。

在推广CLM方法，拓展业务场景的同时，为了更好的服务业务，我们自身的能力建设也没有停下脚步，特征库、算法库、AB test工具等已经日趋完善和成熟，另外值得一提的是，我们近期上线的lookalike功能使得需求的响应速度又有了进一步的提升。以前业务有一个拉新的需求，需要先跟我们沟通需求，我们了解需求之后要经过数据准备、采样、模型训练/验证/部署等过程，这么一个过程下来，快则一两个星期，慢则一个月，模型才能上线使用，这个对于需求紧急、心情急迫的运营同学来说显然是不能忍的。现在，运营同学只需要上传一个种子用户号码包就可以通过lookalike功能进行人群扩散，返回跟种子用户相似的其他用户进行运营活动的投放，前后只需要一个小时左右，速度有了质的飞跃，当然这也得益于我们投入了很多精力进行基础特征库的建设。

       3.2 用户分群

CLM模型建立之后，我们可以通过模型找到更加精准的目标用户，但是为了把运营活动做的更加精细，我们还需要考虑这些问题：我们的目标用户的人群属性怎样？有什么行为特点和兴趣爱好？根据这些应该怎样设计运营活动。这就要用到用户分群了。用户分群从语义上理解就是对用户群进行细分，不同的用户群有不同的特征，好的分群能够帮助业务充分认识群体用户的差异化特征，从而找到正确的营销机会、运营方向。所以在数据分析行业里，有一句老话叫做“不细分，毋宁死”，讲的就是这个道理。既然用户分群这么重要，那我们要怎么做呢？用户分群常见的维度包括以下几个：

1.    统计指标：年龄，性别，地域

2.    付费状态：免费，试用，付费用户

3.    购买历史：未付费用户，一次付费用户，多次付费用户

4.    访问位置：用户使用产品的区域位置

5.    使用频率：用户使用产品的频率

6.    使用深度：轻度，中度，重度用户

7.    广告点击：用户点击了广告 vs 未点击广告

在维度少的情况下，用户分群是很好做的，比如年龄维度，我们经常会按照人生不同的生命阶段进行划分，再比如活跃维度，我们可以划分成低活跃、中活跃、高活跃用户群体。但是当维度增加到几十个甚至几百个维度时，人脑就完全处理不过来了，这个时候无监督聚类的方法就派上用场啦。举个例子，我们采集了以下10几个维度的数据，需要对用户进行分群。

图5：用户特征维度

就算经验再丰富的运营同学，面对这十几个复杂的数据维度，相信也很难对用户群进行准确的划分。而我们借助无监督聚类分析的方法，可以很快的把用户分成以下几类：

图6：用户无监督聚类结果

当然这里的结果都是数值信息，还不能直接指导运营方向和思路。但是结合业务理解对数据进行提炼和解读，我们很容易将数据转化成人可以理解的用户分群：

聚类1特征：年龄未知或低龄，好友少，活跃度和使用粘性都极低【低端低龄群体】

聚类2特征：年龄偏小，前台在线和消息活跃均比较高【学生活跃群体】

聚类3特征：平均27岁左右，PC端和手机端活跃度均非常高  【职场高粘性群体】

聚类4特征：平均28岁左右，前台在线和消息活跃都极低【职场低粘性群体】

聚类5特征：年龄较高，手机在线时长高，但消息沟通极少   【高龄低活跃群体】

当运营同学拿到这样一个科学、可理解的用户分群结果时，就可以针对不同用户群体的特征设计符合该群体特点和需求的文案、道具和活动形式。运营活动也必将取得事半功倍的效果。

4. 总结

正如文章开头所说，数据涉及到的知识体系和领域太过庞大，这里的介绍只是冰山一角，海量的数据中蕴含着丰富的金矿还等着我们去开采。回顾这些年的数据工作，我们在数据类型上，从结构化的用户行为数据挖到LBS轨迹数据，从关系链的图数据挖到文本数据，在系统架构上，我们也在不断完善和优化我们的数据系统及架构，为业务提供更好的数据服务。我们一直相信，通过数据驱动来帮助业务增长是数据团队最大的使命和价值，我们会在这条道路上持续探索，不忘初心，砥砺前行。

来源：腾讯QQ大数据 

目前，某产品营收运营正处在从过去依赖产品经理的经验到通过数据来驱动增长（Growth Hacking）的过渡期。在这里梳理一下通过数据模型帮助该产品营收的一些经验。

正文

本文主要包括7部分：定义目标：转化为数据问题、样本选择、特征搭建、特征清洗、特征构造、特征选择、模型训练与评估。如图1下：

图1

一、定义目标：转化为数据问题

营收活动就是要从大盘中找出那些响应活动的高潜用户，这实际上是一个有监督的分类问题。通过训练集找出典型的响应用户特征，得到模型。再将模型用于实际数据得到响应用户的分类结果。这里选择逻辑回归（Logistic Regression）。为什么是逻辑回归？因为逻辑回归鲁棒性好，不容易过拟合，结果便于解释，近些年有很多新的算法可能分类效果会更好，但很多前辈的经验表明，精心做好特征准备工作，逻辑回归可以达到同样好的效果。

二、数据获取

特征主要包括画像和行为数据，画像数据最稳定且易获取，行为数据预测能力最强。基础特征包括画像数据（取自达芬奇）、特权操作、平台操作、历史付费行为、QQ和空间活跃等共计236个特征。

三、样本选择

选择最具代表性的样本，如果样本倾斜严重，则进行抽样，保证正样本比率不低于10%。

训练样本的选择决定模型的成败，选择最能代表待分类群体的样本。最佳选择是用先前该活动的数据做训练集，如果是新的活动，用先前相似的活动数据。

有时遇到这样的情况，先前活动的号码包是通过模型精选出来的，通常，这些号码包不是整体的有效代表，不能直接用来做为新的模型的训练样本，当然如果这些号码包占整体用户的80%以上基本就没问题。一种解决办法是随机选取样本投放活动等待响应结果来构建模型，这种方法比较耗时耗力，通常不用；另一种方法是抽取部分未投放的号码标记为非响应群体，这样构建的模型虽然不是效果最优的，但却能提升模型的泛化能力。

样本多大合适？没有标准答案，一般来说特征越多，需要的样本越大。我们建模一般有上百的特征，训练样本会选择几十万数据级。

当前计算机的计算能力已经提高了很多，抽样并不是必须的，但抽样可以加快模型训练速度，而且用单机来做模型的话，抽样还是很有必要的。通常目标用户的占比都很低，比如该产品某次活动的目标用户占比只有1‰，这样数据是严重倾斜的，通常做法是保留所有目标用户并随机抽取部分非目标用户，保证目标用户占比大于10%，在该产品营收模型训练中，一般用目标用户：非目标用户=1:4。

四、数据清洗

了解数据特性是保证优质模型的第一步。数据清洗是最无聊最耗时但非常重要的步骤。包括脏数据、离群数据和缺失数据，这里了解数据的先验知识会有很大帮助。用箱线图来发现离群点，这里关于数据的先验知识会有很大帮助。如果变量太多，不想花太多时间在这个上面，可以直接把脏数据和离群数据处理成缺失值。对于缺失值，先给缺失值建一个新变量来保留这种缺失信息，连续变量一般用均值、中位数，最小值、最大值填充。均值填充是基于统计学中最小均方误差估计。如果数据是高度倾斜的话，均值填充是较好的选择。或用局部均值填充，如年龄分段后所属年龄段的均值。还可以用回归分析来填充，实际中用的比较少。分类变量一般用频数填充。

五、特征构造

已经有原始特征，为什么要进行特征构造？特征构造的必要性主要体现在发现最适合模型的特征表现形式。

清洗工作之后，就可以进行特征构造了，主要有3种特征构造方法：汇总、比率、日期函数。

• 汇总：如按天、周、月、年汇总支付金额，近三天、近7天、近14天、近21天、近31天听歌/下载次数，统计用户近一年累计在网月份等。
• 比率：曝光点击转化率、曝光支付转化率、点击支付转化率、人均支付金额、次均支付金额。
• 日期衍生：首次开通服务距现在时长、最近一次到期时间距现在时长，到期时间距现在时长。
• 转换特征：对原始连续特征做平方、三次方、平方根、立方根、log、指数、tan、sin、cos、求逆处理。然后从所有转换中选择2个预测性最好的特征。实际中，使用最多log处理。

逻辑回归本质上是线性分类器，将预测变量尽量线性化，虽然我们的特征有连续变量和分类变量，模型训练时会把所有变量当做连续变量。

连续变量可以直接用来训练模型，但分段会使得变量更具有线性特征，而且可以起到平滑作用，经验表明分段后的特征会提升模型效果。分段一般依据经验划分或先分为均等10段然后观察各段中目标变量占比来确定最终分段。如年龄分段主要基于常规理解，分为幼儿园、小学、初中、高中、大学、硕士、博士、中年、壮年、老年。

六、特征选择

特征选择的目的是要找出有预测能力的特征，得到紧凑的特征集。

特征成百上千，对每一个变量进行深入分析并不是有效的做法，通过相关系数和卡方检验可以对特征进行初步筛选。相关性强的特征去掉其一，对每个特征进行单变量与目的变量间的回归模型，如果卡方检验小于0.5，说明预测能力太弱，去掉该变量。

做过初步变量筛选后，用剩余变量训练模型，根据得到的回归系数和p值检验，剔除回归系数接近0和p值大于0.1的特征，得到最终用于建模的特征集。

特征多少个合适？这个没有标准答案，主要原则是保证模型效果的同时鲁棒性好，并不是特征越少，鲁棒性越好。主要取决于市场，如果市场比较稳定，变量多一些会更好，这样受单个变量变动的影响会较小；当然如果想用用户行为来预测未来趋势，变量少一些比较好。对我们做营收增长来说，模型特征尽量简化，这样便于从业务角度进行解读，便于跟老板和产品同事解释。

七、模型训练和评估

前面花了大量时间来确定目标、准备特征、清洗特征。使用一些简单的技术来过滤一些预测性弱的特征。接下来，用候选特征来训练和验证模型。

模型实现步骤：

1、 通过挖掘算法获取不同群体的差异特征，生成模型用于分类。

2、 待分类用户群通过分类器筛选出目标人群，形成标识和号码包。

3、 用户号码包通过渠道进行投放，营销活动正式在外网启动。

4、 收集曝光、点击、成交数据用于评估模型效果，明细数据用于修正模型的参数。

5、 重复1——4

图2

另外，活动投放参见组选择很有必要，一般是依据产品经验或随机选取，参照组的效果一般不如模型选择的，这会导致收入有所减少，有时很难说服产品，但对于对比、监控和检验模型效果来说很有必要。

该产品营收依据模型精细化运营以来，收效显著，支付转化率提升30%~150%。

最后致上一句名言：Your model is only as good as your data!

参考文献

[1]. OP Rud. Data mining cookbook: modeling data for marketing, risk, and customer relationship management. 2001

[2]. https://zh.wikipedia.org/wiki/逻辑回归

 

来源：腾讯QQ大数据