RTC 体验优化的“极值”度量与应用

随着线上互动需求的增加，直播连麦、语音/视频聊天的应用越来越广泛。我们一直在说“追求用户的极致体验”，但是体验是一个抽象的概念，很难量化和统计。如何从用户的行为中得到所在场景的优化“极值”，如何依据“极值”建立统一的质量指标体系以指导业务优化？如何迁移抖音的服务经验，满足toB用户的体验需求？LiveVideoStackCon 2022北京站邀请到火山引擎RTC团队负责人——杨智超，为大家介绍在实时通信场景下火山引擎RTC对体验的理解与应用落地。

文/杨智超

编辑/LiveVideoStack

大家好，本次和大家分享的题目是RTC体验优化的“极值”度量与应用，重点在于“极值”二字，因为RTC很多时候很难定义体验天花板，如何通过数据手段定义天花板并指导团队进行极致体验优化？

我是杨智超，火山引擎RTC体验团队的负责人。

本次分享包括以下方面：

一、RTC指标体系及目标；

二、直接指标的“极值”探索-以进房为例、间接指标的“极值”探索-以卡顿为例、“异常特征库”指标：这三类指标在日常的使用和分析过程中的思路不同；

三、体验优化的能力迁移与最佳实践：用实例说明以上三类指标如何提升用户体验。

-01-

RTC指标体系及目标

为什么要花大精力做指标呢？因为很多团队做RTC时在指标体系花的精力并不大，很多是算出来，我刚进字节的前两年管理RTC供应商，他们为我提供了非常多指标，但在过程中遇到了一些事情让我意识到指标的重要性。在一次重大事故中，抖音连麦持续40+分钟无法成功进房，只能直播无法连麦，而进房指标依然99%+，我们对此表示怀疑，供应商提出的理由是一个旁路服务器出现了故障，但这也同时体现出了指标定义的问题。

在日常工作中，即使整体的服务业务没有波动，指标有时也会持续变化，且变化的范围在绝对值20%-30%。直观地看来是服务业务的某一环节出现了问题，但在实际排查后得到的回应往往是没有达到阈值，暂时无需关注。当达到阈值后，又会发现供应商侧的报警形同虚设，也无法排查出原因，此时得到的建议是再观察两天，而最终结果要么是过两天指标自动恢复正常，要么是持续处于高位，供应商便会问我们的用户体验反馈有何变化，如果没有变化，那就直接调整较高的阈值后继续观察。

在多次发生此类事件后，我们便开始自己做指标。经过两年的沉淀后，指标体系也变得“稳、准、狠”。

• 稳——极小波动，月初14日的核心指标的方差<0.003，选取月初14天的原因是国内套餐在月初14天的网络波动较小。非核心指标包括进房、80ms音频卡顿及500ms视频卡顿的方差基本在万分级的水平波动。

• 准——波动即有因，在出现问题时要找准大致方向排查原因，在进行了大量的归因分析后，我们定下了归因比例>95%的目标，只有达到此水平，才能看出指标的整体波动趋势，有章可循，反之没有分析出原因的波动是无意义的。核心指标的归因比例如进房达到98.23%、80ms音频卡顿是94.92%，这个比较低，因为小的卡顿没有必要归因，500ms视频卡顿是97.36%。

• 狠——有因必有果，报警的时候必须查明原因，近一个月的报警次数是41次，近一年能查出确切原因的比例是92.7%。

指标做“准”的要求有三个：

• 目标清晰。这是非常关键的一点，对于RTC来说，目标包括相背的两方面：一个是商业化，要求指标尽可能准，波动不大；另一个是敏感，只要出现问题，就要提前出现波动，能够展示每一个case并分析原因。我们调研市场中的其他方案，他们都将其当成两套指标执行，但我们在拉着产品和研发讨论后认为要做成一套指标，将另一套指标的经验放在这套指标的研究上，争取把这套指标研究透彻，向业务方展现更多细节，使其更加信任我们。

• 态度。每个数据的问题是否能在下一版本上线？火山引擎本身非常关注AB实验，大家对数据的需求非常重视，这点做的非常好。

• 落到实地。我总结要将指标做准的三个词，最小行为粒度、API行为对齐、对其体验感受的最小阈值。

在会议场景中，从进房到发言、Mute自己、Unmute自己，再到发言，其