神策数据依据服务 1000 多家行业标杆企业的实践经验推出《产品用户体验的数据化评估》白皮书，主要围绕用户体验的“操作”和“反馈”两部分对用户体验的数据化评估展开说明。下文将简单介绍：
用户体验可以从很多的维度进行定义，《用户体验要素》里将用户体验分为五个层次，具有较强的主观性和战略性。这五个层次为表现层、框架层、结构层、范围层和战略层。- 表现层：产品界面的视觉体验，是用户拿到一款产品后，对产品的第一印象;
- 框架层：产品的导航和信息设计，关系到内容信息的易读性和易懂性;
- 结构层：交互方式以及信息架构，直接影响产品的易用性和使用效率;
- 范围层：功能设计以及内容，决定用户需求的满足度以及产品价值传递;
- 战略层：商业模式、产品模型以及目标用户，产品原始的立足点。
下文内容将从数据的角度来说明如何去评估和定义用户体验。用户来到 APP 首页，点击 banner，看到商品详情页，之后加入购物车，这四个步骤组成一个非常常见的操作流程。但如果从用户的角度出发，“用户体验”包含的内容显然并不止这四个步骤。不仅仅是用户打开首页，点击某个 banner，其实随后等待页面加载的过程也是“用户体验”中应当包含的一部分。接着，用户进入详情页后下滑浏览商品详情，同时又会出现图片信息加载的场景，最后用户选中商品加车，获取加车成功反馈，完成这一购物的操作流程。在此流程中出现的加载、报错等都是用户体验范畴的组成部分。在上述的购物过程中，用户体验的内容可以被分为两部分：一部分是用户自己的“操作”，一部分是操作后产品的“反馈”。首先，用户的点击、下滑等行为都是“操作”的范畴，与大众直观认知的“用户体验”一致。信息架构是否合理高效、 操作方式是否符合习惯 / 容易学习都直接影响使用者的操作体验，是属于产品交互体验的范畴。可以通过相应的数据指 标来衡量操作体验的好坏程度，比如表单填写是否高效，购买流程是否易用等。其次，反馈是指用户在产品上操作后，产品给出的所有反馈体验过程，包括系统是否给出反馈、反馈是否及时、错误后反馈提示是否合理等，直接影响产品或系统是否可用，属于产品可用性的范畴。失败反馈和反馈过慢是需要重点关注的内容，因为这两者都会打断用户体验流程，可以用相应的数据指标进行分析优化。《产品用户体验的数据化评估》白皮书中将介绍两种评估方案，其一为应用性能管理评估方案(APM)，该方案主要介绍如何通过数据去衡量 APP 的反馈性能以及用户体验的性能等；其二为功能流程交互体验评估方案，该方案主要介绍如何通过数据的方法去对产品流程的优劣、效率等方面进行评估。由于篇幅限制，本文将主要介绍“应用性能管理评估方案(APM)”，获取白皮书全文内容可点击文末“阅读原文”。二、反馈评估面向用户的应用性能管理 (APM)评估方案
应用性能管理(Application Performance Manangement), 对企业系统实时监控以实现对应用程序性能管理和故障管理的系统化的解决方案。通常分为针对前端用户操作与针对后端业务运转两个方面，本部分主要围绕面向用户层面的即前端用户操作方面的应用性能管理方案，即如何通过埋点的方式进行分析与优化。(1)对平台各业务流程的处理结果、故障、性能等进行埋点量化，了解平台产品与服务的性能现状。在这一阶段，通过埋点、数据采集等方式，了解现阶段状态，比如某些报错、加载的具体情况和表现。在一些电商或理财类产品中，能否购物、能否投资等核心业务是其本身的强需求，需要通过实时监控来进行预警的快速定位，在这部分将重点介绍如何搭建预警体系。(3)通过数据分析持续迭代应用性能与用户体验，为平台业务指标(转化率、成功率)带来正向影响，甚至直接提升。当了解了现状、预警体系之后，接下来要通过一些指标和模型，去迭代和优化用户性能及体验，最终带来正向的影响从而实现商业目标。面向用户的 APM 埋点思路是将用户操作后，产品反馈生成的全流程进行拆解，在所有可能会出现体验的环节进行埋点。比如用户在 APP 注册时，点击“下一步”按钮，APP 在向服务端发送注册请求前，客户端会对用户填写信息进行规则判断，比如手机位数是否 11 位，密码规则是否符合平台要求等，当不符合规则要求时，就会出现报错，此时我们就可以在前端报错环节进行埋点监控。如果前端的规则判断没有问题，前后端就会进行交互，向服务端进行请求，此时可能出现由于网络信号弱等问题导致请求发送失败而报错，在此环节同样可以进行埋点。就服务端而言，其内部也会出现相应的报错并且可进行埋点的环节，但本白皮书主要聚焦前端体验领域，服务端暂不讨论。服务端处理请求之后，会返回相应的请求结果(也会有无结果返回的情况出现，在此不做分析)，比如点击注册的返回，结果可能是该手机号已注册，即用户收到报错的反馈，此时可以部署埋点。另外在加载过程中，由于网络环境等原因，很可能出现电商产品的图片、H5 活动页面等加载困难等场景，这同样是用户可以直接感知的领域，可以在此环节进行埋点。以上是整个方案的埋点思路，数据人员可以按照这个思路，对用户反馈的整个链条中可能会面对的加载、报错等环节，部署相应的埋点。针对注册、支付等核心业务，在后端部署埋点，当收到前端请求后，后端处理完成返回结果时触发。常见的场景为:注 册、充值、购买、实名认证等。在 APP、web、小程序等前端进行埋点，当前端出现报错时触发，可以将前端规则报错、接口请求报错，以及反馈结果报错全部融合。因为无论是哪种报错，实际上还是要站在用户的角度来去进行埋点，即只要用户在前端接收到一个弹窗报错时，就会进行相应的埋点。常见的场景：手机号位数错误，前端文案报错，以及短视频下拉刷新内容，返回内容失败等。在 APP、web 等前端进行埋点，页面加载失败时，由前端触发，常见的场景:活动 H5 页面加载失败。在 APP 进行埋点，由 APP 崩溃时触发，常见的场景：APP 崩溃闪退。本方案的分析应用主要分为两个部分，一部分是通过分析减少故障、优化故障，比如对注册流程中的报错环节、注册结果进行埋点，通过分析报错渗透率、退出率等指标评估故障对注册流程的影响并确定迭代优先级。第二部分是监控预警，指对平台关键业务结果以及核心体验场景的性能指标进行监控，建立起一整套的预警体系，提高业务故障的响应速度与效率，比如对注册成功率这个核心指标进行小时监控，出现异常波动时及时通知对应负责人员。报错、失败会直接导致用户体验流程的中断，严重时导致用户离开，阻碍转化。因此，优化分析的指导思路是减少报错影响、优化报错体验。故障诊断除了分析报错场景的基本数据，还要分析报错对于业务的影响程度如何，比如对于转化流程的影响、对于业务转化的影响。可以按照下述思路进行:第一，分析报错影响面，常用报错渗透率指标:
报错渗透率 = 报错的触发人数 / 活跃人数(常用 APP 启动人数)渗透率表示在我们产品的活跃用户中，报错或其他故障的影响面有多大，比如一百位活跃用户中，到底有多少人会遇到这种情况。第二，分析报错严重程度，常用报错的人均次数指标，它表示用户遇到报错情况的频率如何，常常也会按接口名称、业务场景、网络类型等维度下钻分析，找到报错最严重的那批场景。人均报错次数 = 报错触发总次数 / 报错触发总人数第三，报错原因分析，报错埋点时加上错误原因、技术错误代码等信息，就能了解到各个场景故障的详细原因。在进行技术迭代时，除了了解报错的影响面、严重程度，技术错误原因能够帮我们更准确地评估迭代成本，决定报错迭代的优先级。第四，分析报错对产品转化的影响。在产品转化漏斗中加入报错事件，分析报错对于最终转化的影响。比如注册流漏斗由注册首页→注册二页→注册成功三个事件组成。如果我们想要分析注册二页的密码设置报错对转化的影响，把漏斗分析改为注册首页→注册二页→密码设置报错→注册成功。这时，注册二页→报错的转化率含义是本环节报错渗透率，而将报错→注册成功的转化率与原注册二页 - 注册成功的转化率进行比较，就能分析到报错对于用户转化的影响。最后，分析报错带来的用户离开影响。我们可以很直观感受到的场景是，当用户在 APP 遇到一个严重报错时，他可能因为这个报错而离开，此时可以通过报错退出率来进行评估:报错退出率 = 报错后离开次数 / 报错触发总次数报错触发总次数很好理解，那么如何定义“报错后离开次数”呢?我们以一个“加车流程”的案例详细说明:平台上有三位用户来购买 iPhone，A 用户来到详情页就触发了报错，但他并没有离开，而是继续点击购物车，将 iPhone 加车成功，完成支付结算。因此，报错并没有导致他退出详情页或者离开 APP。B 用户来到详情页点击购物车，此时报错提示库存不足，iPhone 没能加车成功，用户 B 带着不满的情绪离开 APP。从行为上来看，报错后用户发生了 APP 退出的事件，所以这是一次“离开”的报错。C 用户来到详情页后触发活动结束的报错，于是他不再继续购买而选择去做其他事情，虽然他没退出 APP，但是已经从购买流程(详情页→加车→结算)中离开，因此，我们也可以定义这是一次“离开”的报错。神策分析中的 Session 模块可以灵活选择分析哪些行为(比如只选购买流程事件时，上述 B、C 用户的报错都是处于行为序列的末尾)，行为切割的时间规则，因此，利用 Session 分析我们就能方便地计算出功能流程中报错事件的退出率。进而，如果用报错文案做维度下钻，还能看到不同报错事件的退出率。比如可借助退出率分析得到注册流程内的信息填写情况:手机位数不足 11 位、密码不符合大小字母规则、验证码错误等等提示造成的退出情况。
上述提到的漏斗分析以及 Session 分析都能分析报错对业务转化的影响，两者有何差异呢?简单来讲，漏斗分析用于报错对业务转化的基本面了解，而 Session 分析用于交互过程的报错影响。比如注册流程中，先通过漏斗诊断报错对业务影响，再用 Session 分析在哪个交互环节的报错问题更严重。监控预警可以帮助我们去提升故障的响应速度和效率，但核心问题是如何去建这套监控预警体系。指标变动多大时候触发报警，是预警体系搭建的核心问题。比如电商的支付环节，30 日支付成功率在 80% 左右，那么报警阈值设置多少合适呢?是 70% 还是 10% ?两者可能都会带来问题。如果将报警阈值设定为 10%，那么带来的直观问题是轻微的故障将被忽略，只有非常严重的故障才会被发现，对于支付这样的核心场景来说，轻微的故障也会直接带来成交金额的损失。而如果将报警阈值设定为 70%，虽然轻微故障也能覆盖上，但将会发生频繁的误报情况。比如当支付成功率从 80% 降至 69% 时，很有可能是渠道或者其他因素造成的波动，而不是故障，相关人员仔细排查后很有可能不会发现故障。久而久之，大家对于报警的信任度下降，慢慢就会忽视报警信息，没起到预警的作用。从上面的例子可以看到，给某个关键指标设置偏高、偏低的预警阈值都会有其局限性。因此，在实际搭建预警体系过程中，不能将预警直接“一刀切”，而是要进行分级处理，场景的重要性决定预警阈值的宽松程度以及对应的报警触发方式。首先，可以根据场景将预警体系分级。比如在互金理财产品中，我们可以根据营收场景、关键支持场景、功能场景进行划分。营收场景包括支付、充值等，关键支撑场景包括注册、体现等，功能场景包括领取优惠券、签到等。另外可以根据严重等级将预警体系分级。比如关键支撑场景和功能场景根据其严重程度可能只需两档预警等级，而营收场景则需将预警等级分为三档，当出现支付成功率降至最小值等极为严重的情况出现时，将启动最紧急的预警方式将故障信息通知所有相关人员，而在一些重要程度稍低的场景，只需通知核心成员即可，无需通知全体人员。
围绕场景分级和严重程度分级，是搭建预警体系的核心思路。而具体的阈值设置，高效的方法是结合过往数据确定经验值，再根据执行反馈结果持续迭代。登录神策分析页面，在事件分析模型的页面右方找到“预警建设”，点击之后可进入如下界面。
神策分析的预警功能支持自定义设定时间段，但要注意避开业务数据低谷期，常见的低谷时段如凌晨 1-5 点，如果在此时间段有 5 人进入支付页面，4 人流失，支付成功率只有 20%，但这并不是因为业务故障，只是因为用户数量少导致的数据波动。所以在选择预警时间时，要注意避开业务低谷期。另外，需要结合业务的周期特点，做不同的预警设置，比如证券行业的交易与非交易时段其用户活跃数等指标相差很大，需要设置不同阈值。由于篇幅限制，获取“功能流程交互体验评估方案”以及全本白皮书，可点击文末“阅读原文”下载。 ▼▼▼
收藏★公众号，及时获取精彩内容
关注
神策数据
帮助客户实现数据驱动。
↙↙↙点击“阅读原文”，免费下载白皮书“在看”，你就戳戳我☟