用户体验数字化平台落地

原创魏子翔 Qunar技术沙龙

作者介绍：

魏子翔，2017年7月加入去哪儿网，主要负责Android原生和跨端框架方向的研发和维护，期间主导了客户端架构升级、稳定性提升、性能优化等多个重点项目，近期专注于用户体验优化治理相关事务。

一、背景介绍

（一）关于我们

我们先看下网上对数字化平台的解释，是指由人员、流程和工具组成的定制化平台，即服务产品，使团队能够快速开发、迭代大规模运营的数字化服务。

再来介绍下去哪儿网的业务，去哪儿网是一个典型的在线旅游平台，它上面的业务繁多，有机票、酒店、度假、火车票、汽车票等，细分业务线多达近40个，业务功能更新迭代快、同时伴随着产品开发人员更替、多技术栈混合使用，产品逻辑复杂多变。

（二）为什么做体验平台

那么我们为什么要开发用户体验数字化平台，其实有以下几个方面的原因：

第一个是不同业务线对于相同指标口径和采集方式不一致，拿页面可交互时间指标来说，口径上有从页面跳转或者从页面创建开始采集的，采集方式上有使用插桩来也有手动埋点实现的。这样来看会比较混乱，不同的业务线也没办法横向对比，通过用户体验平台，在框架层面确定一致的采集方案，并统一指标采集口径。

第二个是对体验维度的关注侧重点不同，比如有的业务线更关注应用的稳定性，有的业务更关注应用的流畅度，通过平台可以补齐各业务线的差异，确定不同指标的优先级，梳理出统一的用户体验度量模型。

第三个也是最重要的是，客户端作为业务的主要入口，其所提供的用户体验是非常重要的。虽然我们一直都在致力于提升用户体验，但是我们缺少系统化的定量评价的手段，清楚的说明我们的用户体验当前处于状态和水平。通过该平台可以创建一个有效的机制，让我们对用户体验有量化认知，同时也让我们的日常治理活动可观测，更好的适应不断变化的环境，建立可持续的技术和运营基础。

二、体验度量模型

既然已经知道了构建用户体验平台的原因，那么重要的就是我们的体验度量模型，其中会包括我们的评测维度，评分标准以及如何对数据进行度量分析等。

（一）模型

接下来介绍下我们的用户体验度量模型：

通过上述模型我们可以看出，主要是对流畅度、稳定性、能耗、磁盘占用和用户反馈五个方面进行评测，对用户使用应用相关的数据进行采集。如图中所示每个指标有P1 P2 P3标识，这代表着指标的重要程度，数字越小越重要。级别的划分是依据对用户体验影响的大小来评定的。

关于指标的选取我们是采取了业内关注+自身经验的结合：启动时间、崩溃、卡顿等都是业内各个大厂重点关注的指标，口径也比较统一；除此之外我们也通过用户投诉，整理沉淀下来了页面30秒后台被杀和应用发热指标。每个指标选择背后也都有对应的理论支撑。

流畅度指标：我们可以很容易通过业内的研究报告看到其中的价值，减少用户可见时间，可以提升用户留存率和交易量。

Google发现页面加载时间超过3秒 53%的用户将停止访问
Amazon发现加载时间每延长1秒一年就会减少16亿美元的营收
FPS和卡顿会带来页面刷新不稳定、视觉感官画面不连贯的问题

稳定性指标、能耗指标：导致用户流失，减少收益，打断用户正常操作。

切后台短时间被杀或者使用过程发生crash，属于中断性的，打断了用户的正常操作，对用户伤害很大
手机使用期间发热和切后台被杀，由用户反馈，值得关注，因为据统计，73%的性能体验问题都是由用户发现的，遇到问题98%的用户会选择沉默或离开，仅有2%的核心用户才会进行投诉反馈。

磁盘占用指标：减少磁盘占用可以提升用户转化率。

当手机存储空间不够用时，会优先删除占用存储空间较大的app
Google play数据分析一个 APK 的大小每增长 6 MB，下载转化率就有 1% 的降低，如下图:

（二）指标评分

针对每个指标级别指标划定不同的得分标准，用于区分不同级别在整体得分中的权重，如下图所示：

有了上面的指标模型和得分标准，然后可以对收集上来的指标进行得分计算，下边我就基于稳定性的 Andorid 崩溃指标介绍一下数据处理流程及计分规则：

1. 确定指标级别

Andorid 崩溃属于 P1 级别。

2. 确定该指标值所处的好中差范围

