分析指标波动,数据模型得这么建

大数据 数据分析
数据分析需要跑数,但想解读跑出来的数,需要的是掌握丰富的事实情况,用数据量化评估其中可量化的部分,监控其中持续发展的部分,拆解其中模糊部分,从而越来越接近真相。

当业务指标开始波动的时候,人们总会有问题:

“为啥涨了5%”

“为啥又跌了1%”

“为啥涨了2天又跌了?”

“为啥三天了都没变化呀?”

总有十万个为什么,从各个部门口中脱出,然后搞得做数据的同学天天忙着跑数,晕头转向不说,还落个:“为啥不能事前洞察?”“你这也不深入呀!”的抱怨。

咋整?今天系统讲解下。

一、常见的错误做法 

最常见的做法,就是遇到指标变化就拆解。各种维度都拉出来做交叉,最后哪个差异最大,就说是哪个因素导致的指标波动(如下图)。

图片图片

而这么做,非常无脑+低效。

无脑,是因为:业务方关心的是具体的问题。比如:

是不是新品不给力

是不是对手有动作

是不是执行没到位

是不是环境有变化

……

这些业务原因,不是数据库里“性别、年龄、地域、产品名”这样的简单维度能概括的。因此即使拉出交叉表来,也不能解答这些深层问题。

低效,是因为:严重浪费数据分析师的时间。相当多的波动,丫根本就是自然波动,或者是业务自己整出来的活。相当多的波动,就是单纯因为开发动了埋点又没吭声。这些问题根本不需要反反复复拉交叉表。只知道逼数据分析师拉交叉表,不但浪费时间,而且错失了总结规律,深入分析的机会。

那么,怎么优化做法呢?

二、诊断模型三大关键

从源头上看,反问三个灵魂问题:

1、是不是所有指标波动都很重要?

2、是不是所有波动都原因未知?

3、是不是所有波动都值得行动?

回答是:不是、不是、不是!

至少3/4以上的波动是计划内的、可预知、不值得理会的。因此事前的基础工作,远比着急忙慌有用。把指标分清楚,原因提前收集,结果提前预判,是系统解决问题关键。想达成这一点,靠的是整个工作流程的支持,而不是一串神秘代码。

三、区分核心、附属、边缘指标

同收入、成本、利润相关的,都是核心指标。核心指标发生波动一定是优先关注的。

附属指标,则是组成收入、成本、利润的过程指标或子指标。比如用户数、转化率、客单价等等。附属指标的波动是问题吗?不一定是。很有可能只是业务发展有了新形态。因此,不需要每天看变化,而是关注发展趋势(如下图):

图片图片

边缘指标,而是一些不直接相关,甚至不可准确量化的指标,比如满意度、NPS等等。这些指标监控其长期趋势即可。并且,关注口碑、舆情中极端个案(特别不满的顾客或者恶意攻击)会比看统计指标更有价值。

当然,不同业务的核心、附属、边缘定义会有差异。但区别对待是必须的,不然很有可能出现:“分析了一堆,对业绩影响一毛钱都没有”的窘境。

四、理清正向、负向原因

常见的正向原因:

  • 促销活动
  • 政策利好
  • 新品上市
  • 新店开张
  • 旺季到来

常见的负向原因:

  • 系统宕机
  • 政策利空
  • 旧品退市
  • 阴雨天气
  • 淡季到来

这些不但可以提前知道,而且其中相当多的部分,可以提前做分析,给出可接受的范围。

淡季/旺季,可以用周期分析法,从过往数据中提取周期波动规律(如下图)。

图片图片

促销活动,可以先对活动类型打标签,再根据过往数据,测算每一类活动投入产出比。

图片图片

新品上市,可以先对商品类型打标签,再根据过往数据,测算商品LTV曲线。

图片图片

新店开张,可以先对门店类型打标签,再根据过往数据,测算店铺LTV曲线(原理同商品分类)。

通过标签分类+复盘分析,大部分自然原因、人为原因导致的波动,可以得出一个量化范围。在事前收集这些原因,就能极大地缓解指标波动带来的神经过敏,聚焦真正该聚焦的问题。

