神策数据刘伟：产品用户体验数据化评估

 本文根据神策数据高级分析师刘伟《产品用户体验数据化评估》直播整理，本文主要内容如下：

• 互联网产品用户体验的定义

• 用户体验数据化评估

• 产品性能分析

一、互联网产品用户体验的定义

每一个人针对不同颜色、不同页面、不同结构的互联网产品，都会有一些不同的主观感受，简单来说这就是一种用户体验。但如何客观评估用户体验的好坏呢？这种主观的评价能否成为产品在后续进行迭代优化时的可靠依据呢？

比如不同的电商平台在用户注册页面，会有不同的页面设置及风格。有些页面简洁明了，输入手机号与验证码即可完成注册，有些页面具体而丰富，会让用户输入用户名、手机号、密码等多条信息，并根据选项设置相关按钮，完成注册。针对如上情况，不同的用户就会对不同平台的注册页面产生不同的主观感受。

1、“传统”用户体验研究

用户体验研究已有一些通用研究方法。比如 Google 的用户体验测量框架 HEART，包括愉悦感、参与感、接受度、留存度、任务完成率五个维度。通过填写表单及问卷的方式收集用户数据，或是通过志愿者去做用户研究。

但这些方式的人力成本投入都非常高，一个用户体验的小专题研究都可能需要耗时 2~3 周，量表填写以及数据回收也需要很多专业人员的投入。

在大数据时代，人们开始利用类似神策分析等数据采集工具去代替人力采集数据，再基于已采集的数据，即用户在产品内进行操作或者进行互动的一些行为数据，进行用户体验层面的分析。

12、互联网产品使用流程

下面通过还原互联网产品使用流程，探索用户体验数据化评估的思路。

以某电商平台 APP 的启动和使用为例。用户通过点击桌面的 APP 的图标进入 APP，根据页面展示的各种内容进行点击，与 APP 产生交互，下图是一个完整的使用路径整理。

从技术逻辑的角度而言，当用户进入 APP 的页面内容后，该页面即向前端发起请求，再由服务端返回页面内容，在前端通过页面加载，用户才能进行阅读理解，然后再到进一步点击各种 icon 等内容发生跳转，可进入到一个完整的使用流程或者行为处理流程。 

3、用户体验定义

在上述的产品使用流程中，包含两类的内容，一类是用户点击，一类是开发者的反馈，基于此，我们引入了用户体验的定义：基于“操作”与“反馈”，两个交互层面的关键变量，进行用户体验的评估、后续的数据采集以及优化标准的具体制定。

操作指在产品界面上，用户的操作流程，属于产品交互体验的范畴。比如表单的交互设计是否高效，包括重点内容是否突出、按钮操作是否便利等。

反馈指用户操作后，产品的反馈过程与结果，属于产品可用与性能的范畴。比如用户提交的注册密码不符合规则时是否给出报错，以及报错文案是否提示正确等。

二、用户体验数据化评估

1、真实环境下的用户操作路径

以一个注册页面为例。用户的操作路径如下：

• 到达注册页—>输入手机号—>获取验证码—>输入验证码—>输入密码。

在这个过程中可能遇到的问题是：密码报错和验证码过期。那用户操作路径就变成：

• 到达注册页—>输入手机号—>获取验证码—>输入验证码—>输入密码—>密码报错—>输入密码—>点击注册—>验证码过期—>获取验证码—>输入验证码—>点击注册

2、用户体验评估两大关键指标

基于上述用户操作路径，我们提出针对用户体验数字化评估的两大关键指标：操作（交互）步长、操作（交互）耗时。

• 操作（交互）步长，即为了达到这个目标，用户进行操作的步骤有多少？在上一个场景中——用户从注册页到注册成功的平均操作步数。

• 操作（交互）耗时，即用户从注册页到注册成功所需时长，在上一个场景中——用户从注册页到注册成功的平均时长，上述用户操作路径中的“验证码过期”环节，这就是产品内耗时较久环节。

（1）产品流程的操作步长分析

