当指标下跌,该如何进行分析?

大数据 数据分析
提示:这是一篇超长硬货,建议先保存,之后反复看,“当XX指标下跌时,你会如何进行分析?”XX包括但不限于销售额、用户数、活跃率、ROI等等。

 

[[398559]]

 本文转载自微信公众号「接地气学堂」,作者接地气的陈老师。转载本文请联系接地气学堂公众号。

这个问题是一个面试时经常遇到的问题,也是日常工作中很常见的一个问题。可同学们在回答的时候,经常丢三落四,似乎不管怎么讲都讲不全。在日常工作中,也经常被业务方纠缠。屁大一点波动也让你分析一下,分析完了又嫌弃:“我早知道了!”。今天我们系统性讲解一下,该如何应对这个问题。

1解读指标波动的大原则

首先要明白一点:单纯靠数据分析,不可能100%理清所有原因。真实的原因往往需要数据分析+市场调查+一线走访+行业研究共同努力才能锁定的。数据分析在解析原因上,更大的作用是定位问题而不是解答问题。想要解答问题背后的业务逻辑,市场调查要有用得多。

其次,业务出现波动是很正常的事,哪天不动了才是见鬼了。所以日常会经常碰到类似问题。第一顺位要解决的是判定问题的轻重缓急。这样才能在时间和精力都有限的情况下,选择合适的方法。如果每一个问题都要深入彻底分析,就会浪费大量人力精力,耽搁其他工作。数据分析工作也要讲投入产出比的。

最后,很多时候其实真实的原因很难100%解析出来,但对业务来说,也不需要100%解析原因才能行动。对业务方而言,在特定的时间内,可以调整指标的方法是非常有限的,只要信息量足够支持行动就行了。

以销售指标波动为例,影响销售指标的原因有一大堆(见下图)

其中:顾客态度非常难量化,需要调研支持;外部竞争,行业景气这些需要行业研究。而产品卖得不好,到底有百分之多少归罪于用户,百分之多少归罪于销售,百分之多少归罪于营销,很难完全剥离清楚。可能还得上个ABtest测试一下。如果每一次波动都这么折腾去找原因,公司就可以关门了。

与此同时,改善指标的方法却非常有限的:

  • 如果时间是一天,只够在门店做个商品堆头
  • 如果时间是一周,可以做业务员话术培训
  • 如果时间是一月,才考虑拉动销量的活动
  • 如果时间是季度,才足够调整产品线布局
  • 如果时间是一年,才能策划新产品

所以判定了问题的轻重缓急之后,在有限的时间内帮业务部门找到应对策略,改善局面才是最重要的。指标能改善回来才是终极目标,探索宇宙真理不是终极目标。这是企业里做分析和大学里做研究的根本区别。

分析指标下跌的时候,本着:清晰情况 + 突出重点 + 够用就行的三原则,就能应付实际工作中各种场景。分析指标下跌并不是下钻得越多越好,并不是找的指标越多越好,并不是事事都得上ABtest。

在能满足业务需求的情况,尽量依靠日报、周报、月报等固定报表解决战斗。尽量把专题分析留给真正有意义的话题,而不是每天对着这钻来钻去。

2判断指标下跌的轻重缓急

第一步:确认数据没有异常。实际上因为数据源出问题,导致的指标异常非常非常多,具体的可以参见做埋点、ETL、数仓的同学们的各种吐槽。所以遇到问题第一顺位先确认数据没有错,不要报假警。

第二步:确认指标波动幅度。这是确认问题的轻重。常见的指标,比如销售额/新用户数/活跃率等等,其波动是有一定范围的,根据历史经验可以划分为轻中重。在数据真实的情况下,一般重度波动都是有明显迹象的。比如受政策影响要停止某些业务,公司主动关停业务,春节/十一等假日因素。所以对于重大变化,事先要设好预期值,这样看数据的时候,就不会一惊一乍。对于严重超出预料的情况才做重点跟进。

第三步:确认指标波动持续时间。这是确认问题的缓急。

