极客时间已完结课程限时免费阅读

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

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

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

2018-10-10 邱岳 来自北京
《邱岳的产品实战》
课程介绍

讲述：邱岳

时长12:46大小5.85M

极客时间的专栏读者你好，我是邱岳。这次我们继续聊跟数据分析相关的话题。上一次我们假设了一个情境：“你在某天早晨起来，发现昨天产品流量暴跌 20%”，并从这个场景出发，分享了产品经理需要具备数据走查习惯和日常数据体系。
今天，我们则会重点分享，遇到流量暴跌的情况具体应当怎样应对，并会以此为线索，穿插介绍各种数据指标和分析思路。
在我们开始之前，你不妨先暂停一下，自己代入设想一下，如果换做是你遇见了流量暴跌，会如何处理和应对；之后再向下继续阅读，看看我们的想法是否一致。

1. 有没有业务变化或发布？

面对流量暴跌，我们要考虑的第一个可能性：是有没有产品或业务的变化。
比如商品调价、试用到期、网站改版等等，这一类变化对流量的影响通常是粗暴直接的。之前有个做内容产品的产品经理告诉我，由于版权到期，他们下掉了热门的视频内容，结果导致几天之内整个产品流量接近腰斩。
像这样的数据变化应该在产品经理的预料之内，我们要做的是取一些数据，详细分析细节上的具体变化和影响，以供给业务部门做策略参考。
可能有的产品经理看到流量暴跌，第一反应就是急忙开始做数据分析，分析了半天，才突然想起来原来昨天有业务调整，结果浪费了时间，这样就很不划算了。

2. 排除技术故障可能性

如果没有大的业务或产品调整，那么，我们接下来要排除技术故障的可能性。除了询问技术是否有相关发布（有时候纯技术的变更产品经理可能不知情），请他们查看系统监控和报警之外，我们也可以去看相关数据的分时报表，看一下 24 小时内的流量变化。
比如，我们发现上午某个时间段内的流量很低。甚至为 0，那很可能是这个阶段出现了系统故障，导致用户无法访问。
如果我们自己的系统没有故障，我们就需要排除环境故障。 比如网络故障和终端故障。这个时刻，我们需要对用户进行分类，从而观察数据，区分出不同的设备、网络条件、浏览器和屏幕尺寸等技术参数，再做一下对比。
举个例子，我曾经负责的某产品流量下跌，但是看起来系统功能和流程都是正常工作的。结果通过数据分析发现，是 1 某运营商的网络来源流量大幅度降低，其他运营商都是正常运作，再进一步调查发现，原来是这个运营商做了 DNS 劫持，但没有正确处理 https 访问，导致大量用户访问出错，最终投诉运营商才解决问题。
还有一个例子是朋友的经历，他说自己的产品流量下跌，自己这里看了半天一切正常，后来发现其他浏览器流量都正常，唯独来自微信内置浏览器的流量跌得厉害，仔细一查才发现，这是一处特性在微信浏览器下访问出错导致的问题。
我在上面举的这两个例子，都是可以通过对终端的技术参数进行细分比对发现的，前者是对网络条件做细分，后者则可以通过浏览器版本做细分。

3. 流量降低的“案发现场”在哪里

排除了技术故障之后，我们要找到流量降低的“案发现场”，去观察在所有的产品页面和功能模块中，是否存在某一个模块的流量显著降低，影响了整体情况。
这就要求我们对产品构成有一个宏观的了解，至少要知道有哪些页面或模块。我们需要从信息架构层面去考虑不同页面。
比如对于电商网站来说，可能会关注搜索、类目、推荐、店铺和商品详情页等等。也就是说我们要分别去看这几个模块的流量情况，是否存在“某一个模块显著降低，而其他模块一切正常”的情况。
这需要我们的数据体系中有相关数据指标的准备，而且我们要对不同模块的流量数字和比例做到心中有数，这样才能帮助我们快速定位问题。
找到案发现场，并不代表找到了具体的原因，只是找到了进一步做数据分析的一个努力方向，所以还是不能松懈。
不过，如果运气好，我们也许能找到流量显著下跌的页面或模块，这样接下来定位问题会轻松不少，如果个整站下跌非常均匀，那问题通常会比较棘手。

4. 数据变化的渠道特征

