多屏云视听小电视渠道用户承接思考与实践

原创何化钧哔哩哔哩技术

本期作者

何化钧

哔哩哔哩资深开发工程师

一、背景概览

1、背景

云视听小电视作为一个发展迅猛的APP，是多屏部门主要产品线，会安装于各电视厂商的智能系统上。用户通过点击端外的资源位进入小电视APK（外唤）或者直接打开小电视APK（主启），这两种方式进入端内，来消费各种视频资源和信息。在此商业逻辑链条中，涉及端外投放拉新拉活获客，进入APK后端内承接，浏览消息过程中用户体验，以及退出时用户的整体观感，对活跃过的用户预期召回等很多要做的事情。本文中我们主要关注渠道用户通过外唤或主启的方式进入小电视后，在用户全链路的生命周期过程中，在各个节点上，对用户进行更好的承接，让广大用户更加喜欢我们的产品。

2、目标

云视听小电视历经多个产研走转，本身就存在历史技术债较重，数据埋点缺失较为完整工业化体系的问题，而做好渠道用户承接首先就需要做好用户数据的全链路跟踪，看清用户的行为。之前的客户端埋点数据存在以下问题：

用户访问难量化 - 客户端埋点并未有用户访问的标识，只有设备ID单天访问页面的时间线，难以准确量化
用户路径难跟踪 - 客户端spmid埋点体系下，设备ID粒度比较散，串联用户访问页面成本很高，需要耗费大量BI数分人力
用户承接也缺乏分析抓手 - 用户承接数据分析缺乏具体的有效抓手，仅限于有限场景下具体分析

这些问题会阻碍我们对用户行为的清晰认知，也让用户承接只能通过一些后向统计数据进行。

另外一个问题是之前外唤用户缺乏灵活的承接策略执行，每次执行用户的外唤承接策略都需要走跟版发布

故结合以上两点我们目标总体来说是

数据精细化基建：清晰提供生命周期会话级别的用户访问全链路精细数据和用户访问路径数据
提人效 : 运营同学用户承接找到分析的抓手，提给给运营同学直接的分析平台，能直观地检索到用户行为数据
提产效 : 对外唤用户提供常见的可配置化用户承接策略能力，帮助策略产品和运营快速验证和实现自己的产运策略

二、方案设计

1、流程概览

流程简述

为实现以上的目标，我们参考业界常见埋点实践方案，设计一套以session_id和投放ID为核心串通数据的埋点与分析处理流程。其中投放ID是由我们内部渠道投放平台生成的某一次端外投放ID，作为产运回收投放效果标识的唯一ID，在本文中暂不详细展开说明；而本文主要关注的session_id来自于每次APK冷/热启动时，服务端下发的一串数值，作为用户该次生命周期的会话ID。从数据流程视角看，如上图所示，session_id的生命周期控制由端上控制，会在APK启动后在各个业务接口的HTTP头中带上，准备服务端的各个接口的前置拦截层会将该ID进行收集上报，当然如果是外唤情况，会将投放ID一起关联上报。之后，session_id进入服务端的承接策略层，该层承担着外唤OLTP处理的功能，根据用户请求的参数和运营配置的承接策略，以内置的外链干预模块为抓手，执行相应的承接动作。session_id上报进入数仓后，服务端和客户端的ODS层用户会话粒度的数据就绪，会持续进行OLAP处理，在客户端测埋点，会有BI同学进行日常的数据挖掘工作。在服务端埋点测，我们会根据会话数据，做相应的分析聚合固化，可将分析数据平台化工具化；另一方面，会根据数据进行算法处理，将用户访问场景还原，做对应的BI视觉化；最后session_id随着下游的rpc服务，进入rpc链路的上报，以便根据访问时长等信息做一些技术向优化，不过本文主要关注用户承接方面工作，这里并不详细说明。

所以整个流程可以分为四个主要环节：数据产生、数据收集、外唤OLTP处理、OLAP处理

1.1 数据产生

每次APK冷/热启动时，服务端下发用户session_id，并且将投放计划与session_id绑定，通过下游服务端接口全链路埋点上报，完成接口粒度访问数据采集

1.2 数据收集

服务接口拦截层将用户session_id上报到各个ODS表中，并且客户端会将session_id打入埋点上报播放行为数据，完成用户播放行为串起采集

1.3 外唤OLTP处理

服务端承接处理层会根据YST外唤和主启，执行运营、策略向的各种承接需求，会在用户整个冷/热生命周期中，执行相应的用户承接动作

1.4 OLAP处理

