效能度量 商家体验 — 质量技术如何从 1 到 1.1

周助 蚂蚁质量 AnTest | 作者

前言

支付宝商家体验主要针对商户反馈的痛点，在各大站点部署了商户反馈组件，重点反馈质量建设，不仅在质量分层活动中的用户体验保障层，有了打点的产品和应用场景，解决商户反馈问题，另一方面，也是在整个定义问题、分析问题、解决问题的一次较好实践，把质量技术真正当做一个业务来做。文章源自玩技e族-https://www.playezu.com/239616.html

再次面对体验的课题，以及有一定基建的基础上，如何定义问题，并做好相应的解决方案，如何从 1 做到 1.1。这里老生常谈 “定义问题”，因为不论是技术还是业务，首先要回答的是 “你要解决的问题是什么”，支付宝首席架构师墨颜也提到 “架构师最重要的能力就是定义问题”，要不停的追问和思考，当把问题有了一个全面清晰的认识之后，后面很多的设计工作就是自然而然。文章源自玩技e族-https://www.playezu.com/239616.html

（定义问题的 SMART 原则：S:具体的；M：可衡量的；A：能落地的；R：相关的；T：时间性强的，有限制的）文章源自玩技e族-https://www.playezu.com/239616.html

背景

图片文章源自玩技e族-https://www.playezu.com/239616.html

上图是去年分析出来的业务痛点，针对商户侧反馈组件无部署、反馈问题分发及分析效率低下、反馈无回复及触达能力的三大痛点问题，建设了相应的产品能力，在商家反馈的业务上，解决了部分商家体验问题。文章源自玩技e族-https://www.playezu.com/239616.html

今年，再次面对这个课题，如何跳出来已有的业务模式，重新审视这个课题，如何推导出从 1.0 到 1.1 的演进，也是一次很好的对 “定义问题” 的实践。文章源自玩技e族-https://www.playezu.com/239616.html

定义问题

范围聚焦

“聚焦要去定义问题的业务与边界”文章源自玩技e族-https://www.playezu.com/239616.html

体验这个话题比较大，会涉及多个角色，绝不是光一个反馈质量就能涵盖的，也绝不是光靠质量一方 f 就能闭环解决的。与其在一个比较大的话题中纠结，不如缩小 scope，跳出来看，质量角色在体验的这个业务中，到底应该承担什么样的角色？解决体验的什么问题？这个是需要迫切回答的。文章源自玩技e族-https://www.playezu.com/239616.html

类比到技术风险业务领域，当把研发和业务 PD 的角色 involve 进来后，梳理得到关系图如下，在体验的业务领域中：

●PD 往往承担着产品决策者和发动者的角色，他们需要知道客户在哪里，客户在使用产品时遇到了哪些困难，哪些问题紧急度高，进而决策推进产品优化；

●研发负责优化修复产品体验问题，并且在产品有多种解决方案的情况下，提供最小成本验证能力；

●质量角色更应该聚焦在自己的专业领域，在产品体验中铺设效果防护网，接轨产研，建设商家产品的度量体系，数据化、科学化的度量产品优劣，需要回答产品的体验问题到底有哪些，用户在使用产品时遇到了哪些体验问题，将这些信息输出给 PD 辅助决策，并且在实验推进时提供强准出卡点

整个闭环机制，共同推进产品迭代由报表型产品向决策型产品演进，可持续优化，以不断满足快速变化的业务需求。

“若无法衡量，则无法优化”

明确聚焦的业务与边界是第一步，质量侧在商家产品体验中明确要解决的问题是度量体系，通过度量，驱动产品体验提升。

识别问题

“全局视角看业务，找到矛盾，找到问题”

如何去回答产品的体验质量到底怎么样，根本还是得回归到客户本身，毕竟产品是给客户使用的，客户的使用感受就代表了产品体验质量，就像饭好不好吃，吃饭的人最清楚。

