mirror of
https://github.com/cheetahlou/CategoryResourceRepost.git
synced 2025-10-17 23:43:44 +08:00
89 lines
8.2 KiB
Markdown
89 lines
8.2 KiB
Markdown
<audio id="audio" title="25 | 突发式流量数据暴跌，产品经理应该如何应对？【处理篇】" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/6d/f3/6d7abd2a16e097b9aff5a8736277e2f3.mp3"></audio>
|
||
|
||
极客时间的专栏读者你好，我是邱岳。我们继续聊跟数据分析相关的话题。
|
||
|
||
前面的分享中，我们分别从渠道、用户以及业务的角度去看如何应对“产品流量暴跌 20%”的情境。今天我们来给这个情境收个尾，分享一些数据分析之后要做的工作。
|
||
|
||
我曾经跟一位非常优秀的数据分析师合作，共同负责过几个商业产品。在我们的合作过程中，每一次发生核心数据指标的波动之后，很快就会收到他非常详细并且有条理的分析邮件。
|
||
|
||
**这封邮件的基本结构和内容都很清楚而且很专业，首先是通报发生了什么事，之后直接了当地给出结论和原因，接下来就是用详细的数据分析过程作为依据，最后是他作为数据分析师，给出的一些思考与建议。**
|
||
|
||
比如，某个工具产品的流量降低，他的邮件开头就是通报：某产品流量昨日环比下降 XX%。主要下降原因是平台新用户引流减少，推测是兄弟部门的平台上产品入口页面改版导致。
|
||
|
||
之后是一套具体的分析过程，他会列出不同渠道的近日流量对比，以及与新老用户的交叉分析，这里通过分析，明显可以看到来自其他部门的平台产品的新用户引荐流量降低。
|
||
|
||
作为产品经理，收到这封邮件后，我就可以直接开始跟其他部门交涉协调就好了，并不需要再花时间分析数据了。这样一目了然的数据邮件，既节约时间提高工作效率，也定位精准，方便处理。
|
||
|
||
说句题外话，我后来跟很多数据分析师和产品经理合作过，但很少再见到过这样扎实、清晰、专业的数据分析。这个兄弟职业素养之高，我现在回想起来依然充满敬意。虽然我们可能不需要做这么正式和完整的分析报告，但是在其中的几个核心思路，依然值得我们借鉴。
|
||
|
||
## 1. 数据分析要形成结论
|
||
|
||
首先就是数据分析要形成结论，我们在前几次分享中介绍了在面对“流量降低 20%”时的分析思路，作为产品经理，当然不能以做完数据分析为终点，我们要做的事情还有很多。
|
||
|
||
数据是我们发现和研究事实的线索，数据本身没有意义，我们需要分析和加工才能为其赋予意义。
|
||
|
||
**如果作为一个产品经理，只知道“流量降低 20%”，然后没有任何分析结论，也没有补充说明以及应对措施。那我们只能算得上是数据工具的传声筒，没有起到应有的作用。**
|
||
|
||
这是很浅显的道理，似乎并没有什么难的，但其实有大量的产品经理（也包括我在内）并没有做好。
|
||
|
||
那如何检验我们是否形成了合适的数据结论呢？这其实就跟做需求分析差不多，也是向上追溯原因，向下推测结果。方法我们在上一季专栏提到过，就是从数据指标变化出发，连问五个为什么（why），再连问五个那会怎么样呢（so what）
|
||
|
||
如果你自问自答结束，感觉对这个回答很满意，那基本就算有结论了。比如：
|
||
|
||
- “流量降低 20%”，为什么？
|
||
- 因为商品详情流量降低了。
|
||
- 为什么？
|
||
- 因为引荐流量降低了。
|
||
- 为什么？
|
||
- 因为我们的投放渠道到期了。
|
||
|
||
如果我们问那会怎么样呢？就是去观察这样的数据变化可能导致的结果。流量降低 20%，会怎么样呢，会不会持续降低，会不会影响收入等等。
|
||
|
||
当然，我们未必真的要这么刻意地问问题，这只是个思路，找到数据波动的原因，分析可能产生的结果，合起来就能形成一个不错的数据分析结论。
|
||
|
||
## 2. 进行必要的有效沟通
|
||
|
||
发生数据波动之后，作为产品线的负责人，我们有义务主动向相关方通报数据波动，并附上相关结论和应对措施。
|
||
|
||
**有时候这样的数据波动可能是工作失误导致的，所以我们不愿意声张，其实大可不必，面对问题，分析问题和解决问题本来就是我们的日常工作。**
|
||
|
||
类似的分析其实有两大忌讳，一个就是只给现象不给结论，而且现象也很粗浅。另一个则是一次说不清楚，要不断反复地说。
|
||
|
||
前者刚才提到过了，这个细节做不好会显得你非常不专业。后者也一样，我有一次参加产品例会，部门总监问某产品经理，是不是用户量最近降低了，产品经理说是的，总监又问为什么，产品经理说获客不力，总监再追问哪个渠道出了问题，回答说合作方的投放。
|
||
|
||
这时候总监已经非常不耐烦了，敲着桌子厉声问：“哪个合作方？什么问题？怎么解决？你能不能一次把话说完？”当时会议上气氛就变得很尴尬，我们的主管后来起身救了场。
|
||
|
||
后来我也遇到过类似场景，真的很着急，所以在这里提醒一下，我们一定要避免这种情况，保证自己沟通中的信息量，直接给结论，干净利落最好。
|
||
|
||
## 3. 要有应对策略
|
||
|
||
我们的表现可以分个级。最糟糕的是什么也不知道，等别人问起来才去看数据；其次是知道数据波动了，但是没有分析也没有结论；稍好一点的是知道数据波动，也有分析结论，却没有应对策略。
|
||
|
||
合格的产品经理，面对像“流量骤降 20%”这样的情境，应当能够从短期、中期和长期出发，去考虑如何应对，即便是经过权衡后决定不采取任何措施，只是保持继续观察，也是一种策略。
|
||
|
||
短期策略指的是如何快速把数据抢救回来；中期指的是怎样修复相应机制，防止问题再次发生；长期则是指类似的数据波动是否会对我们整体的产品规划和方向选择有所影响。
|
||
|
||
我举个例子，就是上次分享曾经提到过的，百度自然搜索的流量降低导致整站流量降低的情况。
|
||
|
||
短期来看，我们要做的是想办法向百度反馈我们站点的收录变化，并请负责 SEO 的同事检查收录减少的页面结构，对可能影响收录的功能点做调整，同时将 SEO 的细节数据列入每日监控的范围内（就是爬虫访问、爬虫路径、收录以及展示和排名情况的相关数据）
|
||
|
||
对于中期，我们开始规划一系列自动静态列表页和静态类目页的 SEO 项目，重新对主要的搜索引擎着陆页做优化，保证整个搜索引擎的来流能够稳定。
|
||
|
||
而长期来看，我们需要考虑目前的流量是否过于依赖搜索引擎（当时这条产品线的搜索引擎流量占比过半，并且主要来自百度），我们是否需要开始考虑建设自己的流量池，比如做个自己的社区，或者做个新的工具，去稀释搜索引擎流量占比，从而降低对个别搜索引擎的依赖。
|
||
|
||
短期措施立刻投入资源并监控产出，中期措施资源列入需求池，等待评估启动，长期措施并不会立刻做决议，而是留下问题和线索，等待进一步讨论。
|
||
|
||
到了这里，我们也应该引出关于数据分析的下一个话题了。就像刚才提到的，我们要不要去做自己的社区，或者做个新的工具，吸引流量？这时，我们都需要数据来支持我们做出决策。
|
||
|
||
我们不妨就以此作为接下来分享的线索，如果我们希望提高流量的控制力，如何利用数据来支撑我们在“做社区，还是做工具”这两个选择中，做出选择。我们会在下一期的分享中，聊聊如何用数据来做决策支撑。
|
||
|
||
## 4. 总结
|
||
|
||
好了，今天的内容就到了这里了，我们主要围绕着数据分析之后的处理展开了今天的内容。
|
||
|
||
在做完数据分析后，我们首先要做的是形成一个具体的结论，接下来，我再围绕这个结论，与相关方进行有效沟通，这里的有效沟通指的是要有结论，并且精简直接。最后我们还要按照短期、中期、长期制定一系列的应对策略。
|
||
|
||
你用数据来做过什么样的决策呢，可以给我留言，我们一起分享，感谢你的收听，我们下期再见。
|
||
|
||
|