文章强调了弥合产品分析和可观测性之间差距的重要性，以优化用户体验。传统工具存在局限性，需要以用户为中心的方法，连接前端遥测数据和用户行为，促使工程团队更关注用户体验。
译自：When Performance Is Product: Bridging the Gap
作者：Kasey Smith
在现代前端应用程序开发中，有两个不容否认的事实：系统更加复杂，用户比以往任何时候都更不宽容。
对于速度、可靠性和无缝体验的期望非常高。然而，团队用来理解和改进这些体验的工具仍然是高度孤立的。
一方面，你有经典的产品分析工具（例如 Mixpanel 和 Amplitude）。你通过这些工具获得的数据非常擅长告诉你用户在做什么以及他们在哪里放弃。这些工具通常侧重于漏斗分析，对于产品经理的工具包来说是不可或缺的。
另一方面，你有传统的可观测性工具。这些工具擅长告诉你系统或应用程序在底层是如何运行的，侧重于诸如日志、指标和追踪之类的技术遥测数据。这些工具完全属于工程领域，并且在很长一段时间内，主要限于后端工程团队，前端工程师只是最近才开始接受可观测性实践。
这两种类型的工具都通过不同的视角来衡量一个应用程序在多大程度上成功地实现了它的目标。
然而，产品分析和技术可观测性传统上生活在不同的世界中，孤立于不同的团队。这是一个问题，因为它们都不能单独讲述完整的故事。
一种现代的应用程序构建方式需要一种更具凝聚力的方法，将技术和行为要素联系起来。我们需要弥合产品分析和可观测性之间的差距，以真正理解并最终优化最终用户体验。
仅依赖产品数据的局限性
传统产品分析的问题在于它们针对视觉和交互设计进行了优化。漏斗、放弃和参与度地图突出了摩擦发生的地方，但很少说明原因。这些工具很少考虑性能——当它们考虑性能时，通常是通过通用的阈值，例如，“如果花费超过两秒钟，用户就不满意。”
但这种假设在实践中并不成立。现实情况要细致得多，通用的性能基线通常不能跨不同的行业和应用程序类型进行转换。
例如，用户可以容忍内容提要延迟两秒钟，但可能会因为额外的 300 毫秒而放弃结账流程。上下文很重要。如果没有将技术性能与行为变量联系起来，团队只能猜测。
仅仅依靠产品分析工具通常会在产品经理、设计师和工程师之间创建一个令人沮丧的循环，无法充分解决问题。
这是许多产品经理熟悉的情况，通常是这样的：
“产品分析工具告诉你，你的用户参与度指标没有按照你想要的方式发展，但没有提供任何关于原因的见解。你去找工程团队，他们说，‘告诉我们该改变什么。’由于你的工具没有提供技术指导，你无法给他们答案。所以，你然后去找产品设计团队寻求帮助。该团队指派一名设计师进行大量（通常是徒劳的）练习，以了解 UI 存在什么问题，并做出很大程度上基于假设而非数据的更改。现在你已经更改了 UI/UX，每个人似乎都很高兴参与度问题应该得到解决。随着时间的推移，该指标仍然没有改善，三个月后，你仍然陷入浪费另外两个 sprint 来运行完全相同的过程，希望‘这次，我们会做出改变’。而且一直以来，一些前端组件都很不稳定、不一致且速度很慢，如果你能够同时捕获技术数据和产品分析数据，你就会知道这一点。”
如果这听起来很熟悉，那么你可能已经亲身体验了产品分析的局限性。
传统可观测性数据的局限性
传统的可观测性工具也有其自身的一系列局限性。
虽然指标、日志和追踪是了解软件健康状况的一个很好的窗口，但它们并没有提供太多关于软件对用户的影响的见解。它们本质上是低上下文的，旨在为对技术操作有深刻理解的工程师工作。造成这种情况的一个重要原因是，可观测性作为一种实践始于后端，并且只是最近才开始发展和适应，以考虑非常不同且更难控制的软件前端世界。
以围绕 API 端点性能的典型可观测性指标为例。虽然对于应用程序功能（例如产品搜索）至关重要的端点可能运行良好且可操作，但由于前端渲染问题， предназначенный для устройства пользователя контент может быть задержан. 这会导致性能不佳和潜在的用户放弃，传统的可观测性工具甚至可能没有注意到这一点。
采取以用户为中心的方法
这就是以用户为中心的可观测性的用武之地。通过将前端遥测数据（核心网页指标、网络事件、JavaScript 异常等）连接到真实的用户行为，工程和产品团队可以围绕对实际用户体验的共同理解进行协作。为了做好这一点，你需要能够弥合高上下文、低粒度的产品空间和低上下文、高粒度的工程空间之间差距的工具。
这闭合了系统性能和最终用户影响之间的循环，使团队能够不仅基于损坏的内容，而且基于真正重要的事情：你的用户做他们想做的事情来优先进行改进。
工程领域的文化转变
还有一个文化转变来支持这种朝着有凝聚力的、以用户为中心的可观测性的运动。
由于更好的工具、自动化和部署实践，工程团队在编写和调试代码方面变得更快、更高效。超越这些 P0/1 问题意味着他们应该考虑通过用户的体验来优化性能。对于工程团队来说，自然的下一步是坐在战略桌旁。世界上最好的产品拥有参与、积极和协作的工程团队，这些团队致力于他们的最终用户。
能够揭示工程主导的变更（例如改进绘制时间或减少长时间任务）如何影响用户参与度的工具创建了一个反馈循环，使工程师能够以对最终用户更多的同理心而不仅仅是速度来构建。
最后的想法
尽管我们在构建方面可能倾向于隔离我们的工作和责任，但最终用户并不这么看。失败就是失败……延迟就是延迟。根本原因是一个糟糕的设计决策还是一个渲染错误并不重要，因为最终用户不会区分这些类型的问题。令人困惑的交互和延迟的响应感觉是一样的。
