9月23日，“掘力计划”第25期性能专场在北京举行。来自字节跳动架构前端APM团队的彭莉和张皓洋，就《“抛弃”技术指标，构建真正意义上的用户体验评价体系》进行了分享。两位讲师均来自于字节跳动的架构前端 APM 团队，一直专注于前端监控和用户体验度量领域的开发和探索。
一、前端监控观测现有体系的问题
用户体验评价体系的建设是基于“前端监控”这个领域发展而来的。字节和业界常见的监控建设方案一样，也会随着时代和技术的变化，去更新自己的监控能力，提供更多的视角，去尽可能的帮助研发用户更好的观测并提升实际用户的产品体验。
但是，回过头看，由于指标和监控项目的演进并非一蹴而就，这样的演变过程难免会存在随意和缺乏考虑之处，指标和视角的增加并没能在一个完善的框架下合理的运转。 主要问题有：
1.1 功能孤岛
过多低密度功能堆砌，用户迷失在功能的海洋中。现有监控系统功能之间缺乏内在联系和统一的消费引导，缺乏有效的全局视角，功能越堆越多但是每一个功能做的事情却很有限，这反而增大了研发同学使用前端监控平台去解决问题的难度。
观测指标的增加，没有伴随着最佳实践和用户行为动线的规划，即使我们有了大量存在于规范和标准的各类指标，仍然只有最为常见的 JS 错误监控存在较为完善且闭环的解决方案（sourcemap 解析 + 堆栈分析 + 转化为 issue 跟进）。其他的监控方案，却变成了一千个人眼中有一千个哈姆雷特。
体现在字节内部的监控现状，便是功能与功能之间缺乏内在联系和统一的消费引导（缺乏提前思考和规划)。成为了一个一个的功能孤岛。缺乏（用户维度→会话+系统维度的→insight）全局视角。功能越堆越多，但每一个功能实际能做的事情却很有限，同质化很严重，用户会把大量时间消耗在切换一个又一个的功能去检查监控系统中是否有异常这件事上。
参考观察业界先进的监控和可观测系统，虽然各自监控的交互方式、设计思路不同，我们发现他们并没有强调自己有多少数量级的功能，而是尽量让每一个功能都做到信息密度和效用最大化。同时，通常尽可能多的在一屏内放下诸多关键信息。帮助用户迅速定位问题。
1.2 数据孤岛
数据间缺乏横向关联，潜藏的对用户体验的合并影响被忽视。数据和数据之间其实是有紧密的关联性的，但是现有监控平台在设计的时候忽略了数据之间的关联性，导致研发同学使用前端监控平台去优化性能的时候，需要主动的挖掘这些关键数据，提高了研发同学解决问题的成本。
例如，页面的 LCP 值严重低于预期，这背后可能是组文档加载慢，也可能是主要资源加载慢，还有可能是 JS 逻辑比较重阻塞了渲染。这些因素看似很多也需要人为的去发现，但是这些数据监控平台都有，由于我们设计的时候忽略了数据之间的关联性，导致研发同学使用前端监控平台去优化性能的时候，需要主动的挖掘这些关键数据。
二、用户视角下的真实体验评价
要解决以上问题，我们需要建立用户视角下的真实体验评价体系。
2.1 如何定义用户体验
在单次用户旅程中，多种因素合并影响、共同作用。用户的一次体验是一个渐进的过程，由异常和性能等因素合并影响、共同作用，这些因素在用户的绘画过程中逐渐积累，最终对用户的体验产生影响。所以从单次绘画的维度去定义真实的用户体验，是一个可行的方式。
例如，用户进入页面时站点的加载速度和响应速度就是用户对于站点的第一印象，也是体验的起点。在随后的交互中，站点响应迅速时用户会有比较好的使用体验。另一方面，如果遇到异常或者响应迟缓，用户就会感到不满意。这些因素在用户的绘画过程中逐渐积累，最终对用户的体验产生影响。
2.2 如何度量真实的用户体验
那么应该如何通过单会话维度去度量真实的用户体验呢？答案是：可以结合整个会话上报的多种事件来综合量化这次访问用户的感受。
第一步就是挑选在会话过程中能左右用户情绪的因子，也就是**「体验因子」。** 因为就是这些因子在会话过程中相互作用，最终决定了用户的体验。利用“体验因子”构建满意度模型。我们通过统计绘画中所有体验因子的权重和属性，最终得到满意度等级。
体验因子可以分为三类：
- 交互性能：评估用户与页面交互带来的情绪波动。
- 超长等待：评估长时间等待带来的情绪波动。
- 阻断信号：评估用户没有完成预期行为带来的情绪波动。
这三类因子囊括了所有可能引起用户情绪波动的情况。我们为每类因子设计了不同的属性和权重，正向因子可以带来满意，负向因子会带来沮丧。按照因子的权重占比，我们可以计算出每次绘画的满意度等级。
2.3 基于用户体验视角评价体系的实践
通过这样的模型，来提供给研发精简的有价值的关键数据。
首先是满意度等级，它是给体验定级。其次是这背后的 体验因子的满意度权重占比，它是给体验定程度，它能告诉研发如果一个用户的体验是沮丧的，那么到底是有多沮丧，这可以帮助研发分析用户体验的分布情况，分析极端异常的用户，来做定向的体验优化。最后就是单次会话关联的沮丧因子的数据，它主要是用作归因，它能够帮助研发，深入分析用户体验，以及沮丧的原因。基于这样的金字塔数据来帮助研发做到全面的满意度分析。
“抛弃”技术指标，以用户体验为中心，成体系地指导体验优化。满意度模型可以为研发提供精简的有价值的关键数据，包括满意度等级、体验因子满意度权重占比、关联的沮丧因子数据，可以帮助研发定级、定程度和归因，从而进行满意度分析、异常会话探索、会话终止原因分析等，以用户体验为中心，助力研发提效。
三、宏观视角下的整体体验度量
接下来张皓洋讲师提到，除开用户视角之外，我们更常见的其实是基于整个前端系统观测和分析问题的需求。这也是一般的前端监控系统会做的事情。例如，我们想从整体视角看，当前所维护的前端页面的性能到底怎么样，稳定性如何(会不会很容易崩溃白屏)，可用性又高不高，例如：用户会不会点什么按钮都没反应？
3.1 现有系统视角度量的缺陷
看起来，传统监控已经解决了这些问题，对于稳定性问题，我们可以上报 JS 错误，通过观察 JS 错误率来判断，而对于性能指标，我们可以使用 RUM 指标来分析，对于页面可用性，我们可以通过 ResourceTiming 和 ajax, fetch hook 来收集请求相关指标。最后，这些数据再通过一个大盘展现监控系统的首页。然而，这样的视角其实存在一些缺陷，我们自身其实也遇到了同样的问题，正如我们前文在审视自身监控体系问题中所提到的：
- 观测视角不合理：整站观测视角下的聚合数据掩盖了大量信息，无法反映不同页面的实际情况。例如整站的 FCP 指标显示性能不错，但拆分后发现不同页面存在明显差异，有些页面的FCP远超指标标准。
- 数据孤岛：单个事件难以全面描述系统整体表现，需要聚合分析多个有关联的指标。例如问系统稳定性如何，不能仅看单一的JS错误指标，而要综合分析 JS 错误、白屏等多个指标，才能对系统稳定性有较好判断。
3.2 如何建立合理的系统视角
那么，如何建立起合理的系统视角呢？其实就是针对上面所提到的两个核心问题找到解决方案。要克服上述问题，需要从以下几个方面入手：
- 选取正确的指标和维度进行分析，在直接分析数据之前，我们应该先使用合适的观测角度去划分数据集合。对于 FCP，我们会优先关注这个指标在不同页面的指标情况。只有当发现有某个观察角度下的数据出现问题后，我们再去进一步下钻，查看这个维度下的具体事件是否有明显问题。这样做还可以避免可能的问题被整站点的平均值隐藏。让用户更快的发现问题。
- 不同场景采取不同标准进行评估，不同场景需要采用不同标准进行评估，因为同一站点的不同页面在复杂度和场景上可能存在差异。使用统一标准评估会导致对某些页面不公平，而这种不公平在系统中累积会导致更大误差。因此，在校准观测数据后，我们应该使用适当的标准进行评估，例如定义多个子分类采用不同的标准。这样做的好处是，不同标准可以代表不同优先级，我们可以先处理重要的，再处理影响较小的。不同标准适用于不同场景，不需要要求中后台页面与C端页面具有相同性能，这更符合人性化的要求。最后，通过指定正确的观测角度和对结果进行分组评估，我们可以获得比整体均值更有意义的度量结果。
- 聚合数据抽象系统状态，在构建合理的系统视角时，我们需要将前端系统的指标数据进行拆分并对每个结果进行评估。然而，评估后的结果仍然是一个指标表格，我们需要进一步聚合这些数据，构建出一个量化的核心指标，即“北极星指标”。这可以通过横向聚合和纵向聚合来实现。横向聚合是通过将多个指标整合得到维度结果，如将JS错误率和错误影响用户率等指标整合，以得到某个页面的聚合分数，从而全面反映该维度的表现。纵向聚合则是通过计算达标率来聚合维度表现，即达到标准的维度占总观察维度的比例。这种方法由于引入了维度的信息，能够更好地表示当前站点的指标表现，最终得到我们需要的核心指标。
- 支持更高维度的分析，在单个前端项目之上，可能还有更多虚拟的维度，例如业务线，团队，部门等。因此，我们还可以在具体项目的基础上，再构造一层聚合，聚合的数据可以定义并下发统一的规范，下属的业务都可以在同样的整体规范上进行度量，结果可以进行有效的量化和比较。这对于团队性能优化，制定统一体验标准等工作都有很大意义。
通过这种以指标和维度为核心的方法，可以克服现有方案的不足，获得更合理和客观的系统整体表现量化结果。
四、基于系统视角的监控及体验优化实践
我们正在对一个内部团队的约50个核心项目进行统一的性能分析和治理。这些项目的形态、场景和技术栈各不相同，甚至上报的指标种类也无法保持一致。我们的目标是确定合理的度量角度，建立一套统一的标准，使用合理的分级，以及批量、定时获取所有业务的数据和报表。我们希望通过这种方式，找到需要治理的关键业务。
在实践中，我们利用了内部的 Insight 能力的长周期度量报表来完成这个任务。首先，我们建立了一个虚拟的组织，其中可以容纳多个项目的数据。在这个组织中，我们的用户可以批量查询数据，还可以批量下发，管理统一报警等工作。然后，我们在组织中开启了我们的度量能力，包括用户体验、稳定性和可用性的度量。我们为每个度量模块都指定了三个子分类，并为每个子分类指定了不同的基线和指标。
在配置完成后，后台会定期生成长周期的报表。在报表中，用户可以看到当前组织的整体达标率，以及以子分类的重要程度赋予权重的加权分数。如果发现有问题的模块，我们可以进入度量模块的详细分析页面，快速定位出存在问题的维度，并利用监控提供的详细指标分析能力查询问题的根源，并进行针对性的修复。通过这种方式，我们可以以较低的成本获得整个前端系统乃至整个业务线下多个前端系统的整体表现，并可以自上而下地度量、评估和跟进修复这些系统可能存在的问题。
五、总结
通过上述从用户和系统两个维度建立前端监控评价体系的实践，彭莉和张皓洋两位讲师带我们重新审视了各类指标和数据在度量前端性能和稳定性方面的价值，在降低监控系统使用成本的同时，做到更大程度发挥它们的作用，从而更好地服务于业务，提升用户体验。
掘力计划
掘力计划由稀土掘金技术社区发起，致力于打造一个高品质的技术分享和交流的系列品牌。聚集国内外顶尖的技术专家、开发者和实践者，通过线下沙龙、闭门会、公开课等多种形式分享最前沿的技术动态。