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

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

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

本次分享包括以下方面：

一、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自己，再到发言，其中包含了两次首帧发送，每次首帧发送都是一个样本，这一点在指标定义中非常重要，要找到最小行为粒度并将其定义为最小的指标粒度。

这是典型的成功率指标的计算模型，从过程开始到成功/失败/超时，成功后还有其他事件。但计算指标的时候只会选取B事件或者A/B1事件，如果不考虑所有的ABC三类事件，指标很容易随着日志上报量的波动而波动，考虑所有ABC事件是和用户调用API行为完全对齐的，不会出现用户已经无法进房，而指标仍然99%的情况。

RTC指标中有许多阈值，最简单的是音频卡顿率阈值，业内音频卡顿率一般是80ms、100ms、200ms，我们定指标的时候如何判断阈值呢？RTC主要使用Opus编码器，编码器出现卡顿时会有补偿，当补偿到4帧时，它会把声音分为清音、谐音和噪音进行编码，谐波的衰减系数已经降到0.48，一般衰减系数降至0.5以下，其实已经完全听不清了。所以最多补齐4帧，也就是80ms，正常人说话发一个音节的声音也是80ms，可以理解为，当发“和/he”的音时，如果“h音”出现了卡顿，那么对面听到的就是“额/e”，如果大于80ms，声音已经发生了偏移，不是原来的声音，这是无法接受的，所以我们在定义指标的时候针对此原则确定最小阈值。

做出指标体系后，如何对其进行打磨？这个过程持续了大概两年，原理是当一个指标非常稳定的时候，它是符合正态分布的，也就是3倍标准差范围的概率是99.7%，也就是说一旦超过了3倍标准差的范围，那么会有99.7%的可能性出现了问题。

去年5月19日，我们的5s进房成功率变为99.3%，拉长看好像没什么问题，但将其单抽出来，可以看到前14天的平均值是99.342%，标准差是0.013%，监控阈值判定是99.303%，也就是99.3%的实际值中有超过99.7%的可能性是线上出现了问题，根据当时的归因，5月19日的ICE建联获取节点失败也在上涨。我们由此牵引开始排查，发现服务器上线了一个概率非常小的bug，有一定的可能拒绝连接，影响进房成功率不到0.01%。这正是因为指标非常准确，及时发现问题，才能够避免它在线上一直存在且随时可能爆发。

指标体系分为三类：直接指标、间接指标和异常特征库指标。

直接指标包括进房类、首帧类、Crash等，间接指标包括卡顿类、延迟类、CPU、内存等，两者是0和1的关系，对单个语音用户来说，进房要么成功要么失败。而间接指标如卡顿可以是50ms、100ms等，是一种程度的关系。

异常特征库指标解决的是QoS指标无法覆盖的无声问题、噪音问题、回声问题等。

本文分别通过举例具体介绍这三类指标。

进房类指标对用户来说进不去房是最大的的体验损失，最初对接抖音的时候，对方提出的要求是任何一次进房失败都是不可接受的，而当时我们的结论是，这样的要求也是不可接受的，甚至认为这是不可能的，于是我们理直气壮地和业务方PK。

PK的结果是抖音给我们看了连麦的流程图:用户A邀请用户B后，业务侧转发给B，AB一起进房开始连麦。然后抖音提出两个问题，第一，如果说断网是由于网络不好，那为什么前面的业务请求都是好的，却总是在你这里断网？第二，一个开直播都卡的用户，为什么要去连麦呢？他不应该先解决直播卡的问题吗？

我们认为业务侧视角的解读很有道理，于是定了一个目标，实现进房成功率100%。

经过分析，我们认为要扎扎实实做好拆解与归因，典型的例子便是“ICE建联失败不等于网络不好”。在之前排查case的时候，大部分建联失败的原因会归结于网络不好，但业务方并不认可这个结果，他们认为是业务内部的bug导致失败。

后来我们内部明确了一个观念，分析指标的时候，拆解和归因完全是两件事情，ICE建联失败只能说是一个步骤的失败，并不能说是这次失败的原因。第一步要明确拆解的步骤，在做进行具体归因的时候需要达到“技术认可，业务理解”的标准，如果业务不理解，只能说是技术的“自嗨”，如果技术认可，业务理解，那么便可以达成共识并为此100%努力。

关于上文业务方提到的网络问题，后续的解决方法是我们在进房的同时会发出标准http请求，标准到完全和业务方对齐，覆盖全球30+域名，每次请求至少选中3个域名，当这些请求失败时，我们认为业务网络不通是由用户网络不通所导致，这次的归因也得到了业务方的认可。相应地便有了第二条归因：http成功但ICE建联失败，这是技术和业务都认可的，是技术内部的bug，需要继续优化，这是因为ICE建联本身应该比http更易成功。

