作者介绍：
魏子翔，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 在用户浏览首页时发生了崩溃，但是真正崩溃原因是地图组件代码导致的，对于这类指标我们采取的策略是和真实的用户体验挂钩，还是刚才的例子，我们把这个地图组件导致崩溃的页面就归属在首页，而不挂在地图组件的页面上，因为用户感受到的就是在首页的时候崩溃了，影响了也是首页的用户体验。所以类似这种指标都以发生页面为准即可（二）团队归属既然指标已经可以和页面的归属问题已经解决，接下来需要考虑页面和团队怎么关联，其实这个问题也好解决，我们可以给页面生成一个持久化 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 数据同样保存在后端数据库进行增删改查。具体流程如下：
（三）指标因为本篇文章主要介绍平台落地，指标收集方式实现就不展开讲了。这块网上相关介绍也有很多，不过大家需要关注用户体验数据的收集本身也会带来性能损耗，可以采取抽样采集策略，但是抽样的多少需要自己把控，过少也会导致数据的波动，至于指标的一些方案选型，业务定制化场景等相关信息如果有需要可以评论区讨论。
四、平台运营计划接下我们来看看运营计划是如何建立可持续的技术和运营基础的。（一）目标我们的运营目标稳步提升公司中位线：重点推进未达标团队达到基线标准；激励已达标团队不断寻求向上突破，达成优秀/卓越更高层次目标（二）阶段年初我们进行了数字化平台的搭建，上线后经过了一段时间的运行，得到了用户的良好反馈，同时也在反馈的基础上将模型打磨的更加精确合理。模型建立后我们主要进行了以下几个阶段：1. 试运行：接受用户的反馈，解决边界值情况让数据更加精确；真实数据验证并进行模型调整，让度量更加准确2. 建立基线：经过试运行的验证之后建立基线，让各团队对自己的现状有初步的掌握3. 专项治理：基于基线进行统一提升（三）方案我们的运营方案主要分为以下三个部分：1. 日常运营对用户使用过程中的问题进行答疑解惑同时收集用户反馈，从而实现模型的不断优化完善，主要通过以下几个方式：
2. 月度汇报通过平台月度数据统计让各团队，主要负责人对数字化变动有直观的了解，同时如果有问题直接暴漏出来推动改进，主要包含以下几个部分：
-
团队达标情况和变更趋势；
-
各模块达标情况和变更趋势；
-
指标、团队排行榜；
-
三/四级团队详情；
- 公共/团队改进。
如图所示：
3. 激励策略每半年对在数字化中有突出进步的团队和应用负责人进行激励，更好的让大家提升。
五、总结（一）效果1. 业务线的优化得到了很好的体现，下面截图是公司某业务线专项治理的指标趋势效果图：
2. 应用出现体验问题时也从指标上得到反馈，下面是客户端卡顿问题上升后，卡顿指标趋势效果图：
3.最后让我们看下全局看板下的用户体验平台效果：
（二）小结用户体验数字化平台从立项到现在已经 10 个月了，开发阶段也踩过不少的坑，指标的合理性也会被质疑，度量模型也做过调整，但总体来说用户体验平台带来了很好的反馈，预期目标也已经达成：
1. 统一用户体验度量模型以及指标采集方式和口径
2. 创建一个有效的机制，让我们对研发过程有量化认知，同时也让我们的日常治理活动可观测，建立可持续的技术和运营基础。（三）展望未来规划主要有以下几个方面进行优化推进：
1. 改善评分策略，使曲线更平稳，减少不必要的波动；
2. 收集指标相关的过程数据，整理输出更多的治理实践；
3. 针对不同维度的数据进行定向分析，如：高低端机。