指标下跌/上升,通常有三种形态:

  • 一次性变化:只在某个时间点发生波动。一次性变化背后的一般都是短期/突发事件,比如系统down掉导致无法交易,比如某一天突然下大雨,比如某天上大促销等等。
  • 周期性变化:会周期性发生,比如每周的工作日和周末。一般业务开展都有周期性,比如零售行业,就是以周为单位循环。工作日和周末就是有明显波动。
  • 持续性变化:从XX时间开始,一直出现上升/下降趋势。持续性变化背后往往是有深层次的原因,比如用户需求转移,行业繁荣/枯萎,渠道形态变迁等等。这些都是单一企业很难低档,只能跟着走的力量,所以才会显示出持续变化。

这三种形态本身意味着问题的严重性不同。如果是指标下跌的话,持续性下跌≥一次性下跌≥周期性下跌。如果是周期性下跌,一般都不需要大惊小怪。如果是一次性下跌,往往来得猛去得也快,要关注事件持续性。持续性下跌,特别是不见好转,一路大牛市的下跌,持续的时间越长问题越严重。

单纯看走势并不能严谨解释问题,要和波动幅度结合起来看。比如同样是周期性下跌,如果本周期的数值明显比上周期跌得更厉害,就得注意,可能在周期性变化背后隐藏了其他问题。

同样是一次性下跌,如果相同事件下,跌得越来越厉害,就说明隐藏有其他问题。有些看似一次性事件,带来的影响可能持续发酵,最后演化成持续性下跌。持续性下跌中,可能每一期跌幅都不大,但放长线看,就会发现累积跌幅特别大,这时候问题严重性就更高。

很多业务部门会在这里犯错误。比如一说为什么二月份销量下降,就理所当然地认为是春节影响,没有认真计算其实今年春节后恢复速度大大慢于往年。一看上促销有销量,就急着庆功,没有计算促销前的蓄力期和促销后的疲软期越来越长,很有可能平台的用户已经出现了结构性变化,忠诚用户越来越少。这些都是一味凭经验办事,不细致看数据的恶果。

做数据分析的同学们,往往会犯相反的错误,还没有判断轻重缓急,听到要分析XX指标下跌就急着提取一大堆数据。既浪费时间,又没有什么分析假设,结果大海捞针一样空费气力。

3不同轻重缓急,不同分析手段

重+急:赶紧打电话向相关部门确认,之后向领导汇报。如果真的短时间内发生重大问题,慢慢写代码分析本身就是贻误战机的行为,就像火灾来了不去打119,还在这认真分析哪里起火了,火大不大一样脑残。这时候赶紧先确认数据有没有问题,不能报假警。之后抓起电话赶紧向相关部门反馈。

重+缓:对于长期存在的重大问题,要深入分析才能找到症结,这时候就得慢慢来,做多角度多维度的分析,而且分析结论要放回到市场调查、一线走访、行业研究里去相互验证,这样才是从根上解决问题的办法。不然分析完一版,业务并不觉得好用,最后还是白费力气。

轻+急:不严重但是突发问题,先锁定问题点。因为问题本身并不严重,如果全面做检查,很有可能被淹没在平均值的计算里。去平均化,把真正问题严重的点暴露出来,这样后续分析才能深入。

轻+缓:这时候不用急着取一堆数据,问题本身不严重,取了也对比不出来所以然,可以再观测一段时间再说。

要注意的是,到目前为止我们没有谈到任何专业的分析方法或者技术,只要盯着一根销售曲线或者用户数曲线,做一些简单的同比,环比就够了。这就是传说中的数据敏感性。看到指标曲线开始下跌,敏感性高的话会先对走势进行解读。这一点后续我们还有专门的分享。

有了轻重缓急的判断,下一步就可以缩小怀疑范围,建立分析假设。之前我们说了,单纯依靠数据很难把原因搞清楚,但当我们缩小问题范围的时候,就更容易找到问题源头。而建立假设,有助于去伪存真的进行验证,进一步逼近真实原因。

4缩小怀疑范围,建立分析假设

角度一:事件

往往重大的变化都伴随着重大事件的发生。因此反映在数据上,往往表现为在事件发生后,指标应声而落。这样即使不需要严谨的分析,只要在指标走势图上标识出事件发生的先后顺序,都能看出事件的影响。

