作者：闲鱼技术-莫癫

1. 业务背景

闲鱼直播业务上线后面临的最大问题是增长问题。闲鱼BI同学分析发现，对比短时观看和长时观看人群，发现两部分人群有较明显的兴趣阶段性差异。
业务希望在理解直播、主播和用户的基础根据兴趣对头部优质直播精准投放, 放大头部主播马太效应实现直播转化和观看时间的增长。

2. 目标

简单概括需要达成两个结果：

• 在三周内实现精准投放平台，沉淀基础运营平台的基础设施；
• 业务上保证头部直播间场均转化uv达成一定目标，转换率得到明显提升；

那么单纯借助算法模型实现优质直播推荐，是否也可以达成业务上的目标？然后现实却是，巧妇难为无米之炊。 直播上线时间短, 播放和观看场次有限, 使得模型的训练没有足够的样本直接去理解用户对直播的兴趣, 平台也未对主播直播内容做强控实现内容的结构化。那么就需要将运营对直播领域经验与BI分析、算法结合， 在理解用户、直播和直播间的基础上，实现对直播间到兴趣人群的投放，并沉淀平台化能力。

3. 实现方案

给兴趣人群投放实时直播间的第一步是要实现对人的理解，包括C端用户以及主播的理解，其次是直播的理解。理解的结果最终会以兴趣人群、主播人群的方式与页面资源位关联，形成人（用户）货（直播）场（资源位）的初步匹配。


用户的理解依赖于用户的特征数据，包括闲鱼用户基础特征，搜索、浏览、发布、交易等商品相关行为记录，互动行为特征和用户兴趣标签特征等。这些特征对实时性要求不高，大部分特征通过离线计算产出，后续通过离线计算方式对不同数据来源的特征归一化。


用户所有特征会同步到人群圈选平台，通过交并差的方式实现人群圈选，进行人群预览和导出。

平台整体设计


圈选的人群数据是以userId和人群Id的映射表方式保存离线，与投放的配置进行联合后得到<用户, 资源位, 主播>的关联关系，而后关系数据会同步到图数据库Igraph，提供给算法在线推荐时查询关联直播实现按兴趣推荐和曝光。受限的是整体的曝光流量有额度的，算法会基于模型，在有限PV额度内对在线直播间实现较优的选择。


下面详细阐述是怎么实现用户理解和直播间投放的。

用户理解

对用户理解的常规特征生产不是个难事, 而用户的兴趣标签需要针对闲鱼用户从零开始, 弥补这方面能力的缺失。 兴趣标签主要是通过分析用户历史行为产生的行为文本，找出其与领域标签涉及到词组的关联性。 包含如图商品和帖子的各类行为文本，目前数据在逐渐补充中。

运营会整理不同领域的关键词词组作为输入, 匹配到关联度高的用户关联上领域标签特征。 要实现兴趣标签的产出, 要解决三个问题: 存储、检索和相关度计算。 

兴趣标签产出（方案一）


如图方案一是最初设想方案, 整体流程如下:

• 关键词结构化: BI同学完成行为文本明细的处理, 包括数据源归一、去重和UDF处理分词, 并根据关键词频次和预设权重算分。 输出结构化后的用户行为文本明细, 包括用户ID、实体ID、关键词列表和关键词对应的分值列表；
• 打标规则DSL化：对运营输入的行业兴趣关键词组进行分词后转成数据库可执行的DSL；
• 兴趣用户DUMP: 执行DSL检索出与输入关键词匹配的结构化行为文本, 进行用户去重, 完成用户兴趣标签关联；
• 人群圈选: 基于用户兴趣标签和其它特征数据做交并差后导出最终人群, 该步骤是在二方人群圈选平台进行；

整个方案是可行的, 而且具备很好的灵活性, 离线部分可不断完善和丰富结构化行为文本, 工程测专注于DSL可视化优化和整个数据流的流转提效, 整个平台可以良性迭代进化。 但是该方案确难以实行, 主要存在以下问题:

