从 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 将不断探索更科学的数据指标分析和监控能力，帮助广大企业和开发者真正做好“追求极致的用户体验”。