如何进行平价版的体验度量实践.docxVIP

如何进行平价版的体验度量实践 前言 关于用户体验是否可以度量的命题，之前看过很多关于体验度量相关的文章和研究，度量的模型和对应指标层出不穷。但实际操作中，往往因为涉及较多数据基建的工作，准备成本高，数据分析资源不足，追溯周期过长，价值优先级靠后等原因而中道崩殂，真正实际验证的案例也较少对外分享，一度出现人人都能说出几个模型名称，几个体验指标，但是都对其能对业务起到的价值讳莫如深的现象。 去年我们在一个小型工具产品上进行了一次较为完整的用户行为度量的实践，提炼出一套落地成本更低，对业务价值更加显性的行为度量方式。 本次分享仅做抛转引玉，也是对整个过程的思考推导做一次梳理和记录。 1. 奢侈全埋点 v.s. 平价核心路径——节省技术成本 在理想状态，如果用户在产品中的所有行为都有埋点，即有整个产品的全埋点，我们理论上就可以还原出整个用户操作路径的流向，然后从全局中可以一目了然判断出不符预期或有问题的行为数据流向。但现实产品中，尤其是工具产品，用户的操作集中在非线性的自由画布上，因数据成本极高和开发资源消耗大，全埋点的实施过于奢侈。 退而求相对平价做法，比起全埋点，我们选择对「核心路径」进行定向埋点。定义重点关注的关键路径，以缩小数据范围。 打个比方，就像是在一摊磁粉中，放一根磁条，靠近（相关）的会被更紧密的吸附（筛选）。减少了遍历用户所有行为数据的计算量，从而降低成本。 那么需要达成共识的前提是核心路径的定义： 用户在使用后可以理解到产品的定位和价值的功能点的串联。 我们可以简单理解为，在产品定位没有大偏差的前提下，能够体验完产品预设的核心路径的用户可以更容易理解到产品的定位和价值，即更容易转化成活跃留存用户。而有很大一部分的用户流失，正是来自于没有能够成功体验完核心路径，即没能够充分感知到产品价值。 没有体验完的原因可能来自于没有发现该功能，也可能因为功能可用性太差以至于放弃完成等等。 故通过对核心路径架设监控的指标，监测用户的实际行为数据表现，来识别核心路径和路径上各个触点功能的健康度和问题点，作为对整体用户留存提高的贡献指标的重要一环。 2. 理论侧：体验指标转译业务结论——节省沟通成本 2.1 单指标模型的困局 本次使用到的核心体验指标：（此处为白话释意便于快速理解，若感兴趣请关注系列续篇，将会阐明每个指标背后的数据采集和定义。） 触达率: 用户是否能注意到并使用功能 任务完成率：用户是否能顺利完成任务 跳出率：该步骤作为用户在完成任务时最后一步的可能性 任务完成步骤：用户完成步骤的分布 任务完成时间：用户完成任务的时间分布 根据每个指标单独看的话，报告的结论可能会是例如“全量用户在核心路径A的任务完成率为67%”，而这并不算是一个有效反馈，因为不足以启发业务侧产生深入的机会点发散，同时也会产生大量的沟通解释成本。 故仅是描述单个指标的数据表现是不够的，需要得到更深入的结论并转译成业务指导意见。我们归纳了两种方法，进行进一步的指标数据分析，同时能让业务能够自助解读指标数据含义。 2.2 方法一：分层对比 单个指标的数据的绝对高低没有意义，例如“数据A功能入口触达率43%”，是无法独立得出有效结论的，需要通过比对才能看出相对高低。 分层对比指的就是在比较指标的时候借助参照进行比较，常用的如新老用户对比、达到同一个目标的相似路径对比，或者借助标杆如活跃用户来进行比对，从而得出结论。 下表为一些通用型的结论方向： 2.3 方法二：交叉对比矩阵 方案一是我们常见的用法，但是在真正处理数据时，我们发现交叉对比另一个指标的高低，可以结合另一个视角，得出更深入的结论。我们整理成矩阵的形式进行呈现，方便对照查看。其中对应的结论有一定的普适性，但同时也需要结合具体业务情况进行进一步的剖析。 3. 实践侧：前期预设后期验证——节省分析成本 在多条核心路径会包含多个触点的基础上，如果想用枚举的办法去建立数据看板，从而得出业务结论的话，其实仍然发散性过强工作量庞大。从设置指标到埋点再到数据获取和分析有一定的时间周期，在埋点之前能够借鉴科学实验设计好整个实验思路，能对执行的进度和之后能够得到的反馈有更强的掌控，避免在输出结论的时候全是散点。 所以我们在具体实践的时候借的鉴了实验的流程步骤：定义路径，建立猜想，数据验证，得出建议。通过猜想和验证的形式来收敛数据分析的方向从而节省分析的资源投入。 定义路径：拆解业务目标到体验目标，在体验目标中找出具体需要关注的核心路径。并检查埋点是否到位。 建立猜想：基于理论模型进行多条猜想的建立，如果核心路径的A指标出现了B1的数据表现，即可能是C1问题。如果核心路径的A指标出现了B2的数据表现，即可能是C2问题 数据验证：拉取一定周期内，某一用户层在该核心路径和路径的各个触点上的数据，并建立数据看板。 转译建议：对