我曾受益于数据，发现一个不被公司重视、却每天能带来用户线索的 APP。

随后，对其数据，进行全面分析，针对每个环节存在的问题，制定优化方案，说服公司继续投入。

在没市场推广的情况下，线索翻了一倍。这个经历，成了我提升的一大跳板。

因此，每次面试，我都会重点了解应聘者，是否有用数据分析辅助做产品的经验，还是习惯 “ 拍脑袋 ” 决定功能设计。

结果总是不如人意。

深感能否用数据分析指导产品设计，真是产品经理水平的一大分水岭。

数据分析，是产品经理一项非常重要的能力，能指导我们设计产品，透过数据，更能及早发现问题，找到解决方案。

如今，有很多成熟的数据统计或 BI 工具，产品数据的获取与计算已非难事。

对产品经理而言，更需掌握的：是定义采集数据的标准，即数据埋点其次，。

数据埋点，在 C 端产品很常见，在 B 端方面，似乎很少提及，有人甚至以为不用。

稍有规模的系统里，很多环节的运行状况都需要监测。这时定义清晰数据埋点，用于分析系统运行情况，反映系统性能，尤为重要。

可从何学起呢？

现在 B 端产品流行，今天分享一个 B 端系统里面，很实用、有代表性，却常被忽略的数据分析过程：

（订单在各类系统中较典型，以此为例）

对系统中订单完成的处理时长进行分析，最大的好处，是可以得知系统的效率多高。

同时，还很容易发现哪个地方出问题。例如，一旦订单流转过慢，就能看出在哪里耽误了。

有人认为，这是开发做的事，常常忽视了产品经理应该做的那部分。

数据的获取和计算，确实要开发实现（如有统计平台或 BI 则更为简单）。

产品经理则要根据分析思路，进行最关键的流程梳理、节点定义，统计出来的数据才准确、有意义。

具体怎么做呢？

1、绘制时序图

做系统需求时，绘制出系统业务流转的时序图，能让系统在各个环节的信息交互顺序更为清晰、明确。

2、定义信息交互节点

做完功能需求后，围绕整个订单的流转过程，定义要统计的时间节点。

这时，时序图的优势彻底发挥出来了。

这也是我在实践中的偶然发现，用时序图来定义节点，非常方便，开发、测试一看就懂。

以 “ 手机充值 ” 为例，稍微简化下，只保留核心流程，以便说明。

用户从下单充值，到充值完成，这一流程，需在前端产品（如 APP、H5 或小程序 ），后端系统（因公司而异，或有多个系统，这里简化成一个），供应商（如三大运营商）之间交互。

交互的顺序和节点，可看下图：

如图，按业务分析的需要，在每个节点标出编号。同时，定义清楚触发时机，如下图：

只要把这些节点定下来，马上可得出各个环节处理时长的计算方法。

3、明确各环节时长算法

一旦在时序图上，标出了对应的信息交互节点，各个环节的时长一目了然。需要统计哪个时长，一看便知，是从哪个点到哪个点。

这例子中，一般会关注：订单总时长、后端系统处理时长、供应商处理时长，这三项数据。

4、分析数据

有了以上的定义，再借助技术手段，获取、汇总并呈现数据，分析起来别提有多方便。

一谈到分析数据，都喜欢看趋势和平均值。这里要讲的是，

常用的是，看一段时间内数据的百分位数去分析。比如，一天内所有订单总时长的 50% 分位、90% 分位。

所谓百分位数，就是将数据，从小到大排列，计算相应的累计百分位，则某一百分位所对应数据的值，就是这一百分位的百分位数。

比方说，一天内订单总时长的 50% 分位为 1 秒，即所有订单总时长中，排在第 50% 位置的时长是 1 秒，这意味着有一半的时长少于 1 秒。

此外，还要关注峰值、异常值，如最小时长、最大时长。

简单画个分析报表，以供参考。

数据一摆出来，各个环节效率如何，是否有问题显而易见。

5、得出结论

以上述为例，从这些数据中，至少能判断出：

1）用户感知的充值过程是否够快。

用户不会耐心等待，一旦太慢，甩头就跑。从体验的角度，订单越快，用户体验越好，越能留住用户。

2）自身系统处理效率如何。

系统运行是否正常，有没有处理太慢、卡住的现象。一旦出现异常，可快速定位问题。

3）上游供应商的处理效率如何。

供应商的处理效率，大大影响了平台的处理效率。有了这个数据，就能客观地评估、对比供应商的服务质量。

总而言之。

这只是一种思路，用什么图、什么工具并不是最重要的。

-END-