优酷视频互动曝光率优化实践

一、背景与简介

优酷的视频互动是在播放页横竖屏弹出的互动浮层，旨在让看片更有趣。现有投放评分、高级弹幕、特效广告、子母屏双视频流等运营及广告活动，以及基于 AI 的场景互动，投放效果如下图。

针对这些大量的投放活动，为了衡量活动曝光的质量，我们定义了互动曝光成功率：

曝光成功率=互动实际曝光数/互动应曝光数

通过添加技术埋点，我们统计了现有互动平均曝光成功率在 97.7%，即互动投放后，大约有 2%的用户是看不到的，虽然投放的主要都是 weex/h5 活动页，但是投放失败的比例还是偏高的。为此，我们花了一个多月的时间，分析了链路问题，来优化曝光成功率。

二、优化策略

互动业务曝光分脚本数据获取、插件预加载、插件加载渲染显示三个阶段，在接手业务后，我们首先添加了相关节点技术埋点。通过分析技术埋点和 TLog 日志，发现加载失败主要有以下三种情况：

1）加载超时；

2）weex 和接口业务错误；

3）数据统计不准确。

查看日志，大部分还是超时问题，直接错误占所有错误的比例只有 10%左右。于是，首先来解决的是超时问题。

1. 超时问题

1）预加载时间增大

我们首先拿评分 weex 页加载时间区间分布来分析，从技术埋点统计的加载时间范围看，90% 区间最大需要 457 毫秒，但是到了 99%区间大约需要 17 秒。这里可以看到 90%区间并不能准确衡量业务的好坏，之前配置的 5 秒预加载时间明显不足，导致超时问题一直较多。现在 weex 和接口的预加载时间都调整到了 20 秒以上，确保 99%的用户都可以加载完毕。

2）补齐 zcache 配置

由于投放的 weex 活动页是由多人开发完成的，实际看投放的 weex 页面，发现部分老页面、新页面没有配置 zcache，导致曝光成功率不足 96%，于是找到相应的 weex 开发，跟进配置 zcache。

3）提前触发 zcache 下载

通过观察了多个 weex 页面，发现 zcache 命中率都在 80%左右，现象就是用户在第一次弹出互动时，基本无法命中 zcache，而在没有 zcache 时，页面加载超时的问题就很明显，不解决 zcache 命中率问题，曝光成功率很难再提升。我这边想过几个策略：

方案 1：调整 zcache 优先级，强制更新和全网更新；

方案 2：预置 zcache 到 apk；

方案 3：提前触发 zcache 下载。

方案 1 并不适合互动这样的普通业务，方案 2 因 weex 业务代码更新涉及到重新配置及老版本兼容问题，操作麻烦，而且会增大 apk 大小。后来想到只需要在进入播放页时按需提前触发 zcache 下载即可，于是去查看了 weex 加载链路源码，发现确有 zcache 下载能力接口，于是增加了进入播放页后有相关互动立即提前下载对应 zcache 文件，来提升 zcache 命中率。

从线上发版数据看，weex 页的命中率从 77%提升到 98%左右，首屏平均时间减少 40%，既解决了部分用户的超时问题，也解决了所有用户首次渲染时间问题，提升效果明显。

同时从曝光数据来看，zcache 命中率提升到 95%后，相关互动曝光成功率大约提升了 1%，普通 weex 页面经此优化曝光成功率提升到 99%左右。现在 zcache 预加载能力已经沉淀到互动引擎，在以后的互动活动，及其它 weex、h5 页面都可以使用此能力。

4）超时补偿

现有预加载能力，可以保证互动准时弹出，但是也有一个很明显的缺陷，有时间限制，超时即认为加载失败，针对部分不需要准时弹出的互动，超时就认定加载失败，是不太合理的，因为这里大部分还是可以加载成功。于是我们在预加载逻辑里新增一个策略，如果超过一定时间，还未预加载完毕，允许 plugin 直接弹出，等待 weex 页面加载完毕。目前评分业务已使用了此策略，另外双流业务也存在同步超时问题，android 端同步问题比 iOS 端高的多，我在双流同步时也增加了超时认为同步成功的补偿逻辑。

2. 错误问题

1）weex native 错误

新业务上线时，往往存在很多 js 错误，这期跟进核心互动评分、tips 互动的 weex 页面 js 错误修复，反馈给对应开发来解决。目前 weex 核心页面（评分、tips）暂无业务错误，不过还存在少量的白屏错误，后续待继续优化这种容器层的 js 错误。

2）异常率

我们每期都在跟进互动业务 crash/anr 问题解决，但是实际分析曝光链路过程中，发现相邻两个阶段总是会有少部分数据丢失，但是没有 crash 信息。我从分析代码链路看主要是 try catch 导致链路断掉，于是想到来治理 warn 问题。业务内有很多 try 代码，仅仅是为了避免出错时影响播放业务，但是却没有来解决这些警告。这些警告却会导致互动曝光失败，因此在 catch 之后统一执行异常上报，在 appmonitor 上报异常名称，详细错误日志写入 TLog，这样可以统计警告个数。上线后统计警告数据如下：

实际上线后发现确实存在不少空指针、多线程异常，尤其是多线程 list 读写异常，影响了插件生命周期。我在新版本解决了这些警告。只有数量无法分析某个版本的好坏，于是参考崩溃率，以初始化个数为分母，计算出警告率，可以来衡量各版本警告的指标。

优化一版后异常率从 1.085% 减少到 0.052%，解决了长久以来一直存在的多线程轮询时的 list 读写异常。现在只优化了主要的几个问题，由于在定位过程中发现从 TLog 拉取历史日志，存在设备不在线、数据丢失问题，使用不很方便，后面考虑把错误文件名、行号同时上传到统计后台，方便快速定位问题。其他业务如互动这边弹幕、评论等业务以此为参考，重点治理下警告问题。

3. 互动容器 bug 及数据统计校准

针对曝光成率统计，双端统计分子实际曝光数没有问题，但是在统计分母应该曝光数时，都存在统计不准的问题，为此我们双端讨论并约定分母中，去除了无网导致的预加载问题、音频模式不弹（设计约定）、互斥不弹、未登录用户态导致的不弹、黑名单配置等干扰数据统计，同时解决了分母重复统计问题，跟进播放器解决推荐广告导致的首次不弹 bug，确保双端数据准确、标准一致。

三、总结

本次曝光成功率优化，核心业务的成功率都提升到了 99%以上，主要使用了以下三个策略：

1）提前预加载；

2）增大预加载时间；

3）增加超时补偿逻辑。

同时解决 weex 错误、客户端的错误、警告，补全了互动监控、预警能力，监控并保障投放活动的稳定性，沉淀了 zcache 预加载能力、异常率指标。

通过此次优化，从互动平台角度解决了现有的互动曝光率问题，完善平台化能力，确定了业务投放衡量标准，以此来推进提升及保障各互动业务的质量。

作者 | 阿里文娱高级无线开发工程师 凭海