作者介绍

任龙飞，负责酒店大前端，目前技术上聚焦于可视化配置建设、Serverless 建设、用户体验数字化等相关方向。

陈潜，前端开发工程师，目前负责酒店相关业务以及费力度平台的搭建工作

一、背景

在移动互联网时代，良好的用户体验至关重要，但如何量化其对业务的贡献一直是痛点和难点。毋庸置疑，体验是必须要持续推进的事情，产品、交互以及开发同学也投入很大精力去进行体验优化，但是相关的 ROI(投入产出比)无法快速量化。在大多数情况下，只能通过录屏、纯技术指标(FPS/FCP/TTI 等)来表现技术优化对用户体验的数据提升，但这表征不了整体用户体验的状态，更无法量化体验优化所产生的业务价值。 

通过调研发现，关于用户体验的度量标准有各种各样的规范和模型，较为典型的有下表中的 Google Pulse、Google Heart、支付宝 PTECH、阿里云 UES，其中有满意度、任务效率、体验性能、易用性、收益、留存率、参与度、接受度、与一致性等关键项，其中前三项是较为普遍的共识。   

满意度与易用性可以通过调查问卷来获取数据，比如净推荐值(NPS)就是通过在线上或者线下电话访谈获取数据来表征用户体验的现状；任务效率是指任务完成率和完成时间，可以通过收集和比对用户路径，帮助发现产品和体验设计上的问题；体验性能更多的是从技术维度，多角度来衡量端上的体验，如首屏渲染时长(FCP)，页面请求时长等综合来衡量体验的性能；收益与留存率来说则是从业务维度来衡量业务的现状，是用户体验的结果；参与度、接受度、一致性等则是从用户交互视角来表现用户体验的状态。

二、设计思路

去哪儿一直秉承用户第一的思路去做体验的优化。因此投入了很多精力从技术指标视角去做用户体验的优化，包含一致性、流畅度、稳定性、能耗等。

但同时也在思考另一个问题，用户体验如何关联到业务指标？我们可以对体验度量标准进行细化拆分，其中收益和留存维度是纯业务向的指标，由各业务团队尤其是产品团队负责；在满意度和易用性方面，会定期推进 NPS、用户访谈等进行用户侧体验数据的收集；在体验性能方面，有研发数字化平台 QDD(Qunar Digital Development)来量化体验数据，进而指导技术侧进行系统的体验优化；在任务效率方面，任务完成率对应的是业务的转化率指标，但是业务预订的完成时间或者费力度，其实是没有度量和分析的指标依据的，在体验性能维度也无法拆分出来对应的指标。

通过同行业比较、调研和分析，最终产出了一套方案来定义和测量用户在端内的预订完成时间和费力度，下面从这两个维度来分别介绍下对应的方案和设计思路。

三、整体方案设计

在整体方案的设计中，遵循 6sigma 原则来推进整体事情，重点考虑数据基建和指标的定义测量，这意味着在技术方案制定前需要明确如何定义和测量用户侧对 APP 费力度的真实感知。

用户费力度重点关注的是用户行为的数据状况。在用户实际操作的链路中，用户行为非常复杂且不可预测，APP 进入的策略多样、页面间的跳转方式多样、页面的点击行为也多种多样。从整个交互流程中得出页面跳转、交互行为、生单这三个关键点，费力度关注的核心数据抽象也随之展开。

围绕这三个点可以扩展出一系列具体指标，页面跳转频次、生单前的关键路径、生单前的耗时、页面及行为停留时长、用户页面访问深度、页面跳出率等。从中可以抽象出时长、频次、深度三个维度的指标，时长是结果指标，频次和深度是过程指标。

通过这三个指标，可以抽象出用户在 APP 使用过程中体验的状态。接着，时长可进一步细分为生单时长、页面停留时长和关键行为耗时，生单时长能表征用户从进入业务到业务结束的真实时长，页面停留时长和关键行为耗时能表征用户在真实操作中的所耗时长；频次可细分为单页面的展示频次、关键行为的点击频次等；深度可细分为一次生单中的页面路径长度、行为长度等。最终把重点目标聚焦在生单时长、页面频次、页面深度三个方面，以此来综合衡量用户使用 APP 的费力度，并汇总收集计算处理数据做数字化展示。这样一来，可以快速识别出偏离正常值范围的页面和行为，并加以优化。 

