23 | 突发式流量数据暴跌，产品经理应该如何应对？【分析篇】

二爷文中总结的非常全面和细致，里面提到的点，自己在之前的流量异常分析过程中基本都经历过，读来非常亲切，分析排查的过程就像破案一样，非常有趣，找到原因之后的成就感也是满满的。给大家分享几个我之前遇到的情况： 1、页面内容更新时，里面的日志统计代码被开发人员误删除，导致页面的流量没有被统计到，这种情况在技术人员更替频繁，没有充分交接的情况下会经常发生。对比一下流量下降前后的页面流量明细很容易能够排查出来。 2、日志采集服务器中的某一台出现某种故障，导致日志丢失或没有纳入到分析当中。对比一下当天和之前日志文件的大小基本就可以看得出来。 3、还有一种情况比较有意思：不是流量下降了，而是此前的流量本身就不真实，是虚高的。比如之前页面一直都在被某爬虫抓取，产品和技术的同学都没有发现。某一天爬虫突然停止抓取了，流量一下就下来了。这种下降一般都体现在直接流量里面，不太容易发现。 非常喜欢二爷这一部分的内容，期待续集！

金字塔思维方式，可以与数据分析问思路结合起来

由宏观到微观垂直分析，在同一层面切片分析，颗粒度极细。 从开始检查产品运营以及技术环境，然后去检查外部的网络环境，再到对产品模块环节的分析，然后对渠道和用户进行分析。

这是看文章前的想法： 1、公司或是业务有没有什么大事件或是变动？例如产品更新、运营策略变化、服务器到期等；这是从内部了解问题 2、同行或是对手有什么动作？例如竞争对手今天开始大幅补贴，导致流量被抢占；这是从外部知根知底 3、统计口径是否正确？若前两者都如往常，这里要考虑统计指标是否出现数据异常，各个渠道来源是否调整？ 当然，看完了二爷的思路，自己的确差距很大。从技术上考虑明显不足，而且后续的解决路径有待提高。 再次感谢。

我曾经尝试去探索一下把公司的业务指标数据变动和基础架构变动联系起来，比如活跃用户数如果有异常，会不会跟基础架构的变更有关系。真的看进去就发现很困难，业务那里的项目落到基础架构已经细分成很小很小的一个一个工程角度的功能，而我们其实没有在系统里可以联系业务视角看到的项目和底层基础架构看到的项目。要做也可以，但是要改变现有的执行计划牵涉到的人又很多，后来就搁置下来了。

是否还可以从竞品层面，市场，甚至是更宏观的环境层面分析，虽然这些因素的影响程度可能会低一些。以及，文中提及到分析纬度是否有程度划分。影响因素被证实后，该如何挽救或避免呢？

部分场景产品流量其实有周期性表现，这个其实需要注意的盘外招

看了二爷的分享深感自己在更细颗粒度上的分析维度还有待提升。 另外上文所述从产品视角出发，找到流量降低的案发现场，引起了我一直以来的困惑，到底怎样才算是具备产品视角，希望能得以解惑。