导读：数据的用途其实有很多，比如定位异常问题，比如寻找新的增长点。今天主要讲讲如何利用数据定位商业问题，希望对大家有所启发。 　　

　　产品经理工作中大概有三种场景需要定位异常问题：单日数据波动较大，数据趋于下降，版本迭代后数据达不到预期。一个一个说吧。 　　

　　00-1010是最常见的，产品经理需要每天看数据。只是数据每天都在波动，也就是说有很多时候产品经理不知道的事情发生了。产品经理必须从数据仪表板中找出波动的部分，并给出合理的解释，以确定是否存在问题。 　　

　　但是产品经理没必要一有波动就去查数据。从我们的经验来看，数据总是在波动的，它会有一个有规律的波动区间值，随着不同的业务类型和业务发展阶段而变化，所以只要不超过这个波动值，就没有必要刻意去查。 　　

　　我先说说这个波动值。对于初创企业来说，业务量并不大，所以波动可能会很大。我们一般建议，如果波动的幅度不超过100，就赶紧做成长。任何幅度这么小的波动都是正常的，根本不需要分析，非常偶然。如果量级小于一千，可以先根据历史数据设置一个值，但不要太在意这个，日增长才是重点。 　　

　　好了，回到数据波动需要校验的问题。 　　

　　我们以简化的电商业务为例。比如今天早上起来发现昨天的营业额下降了。最近两周的数据基本在1000万左右，昨天降到了800万，出现了单日大幅下降。这个时候，我们就要去看看了。 　　

　　怎么检查出来？ 　　

　　你可以根据业务环节从前到后或者从后到前看，我们可以单独谈。 　　

　　说先去后看。你需要先检查一下新用户注册数和老用户注册数有没有减少。如果没有问题，检查产品详情页面的浏览量是否有所下降。如果没有问题，检查订单生成金额是否有问题，检查订单支付金额是否有问题。 　　

　　中间可能会有问题，比如新用户少。可能是渠道来的用户比较少，也可能是用户注册页面有问题，需要详细看，产品经理需要对这个问题的原因有个大概的了解。比如订单生成量减少，说明订单模块可能有问题。 　　

　　可能业务环节没有问题。这时候就需要看客单价问题了，因为订单量没有减少，营业额减少了，也就是客单价降低了。这意味着我们需要看到是否存在商品价格错误的问题，我们需要看到哪些商品价格发生了变化，并在这些商品中寻找异常。 　　

　　有时候，如果没有办法知道哪些商品的价格发生了变化，会很麻烦，可能需要你稍微看一下，从低价商品区开始。 　　

　　一般来说，可以从单量和客单价两个维度来看，按照拆解公式来看就可以了。 　　

　　我们前面说的是从1000万降到了800万。如果从1000增加到1300万，这也是异常波动，需要调查原因，不是说改善了就不用调查了。 　　

　　当然如果是改善的话，先看营销有没有买多量或者运营有没有搞大活动，再看业务环节。一般来说就是买多了或者搞活动。 　　

　　还有一种情况是最麻烦的，就是你看业务环节的每一个环节，都有下降，但是每一个环节都有小幅下降，到了最后一个环节，又有大幅下降。 　　

　　这真的很难受。虽然很少发生，但是一旦发生就很头疼，不能马上采取措施。你需要看看后续会不会继续出现这个问题。如果持续发生，说明不是局部问题，而是系统性问题。需要从客户质量、产品推荐策略等更复杂的维度去考察，这需要花费更多的时间和精力。 　　

一、单日数据出现大幅波动

　　什么是趋势性下降？就是连续几个月，每个月都有小幅下降，但是基本上，每个月都有下降。如果半年不行，就降30%。单个月来看的话，跌幅不大，但是连续下跌就受不了了。 　　

　　这种情况下，一般来说，老板很着急发火。都是钱。 　　

　　趋势下跌不会是业务链接的原因，一般来说需要换个角度拆解。 　　

　　我们以简化的电商业务为例。GMV在半年内下降了20%，降幅很大。 　　

　　这时候就要按照收益公式来拆解了： 　　

　　GMV=新客户购买量新客户单价老客户单价=新用户注册数新用户转化率(新用户购买总额/新用户数)老用户活跃数老用户复购率(老用户购买总额/老用户数) 　　

　　从这个公式可以看出问题出在哪个环节，进而可以看出是增加客户数量还是提示客户质量还是激活老用户，如何提高转化率——这就涉及到各种算法推荐模型的优化； 　　

　　一般来说，趋势下跌，如果产生的话，是 　　

趋势性下降的时候一般来说就是找原因和想对策，老板也知道下降了，他就想知道解决方案，所以这个时候的重点就是马上做各种策略把数据拉回来。

三、版本迭代之后数据未达预期

最后一个也是最复杂的一个问题――版本迭代之后数据未达预期，这个就是最难定位了，有很多时候我们在设计方案的时候就很难说清楚提升的具体比例会是多少。

究其原因，就是我们在做版本迭代的时候就不一定有依据。有的时候是因为老板说要这么改，有的时候是竞品这么改了所以这么改，有的时候是依据一些模糊的经验和原则。

不管怎么样，设计的时候就是模糊的，结果如何就也是无法预测的。

A/B test测试技术的出现在一定程度上规避了这个问题，在做灰度测试的时候如果数据不行就会代码回滚。

但对于大量的小厂来说没有条件做这个A/B test 测试，所以会出现版本迭代之后未达预期的情况。

这个时候其实非常尴尬，因为新版本已经上线了，但是数据没有提升或者提升非常小。

原则上如果数据没有出现下降就不回滚代码，就在线上使用新版本就行。

最重要的是在做下次版本迭代计划之前，尽可能的使用有数据依据的假设。

小厂的产品经理之所以在很多时候没有一个可靠的方法论就是受限于平台条件，无法使用更好的验证技术。而靠经验这个事情就永远比不上靠技术验证来的快。

四、最后

产品经理的主要工作就是发现问题和解决问题，所以一切可以依托和使用的工具和方法都必须用起来，而数据显然是最直观的工具，所以这是首先要用起来的。

当然光有数据不行，数据只是结果的呈现，怎么解释这种结果就依赖于产品经理对业务的理解程度了，所以一个对于业务有着深刻理解的产品经理其实是非常有价值的，大家还是需要多花点时间在业务上。

希望我的分享对你有所启发，谢谢。

本文由 @产品人玄青 原创发布于人人都是产品经理。未经许可，禁止转载

题图来自 pexels，基于 CC0 协议