四、技术方案设计

依托于初期整体的思路和方案，下一步便是技术方案设计。因上述指标在数据表底层和事实层缺乏现成的数据支撑，整体技术链路需要从端上、数据侧、平台侧梳理，来确定合理的技术方案，再在对应的平台做数字化的展示。其中，涉及四个重要环节：

• 指标的定义

• 埋点的基建

• 数据指标计算

• 数据化展示

下面分别对每个关键环节做方案简述：

（一）指标的定义

如何将上文提到的指标，进行方案设计并落地是整体项目过程中的主要难点。以生单时长为例来说明指标的定义和计算过程，生单时长从概念维度泛指用户从进入 APP 到业务生单的过程。从体验和业务维度，对去哪儿侧业务进行了梳理和流程归类，发现用户的大体路径是一致的。行为始于 APP 对应的入口的进入，结束于生单完成，对其中与 APP 体验强相关的链路进行细化梳理和抽象，抽象得出下面的业务流程图，即用户在 APP 的核心路径。基于此，可以产出计算公式：用户生单时长=生单时间 - 进入业务时间。如果需要获取订后时长或者其他时长，也可以通过相关疏理得出对应的公式。

根据上图不难看出，所有业务的下单路径大体会依次经过，Home 首页（搜索入口）、List 列表（搜索内容）、Detail 详情（内容展示和筛选报价）、Booking 填单（填写信息和支付）、Pay 完成（支付完成展示页）、 OrderDetail 订单详情（订单订后服务页）的流程。为便于描述，把以上流程分别简写为 HLDBPO，HLD 都是业务的搜索和内容展示入口，PO 是订后服务相关的关键入口。当然，以上各个关键路径还有很多分支或者异常路径，其时间开销不容忽视，限于篇幅不再详细展开了。

再回到生单总时长的指标，具体是指生单前的全部页面停留时长的总和，在实际用户操作中，存在各种异常边界 case，行为可能是被中断或者打断。因此，每个页面的停留时长要去掉后台损耗时间。如果要看某个业务线的生单净值，还应去掉中间进入别的业务线页面的时间，这就依赖页面的业务归属来做数据计算。此外，还有其他的异常情况，比如用户进入 APP 某个页面后长时间停留不动的场景，端上是没有能力发现的。针对这种情况，在最终选取数据时，把极端数据和指标通过阈值降噪和 P99 指标过滤的方式进行规避处理。完成指标的定义后，下一步着手数据基建。

（二）数据基建

要获取上述的指标就要从最基础的数据维度去获取数据底表，在无基建的情况下底表里只有最底层的页面、行为数据，加上不同业务部门的规范是不一致的，所以第一步要统一埋点规范，补全数据基建，为下一步指标的测量打好基础。需要强调的是，所有的用户行为都是可穷举的，不管是页面维度、行为维度还是业务自定义埋点维度，故基建完的数据可以沉淀下来，持续复用，这也是数据基建的核心。对去哪儿侧来说，历史以来线上的埋点存在多套，各业务线都有自己的基准或者规范，一些通用的自动化工具也会增加独立的埋点规范，导致线上其实存在多套重复数据。针对该问题，长远来看更好的解决办法是业务侧的自定义埋点统一收归到一套埋点方案(除了某些特殊场景)，这也是后续数据基建要推进和落地的方向。

1. 埋点基建

通过对线上多套埋点的调研发现，前端侧已经有一部分数据基建存在，如在用户行为侧已有 click 事件埋点，在页面流转上也有 show，stayTime，to 事件的埋点，但这只是最基础的数据，还缺失业务侧需要的扩展数据。因此，可以通过复用已有埋点，添加额外扩展参数的方式快速完成基建。但要表征用户体验的费力度，还需要补充业务角度的数据(用户身份、商品星级、地区维度等)，以便后续进行多维度的精细化分析。基建建设过程中，还得同时考虑费力度与业务数据的关联，统一各业务线的核心数据，以方便地进行统一计算和处理。