客户端埋点可做日常数据挖掘工作
对HTTP的ODS表进行聚合处理，将用户数据查询和分析工具化
利用HTTP的ODS表中接口时序访问数据，尝试算法动态滑动窗口和AC机森林进行场景还原，做BI的视觉化工作，比如完成用户访问的桑基图

2、实现细节

2.1 数据产生

在客户端的外唤和主启时，会用一个ID标识当前整个用户的生命周期，包括冷/热启动，而该ID是由服务端根据设备请求公参，生成的MD5值，作为整个云视听小电视的会话ID，将会作为整个用户全链路追踪的唯一标识，这里接口的调用时机完全由客户端来控制，服务端主要负责生成和下发

投放ID主要由渠道投放平台产生，包含该次投放中的所有重要信息，与会话ID关联后可将用户外唤与会话信息串起，本文暂不详细展开说明

2.2 数据收集

在客户端请求下游的业务网关时，会在HTTP头中带入会话ID，并且能够带入端外投放的ID，整个链路上，会使用BM的拦截器去收集每一次业务接口请求中的session_id，并将相关的请求私参与session_id上报，同事传递到下游的RPC的头，GRPC框架的拦截器也会收集session_id并和rpc的入参并上报。这样每个用户每次的业务请求都进行服务端埋点上报。

2.3 外唤OLTP处理

在外唤用户进入后，客户端接口调用链路中，跳转外链干预会优先调用，获取到策略化干预之后的外链才执行后续业务动作，在这里用户承接可以实现在配置后台中灵活配置，并进行外链跳转干预，对不同的用户群体就能执行不同的承接策略，常见的是用不同的落地页承接用户且展现细节可以有不同区分。如下图是策略承接层的一个典型的干预模块

2.4 OLAP处理

数据挖掘

客户端埋点的日常数据挖掘工作本文暂不展开说明

场景还原

场景是指用户在一个会话生命周期里，从开始到结束期间在小电视内不同分区模块之间进行切换，播放等访问场景。在数据收集到数仓后，由于是服务端收集到的接口层面的细粒度数据，新老版本多样，客户端很难为单独接口打上场景标签的情况下，并没有带入用户页面场景跳转信息。而运营在直观分析时，是以需要参考当前用户访问场景的。比如用户这次跳转什么地方，请求了什么接口，故我们需要根据接口访问时序，将单session的访问场景进行还原。这里本质上是一个离线数据模式串匹配的算法问题，故我们将每个接口进行序号化（比如a），几个序号组合定义为一种模式串（比如bdc）定义清楚模式映射的场景（比如ac→详情页起播）。故就能通过滑动窗口+AC机森林，能识别出对应的跳转场景，这里我们使用Spark的批处理脚本，进行模式识别。以上流程输出基本的场景还原数据后，其中一部分数据简单聚合，结合用户画像的维表信息，就能为产运提供有价值的用户访问日志信息；如下图，是OLAP处理其中BI视觉化的前置工作，在同步到BI平台前进行场景还原的调度任务图

如下图所示，我们根据某些客户端版本，定义接口组合到场景的映射

算法实现采用滑动窗口+AC机森林，解析出离线接口序列对应的场景序列，具体过程就是用spark的脚本按每个session_id聚合出单时序数据，在单条时序数据中用滑动窗口去识别，每个滑动窗口内用若干个场景识别的AC机去多子字符串匹配，最终输出场景的时序

示意如下图

BI系统视觉化

洗出用户承接step中前5的数据到hive表，并同步到BI系统

用户数据分析平台化

我们将用户按会话的粒度进行聚合后，结合用户画像的数据，加入一些产运常见的查询维度，可将数据分析工具化，如下图所示用户路径分析平台（红色部分属于敏感信息）

同时该平台可按会话ID下钻数据，结合之前的场景还原数据，可按单会话场景路径Track用户的访问路径（按场景访问时间戳正序）

3、用户承接优化案例

在以上的数据基建下和用户承接层设计下，可以衍生出一系列的承接方案和执行策略，本文挑选其中两个作为case来简单阐述

案例1：渠道退出挽留弹窗

产品根据承接流失的情况，提出的一个策略需求，具体来说，根据BI系统视觉化中的示例图，发现在所有渠道上，外唤用户每一步都有一定比例的流失，尤其是在step1，刚刚进入端内后，haixin渠道大约有1/5就退出了。故产品在step前置的路径上，在用户做出退出APP动作时，通过挽留弹窗策略来降低某些人群的流失率，给对应的人群配置感兴趣的弹窗内容（比如用算法多卡计算出人群的喜好OGV）就能提高用户留存。下图是运营配置的平台界面，其中干预项中是包括人群在内的细节配置。