如何构建用户体验监控体系？

本文首先围绕打造产品口碑，阐述构建用户体验监控体系的必要性；然后列举了几种常见的用户体验监控模型；最后从产品团队如何提升产品用户体验的角度，给出了构建用户体验监控体系的一种思路：采集、分析、治理、验证。

用户体验监控的必要性

在用户日常使用互联网产品过程中，以电商APP（苏宁易购、淘宝）为例，偶尔会遭遇一些较差的用户体验，有：APP启动慢、崩溃、无响应、页面卡顿、商品主图/视频加载失败、商品无货、网络响应超时、地址保存失败、加入购物车失败、支付失败……这些问题对用户的产品体验有着或大或小的影响，尤其是在一些关键场景（加购、支付……）直接决定了产品在用户群中形成怎样的心智模型，借助社交放大，这种心智模型会逐渐成为产品口碑，而对于互联网产品来说，产品口碑往往决定着生死。

那么问题来了，如何引导产品口碑良性发展、甚至弯道超车抢占用户的心智模型？

在相同的外部环境下，对于产品团队来说，就是不断迭代打磨产品的用户体验，追求至臻至美。

当然，打磨产品不是喊口号，更不能拍脑袋，需要产品团队针对用户在真实场景下的痛点、痒点逐一解决。对于用户的体验诉求，产品团队需要保持敏锐的嗅觉，常见的有很多手段：可用性测试、易用性测试、线上走查/反馈、问卷调研、用户访谈、竞品分析、角色建模、体验地图……

这些都有一个共同的缺陷：“无法真正覆盖全场景、全用户”。

如何能够覆盖全部场景和全部用户？人工测试肯定是无法100%做到的，自动化测试倒是有可能覆盖全部场景，但无法模拟全部用户状态（设备、地理位置、网络状况…），各种方式的反馈、问卷、访谈也不可能做到全量用户，因此只能采用技术手段。

监控，就是一种行之有效的技术手段，对全场景、全用户在产品使用过程中用户体验的实时“监控”，就可以感知到任一场景、任一用户的体验质量。就像十字路口的监控摄像头，极大解放了交警的生产力，不用再依靠人力去辨别、威慑交通违规行为。

用户体验的监控模型

在互联网产品的监控领域，一直都有对系统、服务等中后台系统的监控，即APM（Application Performance Management，应用性能管理），国内外专业厂商有博睿、听云、dynatrace等，头部云计算厂商（例如阿里云、腾讯云、华为云）也都有相应的APM产品。这些APM产品主要是围绕应用性能来提升服务质量和产品体验，主要有响应时间、耗时、TPS等和稳定性相关的指标数据。

响应时间、耗时、TPS这些指标和用户体验也是息息相关的，可以在服务端的性能指标层面反映整体的用户体验画像。例如Apdex（Application Performance Index，应用性能指数）基于完成独立请求任务的响应时间T（T 由性能评估人员根据预期性能要求确定，假定T=1.5s）定义了3种用户体验的表现：

• Satisfied（满意）：响应时间<= T，即完成独立请求任务的响应时间在1.5s内则可以认为用户体验是Satisfied 。
• Tolerating（可容忍）：T< 响应时间 <=4T，即在1.5s～6s则认为用户体验虽然不完美，但是Tolerating。
• Frustrated（受挫）：响应时间>4T，即在6s以上则认为用户体验是极差的，属于Frustrated。

通过计算Apdex指数，得出产品在响应性方面的用户体验质量。Apdex的满分是1，意味着全部的用户都是Satisfied，不过需要注意的是T值本身就是一种很主观的量化数据，过大或者过小都影响 Apdex 值。

此外，Google提出过两种用户体验的监控模型：PULSE模型、HEART模型。

PULSE模型主要利用产品运营的指标来衡量用户体验：

1. Page view/页面浏览量
2. Uptime/持续在线时间
3. Latency/延迟或响应时间
4. Seven days active user/7天活跃用户数
5. Earning/收益