2. 埋点规范

确定埋点基建后，另外一个关键动作是建立完整的埋点规范。这样可以形成文档化记录，便于统一推广到各业务场景中，避免重复埋点建设的工作，减少一部分开发资源的浪费。

以用户行为埋点举例说明。该埋点数据量巨大，场景众多，需要一套统一的可快速识别的埋点方案进行分析。行为埋点的一个关键难点是如何快速知道埋点的行为含义，尤其是代码侧和行为语义的映射。此前一般的行为埋点都是采用手动定义行为埋点，并手动绑定行为对应的语义的方式，这也导致行为埋点的运维和迭代时间成本开销大。本次方案采取的是自定义埋点结合手动标注的方式，来减少自定义埋点的成本。成本后置到标注后，所有的行为埋点都会自定义生成和上传，后续只需要考虑标注的成本。

3. 埋点自动化方案

目前去哪儿客户端业务的主流技术栈是 RN （即 React Native ），所以搭建了一套 React Native 侧自动生成埋点的方案。方案核心是以代码所属页面 &模块 &行数为数据基础生成埋点，由于都是基于 QRN（Qunar React Native）技术栈会在公共侧统一做埋点数据收拢，每一个行为埋点的所属页面+模块+行数的代码是唯一的，所以生成的单个行为埋点也是用户行为的唯一描述值，这样就省去了自定义并维护埋点的成本。下图简要梳理了自定义埋点的生成方案：

• 代码打包时：通过相关插件静态注入埋点参数，再通过在中间层级组件上挂载的中间参数（AQMProps），来不断向下透传当前层级信息，最终在点击组件上挂载的参数（viewProps）处结束。其中层级信息的获取通过 autoPath 方法来承载，需要渲染时进一步补全。

• 组件渲染时：通过执行参数信息中的函数方法（autoPath），实时做参数拼接，将层级信息串接起来。

• 用户点击时：在公共侧做参数收口，将自动注入的埋点信息和部分手动添加的埋点信息做合并，发送给 native 实时埋点信息。

4. 埋点性能优化

埋点方案是打包时注入的，这会影响注入的整个项目的性能，带来全量回归的成本。如何合理地对注入进行优化，降低影响范围，对后续埋点数据的可维护性显得至关重要，我们也在这过程中遇到并解决了不少问题。

首先，由于埋点需要动态的获取信息，势必对渲染性能有一定的影响，尤其是元素层级比较深的页面数据处理量级较大，这将在 TTI 渲染指标上明显体现出来。针对该问题，对应的优化措施是：

• 简化数据拼接逻辑，通过统一的函数方法（autoPath）拼接数据，使用字符串透传中间信息，降低信息透传复杂度。

• 通过在基础架构的 QRN 层进行 hook，使用 RN 自带的通用点击组件(基于 Pressability 封装)充当中间层，尽量简化中间层级。

• 支持黑名单配置，通过配置排除不必要的组件。

通过上述优化，对首屏可交互时间的绝对影响时长从 100ms 级别降低到 10ms 量级，如酒店详情这种复杂场景 TTI 渲染时长从 993ms 降低到 873ms 。

其次，在埋点唯一性中也有一些问题出现。初始时考虑使用行数的来表征每一个独立的行为，因为代码行数是可以起到唯一标记的作用，但是在实际业务流程中，单一文件中的代码改动都可能导致大量的埋点更新，在业务迭代较为频繁的场景下会导致行为标记持续累积。最终，决定使用组件的内部属性信息生成 md5 作为唯一性标记，这极大地减少了日常需求导致的日均新增埋点数量，维持在个位数量级，也减少了行为标记维护的成本。

（三）数据处理

在基础数据埋点基建完后，为转换为业务可以快速感知的数据，还要进行大量的计算和关联处理。比如在原始的底表数据中，所有的用户行为、页面行为、生单行为都是散落在各个表里的零散数据，底表数据要经过多次计算转化之后，才可以成为上层应用采纳和计算的应用层数据。于是对底表数据和目标数据做了梳理，产出了完整的数据处理方案。依托于数仓数据处理的基本理论，对数据进行分层设计，建立起清晰的数据结构，将复杂问题简单化，最终把数据分为三层：ODS 存储层（操作数据存储），DWD 明细层（是数据仓库的主体），RPT 数据产品层（提供为数据产品使用的结果数据）。以生单时长为例，具体说明如下：

