编辑导语：在项目流程中，大部分人认为设计师只会追求视觉好看，不懂业务，所以设计师的话语权一般不高。本文作者从用户行为监控方面分析B端的体验度量衡，希望能帮助设计师拿到话语权。

在实际项目流程之中，通常设计师的的话语权不高，这个来源于大家对于设计师本身的刻板印象（只会追求视觉好看）。但是显示情况好多设计师也不懂业务，所谓的设计的出发点就只有视觉。我也是希望能帮助到同行们拿到话语权。

01 为什么我们要学体验度量衡？

针对项目前期中期后期，体验度量衡有不同的作用。项目前期主要是找设计目方向，找到合适的业务目标确定设计目标从而能说服别人认同自己的想法。

项目中期主要常常场景是制定目标以及之后的向上级要资源，设计过程中不光涉及到页面设计还涉及到了团队资源（用户调研，开发资源支持等等），每一项资源调用和配合都要讲清楚业务上的“必要性”说服别人来跟你进行配合。

项目后期主要场景是拿设计结果（不论正负），来为设计进行证明自身设计的价值。经常性是用来进行复盘和职位晋升报告（向上报告），为自己争取更多的话语权。

02 B端常见的体验度量衡

常见的体验度量衡主要是分为4类：

1. 使用度/路径
2. 使用效率检测
3. CES/NPS
4. 业务指标

使用度/路径检测包括：

• PV
• UV
• 操作步数

使用效率检测包括：

• 完成率
• 完成效率

CES和NPS包括：

• 净省力度（CES）
• 净推荐值 (NPS)

业务指标就比较多了，例子：

• GMV/PMV
• 续费率
• 月活/周活/日活
• 客服成本
• 设计/开发成本

针对不同业务/阶段/目的/功能/流程选择不同的指标，这个需要结合业务去谈。

按照数据进行区分：使用度/路径检测和使用效率属于用户行为监控，CES和NPS属于体验度量衡指标，GMV/续费率等属于业务指标。篇幅有限，这一篇主要是讲用户行为监控。

03 用户行为监控

用户行为监控物理映射的是实际生活中的监控摄像头，监控用户的行为/时间/步骤/位置/人数/从哪里来/去了哪里/接下来要去哪里的等等情况。

本质是通过埋点，检测用户的浏览，操作系统的各类数据。通常分成3类监控使用频率，监控使用效率以及性能监控。

1. 使用频率监控

1）常见参数

频率监控的常用参数：

• pv：用户进入页面或者功能的次数
• UV：进入到功能或者是功能的用户数，通常基于PV进行查重
• 曝光率：首屏进入到用户视野中的次数/使用次数，通常在监控曝光率的埋点是监控功能的点击率

注意点：实际工作中很多人误把只要功能被用户看到了就算一个次数（例如选项卡未选的候），其实这是一个误区这会导致最后统计的错误影响到最后设计的结果。

2）埋点前需要做什么？

埋点之前有个埋点评审，通常要说明：

• 为什么要埋点？——这里主要是讲卖点对于业务/用户/商业的价值
• 埋什么点？——这里会给一个表格，分为模块，功能，字段。开发会转化为KEY的值（具体开发去操作）
• 怎么做？——开发区完成

埋点对于产品经理和设计师的意义不同。如果是产品经理发起的埋点主要是针对新上线功能的使用频率，如果是设计师的话更多情况是流程或者是功能的优化。

注意点：开发有能力把全部的点给埋上，但是埋点贵精不贵多，埋点过多的话会让开发怀疑你埋点的意义是什么，而且在后期拿到数据的时候也会因为数据过多导致分析的难度增加。所以在埋点之前一定要想好为什么要埋点。

如何建立筛选维度也是一个很需要思考的事情。

3）如何建立筛选维度

常见的埋点参数（请根据你的业务和目的进行选择）：

