作者简介: 谭安林, 腾讯高级工程师. 2015 年加入腾讯, 8 年互联网从业经历, 从事大数据平台与产品开发相关工作; 先后参与广告, 金融等领域产品项目, 目前负责行为预测解决方案, 帮助客户盘活现有客群, 挖掘潜在高价值新客. 目前我们的产品包括: 智能客服, 大数据套件, 腾讯移动分析, 腾讯移动推送等.
今天我分享的是在腾讯云在大数据对用户行为预测这个项目中, 有关教育行业的一些实践, 希望可以给大家带来一些帮助. 这一年我们所做的是用户行为预测解决方案, 针对教育行业定制一些行为分析和预测, 希望可以帮助大家更好地借助于数据. 大数据对外开放有两个模式. 第一个模式是平台技术, 我们会将大数据的能力开放到云端给大家使用, 比如腾讯大数据框架. 第二个模式, 我们考虑到对内数据服务的能力模型, 复制对外, 为大家提供一些有针对性的行业服务.
中国的网友有 8 亿之多, 98% 的用户群使用移动互联网. 2017 年始, 月活的移动设备数量稳定在 12 亿左右, 新增红利在渐渐消失. 深挖存量的大盘用户价值, 有两方面的考虑: 一方面, 我们希望给整个大盘的存量用户提供更有针对性的个性化服务, 产品和推荐; 同时针对各个行业, 挖掘出大盘用户的价值, 为行业带来数据上的增长.
我们以前做过智能推荐, 在金融领域进行用户逾期行为预测的开放, 在相关的反欺诈, 风控场景中进行使用. 在教育行业, 随着技术的发展以及产品的日渐丰富, 整个教育行业的用户增长是很可观的. 在未来几年, 教育行业会持续发力, 我们也希望可以在这方面做一些事情.
用户行为预测帮大家解决的问题有哪些? 从运营的角度考虑, 获取潜在客户的环节, 可以帮大家了解谁是你的用户, 哪个平台适合做精准化营销. 获取用户之后, 我们会分析哪个用户价值比较高, 更容易付费转化. 我们可以做这样的识别, 哪些用户在一定的生命周期后会流失, 我们要做出流失预警以提前干预, 而不是等到流失后再干预, 这时候已经来不及了.
我们的产品运营会贯穿数据化的工作, 从用户引流开始, 到判断用户来源渠道是好还是坏, 用户的价值是高还是低, 提升转化效果等. 这就说明产品要做大, 必然需要一些潜在的客户, 将当前用户的盘子进一步扩大. 其中涉及到的数据分析服务, 主要可以分为三个方向:
新用户的预测, 即新增用户.
留存用户, 即当前使用产品的用户.
潜在用户.
现在市场上的移动分析, 也需要相应的工具. 例如上面提到的三个方向, 我们要做数据化的运营, 首先要明白运营指标, 目的是什么, 从而把这个指标转换成数据的指标. 比如每天的转化率, 我们会推动终端做数据的采集, APP 的打点, 将数据分析和数据开发通过相应的报表进行呈现. 整个过程中, 不管是我们自研还是用外界的工具, 比如云盟和腾讯分析等, 我们都可以直观地看到一个产品运营的情况. 但是要做深入挖掘, 判断哪一个用户有价值, 这肯定是不够的. 我们还要进行标签的建设, 模型的建设, 判断应该构建哪些标签, 哪些模型. 最终构建的标签和模型都需要落地去做数据产品, 做到可视化, 使我们的运营, 产品所见即所得, 找到一个比较好的运营方向.
在整个实施过程中, 我们也了解到, 无论是教育行业, 金融行业或其他电商行业都面临同样的问题. 数据在终端收集之后, 我们要落地到标签系统, 生成标签. 这个环节会非常困难, 首先我们要联动很多岗位的同学, 从产品到终端开发, 后端开发, 以及数据分析, 算法等等. 大家的 KPI 是不一致的, 运营同学主要是做数据增长, 后台, 终端同学更多倾向于做出新功能和并维护旧功能的稳定性. 这样的数据需求提给他们, 你说要打一个点, 很有可能很小的事情会做到一个月甚至是半年以后. 这里存在一个应用难的问题.
同时还有一个问题, 对于新用户或 APP 已经留存的用户, 基于我们数据采集的方式获取到的数据非常少. 少到什么程度? 可能只有几条. 这些行为的数据是付费转化的数据, 但你也不知道还需要哪些其他的数据. 这时数据很少, 很难刻画一个用户是不是高价值, 是不是容易被转化. 即使构建了标签系统, 还需要另一批人去建模, 需要四五个人或十几个人做模型分析. 选择哪个模型, 判断哪些特征有效, 模型构建完成以后还要去运营, 落地, 实验, 这时候还需要进行实验的工具, 整个过程是很复杂的.
用户行为预测项目的出发点在于标签建设和模型建设这两部分. 化繁为简地说, 我们希望做到的是我们来提供 API, 大家来上传行为数据, 我们再进行落地的简化. 大家不需要做标签建设和模型建设, 我们可以直接预测用户的付费评分, 转化评分, 以及一周内是否会流失的预警. 在简化落地这部分, 如果大家联动开发, 算法, 分析一起做这个数据产品, 需要 20 个人甚至更多. 但在使用这个产品之后, 只需要两个人去做这件事. 一个人开发 API, 接入数据; 另外一个人使用这个系统做运营. 同时, 我们也提供小步实验的工具.
下面我来介绍一下腾讯云对于用户的刻画, 主要分为五个方面, 包括人口属性, 社会属性, 用户消费, 用户行为, 兴趣偏好. 大家在报考驾照时可能关注点不太一样, 有些人希望周期较短, 有些人希望便宜一点, 有些人希望教练不要骂人. 我们可以通过标签, 刻画不同用户的分群, 针对这些分群做一些定制化的营销. 特别是针对教育行业, 我们可以把一个群体分为七天内流失可能性是高危, 一般还是低流失的不同分群, 进行一些有针对性的运营策略. 接入的方式是围绕用户行为进行接入, 获取用户接入第一方的数据后提供模型, 或从行为中抽取样本再进行建模. 在这个过程中, 系统会提供一键预测的功能, 客户直接在系统上进行操作即可. 预测出的结果可以截取下来进行自己的运营实验, 我们最后也会根据用户行为进行跟踪. 在市场上有一些行为跟踪的产品, 它们要求的是效果反馈, 需要有一些 KPI. 我们根据纯粹上报的 KPI 做变化跟踪, 直观地看出哪个策略好, 哪个策略差.
刚刚提到三个方面的服务, 第一方面是对留存用户, 第二方面是对新增用户, 第三方面是帮助大家挖掘潜在用户. 先来看一下留存用户, 也就是现在已有的用户, 这种场景比较好的地方就是第一方数据相对较多, 我们的模型会比新增用户的模型更好. 主要分为以下四个部分, 一是数据管理, 数据管理不仅是第一方数据, 也包括互联网大盘的脱敏数据, 我们会有针对性地进行融合. 第一方的数据是注册信息, 设备信息, 行为信息, 比如用户登录的时间, 浏览的页面. 这些信息接入进来后, 我们会进行概览性的分析, 比如每天的 PV,UV 分别是多少. 同时我们也会对每一条数据进行质量评估, 因为每一个字段的完善度都会影响模型的效果, 如果完善的话, 模型将在 0.8 以上; 如果不完善则会在 0.7 到 0.8; 如果特别差的话, 模型就不能被使用.
第二是留存预测. 我们可以提取一段时间内的用户包进行预测, 预测模型可以是多种, 根据多种需求可以自定义, 也可以进行增加, 当前的预测主要是流失, 付费, 逾期还款等. 在预测出来后会出现一个概率的分值, 可以根据概率分值将它自定义分成几个分组, 也就是分群. 例如在付费的模型中, 付费转化率高的人, 我们称为高付费, 次之是较高付费. 我们可以在这个基础上再进行分群的洞察, 在这个分群洞察市场上有很多移动分析的软件, 但是它们提供的画像很有可能是通用型的, 甚至对于某个群体是没有显示度, 也就是没有显著性的. 我们针对不同的行业, 特别是教育行业, 有着自己的行业定制标签, 比如教育关注度, 教育坚持度这样一些画像, 能够有效地展示其中的群体形态. 如果你发现这部分人群有怎样的画像特点, 在之后进行广告投放时可以咨询一下广告投放平台, 支不支持这些标签的投放. 如果可以的话, 就可以实现精准投放.
再来介绍一下我们分群所用的标签. 我展示出来的是两个画像, 一个是教育关注度, 一个是教育坚持度. 首先介绍一下图表, 图表上 207 这个数字, 表示的是 TGI 的相对显著性, 数字越高表示这个特征和它所对应的分子越大, 也就是正相关性越高. 这个数字大于 100 表示正相关, 小于 100 就是负相关, 数字越小就表示负相关越大. 教育关注度越高的这些人付费意愿就会更强. 教育关注度就是根据客户在大盘教育类的咨询, 以及周边产品的关注程度聚合出来的画像.
再来看教育坚持度, 它的表现也是一样的, 越能坚持的人, 越愿意付费. 在这里教育坚持度我们怎么刻画的呢? 他持续使用大盘里某类或全部的教育产品, 这种持续的时间投入, 我们称之为教育的坚持度, 这是由很多特征聚合出来的画像.
刚刚看到的是行业的标签, 我们构建的标签分成了通用标签, 行业标签, 场景标签以及个性化标签. 这里是通用标签, 通用标签就是游戏的沉迷度, 比如说在游戏上消耗的时间和周期, 可以根据这些行为进行刻画. 我们发现它的显著性和教育关注度不一样, 越沉迷游戏的人, 付费的可能性就越低. 在自我驱动力上面, 他会自己驱动自己做一些相关的学习, 收藏, 属于比较有自发性行为的数据. 这种数据可以刻画出越上进的人, 越可能会付费.
这是一个实验项目的跟踪展示, 上面是测试数据, 不是真实的数据. 我们的实验包括两种实验, 一是人群对比, 将较高付费的人群及高付费人群做同一个策略实验. 我们可以打电话营销, 发短信营销, 甚至可以建群为他们进行针对性的服务. 在这些方式下, 可以得出哪种人群转化率更高, 哪种策略更适合哪个人群. 第二是策略对比, 针对较高付费的群体, 我们进行刚刚三个策略实验, 就可以看出哪个策略对这部分人的效果更好, 在具体的运营实验上花更少的成本, 去体验整个实验的效果.
第二个方向是新增用户. 新增用户为什么放在留存用户后面讲呢? 因为这部分可以获得的数据更少. 我们可以获取到留存用户的一些行为数据, 但新增用户可能只有手机号, 设备环境信息和相应的价值信息. 我们可以做到的是新增预测, 提供单独的 API 服务. 它的应用场景主要是有两个点, 一是渠道质量的预估, 为什么是预估呢? 我们在运营中会面临一个问题, 投放广告, 投放营销预算应该选择哪个渠道? 评估一个渠道的好与坏有两种方式, 一是咨询别人, 这种方式并不可靠. 第二是进行实验, 在一周, 两周, 一个月之后, 观察这个渠道的付费转化率是多少, 流失情况是多少. 我们对模型进行了预测, 这时就可以把渠道的质量预估提前, 如果预测出某个渠道的质量非常差, 转化效果也很差, 这时就可以把营销预算往好的渠道上面倾斜, 在后期完全可以进行对比.
还有一种情况, 我们在投放广告的时候, 因为广告的素材偏差引进来的人不是目标用户, 导致营销预测浪费. 假设我们在三个渠道都投放了营销素材, 三个渠道质量的预估从原来都很高的预估率同时降低了, 这就有理由怀疑是素材的问题, 可以进行素材上的调整. 同时还可以进行新增的预测, 根据它的阀值进行自定义的实验. 我们的跟踪数据会反馈到模型训练中做一个迭代的优化.
潜客挖掘这部分是很多人都关心的. 一开始我们并没有想做这部分, 以前一直在做广告, 通过广告挖掘新增客户. 无论是教育行业还是金融行业, 都有这种需求. 为了获取更多的客户, 有可能是口口相传, 有可能要投一些预算做广告. 潜客预算有两种模式, 第一种是从其他渠道拿到你认为有潜在价值的用户包, 第二种是在互联网大盘里做一个预测, 哪些人可能会是潜在用户, 而第二种方式只会在腾讯云内部的广告投放平台上进行流通. 我们把挖掘潜客分成两类模型, 一种是和留存新增类似的分类模型, 一种是 Lookalike. 如果我们以到站这种方式作为目标, 其实你不知道谁没到站, 你只知道到站的是谁, 这里是没有负样本的, 所以我们需要用 Lookalike 的方式. 我们对潜客的跟踪有相应的解决方案, 可以跟踪到潜客包转化效果, 从而进行进一步的运营尝试.
下面为大家介绍一下 Lookalike,Lookalike 是将其转化为一个二分类. 以到站的方式为例, 到站的人我们认为他是种子用户, 但我们不知道没有到站的人是谁, 只能在大盘里将到站的用户剔除掉, 其他的作为一个盘, 其中随机抽出一部分作为复例. 最后进行模型训练时, 提取的就是我们潜在的用户包. 这里面临的问题是什么呢? 负样本中很有可能包含正样本即某些实际上是潜在用户的人, 随机性抽样很难保证准确性. 这里我们也通过标签抽取的方式进行实验, 比如先对种子用户进行画像分析, 发现他的教育程度高, 教育关注度高, 坚持度高, 这类人就是潜在客户. 相反, 关注度低, 坚持度低的人, 是不是一定就是负样本呢? 这种方式可能会导致整个模型泛化效果比较差. 实际上, 我们是将种子用户抽取出来一部分, 放到负样本混合后进行建模, 在建模后就可以看到负样本中混合的种子用户的概率分布.
假如我们发现它的概率分布在 0.42 以上, 我们就有理由相信 0.42% 以下是比较高质量的负样本, 再将正负样本拿进去做第二次真实的训练. 训练的过程中可能会遇到一些问题, 我们在教育行业用了 800 多维的维度, 整体的维度有三四千. 这里面临特征拼接的问题, 不管是留存, 新增还是潜客, 或者是付费, 流失场景包的模型, 每一个模型所需要的特征是不一样的, 它们都是动态的, 个性化的. 这里需要有一个特征拼接的过程, 我们采用列存储 + SSD 进行支持.
大家接触的数据量比较少, 当前几千万也是比较常见的. 在整个大盘预测上, 基础是几十例. 我们做一个排序, 也可以做一些抽样的预测. 比如抽取 5000 个用户包, 先预测一下这 5000 个用户的大概 P 值, 比如说预测出的 P 值是 0.85, 在实际预测时就进行阀值的提取, 加强整个链路的优化. Lookalike 的结果会直接与内部广告平台打通, 并在广告投放后从行为变化跟踪上观察投放的效果.
在整体的方向上, 我们的预测从数据采集到特征构建, 模型集成, 最后提供在线化的服务. 在数据采集这部分, 我们会根据采集到的持续数据构建时序的特征, 同时也会将其用到模型中去.
这是一个整体技术架构介绍. 因为这是一个数据产品, 不像我们常规理解的一个显然的系统, 它是各个环节进行协作, 最后进行数据产品的输出. 首先我们在做外部数据接入时, 通过腾讯统一的网关 STGW 将数据放进来, 之后通过 DFS 数据通道存放到消息队列中. 行为数据基于第一方数据的安全, 进行了相应的加密和脱敏, 我们要进行解密并对每一条数据进行质量的评分. 这里有一些质量评分的报警, 如果数据可以达到 80 分, 现在一下子变成了 60 分, 我们就需要和客户沟通, 是不是某个环节出了问题, 因为它最终会导致模型效果较差, 使用的体验也会比较差. 后面我们会将接入进来的数据存放在 TDW, 各家的数据进行分表存储, 没有融合在一起. 之后再将数据取出来进行计算, 进行数据行为概览相应的指标分析以及行为跟踪. 某一个用户包的行为变化跟踪, 就是在这里面进行的.
最后我们将这些统计结果, 跟踪阶级写入 MySql, 通过产品系统提供给用户进行展现. 这里为大家介绍一下我们模型的做法. 样本来自两个部分, 一是行为数据抽取出来, 二是通过用户接口提供或离线提供. 我们要融入大盘的特征, 大盘特征是分级的, 有些特征是按月的, 有些是按周的, 有些是按天的, 有些是实时的. 我们有很多节点计算每个不同的特征, 当然有些特征会放在一起进行计算, 将这些特征放到 Hbase 中以加快它的访问.
在具体应用时, 客户提取用户包后进行模型的预测, 分群的洞察. 我们提取了用户包, 在预测的时候要先去提取存在 Hbase 里面的实时数据, 观察它的实时特征. 实时特征和离线特征融合起来进行模型的预测训练, 在预测完成后, 我们要将一些特征聚合起来形成画像, 最终在页面上展示给大家. 这些也是通过关系型数据库进行产品的展现支持.
关于我们产品的结构, 首先是第一方的数据源. 第一方的数据是客户提供的行为数据, 加上内部画像融合起来进行数据建模的支持. 针对用户上报的数据, 我们会自动生成标签. 内部数据也会通过相应的标签工具, 生成通用的行业, 个性化, 场景的标签, 之后再进行数据建模以及每个用户的落地, 服务落地分为用户分群, 小步实验, 效果闭环. 再往下是各个行业的应用, 比如教育行业以及金融上面的反欺诈实践.
第一方的数据完善程度和模型效果有相关性. 如果第一方数据比较完善, 可以达到 0.8 到 0.9 的 AUC, 它的识别能力非常少. 如果数据不太完善, 只有 50% 或者 60% 的完善程度, AUC 会在 0.7 到 0.8 之间. 如果数据在百分之二三十, 甚至没有第一方数据, 那么 AUC 就在 0.7 左右.
下图是教育类预测线上特征库, 我们将其分为四类. 每类从上往下是通用, 行业, 个性化, 产品化这四类特征. 整个大盘的特征维度有几千维, 教育行业我们用到了 800 多维.
在第一方数据和安全机制部分, 第一方数据, 就是某一方面的数据, 它对某一方面的模型有直接的影响. 在做付费模型的时候, 基础数据 APP 行为, 付费转化有着直接相关性; 在做流失模型的时候, 基础数据和设备相关的信息, APP 行为的信息有直接相关性. 第一方数据是客户提供给我们的, 无论是金融, 电商还是教育, 大家都会面临同一个问题, 提供数据会不会存在隐患, 我们会不会再将这些数据提供给别人. 在安全方面我们分为三个等级, 一是数据传输上进行加密的支持, 即使传输的链接请求被劫持了, 其他人也不知道这个数据到底是什么数据, 他只能看到一个密文. 二是数据存储. 在存储用户数据的时候, 按照分表物理存储, 其中不会有融合的问题, 也不会将这些数据给另外一个产品使用. 三是数据的脱敏. 我们针对账号支持加密, 在内容上可以简单地理解为, 假如用户 A 看了张老师的数学教程, 在这个看的过程中, 我们会将张老师的信息由客户自己定义一个唯一的编号, 将这个数学课程也定义成唯一的编号. 在这些数据上传之后, 我们拿到的只是编号, 而不是张老师, 数学这样的具体信息. 取得这个数据后就可以进行模型上的建设, 这里我们会将具体的用户隐私数据过滤掉.
我们的接入方式比较简单, 但也会存在一定的开发量. 首先客户将行为的数据通过 API 提供给我们, 这里的样本有两种方式. 如果行为数据比较全, 我们可以直接进行操作. 如果行为数据不太全, 或不太符合预期, 我们会让客户提供一个样本. 数据建模由我们进行支持和处理, 客户可以在产品系统上提取用户包进行预测, 实验和效果的跟踪.
Q/A
Q: 刚才提到的教育坚持度, 如果与某个变量因子相反关系, 说明这个人的基础比较薄弱, 是吗?
A: 这不一定, 我们也做过这方面的分析. 我们发现有些人学历很高, 他们还是坚持去学习, 这完全是因人而异的. 所以这部分也要看学历, 学历也是一个因子, 但学历的因子反而没有这个指标显著.
Q: 关于特征的部分, 请问可以公开一些特征吗?
A: 如果合作到一定深度是可以的, 但是现在不方便透露. 我们的特征也很多也比较细, 像通用特征可以通用到各个行业, 没有行业的属性在里面.
大数据在教育行业的研究与应用 - 谭安林. pdf https://ask.qcloudimg.com/draft/1184429/az06y52dzo.pdf
来源: https://www.qcloud.com/developer/article/1153719