mirror of
https://github.com/cheetahlou/CategoryResourceRepost.git
synced 2025-10-16 15:03:44 +08:00
80 lines
8.2 KiB
Markdown
80 lines
8.2 KiB
Markdown
<audio id="audio" title="23 | 突发式流量数据暴跌，产品经理应该如何应对？【分析篇】" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/25/7f/2571295de365cf6dddf14f9a68a05d7f.mp3"></audio>
|
||
|
||
极客时间的专栏读者你好，我是邱岳。这次我们继续聊跟数据分析相关的话题。上一次我们假设了一个情境：“你在某天早晨起来，发现昨天产品流量暴跌 20%”，并从这个场景出发，分享了产品经理需要具备数据走查习惯和日常数据体系。
|
||
|
||
今天，我们则会重点分享，遇到流量暴跌的情况具体应当怎样应对，并会以此为线索，穿插介绍各种数据指标和分析思路。
|
||
|
||
在我们开始之前，你不妨先暂停一下，自己代入设想一下，如果换做是你遇见了流量暴跌，会如何处理和应对；之后再向下继续阅读，看看我们的想法是否一致。
|
||
|
||
## 1. 有没有业务变化或发布？
|
||
|
||
**面对流量暴跌，我们要考虑的第一个可能性：是有没有产品或业务的变化。**
|
||
|
||
比如商品调价、试用到期、网站改版等等，这一类变化对流量的影响通常是粗暴直接的。之前有个做内容产品的产品经理告诉我，由于版权到期，他们下掉了热门的视频内容，结果导致几天之内整个产品流量接近腰斩。
|
||
|
||
像这样的数据变化应该在产品经理的预料之内，我们要做的是取一些数据，详细分析细节上的具体变化和影响，以供给业务部门做策略参考。
|
||
|
||
可能有的产品经理看到流量暴跌，第一反应就是急忙开始做数据分析，分析了半天，才突然想起来原来昨天有业务调整，结果浪费了时间，这样就很不划算了。
|
||
|
||
## 2. 排除技术故障可能性
|
||
|
||
如果没有大的业务或产品调整，那么，我们接下来要排除技术故障的可能性。除了询问技术是否有相关发布（有时候纯技术的变更产品经理可能不知情），请他们查看系统监控和报警之外，我们也可以去看相关数据的分时报表，看一下 24 小时内的流量变化。
|
||
|
||
比如，我们发现上午某个时间段内的流量很低。甚至为 0，那很可能是这个阶段出现了系统故障，导致用户无法访问。
|
||
|
||
**如果我们自己的系统没有故障，我们就需要排除环境故障。** 比如网络故障和终端故障。这个时刻，我们需要对用户进行分类，从而观察数据，区分出不同的设备、网络条件、浏览器和屏幕尺寸等技术参数，再做一下对比。
|
||
|
||
举个例子，我曾经负责的某产品流量下跌，但是看起来系统功能和流程都是正常工作的。结果通过数据分析发现，是1某运营商的网络来源流量大幅度降低，其他运营商都是正常运作，再进一步调查发现，原来是这个运营商做了 DNS 劫持，但没有正确处理 https 访问，导致大量用户访问出错，最终投诉运营商才解决问题。
|
||
|
||
还有一个例子是朋友的经历，他说自己的产品流量下跌，自己这里看了半天一切正常，后来发现其他浏览器流量都正常，唯独来自微信内置浏览器的流量跌得厉害，仔细一查才发现，这是一处特性在微信浏览器下访问出错导致的问题。
|
||
|
||
我在上面举的这两个例子，都是可以通过对终端的技术参数进行细分比对发现的，前者是对网络条件做细分，后者则可以通过浏览器版本做细分。
|
||
|
||
## 3. 流量降低的“案发现场”在哪里
|
||
|
||
排除了技术故障之后，我们要找到流量降低的“案发现场”，去观察在所有的产品页面和功能模块中，是否存在某一个模块的流量显著降低，影响了整体情况。
|
||
|
||
这就要求我们对产品构成有一个宏观的了解，至少要知道有哪些页面或模块。我们需要从信息架构层面去考虑不同页面。
|
||
|
||
比如对于电商网站来说，可能会关注搜索、类目、推荐、店铺和商品详情页等等。也就是说我们要分别去看这几个模块的流量情况，是否存在“某一个模块显著降低，而其他模块一切正常”的情况。
|
||
|
||
这需要我们的数据体系中有相关数据指标的准备，而且我们要对不同模块的流量数字和比例做到心中有数，这样才能帮助我们快速定位问题。
|
||
|
||
**找到案发现场，并不代表找到了具体的原因，只是找到了进一步做数据分析的一个努力方向，所以还是不能松懈。**
|
||
|
||
不过，如果运气好，我们也许能找到流量显著下跌的页面或模块，这样接下来定位问题会轻松不少，如果个整站下跌非常均匀，那问题通常会比较棘手。
|
||
|
||
## 4. 数据变化的渠道特征
|
||
|
||
不论我们找没找到案发现场，接下来我们要做的，就是开始对渠道和用户做各种各样的维度划分，一层一层去找流量下跌的原因。对于 Web 产品或小程序（也包括一部分从外部直接唤起某个页面的 App）来说，接下来通常是分析不同渠道的流量情况。
|
||
|
||
**Web 流量分为直接流量、搜索引擎和引荐流量三大类型，搜索引擎又分为自然搜索和付费搜索结果的来流。**
|
||
|
||
直接流量的分析难一些，我们最后再说，搜索引擎最容易追踪，我们可以通过来源搜索引擎和关键词去判断。还可以与着陆页组合分析，去追查流量降低的原因。
|
||
|
||
我负责的产品曾经流量暴跌过，当时分析发现主要原因是百度来的流量降低，用高频关键词查了一下，发现网站排名很靠后，再进一步用站长工具去检查，原来是网站被搜索引擎降权了。
|
||
|
||
确认了问题，自然也就知道该如何解决了，通常被搜索引擎降权，只要不是有什么违法乱纪的问题，都是可以一些技术手段逐渐恢复的，这里我们就不展开说了。
|
||
|
||
引荐流量通常来自于自然引荐和一些合作站点，其中合作站点的流量最好有明确的来源标识，便于统计分析，对于自然引荐，也可以通过工具找到具体的来源。如果引荐流量显著降低，只要找到对应的源就很容易解决了。
|
||
|
||
引荐流量中还有比较特别的一类是社交网络的来流，这部分可以单独划出来做分析，如果这一部分的流量出现大幅度波动，则有可能是受到来源站点的限流政策影响。
|
||
|
||
直接流量比较难分析，过去有一个说法是用户直接在地址栏键入 URL ，或从收藏夹访问时，就会产生直接流量；但随着终端类型的增加，以及隐私策略的完善，越来越多的流量被归到这一类中。直接流量很难在渠道上找到突破口，只能在后面做用户特征分析的时候再想办法了。
|
||
|
||
微信小程序的渠道分析依托于微信自身提供的分析工具，包括模板消息、公众号文章、二维码扫一扫、二维码长按识别等等（这些渠道的特征未来我们在小程序章节还会做详细的介绍）。
|
||
|
||
在数据分析过程中，每一个渠道的流量波动都有具体的场景对应，比如模板消息来流突然减少，那么，要不就是消息没发出去，要不就是模板被微信禁掉了。长按识别或微信会话的来流波动，则很有可能是触发了朋友圈的限流策略。
|
||
|
||
我们刚才提到过，渠道分析通常适用于 Web 应用和小程序，对移动应用来说，大部分用户可能是通过桌面或推送直接打开 App，不存在流量渠道分析这码事。在移动应用语境中谈渠道，通常指的是应用下载激活的新增渠道，比如各种应用市场或渠道投放等等。
|
||
|
||
对于移动应用的流量变化，需要从用户的角度去做更进一步的分析，这个我们下次接着聊。
|
||
|
||
## 5. 总结
|
||
|
||
今天分享的内容就先告一段落，我们针对上次提出的“流量骤降 20%”的假设，说到了如何排除业务调整和技术故障的可能性，以及从产品角度出发，如何找到流量降低的案发现场，还有对流量进行渠道分解分析的方法。
|
||
|
||
下次分享，我们会从用户特征的角度，进一步介绍对于这一情景的分析思路。如果你有关于这部分内容的任何想法和见解，欢迎在留言区分享讨论，我们下次再见！
|
||
|
||
|