去年，我们在支付宝商家域的各大站点上部署了反馈直通车，寄希望于商家把产品体验反馈给我们。但是我们不停追问，商家在使用支付宝产品时，如果遇到糟糕的体验，都会走直通车反馈给我们吗？回答这个问题，需要再往外跳一层，重新审视下当商家遇到体验问题、对经营助力有限、有竞对更优选择的时候，行为都会有哪些：

可以看到，反馈仅是其中的一种行为，还有更多的商家忍受了操作效率低下、流程中断、低频使用甚至不复访、转向竞对等行为，而针对这部分商户往往缺少有效的监测预警手段，并不会通过直通车反馈给我们，这就是其中的矛盾。虽然支付宝拥有上亿的商家，但是除收单外，高频使用商家服务（31 天内点击商家服务的天数>7 天）的商家仅占比 x.38%，而有大量的商家对商服产品矩阵尚未形成固定心智，对这部分商户的检测、预警及分析能力缺失。

另外，反馈直通车本身是个 1.0 的版本，经过大半年的运营与迭代，沉淀了大量的业务数据，通过这些数据的下钻分析，以及商户和 PD 的采访沟通，可以挖掘出来业务产品当前运行的问题，从而一一解决。

“不停追问，问题到底是什么，scope 是否覆盖的全”

看似一个 1.0 到 1.1 的课题，通过挖掘商户行为模型，不停的追问，会发现还有很大一片领域没有 cover 到，需要跳出来，全局看业务，重新定义问题。

问题细化
“从抽象到具象”

有了上述明确的职责范围以及要解决的问题，如何落地成具体可解决的问题。根据上述分析，建设商家产品度量体系，要分两条腿走路，一条是主动发现和分析效果问题，另一条是被动商户反馈。

主动发现：
主动发现也是从两方面入手（如有更好建议，欢迎补充），一个是从产品本身层面入手，主动发现产品本身能力的不足；另一个是从用户层面入手，主动发现商户使用产品时的糟糕体验；

1、产品本身能力的不足，再往下细化一层，可以从主观和客观两个维度来发现

主观：

由不同的人体验产品后，总结出来的产品体验问题。但是要注意，这不是一个明确的、可解决的问题，是一个到达路径，在这个路径中，存在如下问题

■专家经验沉淀不足

■体验产品需要的资产数据构造成本高，商家类产品走查时多需要如 营业执照、商家等级、商家门店等数据

客观：

主观评测只能解决产品本身体验的好坏，是体验者的主观感受，但是无法回答跟市面上其它产品间的差异，无法知道我们的产品体验处于市场中的一个水位，具体拆解为如下问题

■同类产品竞对分析，如 产品的收费费率差异、入驻的门槛要求差异 等

■竞品变更检测，如 实时感知竞对的产品上新、变更 等

2、用户使用时的糟糕体验，再往下细化一层，可以拆解为数据和监测能力两部分

防御性指标

在目前产品数据化运营的体系中，往往关注正向的业务指标，如 点击率、转化率、PV/UV 等，而对涉及用户体验的防御性指标，如白屏率、成功率、打扰度、流程效率、复访度、操作耗时等，而用户使用产品时遇到上述体验问题时，都会反馈到这些防御性指标上，该维度主要是作为效果防护网，和产品策略指标 merge 形成 B 侧产品矩阵的完整指标体系。

体验监测

有了上述防御性指标，需要再进一步回答如何通过指标数据的计算，提炼业务产品特性，将体验 badcase 召回，并能结合商户特征、产品特征、业务变更，汇总业务产品、动线，将波动归因、异动情况分析、趋势，通过产品化视图的方式展示。

被动反馈：

被动反馈基于去年的产品直通车，是个从 1 到 1.1 的过程，这个过程最好的方式就是通过数据化分析及用户访谈的路径，来重新定义问题：

图片

1、反馈数据质量低

原期望用户能通过文字 + 截图的方式描述反馈建议，但是从历史收集到的全量商户反馈来看，不少商户反馈的数据描述不清，缺少关键结构化信息，导致后续问题分析及处理的阶段效率低下，甚至无法处理，需要与商户进行多轮沟通交互，降低整体效率。