一个完整的产品功能流程，会有它的最短转化路径，即所有链路畅通的情况下的转化路径，这个路径由业务流程、产品设计所决定，以上文注册页面的整个路径为例，最短路径即用户正确填写每一步信息，流畅顺利完成注册的路径。但是实际过程中，除了最短路径以外，还可能出现 s 型路径（如中间出现了密码报错和验证码过期的场景），这意味着用户在实际操作过程中，可能经历了 n 个环节，而这 n 个环节有可能是同一个环节，经历了 n 次。

基于路径梳理，我们可以对交互平均深度进行分析：

由于过程中可能会出现重复与回退操作，所以转化用户的平均交互深度大于最短交互深度。

而最短交互路径深度大于流失用户的平均交互深度，是因为其中包含“跳出、中途退出”两种情况：

• 跳出：用户进入流程，但是未进行任何操作，就离开

• 中途退出：用户进入到流程，有了具体的操作行为后，因遇到故障、阻塞点等原因中途退出

转化用户的平均交互深度分析，主要是为了了解转化用户都是在重复做哪些行为，以开户流程为例，针对一个转化成功的用户，聚焦其在银行的开户流程可能会经历多个环节，包括具体操作过程有多少，以及哪些环节和步骤是重复操作的等等。

神策的 Session 分析，可以完成对转化用户的平均交互深度分析。首先筛选出转化成功的用户，看用户的平均交互深度。其次排查重复操作步骤，可以将各个环节的操作次数和占比进行罗列，就能知道在哪一个环节和步骤进行重复操作的频率比较高，即哪一个环节可能存在问题，有潜在的优化空间。

流失用户最典型的表现是未完成业务流程，所以需要关注用户到底在哪一个环节退出了整个交互流程，以及退出的比例是多少？所以针对流失用户的平均交互深度，重点是分析各项行为的退出率，了解用户到底在哪些环节退出。

所以，针对流失用户的交互深度分析，可以采用两种方法：

• Session 分析：可以建立多个指标，查看各个环节的退出率的表现，然后定位需要优化的环节和低效环节

• 路径分析：排查重复和错误的操作

使用场景是影响交互转化时长的关键因素。从业务出发，可以确定场景的关键因素：

• 用户属性，比如年龄在理财 APP 的功能场景、国家在跨国电商的支付流程

• 环境属性，比如网络状态对于大多的验证码场景

• 业务属性，比如机票改期的延误改和自愿改

（2）产品流程的耗时分析

神策主要通过三种方式来进行耗时分析：

• 漏斗分析。以注册转化漏斗为例，关注每个环节转化时间的中位数，在整个注册转化的行为路径之上，关注整体目标达成率或是各个环节的达成率，进一步观察具体达成目标中间花费的时间以及需要重点优化的环节。

• 多维分析。以开户流程的平均耗时为例，神策可以在开户完成的事件或者开户完成的行为这一个节点去上报整个开户流程的耗时，还可以通过观测它具体的耗时变化趋势和针对耗时的关键因素进行分析。比如关注不同的网点注册或者是年龄差异，通过这种更细颗粒度的多维下钻，真正揭示一些低效环节的关键因素。

• 间隔分析。神策通过计算用户行为序列中两个事件的时间间隔，得到业务转化环节的转化时长分布。比如说 A 事件是注册申请，B 事件是修改成功，两个事件上报会产生一个时间节点或时间戳，用 B 事件减去 A 事件即可看作该环节的所用耗时。

三、产品性能分析

用户某些较差的产品体验可能由于某些错误文案或网络情况等原因导致。可从数据层面，定位这些场景问题出现的关键因素，实现产品的性能分析。产品性能分析，具体指根据前后端交互逻辑通过核心场景的埋点数据采集，实现产品错误、性能与业务处理相关分析。

这三大场景用户侧的产品性能埋点如下：

• 错误类（包括网络报错、加载失败、APP 崩溃等）

• 性能类（加载时长、接口返回时长等）

• 业务类（支付结果 & 失败原因等）

下面将以报错为例，阐述用户侧的性能分析方法。

1、报错的基本情况

针对报错的基本情况，可根据核心指标或者总体指标，对其做进一步拆解。首先关注总体指标，即总的报错次数。

总报错次数 = 日活人数 ✕ 报错渗透率 ✕ 人均报错次数

