从QoS到QoE，RTC的用户体验该如何评判？

在音视频业务中，QoS（Quality of Service，技术服务质量指标）和QoE（Quality of Experience，用户体验指标）并不是一个新的话题。相较于传统流媒体业务，RTC业务方兴未艾，人们对其关注的点从过去的QoS指标转向用户体验QoE，并进入了“数据驱动业务增长”的探索实践阶段。那么，RTC的用户体验究竟是什么？体验要如何衡量？QoS的变化对QoE的影响究竟有多少？QoS要优化到什么程度才能有效提升QoE？业内还没有一个公认的答案。

火山引擎RTC基于亿级DAU用户的真实反馈和RTC全链路质量监测数据，通过长期、大规模的数据分析、归因、验证，建立了一套“标准透明、度量准确、归因全面、预测可靠”的指标体系，帮助企业和开发者更好地关注RTC场景中的QoS及其对用户QoE的影响，有效提升平台的服务质量和运营效率。

关于QoS指标：最小行为粒度和最小阈值感受

一套好的QoS指标体系，必须“真实”地反映线上的质量情况。当线上出现因技术原因导致的用户体验问题时，QoS指标应有相应的体现。否则，研发人员即便对线上问题后知后觉，也无法快速、正确地定位问题根因。

要做到“真实”，指标定义“准确”是前提。火山引擎RTC对用户行为的全流程进行了QoS指标覆盖，并以用户的“最小行为粒度”和“最小阈值用户体验感受”进行了定义。

整体上 QoS 指标和用户行为相对应

什么是“最小行为粒度”？以“首帧发送”为例，如果以“单次通话”为行为粒度，“首帧发送”很容易被定义成“第一次进房后推流成功”，而忽略了闭麦后再开麦的推流行为（此时“用户取消静音上麦失败”不会被认为是首帧发送失败），这显然会使QoS指标与实际情况不符。在“首帧发送”这个指标上，用户最小行为粒度应该是“单次开启麦克风/摄像头”，而不是“单次通话”。

细节上 QoS 指标应对齐到用户“最小行为粒度”

什么是“最小阈值的用户体验感受”？以“音频卡顿率”为例，在实时互动场景，“200ms卡顿率”是一个比较常见的“音频卡顿率”指标。而火山引擎RTC提供的却是“80ms卡顿率”，因为科学上认为80ms是使用正常语速发完一个音节的时长，如果出现80ms的卡顿，且这个卡顿正好落在一个音节上，就可能会让用户“听不清”。从体验角度来说，80ms就是会影响用户体验的最小卡顿值，用它来作为卡顿率指标是合理且严谨的。

指标计算对齐用户行为和反馈：透明可验证

指标定义除了要对齐“最小行为粒度”和“最小阈值感受”，也要对齐用户行为和反馈，以用户触发API为事件计算，而不是以调用API结束为事件计算。以“进房成功率”为例，火山引擎RTC定义的“进房”是指包含“开始进房”这个动作的全部事件，而不是包含“结束进房”这个动作的全部事件。否则，如果“结束进房”这个动作一直不出现（比如一进房APP就崩溃），它就不会被计入“进房失败”，造成“幸存者偏差”，“进房成功率”这个指标就没有反映线上的真实情况。

“N 秒无返回”也应被认为是“进房失败”

用户主观体验QoE如何度量

QoE是用户对“体验”的主观满意度，满意度出现波动可能是因为技术问题导致的，因为房间活跃度、主播互动内容质量的波动造成的，也有可能是因为多个综合原因造成的。我们在探索QoE和QoS关联时，应尽量剔除非QoS原因引起的用户体验波动因素，否则会引入过多变量，让问题变得更复杂。

因此，火山引擎RTC在对线上用户行为进行了大量的分析和探索后，专门定义了RTC用的QoE反馈指标——当用户体验受影响到一定程度时，可能会导致用户出现一些负面动作，包括用户主动反馈、异常情况下的用户退出、退出后重新进房等，QoE指标即做出这些动作的用户比例。

主动反馈是通过在终端用户侧收集“反馈问卷”或者“提交反馈/工单”的形式来收集负反馈率指标，在负反馈中，还可以根据用户反馈时的差评标签或者差评内容得到音频负反馈率、卡顿负反馈率等，用来区分是音频类、卡顿相关类还是其他类别的主观体验的评价。