1. 底层页面表关联订单表，生成订单页面关联表；

2. 根据页面底表，计算页面时长数据，并且串联链路；

3. 根据订单页面关联表，生成订单维度的开始和结束数据，生成订单页面中间表；

4. 通过订单页面中间表关联异常流程数据生成订单事实表；

5. 在应用层对事实表进行二次关联和展示。

在这个过程中，最大的难点是中间数据的计算和处理。由于要对页面和订单进行匹配，还要对关键页面数据进行多维度的排序和计算，所以会生成多张临时表来作为中间表，加大表之间串联关系的复杂度。另外，考虑后续方案的可扩展和任务可拆解，还需要抽象一套可快速配置的通用数据处理方案。

在整体数据处理过程中，另一个关键核心是，如何把行为数据转为应用层可以直接使用的数据，考虑行为数据都是落在 hive 表里这一点，最终同数仓和数据库的同学经过方案选型和评估后，产出了以下方案：

由于多个表的数据量级在千万级别，因此像数据关联和业务数据合并等耗时的处理需要尽可能在 hive 层完成。在 pg 数据表中，为控制空间占用大小，目前仅存储近 7 天的数据，并且把明细数据做统计分析后生成有业务指导意义的概况表，再做长期的数据存储。考虑到数据量级，最终采用了 TimeScaled 的 PG 数据表方式来存储数据，可以自动做到无用的过期数据的清理。当然在数据处理过程中还要进行降噪、去重、业务提取、单位统一等多项繁杂的工作。

数据查询效率方面也是一个重点关注的点。即使 7 天的数据，也达到 200G 的量级，为解决慢查询的问题，还做了索引优化和业务分区细化，方便数据的精确查找。

（四）平台搭建

1. 在系统平台搭建方面，借助 Qunar 内部的低代码 Rock 平台可以快速搭建起一套可视化的数据展示平台，再使用 Sylas 平台可以快速建设一个服务平台。两者相结合，一个内部的系统就可以做到无需关注配置，完整地建设起来。整体方案的优点有：

• 快速搭建

• 服务无感知

• 可自动适配和调整数据。

2. 在平台能够平稳运行以后，从数据明细、数据概览和长期趋势 3 个维度去展示整体 APP 用户体验的情况；

• 明细数据：可以展示出每一个订单经历的各个链路及对应时长。从每次的停留时长，再到行为维度，每个页面里面具体的行为，用户的真实路径和对应耗时都可以实现快速查找；

• 数据概览：通过对基础数据进行统计归纳计算，得出特定指标的均值、P50(升序排列的前 50%用户数据)和 P90(升序排列的前 90%用户数据)数据；

• 长期趋势：数据概览单指每天维度的数据趋势，长期趋势指单一指标的波动状态，如单一页面的波动情况，需要汇总每天的数据形成波状图，来体现整体页面的起伏状态。

（五）数据分析

通过对业务数据的分析可以拿到用户端的数据，如酒店侧的业务平均生单时长如下表：

其中有生单前经过的关键页面频次数据，总体数据是符合现状的，表征了目前用户生单、浏览、行为的现状，也发现了一些待优化点，比如在 List 页的筛选行为明显较多，但是要明确的指导体验或者业务的优化，还需要更多精细化的数据，尤其是业务数据。所以我们进一步融合了业务场景数据，并可以结合 AB 数据做分析和校验。

如下图中通过多维度的业务场景分析机酒生单时长，可以发现当日激活的新客场景明显耗时远大于大盘耗时，再进一步分析会发现主流程详情和预定填写页面费力度较高，结合用户的行为拆分后发掘了一些问题。

