邱岳的产品实战
邱岳
十年资深产品人,无码科技产品经理
38996 人已学习
新⼈⾸单¥59
登录后,你可以任选4讲全文学习
课程目录
已完结/共 58 讲
模块三:产品经典案例解析:小程序的生态与实践 (3讲)
模块四:产品会客厅——场景化处理你的产品疑难杂症 (18讲)
尾声 (1讲)
邱岳的产品实战
15
15
1.0x
00:00/00:00
登录|注册

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

对流量进行渠道分解分析
找到流量降低的案发现场
排除业务调整和技术故障可能性
移动应用的流量变化
Web产品和小程序的渠道分析
信息架构层面考虑不同页面
观察产品页面和功能模块
网络故障和终端故障
流量分时报表
系统监控和报警
网站改版
试用到期
商品调价
总结
数据变化的渠道特征
流量降低的“案发现场”在哪里
排除技术故障可能性
有没有业务变化或发布?
突发式流量数据暴跌,产品经理应该如何应对?

该思维导图由 AI 生成,仅供参考

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

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

面对流量暴跌,我们要考虑的第一个可能性:是有没有产品或业务的变化。
比如商品调价、试用到期、网站改版等等,这一类变化对流量的影响通常是粗暴直接的。之前有个做内容产品的产品经理告诉我,由于版权到期,他们下掉了热门的视频内容,结果导致几天之内整个产品流量接近腰斩。
像这样的数据变化应该在产品经理的预料之内,我们要做的是取一些数据,详细分析细节上的具体变化和影响,以供给业务部门做策略参考。
可能有的产品经理看到流量暴跌,第一反应就是急忙开始做数据分析,分析了半天,才突然想起来原来昨天有业务调整,结果浪费了时间,这样就很不划算了。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结

产品经理在面对突发式流量数据暴跌时,需要采取一系列应对措施。首先,需要排除业务变化或发布对流量的影响,详细分析具体变化和影响,以供业务部门参考。其次,要排除技术故障可能性,通过观察系统监控和报表,对用户进行分类,从而排除网络故障和终端故障。接着,需要找到流量降低的“案发现场”,观察各个产品页面和功能模块中是否存在某一模块的流量显著降低。此外,对渠道和用户进行各种维度划分,分析不同渠道的流量情况,以找到流量下跌的原因。最后,需要从用户特征的角度进一步分析,以全面了解流量暴跌的情况。这些方法可以帮助产品经理快速定位问题并采取相应措施。

仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《邱岳的产品实战》
新⼈⾸单¥59
立即购买
登录 后留言

全部留言(8)

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