事件可分为内部事件和外部事件。严格区分两种事件的影响是个很巨大的分析工程,而且很有可能压根区分不了。但内部外部事件对指标的影响方式与效果是不同的。

外部宏观事件我们常用PEST来分析,P影响一般是致命打击,直接把指标打崩,把业绩搞停。而EST的影响更多是渐进的、缓慢的、基础的、结构性的,因此表现在指标上,更多是阴跌不止。

内部事件往往能短期内快速改变指标,所以在解读指标变化的时候,可以按这个简单原则进行:泰山压顶看政策,短期变化找内因,长期异动找外因。

一定时间内同时发生的事件可能很多,要特别关注三类:

  • 起点事件:指标刚开始下跌时,发生了什么事;往往起点事件是问题发生的直接原因。
  • 拐点事件:在指标持续下跌过程中,是否某个事件的出现,让问题变得更严重,或者开始转暖。拐点职业意味着,这是可以改善指标的手段。
  • 终点事件:当XX事件结束后,指标恢复正常。或当开始XX事件后,指标下跌结束。终点事件的两种形态,代表着两种改善指标的方法:等问题自己过去,或者主动出击解决问题。

我们可以把事件标注在指标变动趋势图上,这样可以清晰地看到事件与指标的关系,从而更好地缩小怀疑范围,细化分析假设。找到那些看起来像是核心问题的事件进行深入研究。

有趣的是,在指标变动趋势图上标事件这件事,业务部门也会干,而且很多业务部门会直接依此下结论。比如天气一下雨销量就跌,一调价销量就涨。他们就想当然的会说:就是这个原因。

这是一种很经验主义的做法,可能会忽视很多结构性的问题。对做数据分析的同学而言,对于非十万火急的问题,其实这么做也无妨大雅。既然大家都这么认可,我们也省省精力。可以精选一些重+缓的问题,深入分析,找结构性变化的原因。这样既显得我们有价值,又显得我们懂业务。

角度二:区域

区分问题发生的区域/渠道,也可以缩小假设范围。比如看起来整体销售业绩下跌了30%,是否所有门店,所有区域都是30%,有没有还在涨的,有没有跌得更惨的,还在涨的/跌的惨的是不是有规律(门店位置、店长资历、开店时间、销售的产品线、存量客户群体……)通过分类对比,可以帮我们更容易找到问题发生点。

这么干还有个好处:为解决问题找标杆。比如在整体销售业绩下滑的情况下,有些省份/地市的门店可以做到不下滑,很有可能他们有独特的手段可以应对问题。比如在整体流量减少的情况下,有些渠道仍然能供应优质流量,很有可能意味着新的机会。因此可以通过对比不同区域的数据,把表现相对好的也标出来,这样未来寻找解决方案也有了依据,不用自己凭空拍脑袋想办法。

需要注意的是,很多做分析的同学在这一步就直接下结论,大标题写“各地区销售问题分析”,然后给个答案是:因为ABC地区销量差,所以拖累大盘。这种分析是很容易引来:“我早知道了”的吐槽的。因为这只是找到了问题发生的地点,没有真正切入问题原因,真正影响零售的是外部内部,是人货场,不找到真正的问题根源,是不能说“问题原因是XXX”这句话的。

角度三:群体

同区域类似,可以区分不同的客群进行切入,看不同客群间是否有差异。产品线也可以做类似的区分观察。一般传统企业没有完善的CRM,缺少客户ID,所以从产品线+区域的角度切入的比较多。互联网企业更关注用户群体,从用户角度切入的多。

这里引发了一个问题,比如当我看到区域、客群、产品线的时候,有可能都存在组间差异,该先从哪个维度切入呢?原则上讲,应该按行业的业务特性来,比如传统企业就是要先看区域再看产品。互联网企业就是习惯性先看用户。如果没有业务理解的话,那就看哪个组间差异大,从明显的问题切入。

截止到这里,字写了很多,可实际操作的时候非常轻松。因为以上所有分析只要基于一张指标日报和有分渠道/分用户群两个维度的日报就能搞掂。难点不是跑一个神奇的指标出来,而是去认真解读指标曲线走势,如收集和指标相关的数据。