注意,这里有两类问题是很难事前准备的:

1、突发型事故,比如系统bug,恶劣天气等等

2、外部因素变化,比如对手促销,政策风险

这些需要沟通+问题排查机制解决。

五、常规沟通与问题排查

常规沟通:

1、从业务:近期促销上线、产品上下架计划、开店计划、投放计划。

2、从技术:开发进度、开发问题

3、从外部:新政策发布、生效;竞争对手已公布动作

问题排查:基础数据质量,常规日报数据核对。

所有信息,汇总到时间表上,就能形成解读波动基本素材,之后静待数据给出结果。看结果再决定是否深入。

图片图片

六、发生结果后诊断

A类:知道原因+期望内+正向变化。只要没有击穿期望值,监控趋势即可。要问波动原因,就四个字:正常波动。

B类:知道原因+期望内+负向变化。只要没有击穿期望值,监控趋势即可。要问波动原因,就四个字:正常波动。

C类:知道原因+期望外+正向变化。比如下图所示,原本预计的上促销会大涨,结果没啥反应,啥原因?活动拉胯了呗……这时候直接切入活动分析细节,让业务方赶紧做做一手调研,想想救命办法更靠谱。

D类:知道原因+期望外+负向变化。比如下图所示,原本预计恶劣天气持续太久,导致一些原本薄弱的门店快不行了。这时候要兵分两路。

一路:分析是否有其他交叉因素,助纣为虐

另一路:做标杆分析,看恶劣环境下有没有应急办法

图片图片

E类:不知道原因+正向变化。超出预期是不是好事?不见得,比如回光返照式短期销售暴增,如果业务方信了,又补了货,那只会造成更大积压,因此正向事件超出预期时,要格外注意关联因素,比如畅销品缺货、滞销品积压、营销成本暴涨(别便宜了羊毛党)、投诉数量激增等问题。

F类:不知道原因+负向变化。这是得警惕的。这个时候要先“三看”

一看:局部问题or全局问题

二看:突发问题or持续问题

三看:有缓解迹象or越来越严重

(举个简单例子,如下图)

图片图片

原则上局部、突发性问题,从内部找原因更快;全局、持续型问题,有可能存在外部深刻影响。之前在分享《提升DAU,数据分析要怎么做?》的时候,有更详细说明,大家可以参考。

总之,有了充分的基础准备,就能快速区分问题的轻、中、重,输出分析结论,也能为后续分析做好铺垫,避免漫无目地交叉。

七、小结

数据分析需要跑数,但想解读跑出来的数,需要的是掌握丰富的事实情况,用数据量化评估其中可量化的部分,监控其中持续发展的部分,拆解其中模糊部分,从而越来越接近真相。

需要注意的是,这些工作并非靠数据分析师一个人能完成。

如果领导自己都不清楚目标

如果开发我行我素瞎胡乱搞

如果业务连啥叫“分类”都不懂

如果业务一定要扯“我做的就是牛掰克拉斯!一定是其他原因干扰了我!”

……

责任编辑:武晓燕 来源: 接地气的陈老师
相关推荐

2023-02-26 17:46:03

2022-01-04 18:40:54

数据模型波动

2020-05-15 16:59:41

Tableau数据分析

2021-02-28 22:20:25

2010-05-26 14:37:56

Cassandra数据

2021-01-27 05:17:27

数据分析指标

2021-04-16 15:03:56

数字化转型IT技术

2023-11-03 11:51:31

2021-01-27 05:34:33

Python对象模型

2009-09-18 14:07:51

LINQ to SQL

2012-03-05 10:54:03

NoSQL

2020-02-07 16:25:26

Java数据分析新型冠状病毒

2017-06-27 10:08:29

数据仓库模型

2010-08-11 09:29:25

FlexJava数据模型

2016-11-02 12:32:47

数据分析大数据模型

2021-07-14 10:09:05

架构模型数据

2022-08-15 14:49:12

物联网数据模型存储

2021-02-10 16:50:35

比特币加密货币货币

2022-12-09 09:39:01

数据治理

2017-04-12 09:18:48

大数据数据模型数据分析
点赞
收藏

51CTO技术栈公众号