此外还有一些归因：在欧洲比较常见的，用户只支持ipV6导致的失败；用户调用的时候有bug，导致在进房的同时出现crash；域名质量不佳等。

进行了以上工作后，我们能够回答两个问题：
①对抖音来说，距离100%还有多少优化空间？
②对其他业务来说，距离抖音还有多少优化空间？之前针对这个问题的回答是，进房率优化到99%就达到了抖音水平。但业务方会说，他们的用户是高端用户，进房率应该高于99%。如何回答这个问题？

间接指标对于单个用户及不同场景来说标准各不相同，比如主播PK和语音聊天室对卡顿的忍受程度完全不同，前者主要为了提升人气，一旦和主播连麦的时候，对方出现了卡顿，他很可能会结束连麦，换下一个人PK，但后者更注重聊天室积累，主播可以和观众聊一整天，不会轻易的换房间。再细分到语音聊天室会发现主播和嘉宾对卡顿的容忍度也不同，主播为了保证直播间热度，出现卡顿的时候不会轻易离开，但嘉宾可能会直接更换聊天室。

对此，我们制定了一个目标，找到一种能够尽可能适应多场景的衡量用户不爽的方法。

上图是站在用户的角度，根据不同的卡顿累计时长及严重程度，用户做出的不同反应：

• 一点点卡顿如100ms时，用户无法感受到；

• 卡顿大一点在500-700ms时，用户会忍一忍；
• 持续秒级的卡顿时，用户虽然发牢骚，但还会坚持看；
• 卡顿达到5s以上，大部分用户会选择退出重进或直接结束；
• 多次持续的卡顿时，用户会试着进行反馈；

• 当反复重试都没用时，用户会认为该服务不行，不再使用。

而业务侧视角则是一直有反馈，此起彼伏，且留存及连麦平均时长降低。连麦平均时长可以作为重要的和QoS打通的QoE指标，原因是当一次连麦不爽的时候会再连一次，一段时间内连麦次数多了，相应的平均连麦时长自然会降低，业务的指标就会向下走。

在上文的反应链下，我们大胆假设，首先明确什么是QoE？我们唯一能够控制并能用自己的锚点能够表述的就是“用户退出”动作。

卡顿时长逐渐增长时，退出的比例如下图所示，刚开始用户感知不到，退房用户比例很低，而随着卡顿时长增长到某一点时，大部分用户便开始退房，斜率会增大到极值。达到此点后，会发现有些用户对卡顿无感，他们由于一些固定的原因而必须连麦，比如参加早会，早会的内容如何不重要，重要的是参加，此时卡顿再严重，用户也不会退房。我们发现，不同的场景都会有一定的堕化比例，所以最终选择用户行为的敏感点作为卡顿是否影响用户体验的阈值。

以上是整体的假设，图中是具体到抖音中的数据。

1v1PK对卡顿非常敏感，在2s左右便出现用户大规模退出重连，主播基本没有曲线形状，他对卡顿容受程度非常高，嘉宾的忍受程度介于1v1 PK和主播之间。中间是抖音的IM通话，这里主叫和被叫的曲线完全一致，代表场景完全一致。

这张图最有趣的在于不会随着时间而转移，无论是每个月的第一周，前半年还是后半年，在不同时间段验证，这张图都几乎重叠，完全和用户体验场景和APP对应的用户群体相关。

我们在此基础上根据每个图算出敏感点，以此为基础，分析超过敏感点的卡顿原因并做拆解，得到以上两图，并指导用户进行线上优化。这样可以得到更容易引起QoE变化的结果。

在支持各种业务包括内部创新业务、保密项目及对外的toB业务时发现，业务方对我们用QoS指标做出的东西并不感冒，他们之间存在很大的Gap。C端用户很容易用QoS指标衡量，但B端业务方会受到关键人即老板的影响。我们经常收到一些反馈说又卡了，需要排查原因，于是业务方便认为我们的RTC不过关。还有一种情况是，部分用户会自行反馈或APP自带反馈功能，当我们拿着很好的QoS指标跟业务方沟通汇报时，他们只会质疑，这么多的反馈，你跟我说质量变好了？

一开始我们认为业内都用QoS指标衡量系统质量，怎么在这就和业务方说不通呢？经过分析得出这类case有三个特点：