附：Android 崩溃率范围好:小于 0.04% ；中:0.04% - 0.08%；差:大于 0.08% 。

假设 Android 崩溃率为 0.05% ，那么所属范围为中等。

3. 查找指标级别和所处分数阶梯

所以当前 Andori d崩溃率指标为 P1 级别中等，得分为 4 分。

（三）度量分析

根据用户体验的指标得分，我们可以从全局和细分两个维度来进行度量分析：

全局维度

APP全局
团队全局

细分维度

团队指标
页面指标

APP 全局维度比较好理解，只要把收集上来的数据解析处理，但是我们是怎么对页面以及团队进行度量的呢，这就取决于我们在采集指标时把指标数据和页面做了绑定，这样页面的得分其实就是该页面所有指标的得分聚合，为了便于用户使用，我们做了百分制的处理，如图所示：

团队的度量就更简单了，我们把页面和团队进行关联（具体的关联方式可以关注下面讲到的用户体验指标收集），团队指标通过页面指标聚合即可。

三、体验数据收集

体验数据的收集是要为上面的用户体验度量模型服务，在度量分析中有一个重要的点就是指标数据和页面团队的关系，这里我跟大家聊一下指标数据的关联处理实现。

（一）页面归属

我们在上文度量模型中可以看出来，我们度量的最小维度是 APP 的页面，那么我们要怎么把所有的指标都和页面绑定呢？

其中有些指标是天然和页面有关联的，比如页面的可交互时间，页面的渲染成功率等，这种数据直接把数据所属页面关联即可。但是有些指标是和页面关联性不大的，像崩溃和卡顿，比如在 APP 在用户浏览首页时发生了崩溃，但是真正崩溃原因是地图组件代码导致的，对于这类指标我们采取的策略是和真实的用户体验挂钩，还是刚才的例子，我们把这个地图组件导致崩溃的页面就归属在首页，而不挂在地图组件的页面上，因为用户感受到的就是在首页的时候崩溃了，影响了也是首页的用户体验。所以类似这种指标都以发生页面为准即可

（二）团队归属

既然指标已经可以和页面的归属问题已经解决，接下来需要考虑页面和团队怎么关联，其实这个问题也好解决，我们可以给页面生成一个持久化 ID ，然后对每个页面 ID 关联上页面所属的团队信息即可。那么应该如何实现呢？

我们可以参考客户端埋点方案，大体分为三类：手动埋点，可视化埋点，无埋点(自动插桩)方案。类比当前的需求，需要在编译前就要确定页面和团队的关联关系，那么可以考虑手动添加页面ID和自动插桩注入页面ID的方式，先来看下这两种方案对比：

方式	手动添加	自动插桩
优势	代码清晰，按需设置页面ID，定制性比较强	业务无感接入，维护成本低，覆盖率高
不足	业务开发工作量大，维护成本高	技术难度相比较手动添加稍高
适用场景	定制或复杂场景收集，或者针对一些边界场景的补充	逻辑不复杂，需要覆盖率高的场景

通过上面表格不难看出自动插桩覆盖率高，接入和维护成本比较低，且技术难度中等，最终我们选用自动插桩的方式生成组件 ID ，整体流程如下：

编译前通过后端接口获取页面 ID 等信息
编译时对页面 Activity/Fragment/ViewController 生成 ID 值并插桩 getPageId 方法
编译后把页面 ID 和所属组件等信息，通过接口传输到后端进行更新存储

这样用户体验数据就可以通过页面 ID 找到所属的团队了，然后我们再看一下客户端技术实现的关键点：

Android 端在 apk 打包的编译期，采用 Gradle Transform + ASM 技术统一处理 class 字节码文件，我们采用两个串行的 Transform 处理字节码，因所有代码都是静态代码，无法动态获取类的继承关系树，TransformA 负责扫描所有类的父子关系映射表，TransformB 根据类的继承关系，判断是否继承自 Activity/Fragment ，然后查找后端统一的存储服务，判断其是否已生成 ID ，如果有则直接在类中插桩增加 getPageId 方法，没有则通过我们自研的算法生成新的 ID 值并通过后端接口更新到数据库。

iOS 端同样采用编译期注入，但技术实现与 Android 有细微差异，iOS 在业务组件库打包时注入方法：使用 clang 工具库 libTool ，在编译时提前预处理 .m 源文件，通过 ast 节点信息判断是否继承自 ViewController，并在其子类插入 getPageId 方法，ID 数据同样保存在后端数据库进行增删改查。

具体流程如下：