不论我们找没找到案发现场，接下来我们要做的，就是开始对渠道和用户做各种各样的维度划分，一层一层去找流量下跌的原因。对于 Web 产品或小程序（也包括一部分从外部直接唤起某个页面的 App）来说，接下来通常是分析不同渠道的流量情况。
Web 流量分为直接流量、搜索引擎和引荐流量三大类型，搜索引擎又分为自然搜索和付费搜索结果的来流。
直接流量的分析难一些，我们最后再说，搜索引擎最容易追踪，我们可以通过来源搜索引擎和关键词去判断。还可以与着陆页组合分析，去追查流量降低的原因。
我负责的产品曾经流量暴跌过，当时分析发现主要原因是百度来的流量降低，用高频关键词查了一下，发现网站排名很靠后，再进一步用站长工具去检查，原来是网站被搜索引擎降权了。
确认了问题，自然也就知道该如何解决了，通常被搜索引擎降权，只要不是有什么违法乱纪的问题，都是可以一些技术手段逐渐恢复的，这里我们就不展开说了。
引荐流量通常来自于自然引荐和一些合作站点，其中合作站点的流量最好有明确的来源标识，便于统计分析，对于自然引荐，也可以通过工具找到具体的来源。如果引荐流量显著降低，只要找到对应的源就很容易解决了。
引荐流量中还有比较特别的一类是社交网络的来流，这部分可以单独划出来做分析，如果这一部分的流量出现大幅度波动，则有可能是受到来源站点的限流政策影响。
直接流量比较难分析，过去有一个说法是用户直接在地址栏键入 URL ，或从收藏夹访问时，就会产生直接流量；但随着终端类型的增加，以及隐私策略的完善，越来越多的流量被归到这一类中。直接流量很难在渠道上找到突破口，只能在后面做用户特征分析的时候再想办法了。
微信小程序的渠道分析依托于微信自身提供的分析工具，包括模板消息、公众号文章、二维码扫一扫、二维码长按识别等等（这些渠道的特征未来我们在小程序章节还会做详细的介绍）。
在数据分析过程中，每一个渠道的流量波动都有具体的场景对应，比如模板消息来流突然减少，那么，要不就是消息没发出去，要不就是模板被微信禁掉了。长按识别或微信会话的来流波动，则很有可能是触发了朋友圈的限流策略。
我们刚才提到过，渠道分析通常适用于 Web 应用和小程序，对移动应用来说，大部分用户可能是通过桌面或推送直接打开 App，不存在流量渠道分析这码事。在移动应用语境中谈渠道，通常指的是应用下载激活的新增渠道，比如各种应用市场或渠道投放等等。
对于移动应用的流量变化，需要从用户的角度去做更进一步的分析，这个我们下次接着聊。

5. 总结

今天分享的内容就先告一段落，我们针对上次提出的“流量骤降 20%”的假设，说到了如何排除业务调整和技术故障的可能性，以及从产品角度出发，如何找到流量降低的案发现场，还有对流量进行渠道分解分析的方法。
下次分享，我们会从用户特征的角度，进一步介绍对于这一情景的分析思路。如果你有关于这部分内容的任何想法和见解，欢迎在留言区分享讨论，我们下次再见！
分享给需要的人，Ta购买本课程，你将得18元
生成海报并分享

赞 10

提建议

© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
上一篇
22 | 产品经理需要具备哪些基本的数据能力和意识？
下一篇
24 | 突发式流量数据暴跌，产品经理应该如何应对？【拆解篇】
unpreview
 写留言

精选留言(8)

  • 東
    2018-10-11
    二爷文中总结的非常全面和细致，里面提到的点，自己在之前的流量异常分析过程中基本都经历过，读来非常亲切，分析排查的过程就像破案一样，非常有趣，找到原因之后的成就感也是满满的。给大家分享几个我之前遇到的情况： 1、页面内容更新时，里面的日志统计代码被开发人员误删除，导致页面的流量没有被统计到，这种情况在技术人员更替频繁，没有充分交接的情况下会经常发生。对比一下流量下降前后的页面流量明细很容易能够排查出来。 2、日志采集服务器中的某一台出现某种故障，导致日志丢失或没有纳入到分析当中。对比一下当天和之前日志文件的大小基本就可以看得出来。 3、还有一种情况比较有意思：不是流量下降了，而是此前的流量本身就不真实，是虚高的。比如之前页面一直都在被某爬虫抓取，产品和技术的同学都没有发现。某一天爬虫突然停止抓取了，流量一下就下来了。这种下降一般都体现在直接流量里面，不太容易发现。 非常喜欢二爷这一部分的内容，期待续集！
    展开
    24
  • 宋建
    2018-11-12
    金字塔思维方式，可以与数据分析问思路结合起来
    2
  • 听天由己
    2018-10-10
    这是看文章前的想法： 1、公司或是业务有没有什么大事件或是变动？例如产品更新、运营策略变化、服务器到期等；这是从内部了解问题 2、同行或是对手有什么动作？例如竞争对手今天开始大幅补贴，导致流量被抢占；这是从外部知根知底 3、统计口径是否正确？若前两者都如往常，这里要考虑统计指标是否出现数据异常，各个渠道来源是否调整？ 当然，看完了二爷的思路，自己的确差距很大。从技术上考虑明显不足，而且后续的解决路径有待提高。 再次感谢。
    展开
    1
  • Dylan
    2018-10-10
    由宏观到微观垂直分析，在同一层面切片分析，颗粒度极细。 从开始检查产品运营以及技术环境，然后去检查外部的网络环境，再到对产品模块环节的分析，然后对渠道和用户进行分析。
    2
  • JianXu
    2020-11-28
    我曾经尝试去探索一下把公司的业务指标数据变动和基础架构变动联系起来，比如活跃用户数如果有异常，会不会跟基础架构的变更有关系。真的看进去就发现很困难，业务那里的项目落到基础架构已经细分成很小很小的一个一个工程角度的功能，而我们其实没有在系统里可以联系业务视角看到的项目和底层基础架构看到的项目。要做也可以，但是要改变现有的执行计划牵涉到的人又很多，后来就搁置下来了。
  • 椰子
    2018-12-02
    是否还可以从竞品层面，市场，甚至是更宏观的环境层面分析，虽然这些因素的影响程度可能会低一些。以及，文中提及到分析纬度是否有程度划分。影响因素被证实后，该如何挽救或避免呢？
  • 孙伟贤
    2018-10-10
    部分场景产品流量其实有周期性表现，这个其实需要注意的盘外招
  • Novelty
    2018-10-10
    看了二爷的分享深感自己在更细颗粒度上的分析维度还有待提升。 另外上文所述从产品视角出发，找到流量降低的案发现场，引起了我一直以来的困惑，到底怎样才算是具备产品视角，希望能得以解惑。