连麦结束后，抖音用户可以对该次通话进行反馈

除了主动反馈，用户自发产生的异常行为也可以作为主观体验的评价指标，例如非预期退出并再次进房、异常退出等。在某些通话持续的场景，比如1V1聊天、主播PK连麦、主播观众连麦，单次通话中退出后并再次进房是非预期的用户行为，可以标识用户的异常体验；在某个明确的客观质量受损的情况下（比如卡顿）的退出，也说明此次QoE体验很可能与QoS问题有关。

QoE和QoS的关联探索

QoE和QoS指标都可以体现和衡量用户体验及RTC质量，但单独使用却都不够全面。我们需要把QoE和QoS关联起来看，一方面分析QoE相关问题背后可能会有哪些QoS原因，对线上用户反馈的问题起到快速诊断作用；或者总结当QoS指标发生变化时会触发哪些QoE反馈与波动，对线上问题及QoS调整优化起到提前感知预警作用；另一方面，将QoE作为用户体验优化的目标，将QoS作为具象化的手段，通过优化QoS指标实现优化QoE是更可行、更高效的方法。

QoE与“直接”QoS指标的关联和极值探索

QoS指标中有一类是与用户体验直接相关的指标，比如进房成功率，首帧发送/解码成功率，SDK崩溃率等。这些指标体现的是RTC的可用性，它们对用户体验的影响是非黑即白的，因此对于优化目标也是“极致”的。以“进房成功率”为例，居高不下的拉新成本使每一位新用户的“连麦初体验”都非常珍贵，因此抖音对于“进房成功率”指标的优化“极值”也很明确——100%。也就是说，任何一次进房失败都是不可接受的。

火山引擎 RTC 把“进房”拆解为11 个步骤，抖音在每个步骤的成功率都达到或接近 100%

乍一眼看上去这个要求似乎过于苛刻，因为“进房成功率”不止和RTC有关，还和业务层调用、网络、APP稳定性等有关。但当我们将进房步骤进行详细拆解并对每一个步骤的失败进行归因分析后会发现，这个目标并没有那么不合理。当前，抖音“进房成功率”已基本接近100%，火山引擎RTC对抖音“进房失败”问题的未归因比例保持在2%以内。

抖音“进房失败”问题的未归因比例保持在2%以内

对于企业和开发者来说，比将指标的优化目标设置为100%更重要、更能落地的是，通过比较自身与抖音在同一个归因上的差距，找到自己的问题是什么，明确下一步优化空间、路径和优先级。

某 APP 对比抖音在“进房成功率”归因上的优化路径预估

QoE与“间接”QoS指标的关联和极值探索

QoS指标中的另一类是与用户体验间接相关的指标，比如卡顿率、卡顿时长、首帧耗时、端到端延时、CPU占用率等，这类指标大部分是“阈值”类指标，它们并不直接指征用户体验受到了影响。用户对这些指标具有一定容忍度，例如他们有时可以容忍“轻微”的卡顿，但一旦到了某种程度就不能忍了。但是不同场景、不同类型用户的容忍度不同，比如1v1聊天场景对卡顿的容忍度比多人聊天要低，并且这类指标优化的“极值”没有标准答案，因此企业和开发者希望了解用户体验和这些QoS指标之间的关系，以解决影响用户体验的真正问题。

我们以“卡顿”为例来探索它们之间的关系。当发生卡顿时，“用户不爽”和“卡顿严重程度”的关系对应关系如下：

用户体验QoE和卡顿程度QoS的关系

通过对QoE问题与QoS异常数据的全量归因分析，火山引擎RTC使用了“异常退出”作为标志QoE行为的锚点来衡量卡顿对用户体验的影响，发现QoE指标和QoS指标存在如下的“乙型曲线”关系：

QoE和QoS的“乙型曲线”关系

在音视频质量问题很小的情况下，绝大部分用户是感受不到体验问题的，也很少会有主观动作；当质量恶化超过某个阈值（用户行为敏感点）时，用户的主观动作比例会陡然增加；到达某个阈值（用户行为堕化点）后，质量问题对用户行为的影响开始堕化，质量再恶化也不会导致主观动作的增加。

