|
产品经理在工作中大概会有三个场景需要定位异常问题：单日数据出现大幅波动，数据出现趋势性下降，版本迭代之后数据未达预期。，我们一个个聊。
一、单日数据出现大幅波动
这个最常见，产品经理每天都需要看数据，恰恰数据每天都是波动的，这就意味着这里面有很多时候都是发生了产品经理不知道的事情，产品经理必须要从数据这个仪表盘里去寻找到波动的部分，并给出合理的解释，从而确定是不是存在问题。
但也不是数据一波动产品经理就需要去排查，从我们的经验来说数据一直都是波动的，它会有一个常规的波动范围值，因业务类型和业务的发展阶段不同而不同，所以只要不超出这个波动值就可以不用刻意去排查。
我先讲一讲这个波动值的问题，对于初创型的企业来说，业务量不大，所以波动就可能很大，我们一般是建议量级不过百的就赶紧去搞增长，量级这么小任何波动都是正常的，根本不存在分析的必要，偶然性很大的。如果量级不过千的那就先可以先根据历史数据设一个值，但是也不要太关心这个，日常搞增长才是重点。
OK，说回这个数据波动需要排查的问题。
我们以简化的电商业务为例，譬如说今天早上起来一看，发现昨天的成交额下降了，最近两周的数据基本是1000万左右，昨天下降到了800万，出现了单日的大幅下降，这个时候就要排查了。
那怎么排查呢？
你根据业务链路从前往后看也行，从后往前看也行，我们分别可以讲一下。
先说从前往后看。你就需要先去看新用户注册人数和老用户登录人数有没有下降，没有问题就去看商品详情页的浏览量有没有下降，没有问题再去看订单生成量有没有问题，没有问题再去看订单支付量有没有问题。
这中间可能会有问题，譬如新增用户少了，那可能是渠道来的用户少了，也可能是用户注册页面出了问题，这就需要具体去看，需要产品经理对这个出问题的原因有一个大概的认知。譬如订单生成量减少了，就说明订单模块可能出现了问题。
也可能业务链路是没有问题，这个时候就需要去看客单价的问题，因为订单量没有下降，成交额下降那就是客单价下降了，这就需要去看是不是出现了商品价格错误的问题，就要去看哪些商品价格出现了变化，从这些商品里面找异常。
有的时候如果没有办法知道哪些商品改过价格的话，那就非常麻烦，可能就需要一点点看了，从低价产品区开始看。
总的来说可以从单量和客单价两个维度去看，根据拆解公式去看就行。
前面我们说的是从1000万下降到了800万，如果出现了从1000提高到了1300万，这也是异常波动，需要去排查原因，并不是说提高就不需排查。
当然如果是提高的话就先去看市场推广是不是买了更多的量或者运营是不是搞了大活动，然后再看业务链路。一般来说都是买量多了或者搞了活动。
还有一种情况是最麻烦的，那就是你一看业务链路每个环节都出现了下降，但是每个环节都下降不大，到了最终环节就出现了大幅度的下降。
这个真的是非常难受，虽然极少出现这种情况，但是一旦出现就很头痛，你无法马上采取措施，需要先看看后续是不是会持续出现这个问题，如果持续出现那就意味着不是一个局部的问题，而是出现了系统性的问题，就需要从获客质量和商品推荐策略这些更复杂的维度去考察，需要花的时间和精力会多很多。
二、数据出现趋势性下降
单日数据波动是最简单的情况，是最容易分析的。如果出现了趋势性下降就比较复杂了。
什么叫趋势性下降？就是连续几个月，每个月都小降一点，但是基本上月月降，半年搞不好就能下降30%，你从单月看降幅不大，但架不住连续下滑。
这种情况，一般来说老板就很着急上火了，都是钱啊。
趋势性下降不会是业务链路的原因，一般来说需要从另一个角度去拆解。
我们还是以简化的电商业务为例，GMV半年下降了20%，很大的降幅。
这个时候就需要去根据营收公式拆解了：
GMV=新用户购买量×新用户客单价+老用户购买量×老用户客单价=新用户注册人数×新用户转化率×(新用户购买总金额/新用户购买人数)+老用户活跃人数×老用户复购率×(老用户购买总金额/老用户购买人数)
从这个公式里面再去看问题是出在哪个部分，然后再去看是增加获客量还是提示获客质量还是激活老用户，以及怎么提高转化率的问题-这就涉及到各种算法推荐模型的优化；
总的来说趋势性的下降如果产生则也意味着重新拉升回来也是缓慢的，但不是束手无策。
趋势性下降的时候一般来说就是找原因和想对策，老板也知道下降了，他就想知道解决方案，所以这个时候的重点就是马上做各种策略把数据拉回来。
三、版本迭代之后数据未达预期
最后一个也是最复杂的一个问题——版本迭代之后数据未达预期，这个就是最难定位了，有很多时候我们在设计方案的时候就很难说清楚提升的具体比例会是多少。
究其原因，就是我们在做版本迭代的时候就不一定有依据。有的时候是因为老板说要这么改，有的时候是竞品这么改了所以这么改，有的时候是依据一些模糊的经验和原则。
不管怎么样，设计的时候就是模糊的，结果如何就也是无法预测的。
A/B test测试技术的出现在一定程度上规避了这个问题，在做灰度测试的时候如果数据不行就会代码回滚。
但对于大量的小厂来说没有条件做这个A/B test 测试，所以会出现版本迭代之后未达预期的情况。
这个时候其实非常尴尬，因为新版本已经上线了，但是数据没有提升或者提升非常小。
原则上如果数据没有出现下降就不回滚代码，就在线上使用新版本就行。
最重要的是在做下次版本迭代计划之前，尽可能的使用有数据依据的假设。
小厂的产品经理之所以在很多时候没有一个可靠的方法论就是受限于平台条件，无法使用更好的验证技术。而靠经验这个事情就永远比不上靠技术验证来的快。
四、最后
产品经理的主要工作就是发现问题和解决问题，所以一切可以依托和使用的工具和方法都必须用起来，而数据显然是最直观的工具，所以这是首先要用起来的。
当然光有数据不行，数据只是结果的呈现，怎么解释这种结果就依赖于产品经理对业务的理解程度了，所以一个对于业务有着深刻理解的产品经理其实是非常有价值的，大家还是需要多花点时间在业务上。
注：本文转载自网络，如有侵权，请联系删除
|
京公网安备 11010602105141号
