关于react.js:闲鱼直播三周内实现点击率翻倍我们是这么做到的

作者：闲鱼技术 - 莫癫

1. 业务背景

闲鱼直播业务上线后面临的最大问题是增长问题。闲鱼 BI 同学剖析发现，比照短时观看和长时观看人群，发现两局部人群有较显著的趣味阶段性差别。
业务心愿在了解直播、主播和用户的根底依据趣味对头部优质直播精准投放, 放大头部主播马太效应实现直播转化和观看工夫的增长。

1. 指标

简略概括须要达成两个后果：

• 在三周内实现精准投放平台，积淀根底经营平台的基础设施；
• 业务上保障头部直播间场均转化 uv 达成肯定指标，转换率失去显著晋升；

那么单纯借助算法模型实现优质直播举荐，是否也能够达成业务上的指标？而后事实却是，巧妇难为无米之炊。直播上线工夫短, 播放和观看场次无限, 使得模型的训练没有足够的样本间接去了解用户对直播的趣味, 平台也未对主播直播内容做强控实现内容的结构化。那么就须要将经营对直播畛域教训与 BI 剖析、算法联合，在了解用户、直播和直播间的根底上，实现对直播间到趣味人群的投放，并积淀平台化能力。

1. 实现计划

给趣味人群投放实时直播间的第一步是要实现对人的了解，包含 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 分区则会通过同步音讯机制进行对应雷同工夫分区的全量数据更新；

1. 首页成果

在三周不到的工夫，残缺链路的平台实现并上线，经营人群圈选、投放配置可在分钟级内实现上线。
对局部畛域的头部直播在首页进行试投放后，成果显著：

• 所有头部直播间，UV 点击数远超指标；
• 比照大盘，试投放大部分畛域 PV 和 UV 的点击转化率失去显著晋升，最高达到倍数晋升；

1. 瞻望

整个我的项目因为工夫比拟短, 实现的是趣味直播投放性能的最小汇合, 以反对疾速验证并失去较好反馈和后果。在此雏形上，将来会逐步欠缺和丰盛其能力：

• 在对接 BI 趣味标签的根底上, 须要不断丰富对接趣味标签等各维度的特色数据能力，同时反对经营同学自助产出通用趣味标签以及其它特色；
• 丰盛对资源位的投放能力反对，并具备多维度 AB 计划和多指标通用报表剖析能力。能反对更多业务的疾速尝试、疾速反馈和疾速调整；
• 积淀和形象出外围链路, 不局限于反对直播业务, 能够平台化反对更多的社区和非社区业务。同时在了解用户趣味的根底, 更好的反对理解内容, 实现内容结构化, 实现用户和趣味内容的低成本经营；

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