背景

随着神盾推荐业务场景的不断深入，传统的离线训练+线上计算的模式可以说是推荐系统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大数据

场景分析：

推荐场景一般可以抽象为：内容（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 特征构造框架

写在前面

本文介绍了神盾推荐系统中基于热传导模型的相关推荐模块. 神盾推荐系统是 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:

对于增长黑客（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大数据