2、处理率/时效低

直通车建立了商户和 PD 之间的直达通道，形成了商户反馈的跟踪、流转、处理机制。但是随着产品的运行，处理率及处理时效逐步下跌，通过系统数据下钻分析和线下采访产品经理，总结原因如上。

3、感知度弱
| 指标 | 定义 | 数据 | 分析 |
| -------- | -------- | -------- | -------- |
| 组件红点点击率 | 红点消除数/红点总数100%|%| 回复未触达商户，未感知；触达商户，移动端查看不消除红点 |
| 移动端通知曝光率 | 曝光条数/发送总数100%|%| 触达商户消息模板采集曝光率数据，曝光存在转化漏斗 |
| 移动端通知点击率 | 点击条数/发送总数100%|%| 触达商户消息模板采集点击率数据，曝光及点击存在转化漏斗 |
| 反馈评价率 | 反馈评价数/问题完结数100%|%| 待评价未触达商户；商户评价意愿低；|

去年建设了 PC 组件内红点通知，以及移动端触达，旨在解决 PD 处理后触达商户的时效，但是通过数据分析来看，整体感知度仍然偏弱。

“剥洋葱法，由外向内”

将大的抽象问题，逐层拆解，直到问题细化、可解决。

升级思考

“以客户价值为核心，全链路推演，是否解决用户问题”

上述看似已经得到了今年要去解决的具体问题，但是还需要进一步升级思考，不断追问自己，是不是解决了这些问题后，就能提升商家体验？

很显然，并没有。

再次回到定义问题的第一步，范围聚焦，会发现上述定义出来的问题，仅是聚焦在商家产品度量这一个模块上，解决的都是体验度量的问题，而我们跟研发最小成本验证能力和产品决策机制升级之间的链接，还缺少，需要补充这两个链接以商家体验优化的三角形闭环。为此，又看到如下两个问题：

●问题闭环：

不论是通过主动发现，还是被动反馈，在经过系统数据和算法能力处理，识别出了体验问题、优先级、甚至推荐方案后，终归是要靠产研优化解决的。因此，需要一套工单系统，来解决问题的闭环；另外，还需要持续地给商户以反馈，让商户能感知到我们的产品在逐步的优化，进一步增加商户对支付宝的信心和参与度。

●防御性指标形成产品决策：

正如上述分析的，防御性指标需要纳入产品数据化运营体系中，但是，如果只是作为体验度量大盘，还是比较偏事后。借助 “测试左移” 的思想，需要在事前/事中的环节设置相应的质量策略，更多的将体验问题拦截在产品全量上线前。在升级后的决策型产品，多种产品方案灰度实验期间，防御性指标需要对接实验准出策略，在实验阶段添加效果防护网。

“以客户价值为核心，解决客户问题”

商家体验这个课题，商户核心诉求是产品的好用、易用，最终提升经营价值，质量侧重点通过主动和被动两种手段，建设产品度量体系，但是也要看到跟能力优化、实验准出之间的衔接。

建设思路

有了明确的定义问题后，今年的建设思路也明晰起来，这部分主要分两块简述：场景圈选、解决方案

场景圈选

“大处着眼，小处着手”

项目要成功落地，得先选择一个合适的场景握手，逐步进行能力打磨后，推广全量支付宝商家产品。

我们选择收单商户为圈选人群，收单动线为目标动线，其思考如下：

●动线清晰：涉及签约、物料、收单等产品，并且动线上产品顺序性及逻辑性强；

●用户面广：尽管当前支付宝在向数字化转型的过程中，但是基础的收单产品仍是支付宝商家日常最频繁使用的；

●收益率大：基于上述，收单动线上的产品体验优化，可以让收益率最大化。

整体以收钱码商业版为标杆场景，进行贴合业务的能力及指标建设，其思考如下：

●业务重要性：重点项目，不仅是监管合规，更会对当前整个商家分层运营体系进阶，在市场中支付份额占比起着举足轻重的角色，影响面重大；