5在条件允许范围内,深入分析

锁定问题点以后,我们会有很多问题假设。本次指标下跌是因为:

  • 新品不给力
  • 销售不会卖
  • 渠道缺配合
  • 竞品太凶猛

等等

之后可以根据时间、资源的条件来深入分析了。如果时间紧,可以直接打电话联系一线确认问题,然后把那些做得好的标杆经验直接复制出来。

如果时间宽裕,互联网企业可以做ABtest,尝试剔除一些干扰因素。传统企业可以做试点,丢一些样板店下去看效果。

总之有了明确的假设,验证假设的速度就很快,找优秀标杆的速度也很快。前边所有的工作都是在为这一刻铺路。基础工作做扎实了,后续才越做越轻松。

6为什么要讲这么多

这一篇的长度又破了陈老师的进度。熟悉陈老师的同学都知道,陈老师一向懒得写长文。为什么这个看似简单的问题却写了这么多?是因为:解读指标才是数据分析师的看家本事,而这些年过度迷信技术,沉迷可视化,沉迷阿尔法大狗子,搞得新入行的数据分析师们的看家本事的水平越来越差。无论是求职还是工作都有很多让人尴尬的事。

比如很多同学2月份写日报,就写:因春节因素影响,销量低迷。然后2月份的周报也是:因春节因素影响,销量低迷。然后2月份的月报也是因春节因素影响,销量低迷。这就是传说中的三花聚顶式报表。同一句话啰嗦三遍,完全没有任何解读。

比如看到一天数据跌了,急的抓耳挠腮,结果连往前多看几天,看看是不是周期性变化都不知道。

比如往前看了几天,发现已经连续跌了6周了,结果还是继续盯着眼前的指标继续抓耳挠腮的。

比如知道往前看,问题是丫做了漂亮的曲线,然后用肉眼在看跌了多少,连计算个绝对值都不记得的。

比如算了分渠道/区域的绝对值,然后认为下跌5%与50%是同一类问题,在报告写上:“所有渠道都在跌”就完事的。

比如只知道对着数据着急,连业务方干了什么事都不知道的。

比如期望能有一个人工智能算法,自动计算有几个因素的。

不过这不能怪同学们,因为跟很多同学深入聊以后发现:他们的主管压根没教过这些……难怪,这些年很多挂着“数据分析”组长头衔的领导,其实是做hadoop,做BI出身,写sql出身,本身确实只有开发能力没有分析能力。所以这一篇才特别啰嗦,希望大家能平时多练起来,日报、周报、月报是数据分析的骨架,骨头都软了,人也就直接废了。

照例,这么长的啰嗦是有福利的,陈老师把上边拉拉杂杂所有的总结一张思维导图,下图左边是确认假设,右边是判定轻重缓急。大家在面试的时候,最好自己一边写思维导图一边说,对面试官是秒杀级的,比随口扯几个理由,然后被人嫌弃:讲得不全,讲地不到位要好的多。

 

责任编辑:武晓燕 来源: 接地气学堂
相关推荐

2015-09-25 11:03:14

数据中心日志分析

2014-11-27 10:07:43

IT运维

2023-12-01 10:19:00

接口优化事务

2019-08-16 09:46:51

2017-01-06 14:57:02

2021-02-03 10:34:35

多云云安全CISO

2010-06-29 16:15:05

UML业务建模实例

2010-06-12 09:37:02

UML需求分析

2010-06-02 14:16:18

SVN版本控制

2023-03-24 16:18:08

微服务架构

2010-07-21 14:17:07

Linux telne

2011-07-28 14:07:30

2010-02-03 13:55:51

Python 代码

2010-07-22 10:58:49

batch Telne

2010-09-13 10:45:04

2023-09-03 23:49:35

2019-08-21 17:30:42

网络攻击安全系统服务器

2010-06-18 10:34:05

UML面向对象

2010-02-05 16:35:35

Android操作系统

2013-10-17 23:12:12

Windows 8.1Windows 8.1
点赞
收藏

51CTO技术栈公众号