• 能给的工期短, 要求2到3周完成所有链路功能上线并支撑业务验证, 实现该方案是几乎不可能的；
• 存储成本巨大, 测算大概需要30PB的在线存储资源, 这对于一个未验证价值的业务来数也是不可能申请到的；

有同学也许很快发现, 从文本结构化到检索特定兴趣用户的过程不就是一个可以用搜索引擎实现的业务场景吗？ 最大的问题仍然是预算问题, 搭建搜索引擎也是个不小的成本，而且从搜索引擎dump大量数据存在着严重的性能问题，同时也无法支持BI同学在整个流程中进行优化。 

搜索引擎基本流程


在线方案是比较理想的, 可以实现运营利用自己的行业经验自助完成兴趣标签关联和人群圈选。由于上述客观条件限制, 最终我们选择了离线关联用户和兴趣标签的方式, 快速接入部分兴趣标签, 而后逐步推进在线方案的方式。 这里得益于BI同学全面的能力, 完成了“离线搜索引擎”, 以及未雨绸缪沉淀了部分用户兴趣标签。 这样整体方案就是这样的：

• 离线处理非结构化文本，通过去重、分词和算法得到结构化文本（该步骤与方案一相同）；
• 整理领域标签关联的关键词词组
• 离线计算方式检索匹配关键词词组的用户

方案二的最大弊端就是通用性没方案一高，每个兴趣标签的产出需要BI开发，只能满足T+1的实时性。但也一些优点，离线存储成本低，离线计算可支持自定义复杂UDF。离线部分更详细的介绍可以参考数据团队的兴趣标签体系实现介绍。

兴趣标签产出（方案二）

投放实现

投放分为离线和在线两部分, 运营维护的投放配置存储在RDB (关系型数据库), 需要同步到数据仓库, 离线计算完成用户与兴趣主播关系关联, 形成<用户,兴趣主播列表>关系。 关联的数据同步到在线图关系数据库, 提供算法在兴趣主播中推荐。 整个数据链路需要自动流转, 尽可能及时:

• 在线配置无法做到实时同步到离线, 目前每一个小时调度一次, 达到准时时要求；
• 离线任务之间通过依赖任务驱动, 基本能满足准实时行要求，并每次全量更新“用户主播兴趣关系”新增新分区，同时增加与新分区时间一致的done分区；
• 离线数据同步到在线图数据库是基于数据交换组件, 会定时检查离线表done分区, 有新done分区则会通过同步消息机制进行对应相同时间分区的全量数据更新；

4. 首页效果

在三周不到的时间，完整链路的平台实现并上线，运营人群圈选、投放配置可在分钟级内完成上线。
对部分领域的头部直播在首页进行试投放后，效果明显：

• 所有头部直播间，UV点击数远超目标；
• 对比大盘，试投放大部分领域PV和UV的点击转化率得到显著提升，最高达到倍数提升；

5. 展望

整个项目由于时间比较短, 实现的是兴趣直播投放功能的最小集合, 以支持快速验证并得到较好反馈和结果。在此雏形上，未来会逐渐完善和丰富其能力：

• 在对接BI兴趣标签的基础上, 需要不断丰富对接兴趣标签等各维度的特征数据能力，同时支持运营同学自助产出通用兴趣标签以及其它特征；
• 丰富对资源位的投放能力支持，并具备多维度AB方案和多指标通用报表分析能力。能支持更多业务的快速尝试、快速反馈和快速调整；
• 沉淀和抽象出核心链路, 不局限于支持直播业务, 可以平台化支持更多的社区和非社区业务。同时在理解用户兴趣的基础, 更好的支持理解内容, 实现内容结构化, 实现用户和兴趣内容的低成本运营；

原文链接
本文为阿里云原创内容，未经允许不得转载。