分析报错的用户影响面：报错渗透率 = 报错的触发人数 / 日活人数（常用 APP 启动人数）

分析各报错的频繁程度：报错人均次数 = 报错触发总次数 / 报错的触发人数

然后根据具体的指标表现，日活人数、报错渗透率、人均报错次数再进一步去分析报错的原因。如果在整个报错行为中有错误代码，也可以根据错误代码查看错误原因。

如果有一些错误代码本身的逻辑出现问题，那就不仅需要按错误代码去查看，还要按照一些常用的维度，比如网络状态、操作系统、操作系统版本、业务场景、接口名称等维度方式下钻。最后综合具体指标还原、分析、解决问题。

2、报错的业务影响

如何通过数据去佐证一个报错场景对业务的影响是重中之重。在一个业务流程监控场景下，我们可以通过漏斗分析，分析一个业务流程从开始到完整的过程中出现的报错情况，分析阻塞点对整个流程的影响有多大。

上图左侧的流程为：注册首页—>输入验证码—>注册成功，可看到该业务的转化漏斗和目标达成率。当我们在正常的转化漏斗中加入“报错提示”步骤（用户在输入验证码之后，遇到报错提示），可得到右侧的漏斗图。

可知前三个环节的转化率、注册成功率都很高，但在报错后的注册成功率仅约 4%。之后根据错误提示和错误原因，进行下钻分析。

所以通过这种方式，能够比较清晰地评估出具体的一个错误发生场景对业务达成会有哪些影响，以及它的影响面有多广。

以上以应用场景为例，具体到如何实现埋点方案和数据上报还是一部分较为复杂的内容，不仅涉及接口，还涉及报错和具体业务的处理。

3、报错的预警搭建

神策的埋点思路是：在前端报错、内容加载报错等环节进行埋点监控。核心的逻辑仍以前后端的交互逻辑为例，从前端请求反馈，再到前端加载（或处理）环节，进行埋点。

以一个验证码或密码输入为例，我们会在前端判断一些规则，比如大小写、特殊字符是否符合该规则，如果不符，就会抛出规则报错。如果判定没有问题，即向服务端也就是后端发起请求，在请求的过程中，受限于网络或接口等问题，可能会出现请求报错，比如服务器错误，此时就需要对错误进行分析解决。 

在后端的处理过程中，有两种情况：

自有服务：需要进行判定，然后根据返回的解决结果进行结果错误的提交

第三方服务：根据第三方反馈的一些错误，进行请求结果的采集，然后判断前端请求是否出错，以及计算在整个过程中从服务端发起请求到访问请求的服务端处理耗时有多少，可以进一步评估处理的耗时

梳理用户操作的行为流程，再把它抽象成事件去做埋点。下表是围绕三大场景的产品性能分析埋点方案：

业务处理结果可以作为一个目标达成率去监控，但是无法实现时时刻刻地刷新结果，需要建立一个能够自动提醒、自动报警的监控体系，在该体系之下，实现一些报错监控或性能监控。

预警体系的核心点在于如何平衡报警的依据。比如跨境电商，有可能会出现一些网络问题的报错，或者是有一些影响力度比较小的报错，那什么样的预警或范围才是正常的呢？这个度应该如何去把控？

神策的建议是，监控预警体系搭建的思路之一是根据场景重要性建立起分级的预警体系，场景的重要性决定了预警阈值的宽松程度以及对应的报警触发方式。下面我们以互金理财为例，介绍一套预警分级体系：

由图可知，先根据不同阈值划分不同的严重等级，然后选取不同的预警方式以及预警通知范围。这些具体的阈值划分和预警方式仅仅是一个参考，核心的思路还要围绕各类产品类的各个场景去构建不同的预警分级体系。

神策分析内有指标预警模块，可以根据一些特定的指标，例如流程目标达成率、流程的一些具体操作或是一个步骤的转化率，使用预警功能进行具体的预警配置，理清预警分级的思路，实现预警体系的建立。

两点注意事项：

• 预警设置避开业务数据低谷期，常见的如凌晨 1-5 点活跃人数低的时段

• 结合业务的周期特点，做不同的预警设置，比如证券行业的交易与非交易时段设置不同阈值

本次分享的内容到此结束，感谢大家的聆听。