PULSE模型侧着从产品自身的运营指标数据来倒推用户体验：产品运营数据好、用户体验就好。从运营的角度看这个逻辑确实成立，但从研发的角度看两者并不能简单粗暴的划上等号，尤其是在运营数据不好的时候，不能直接推导出用户体验变好或变坏的原因。

HEART模型则同时覆盖了业务和用户两种角度的指标来衡量用户体验：

1. Happiness/愉悦度（可用性、易用性、NPS…）
2. Engagement/参与度（日活DAU、月活MAU、下载量、激活量、访问频率、访问深度、访问时长…）
3. Adoption/接受度（访问次数、复购次数、APRU、GMV、客单价…）
4. Retention/留存率（次日留存、七日留存…）
5. Task success/任务完成度（完成率、耗时…）

HEART模型同时从业务和用户两种角度衡量产品体验，非常接近用户体验的量化目标。但是这几项指标非常抽象，在各维度指标的选择上也甚是主观，对同一个产品在不同的场景中如何选择合适的指标非常考验产品团队。

和Apdex一样，这两种模型中所使用的指标和用户体验也都息息相关。PULSE模型、HEART模型能够评价得出产品的用户体验是好还是不好，但缺乏具体的产品优化建议。例如：页面浏览量低、响应时间过长、用户愉悦度一般、接受度一般、留存率低，产品团队应该采取哪些行动去落地实施？

针对产品的用户体验提升，在涉及怎么做的问题上，只有明确知道当前产品存在哪些体验问题，才能通过实实在在的体验问题来驱动产品团队采取行动。

因此，监控模型的对象应该是基于体验问题，而不是最终的评价结果。

PS：PULSE模型和HEART模型中均提供了产品多维度的指标，如何处理多维数据以量化为可读性更好、可视化程度更高的数据，可以参考上一篇文章《B端产品用户体验量化的三个案例》。

如何构建用户体验的监控体系

那么如何基于体验问题构建一套指导性强的用户体验监控体系？在回答这个问题之前，需要先搞清楚产品团队如何做才能提升产品的用户体验。

首先，产品好不好，最终还是需要用数据来说话。在Apdex、PULSE模型、HEART模型中，首要前提是采集各项指标数据。

其次，产品的用户体验不是零和博弈，不是非黑即白，是由无数个场景中用户的感知构成了产品的用户体验，因此提升的过程必然基于对各场景、各项指标数据进行分析的基础上。

然后，当分析给出明确的结论后，产品团队已经对产品的优化有了明确的思路，接下来需要做的就是采取行动，以完成用户体验问题的治理。

最后，通过对比治理前后的数据，验证体验问题的治理效果。此时，验证的数据可以是体验问题本身的指标，也可以是采用其他的模型，例如PULSE模型和HEART模型。

基于以上几点，得出几个关键词：采集、分析、治理、验证。因此，基于体验问题构建一套有效的用户体验监控体系必须满足以下四点。

• 采集：采集产品在所有场景中，用户遭遇的一切体验问题
• 分析：结合现阶段业务目标，分析得出体验问题的轻重缓急
• 治理：通过排期落实具体的实施方案，治理体验问题
• 验证：参考绩效相关的指标，验证体验问题的治理效果

当产品团队根据用户在使用产品过程中遭遇的所有体验问题完成采集和分析，以获得具有明确指导意义的产品优化方向和具体可实施的任务，通过付诸行动治理体验问题，最后使用正确的指标验证效果，不断循环这一过程就能够大概率提升产品的用户体验。

因此，构建一套有效的用户体验监控体系，是由基于体验问题的四个环节构成：采集、分析、治理、验证。通过构建采集、分析、治理、验证的用户体验监控闭环，不断修正提升产品的用户体验，从而打造极致的产品口碑。

总结

条条大路通罗马，构建用户体验监控体系有很多可行的方法论，本文只是阐述了其中一种。下一篇文章，将具体阐述如何基于体验问题构建用户体验监控的采集、分析、治理、验证这一闭环，敬请期待。