我曾受益于数据，发现一个不被公司重视、却每天能带来用户线索的 APP。
随后，对其数据，进行全面分析，针对每个环节存在的问题，制定优化方案，说服公司继续投入。
在没市场推广的情况下，线索翻了一倍。这个经历，成了我提升的一大跳板。
因此，每次面试，我都会重点了解应聘者，是否有用数据分析辅助做产品的经验，还是习惯“ 拍脑袋”决定功能设计。
结果总是不如人意。
深感能否用数据分析指导产品设计，真是产品经理水平的一大分水岭。
数据分析，是产品经理一项非常重要的能力，能指导我们设计产品，透过数据，更能及早发现问题，找到解决方案。
如今，有很多成熟的数据统计或 BI 工具，产品数据的获取与计算已非难事。
对产品经理而言，更需掌握的：首先，是定义采集数据的标准，即数据埋点；其次，是懂得如何观察与分析数据。
数据埋点，在 C 端产品很常见，在 B 端方面，似乎很少提及，有人甚至以为不用。
稍有规模的系统里，很多环节的运行状况都需要监测。这时定义清晰数据埋点，用于分析系统运行情况，反映系统性能，尤为重要。
可从何学起呢？
现在 B 端产品流行，今天分享一个 B 端系统里面，很实用、有代表性，却常被忽略的数据分析过程：
分析系统中订单或业务流程完成的运转时长。（订单在各类系统中较典型，以此为例）
对系统中订单完成的处理时长进行分析，最大的好处，是可以得知系统的效率多高。
同时，还很容易发现哪个地方出问题。例如，一旦订单流转过慢，就能看出在哪里耽误了。
有人认为，这是开发做的事，常常忽视了产品经理应该做的那部分。
数据的获取和计算，确实要开发实现（如有统计平台或 BI 则更为简单）。
产品经理则要根据分析思路，进行最关键的流程梳理、节点定义，统计出来的数据才准确、有意义。
具体怎么做呢？
1、绘制时序图做系统需求时，绘制出系统业务流转的时序图，能让系统在各个环节的信息交互顺序更为清晰、明确。
2、定义信息交互节点做完功能需求后，围绕整个订单的流转过程，定义要统计的时间节点。
这时，时序图的优势彻底发挥出来了。
这也是我在实践中的偶然发现，用时序图来定义节点，非常方便，开发、测试一看就懂。
以 “ 手机充值 ” 为例，稍微简化下，只保留核心流程，以便说明。
用户从下单充值，到充值完成，这一流程，需在前端产品（如 APP、H5 或小程序 ），后端系统（因公司而异，或有多个系统，这里简化成一个），供应商（如三大运营商）之间交互。
交互的顺序和节点，可看下图：
如图，按业务分析的需要，在每个节点标出编号。同时，定义清楚触发时机，如下图：
只要把这些节点定下来，马上可得出各个环节处理时长的计算方法。
3、明确各环节时长算法一旦在时序图上，标出了对应的信息交互节点，各个环节的时长一目了然。需要统计哪个时长，一看便知，是从哪个点到哪个点。
这例子中，一般会关注：订单总时长、后端系统处理时长、供应商处理时长，这三项数据。
有了以上的定义，再借助技术手段，获取、汇总并呈现数据，分析起来别提有多方便。
一谈到分析数据，都喜欢看趋势和平均值。这里要讲的是，单看平均值，会掩盖很多事实，发现不了问题。
常用的是，看一段时间内数据的百分位数去分析。比如，一天内所有订单总时长的 50% 分位、90% 分位。
所谓百分位数，就是将数据，从小到大排列，计算相应的累计百分位，则某一百分位所对应数据的值，就是这一百分位的百分位数。
比方说，一天内订单总时长的 50% 分位为 1 秒，即所有订单总时长中，排在第 50% 位置的时长是 1 秒，这意味着有一半的时长少于 1 秒。
此外，还要关注峰值、异常值，如最小时长、最大时长。
简单画个分析报表，以供参考。
数据一摆出来，各个环节效率如何，是否有问题显而易见。
5、得出结论以上述为例，从这些数据中，至少能判断出：
1）用户感知的充值过程是否够快。用户不会耐心等待，一旦太慢，甩头就跑。从体验的角度，订单越快，用户体验越好，越能留住用户。
2）自身系统处理效率如何。系统运行是否正常，有没有处理太慢、卡住的现象。一旦出现异常，可快速定位问题。
3）上游供应商的处理效率如何。供应商的处理效率，大大影响了平台的处理效率。有了这个数据，就能客观地评估、对比供应商的服务质量。
总而言之。
这只是一种思路，用什么图、什么工具并不是最重要的。
想强调的是：作为产品经理，要懂得从整个业务流程运转的过程去分析。
明确统计节点，定义触发时机，才能获取准确的数据，客观地观察和分析出有价值的结果。
这便是，流程化分析，系统化实践。
-END-