在上面数据中，对当日激活的 P90 分位数进行进行细化分析发现重复预定场景下预定费力度比大盘明显高，也存在流程不顺畅的问题，结合业务场景分拆和竞品分析，主流程在重单下有不合理的弹窗阻塞，这样就可以进一步的针对重复预定场景进行优化。最终优化上线后，该场景下的费力度降低 5%，并且线上没有转化率的影响。具体数据如下：

以上是在业务内落地的场景，后续也会持续在各业务线接入去发现更多的费力度问题，从另一个数据方向发现问题提升业务，最终抽象化为下面的改进流程，后续在 UED 体验优化、问题走查、主动发现问题侧会有更大的应用空间。

（六）SOP 流程建设

目前，以上整体方案已在酒店、机票、门票完成初步数据的接入和落地，方案由数据基建 + 数据处理 + 平台搭建三个关键流程环环相扣，实现完整系统的建设。另外在整体方案落地过程中，抽象出一整套快速接入的 SOP 流程。后续如果有其他业务场景需要接入该系统，可依照 SOP 流程，快速的完成数据的集成和展示。

• 数据源：在业务项目中接入埋点依赖包，打包时完成相关业务埋点注入，用户操作时收集目标信息；

• 数据持久化：jeus 定时任务中添加新业务线对应埋点数据，过滤出新增埋点数据；

• 数据计算展示：Rock 展示页面增加对应业务线；

• 数据分析：结合业务侧需要进行分析，发现体验的优化空间，同时精细化分拆出更多维度指标。

五、总结

从整体系统现状来说，费力度系统的搭建还处于初期阶段，目前只完成了系统初期的核心数据基建。用户体验侧的业务价值量化是一项任重道远的工作，目前抽象出来了首个关键指标“会话时长”。不过从用户或者业务视角来说，还需要洞察更多维度的数据，再结合中间提到的业务数据，精细化的拆分不同的场景，汇总"技术"+"业务"侧的双重数据，逐步去完善整个系统。

以上系统的搭建过程，只是第一步。其中也碰到了一些非常棘手的问题在攻坚中，如阅读时长、跳出率的统计等，因此只能称为对费力度度量的初步入门探索，后续团队还会持续深耕系统，从业务视角产出更多有价值的数据分析结果。

最后我们再回归主题——“如何去做用户体验的价值量化"。

在用户维度其实产出了海量数据，如果不加以使用只会成为占用空间的废品，能结合分析的数据才是真金，因此用户体验的数字化是非常重要的一项工作。在业务维度可以把数据与收益强相关的指标进行关联，从而引导业务的优化；在体验维度尝试用费力度指标结合数字化的展示，来与业务做关联。目前平台可以展示一些订单、用户行为维度的关键数据，但是如何运用这些数据去指导业务的优化，是后续最有挑战的事情。费力度表征的是整个产品链路的综合体验，差的体验会导致用户跳离 APP，与 APP 留存率指标有关联。逆向来看，可以通过细分维度发现整体 APP 体验过程的卡点和费力点，进而引导业务的优化。同时，通过用户的点击热力图，对于业务模块的效果评估也可以提供良好的支撑。

费力度系统也对自动化测试和线上 case 分析提供一定的帮助。1）基于自动化的用户回放：在产出数据的同时，依托用户行为语义化方案落地，后续结合自动化测试和回溯系统（Tars），通过语义化编排的方式，简化对用户行为进行回放、录制的成本。2）线上 case 分析：整体系统目前还可以当作用户行为细查的一个辅助工具，结合自动化数据，给底层用户行为数据有效标注，形成一套基础的数据建设，挖掘业务流程中存在的隐藏问题，对于追踪崩溃信息、线上问题排查提供更多的有效信息。

总体来说，在用户费力度系统建设过程中，给我们带来了不少启发。在用户体验工作中，需要跳出技术视角，从业务视角来看待这一关键议题。把业务和技术作为一个有机的整体，回归到技术层，结合数据化思维和可视化方向，呈现出用户角度的业务数据，通过数字化展示给产品、研发、设计同学提供多角度的数据支撑和辅助，实现用户体验的提升与业务流程的优化。未来，我们会持续沿着这一思路，结合数字化的思维，推动业务优化，形成一个完整的闭环，在数据分析和洞察方面投入更多精力，挖掘出更大的价值空间。