●新产品：商业版是新产品，其体验决定了商户对产品的第一印象；

●竞对狙击风险大：受监管影响，微信也会在同期发布其收款商业版，对腰部平台运营型商家的争夺会异常激烈，尤其是在 入驻门槛、费率、差异化服务 的比对分析能力缺失；

●基础设施相对完善：移动端的埋点及框架相对完善，便于指标采集。

解决方案

针对整个产品上线的流程，我们在原有的产研业务流程中，补充嵌入了蓝色部分的体验防护网：

产品构思阶段

重点识别产品体验问题，通过细分评测方法、可选组合沉淀评测模型，并供给客观数据分析结果及评测资产，支撑挖掘产品体验及竞对狙击问题，对产研的正向产品需求形成互补；并通过资产池、评测工具的赋能，提升主观评测效能及复用性。

产品研发&实验阶段

沉淀防御性指标体系，其数据模型可以参考总结的这篇文档，主要供给快速接入的指标组件，并对接商家产品的实验准出能力，形成产品体验防护网。

产品运行阶段

重点通过数据能力，识别运行时的产品体验问题，形成商家产品体验观测大盘，进行相应的诊断分析，再通过后置的问题处理模块解决，建设 数据-->问题-->人 的业务模式，数据驱动产品体验提升。

技术架构

简介

沉淀商家产品度量体系，依托数据和算法，识别体验问题、推荐改进方案，数据化驱动支付宝商家产品的体验优化，并给商户反馈，提升商户满意度及经验价值；重点从主动指标评测和被动商户反馈两条通道发现问题，体验数据纳入产品决策能力。

核心能力

体验监测：

根据下层供给的防御性指标、业务变动、产品特征、商户特征等数据，建设产品体验模型，通过算法模型，支持异常感知、波动分析、影响面预测的分析能力，通过商户动线的维度沉淀可视化大盘。

防御性指标：

基于商户使用产品遭遇差体验的行为模型，构建商家产品的规模化防御性指标体系，包含可用/好用/经验价值指标、反馈数据、竞对数据，为体验模型提供基础，能结合产品及动线透出并下钻。

工单能力：

基于商家服务库及产品星球，对挖掘出来的体验问题路由到对应的角色，结合问题影响面，通过工单系统提升高优问题的解决率和时效，并及时触达商户，挽回因体验问题而导致的沉睡商户及流失商户。

展望与思考

总结

今年，再次面对体验的课题，在去年的基础之上，原本以为是个 1.0 到 1.1 的过程，通过不断的范围聚焦、问题识别、问题细化、思考升级，重新定义了问题。

首先圈定了质量侧在体验的课题中负责的核心问题，通过之前的 “把质量技术当业务来做” 的实践，定义了主动发现商家产品体验需要解决的业务问题；通过精细化的数据分析及走访，定义了已运行一段时间的反馈直通车今年需要解决的业务问题。最后，再次回归客户价值，又定义和产研之间的环节衔接问题。

展望

我们不断追问，一次次否定自己，跳出来看全局。希望在本次升级中，除了工程链路的升级外，完善商家产品数据化运营体系，要让数据成为决策的主要依据。更多结合算法及 AI 的能力，进一步系统化地解决产品体验问题，而非单点解决；并且通跟研发和产品打通整套闭环机制的建设，让产品从商家角度出发，以商家价值为导向，而非上线为终点。

去年，还有一点不足的是架构视野的拓展。今年，除了跟产研的联动，在规划的技术架构中，还惊喜的看到部分模块，BU 内外已经有较为成熟的产品或团队也在做类似的事情，比如 工单系统、外网数据采集、数据洞察分析 等，这些能力的开放与集成，会为今年商家体验的落地大大加速进程，我们站在巨人的肩膀上，重点建设商家业务的域特色能力，共同拿到结果。

思考

随着认知和定义问题能力的升级，我们看到了更大的业务 scope。但是否还有更多隐藏在冰山之下的部分，我们也在持续探索，也欢迎大家抛砖引玉。