①很难用指标来衡量，因为每次问题都是随机的；

②我们与业务方都有可能出现问题，也许是业务方调用错了或是调用的时候改变逻辑才导致了问题；

③量小虽然不影响线上指标，但很影响用户体验，对单个用户来说，他发生较大的卡顿并且都开始反馈了，说明在他自己的场景下很容易闭线，这是非常严重的问题。

为了解决此类问题，我们分析了许多类似的case，得出了“用户比老板更早发现问题”的结论，老板发现的问题都在之前的用户反馈中出现过，没有重视的原因是反馈体量较小，数据量波动较大，很难抽取有用的信息，而且对反馈不太关注。于是针对反馈，我们做出了一套异常特征库指标，希望它能够体验用户的评价体系。

能做成这套指标的基础是抖音集团的特点——在意用户反馈，我们公司的食堂屏幕会无删减地播放用户反馈。

在此之前，我们统一了抖音集团的所有实时通信相关反馈并将其分类。

其次，抖音集团每天线上的反馈多达3W+，都是用户一个字一个字打出来的。我们将其细分维度分析依然很稳定，这对后续分析帮助很大。

我们还设计了一套流程：单个用户做反馈时，会有一波人对其进行分析，再落到异常特征库中，通过两套系统的调用，智能服务助手主动发送给SA，SA能够直接和用户沟通，并根据客户的特点将信息转换为服务落实下去。

这里的关键在于两点：

• 第一点是定义概念：“问题”包括无声问题；“反馈”，无声问题对应的反馈包括“我听不到对方”和“对方听不到我”，看上去没有区别，但这两个bug在同一优化上的走势是完全不同的；“现象归因”，比如audio_level==127是无声问题最重要的现象归因，即采集音量为零。对应采集这一现象归因后便是第四点，“技术归因”，如无声问题，光是audio_level==127就有30+个归因。
• 第二点是归因标准，我们之前也将反馈内容抽象出来作为标准规则供大家使用，但存在的问题是标准是否通用或是反馈强相关？对此，我们定了三个强制标准：
• 目标用户反馈率高于整体反馈率1倍以上，右图是实际内容，大部分反馈的归因对应的反馈率是整体反馈率的2倍以上，最高的达到8倍，说明这一特征对应的无声反馈最明显，基本出现这个特征便会出现无声问题。
• 迁移到有录制的场景，回放人工验证>80%，由于底层的埋点是通用的，所以在某一场景发现问题后，如在会议场景下很难验证此归因是不是无声的，往往只有看录像才能验证，但会议又不可能保留录像，于是我们把会议规则迁移至有录像的连麦场景下，通过人工验证的方式验证规则是否准确。所有的规则要求验证时准确率>80%。
• 整体覆盖率>95%。前两项标准是为了说明归因的规则和无声的反馈是非常强相关的，而这一项是为了能将以上规则拟合成QoS指标，和QoE反馈的动作强相关。

图中是通过反馈优化发现的问题，如“组合必然无声”体现的是产品兼容性问题，这是代码迭代过程中出现的，当时的无声反馈突然增多，于是在业务方反馈之前便排查并修正了bug。还有一种无声问题是由业务方调用或客户设备所造成，典型的是麦克风被占用。右图是收到了啸叫反馈，许多用户没戴耳机使用电脑开会时，会和会议室的设备产生啸叫，此时系统会主动提示“是否采用无音频模式入会”，由此解决问题。

8月12日 11:40  自发巡检发现抖音无声反馈升高

8月12日 11:45  根据技术归因大盘，明确为“采集帧率异常”和“首帧发送异常”，此时前者持续增高，后者开始回落

8月12日 22:31  明确为“首帧发送异常”之前已经处理问题。当前主要为“采集帧率异常”（若非进行了细致的分析，此时会得出和供应商相同的结论，“问题已经解决了，再观察两天”）

8月16日 00:15  明确为业务调用问题，RTC没有实际问题

8月26日 17: 24  业务方复现并明确了问题，由于他们调用多线程，导致在接电话时会给客户设置Mute

9月14日 bug接触之后，“对方听不到我”的反馈率下降，“我听不到对方”的反馈率无明显变化，并且产出新归因——采集启动失败

10月12日 规则 review 过程中，修订规则为“同一用户连续多次连麦，首次正常，后面无声”，因为“首次正常”代表客户设备没有问题，而“后面无声”代表某一环节出现了问题

11月20日 明确规则后放入特征库，发现某内部创新业务同样存在问题，已经优化上线

LiveVideoStackCon 2023上海讲师招募中