产品运营的数据感，是数据分析后的处理能力

之前分别从渠道、用户以及业务的角度去看如何应对“产品流量暴跌 20%”的场景。今天来最后收个尾，分享一些数据分析之后要做的工作。

我曾经跟一位非常优秀的数据分析师合作。合作过程中，如果发生核心数据指标的波动之后，很快就会收到他非常详细并且有条理的分析报告。

这个报告的基本结构和内容都很清楚而且很专业，首先是同步发生了什么事，之后直接了当地给出结论和原因，接下来就是用详细的数据分析过程作为依据，最后是他作为数据分析师，给出的一些思考与建议。

比如，某个工具产品的流量上涨，报告开头就是同步：产品流量昨日环比上涨 XX%。主要上涨原因是由于某某渠道新增上涨，推测是某渠道被分配到曝光位导致的。

之后是一套具体的分析过程，他会列出不同渠道的近日流量对比，以及与新老用户的交叉分析，这里通过分析，明显可以看到来自某渠道的新用户流量上涨。

作为产品或运营，收到这个报告后，并不需要再花时间分析数据了，直接根据结论协调和执行就行了。这样一目了然的报告，既节约时间提高工作效率，也定位精准，方便处理。

说句题外话，我也跟很多数据分析师和产品经理合作过，但很少再见到过这样扎实、清晰、专业的数据分析。虽然我们可能不需要做这么正式和完整的分析报告，但是在其中的几个核心思路，依然值得我们借鉴。

1. 数据分析要形成结论
首先就是数据分析要形成结论，前几次分享中介绍了在面对“流量降低 20%”时的分析思路，作为产品经理，当然不能以做完数据分析为终点，要做的事情还有很多。

数据是我们发现和研究事实的线索，数据本身没有意义，我们需要分析和加工，并去执行落实才能为其赋予意义。

如果作为一个产品经理，只知道“流量降低 20%”，然后没有任何分析结论，也没有补充说明以及应对措施。那我们只能算得上是传声筒，没有起到应有的作用。

这是很浅显的道理，似乎并没有什么难的，但其实有大量的互联网从业者（也包括我在内）并没有做的很好。

那如何检验我们是否形成了合适的数据结论呢？这其实就跟做需求分析差不多，也是向上追溯原因，向下推测结果。可以从数据指标变化出发，连问五个为什么（why），再连问五个那会怎么样呢（so what）

如果你自问自答结束，感觉对这个回答很满意，那基本就算有结论了。比如：

“流量降低 20%”，为什么？
因为自然新增流量降低了。
为什么？
因为某某渠道的量级降低了。
为什么？
因为我们的投放渠道到期了。
如果我们问那会怎么样呢？就是去观察这样的数据变化可能导致的结果。流量降低 20%，会怎么样呢，会不会持续降低，会不会影响日活等等。

当然，我们未必真的要这么刻意地问问题，这只是个思路，找到数据波动的原因，分析可能产生的结果，合起来就能形成一个不错的数据分析结论。

2. 进行必要的有效沟通
发生数据波动之后，作为产品或运营，我们有义务主动向相关方通报数据波动，并附上相关结论和应对措施。

有时候这样的数据波动可能是工作失误导致的，所以我们不愿意声张，其实大可不必，面对问题，分析问题和解决问题本来就是我们的日常工作。

类似的分析其实有两大忌讳，一个就是只给现象不给结论，而且现象也很粗浅。另一个则是一次说不清楚，要不断反复地说。

前者刚才提到过了，这个细节做不好会显得你非常不专业。后者也一样，我有一次参加产品例会，COO问某运营，是不是最近日活降低了，运营说对，COO又问为什么，运营说新增降了，COO再追问哪个渠道出了问题，回答说合作方的投放。

这时候COO已经非常不耐烦了，敲着桌子厉声问：“哪个合作方？什么问题？怎么解决？你能不能一次把话说完？”当时会议上气氛就变得很尴尬，运营负责人后来起身救了场。

后来我也遇到过类似场景，真的很着急，所以在这里提醒一下，我们一定要避免这种情况，保证自己沟通中的信息量，直接给结论，干净利落最好。这时虽然说的很容易，但需要你对产品的核心数据和架构非常了解，而且对每个数据对应的脉络都了如指掌，所以平时一定要多看看数据，并且记住几个核心数据。

3. 要有应对策略
我们的表现可以分个级。最糟糕的是什么也不知道，等别人问起来才去看数据；其次是知道数据波动了，但是没有分析也没有结论；稍好一点的是知道数据波动，也有分析结论，却没有应对策略。

合格的产品或运营，面对像“流量骤降 20%”这样的情境，应当能够从短期、中期和长期出发，去考虑如何应对，即便是经过权衡后决定不采取任何措施，只是保持继续观察，也是一种策略。

短期策略指的是如何快速把数据抢救回来；中期指的是怎样修复相应机制，防止问题再次发生；长期则是指类似的数据波动是否会对我们整体的产品规划和方向选择有所影响。

我举个例子，比如一个短视频工具app，同时多个渠道流量下滑。

短期来看，我们可能要做ASO的优化，做各个渠道的拉量。可能是打关键词，或买渠道量。

对于中期，我们开始规划和监控各个渠道里关键词或排名的变化，保证自然流量能够稳定。并且产品和运营配合形成一套机制，固定时间上线一个产品新功能和运营活动来拉新，给产品注入活力。

而长期来看，我们需要考虑目前的新增是否过于依赖工具，我们是否需要开始考虑建设自己的流量池，比如做个自己的社区，或者在现有架构基础上，在重新做个新的工具，从而应对流量的减少，防止用户对老工具的吸引力下降。

短期措施立刻投入资源并监控产出，中期措施资源列入需求池，等待评估启动，长期措施并不会立刻做决议，而是留下问题和线索，等待进一步讨论。

到了这里，我们也应该引出关于数据分析的下一个话题了。就像刚才提到的，我们要不要去做自己的社区，或者做个新的工具，吸引流量？这时，我们都需要数据来支持我们做出决策。

不妨就以此作为接下来分享的线索，如果我们希望提高流量的控制力，如何利用数据来支撑我们在“做社区，还是做工具”这两个选择中，做出选择。感兴趣的话，下次分享会一起介绍。