火山引擎RTC在不同业务场景、不同时段，不同业务周期上进行了反复绘制论证，认为这条“乙型曲线”是一个适用于多场景的、描绘QoE和QoS关系的模型。尽管曲率、拐点的值会变，但一定存在这几个对用户体验产生质变影响的“阈值”，正是这些阈值，对指导用户体验优化有着非常重要的意义。

下图中，横轴为卡顿持续时长，柱状图是样本数量，曲线是退房比例，从上至下依次为1V1 PK连麦主播，1V1私聊主叫和被叫，多人语聊房的连麦嘉宾和连麦主播的异常退房比例。

不同业务场景、不同类型的用户对于卡顿持续时长QoS的QoE反馈

可以看出，不同场景和用户对卡顿的灵敏度和容忍度是不同的。1v1场景对于卡顿的感受最为敏感，特别是1v1 PK场景，卡顿持续4s左右就会有很多用户明确感知到卡顿开始退房，到20s左右逐渐稳定；多人语聊场景对于卡顿的容忍度较高，不像1v1这么轻易退房，且连麦嘉宾和连麦主播对于卡顿的主观感受模型是不同的。而对于连麦的主播来说，如果发生卡顿，他会更倾向于更换嘉宾而不是退房。无论什么场景或用户，体验无损点（最佳点）都在2s左右或以下，2s的持续卡顿就会对用户的主观体验造成损伤，我们的优化路径，应先将指标优化到用户行为敏感的点，并密切关注所有指标中最靠近用户堕化以及反馈占比最高的问题场景，最后将最佳点作为体验优化的“极值”追求。

每天3万+反馈的“异常特征库”，命中率高于整体大盘1倍

有时候，明明几个QoS指标表现都好好的，线上还是出现了诸如无声、回声、黑屏、模糊等异常反馈。这些反馈量很小却很影响用户体验，又很难通过标准的QoS指标来监控，问题可能出在RTC、平台或用户任意一方，排查起来费时费力，如鲠在喉。

在长期大规模的实践中，火山引擎RTC建立了一个超大的“异常特征库”，它们来自于字节系产品、数亿用户的真实反馈，每天的数据量达到3万+，在进行分析、归因、验证后，经一定的标准筛选进入“异常特征库”。一旦上报数据命中“体验异常特征库”中描述的case，用户主观体验的受影响程度和差评几率都远远大于普通场景。

抖音“无声”问题的未归因比例低于 2%

以“无声”为例，火山引擎RTC将“无声”问了拆解成“听不到对方声音”（上行无声）和“对方听不到我声音”（下行无声）两类，总结了mic被占用、声道选择错误、播放帧率异常等30+归因。目前，火山引擎RTC对于无声问题反馈的归因比例已超过了98%，其中，命中“异常特征库”的比例比命中QoS指标大盘的比例整体上高出了一倍，证明了“体验异常特征库”对于处理QoE问题有非常大的价值。

命中“异常特征库”的反馈率要比命中大盘的反馈率高出一倍

通过火山引擎RTC在QoE、QoS关联这个话题上的持续突破以及建设“异常特征库”的努力，当前，火山引擎RTC对线上用户体验问题的归因比例已经超过了95%。这意味着95%的问题都能快速定位到根因，已达到业内顶尖水平。

更智能、更犀利的数据监控产品——智能阈值告警

火山引擎RTC把上述这套“极致”的体验优化方法论和基于海量用户反馈、归因及验证的实践经验融入到了自研RTC数据监控产品——监控台，其“智能阈值监控”功能就是火山引擎RTCQoS指标定义准确、指征表现稳定的体现之一。借鉴统计学“正态分布”和“3σ定律”方法论，火山引擎RTC对QoS指标波动范围进行了一个理想型的预估，当RTC后台对关键指标进行定期校验时，一旦发现指标波动超出预期范围，即使指标本身未超出事先设置的预警阈值，监控台也会自动推送告警，让企业和开发者可以比用户更早地预见QoE体验问题，并及时解决。

火山引擎RTC监控台上线“智能阈值监控”功能

监控台还将陆续上线基于QoE反馈归因的“用户异常体验告警”功能和“用户反馈批量归因”功能，以及基于“异常特征库”归因的“智能诊断”功能。火山引擎RTC将不断探索更科学的数据指标分析和监控能力，帮助广大企业和开发者真正做好“追求极致的用户体验”。

点击“阅读原文”关注火山引擎RTC，实时了解产品最新进展。

推荐阅读

欢迎关注