• 时间-必要字段：要不然需要的是从项目1.0到现在的所有时间段
• PV/UV：这个具体的要看业务
• 商家ID：这里根据业务可以变化，比如电商里面的商家ID，视频产品里面中的发布者ID等等
• 主营类目：根据主营业务进行，比如淘宝就是电商
• 用户ID：常见的是表格业内的筛选，不同的角色有不同的的字段权限，用户甚至可以自定义模板。工作台也是能根据角色来进行区分，不同的角色有不同的工作台。
• 来源标记：例如文章的来源等等

具体的要看你的业务类型/处在的阶段/埋点的目的等等信息进行自己判断。

4）第三方BI平台

建立BI分析平台需要一定的资金和技术的作为基础，往往一些公司没有多余的能BI分析平台，所以第三方BI平台随之诞生。比较有名气的：神策百度移动统计（主要针对移动端）、友盟、腾讯MTA。

一些公司担心数据泄露又不缺少建立的条件，所以会自己建立BI平台。

2. 使用效率监控

1）常见参数

监控使用效率主要参数是两个完成率和完成效率，分别的计算公式是：

• 完成率=完成结果页PV/新建页面PV*100%
• 完成效率（完成时长的倒数）=访问结果页的时间刻度-完成表单页的时间刻度

接下来分解两个参数的取值范围以及实际情况可能会遇到的误区。

2）完成率

完成率常见的误区是实际工作中有些用uv（进入功能/页面的人数，基于PV去重）代替PV，导致测试出来的数据并不准确。造成的这个原因有：

• 用户可能会多次打开或者是多次关闭页面
• 完成率是基于任务完成度进行计算的，任务完成才是关键
• uv是独立访问，通常基于PV进行去重，但是无法统计任务的个数

3）完成效率

计算公式：

完成效率（完成时长倒数）=访问结果页时长-访问表单页面刻度

通常取值范围：

• 中位数：可以免受最大值或者最小值等极端情况的影响
• 众数：出现最多次数的数据

汇报小技巧：对上级进行汇报的时候，汇报比较大的数字。比如：修改前操作时间是5分钟，修改后是2分钟。按照完成利率的计算就是提高60%，完成效率150%。那你赞找完成效率去汇报，上级会更满意。

4）性能监控

性能监控主要是监控前端页面的响应速度，作为设计师只能发起体验项目，无法进行执行，帮到的忙不多。

通常的判断标准2-5-10原则：

• 2：首页2秒内响应速度，如果是官网的情况下需要更快的反应速度
• 5：普通的的页面响应速度要在5秒以内
• 10：复杂的查询以及表单页面响应速度要在10秒以内

一点超过这个这个标准用户就会大概率离开。

04 测试周期以及数据对比

常规的测试周期：

• 7日：主要是针对营销活动等需要短期数据的进行测试，从而验证运营活动是否达到立项之前的目标
• 14日或者是30日：常用于B端新功能的测试周期使用

真实项目中，有一些项目总是急着要去数据验证，上线后1个月就需要验证需求/设计的必要性。作为一个打工人可以理解这个问题，因为在公司里面很多时候是依靠数据验证自己的价值以及在升值加薪时候的用。

但是这里没有考虑到用户学习新功能需要一段时间（常规是一个月），在用户学习的过程中某些数值会降低（完成率或者是完成效率），而会导致测试的准确性失真从而导致回滚。所以，通常数据对比的隔月的旧数据进行对比。

重点再安利一遍“不要用下一个月的数据进行验证”，而是用隔月的数据进行验证！！比如7月底上线的功能，验证的数据应该是是9月的数据。

05 总结

从整体来讲学会体验度量衡能让我们的设计验证是否符合用户跟场景，以及在做向上管理的时候有不错的效果。其中完成率跟完成效率能实施对用户行为的监控而获得客观的数据，性能监控主要是开发效果的验证。

最后再安利一遍：不要拿下一个月的数据进行对比，要拿隔月的数据进行对比！

资料来自 美芳老师《且曼B端设计》

本文由 @一只鸡腿 原创发布于人人都是产品经理，未经许可，禁止转载

题图来自 Unsplash，基于 CC0 协议