你见过这样精准的预测模型吗?

大数据 数据分析
预售、团购、饥饿营销、订金膨胀、缺货登记……所有的业务手段,需要的不但是运营能力,更需要系统建设支持。显然,对业务来说,比起搞这些系统建设和复杂的运营手段,还是直接甩锅给“模型预测不准”更轻松。因此你要是直接问业务预测需求,他们都会倾向于“不高不低刚刚好”的赌命式预测。

​“预测得不准!”是数据分析领域的终极难题了。讲预测的算法有一大堆,然后遇到现实基本上都被锤成渣渣,业务方怎么都不满意。

到底该怎么破局?

一、预测算法的本质

从本质上看,预测算法只有2大类:

1、基于时间序列的。

  • 平滑:用于相对平稳的数据。
  • 自回归:用于趋势性递增、递减的数据。
  • 带季节因素自回归:用于有周期性波动的数据。

图片


2、基于因果关系的。

二分类问题:未来会/不会发生XX,典型如LR。

多分类问题:未来是ABC哪个情况,典型如决策树。

连续型问题:未来的数值是多少,典型如线性回归。

图片

有可能建模的时候,不是一个模型包打天下,而是用二阶段建模。比如预测一个客群消费情况,可以分别用二分类模型预测会不会消费,再用连续型模型预测消费金额,这样会消费用户数*预测消费金额,就能得出总消费。这是典型的处理手法。

书本上都是这么教的,然而为啥一遇到现实就被锤成渣渣了呢?

二、预测算法的要点

因为:书本为了突出模型效果,刻意选择了质量好、数据全的数据集。

现实中麻烦根本是远远不断:

1、没数据。很多时候给到的待预测数据,就一行“每月总消费”,其他数据屁都没有……

2、还是没数据。很多公司隔着天猫、抖音、亚马逊,拿不到一手数据,只能用后台导出的一点点数据瞎倒腾……

3、就是没数据。大部分公司不是头腾阿这种垄断公司,只拿了非常片面的数据。最常见的,大部分公司的用户是花钱引流来的,用户只有一个手机号+一个优惠订单……

这导致了一个搞笑的情况:很多公司用因果关系类模型,影响最大的变量一定是促销力度。甚至用逐步回归法建模的话,促销力度的变量,能直接把其他变量都干掉。预测结果就变成了:促销力度越大,用户加入越多,购买越多。

这种结果一丢出来,一准被业务评价为:“都TM是废话,我早知道了!”

这就是现实中第二大麻烦:业务效果到底怎么衡量。

比如预测销量是1000万

  • 业务做到900万,会说:预测得一点都不准,搞得货积压了
  • 业务做到1100万,会说:预测得一点都不准,还是我厉害

总之,只要你不是100%精准,他都有理由赖到你头上。甚至可以反复横跳。比如:“本来业务能达标的,看到预测说能达标,我们就省点投入,结果不达标了,都怪预测干扰了业务判断……”

怎么破局呢?问题既然由人而生,当然还得在人这里解决。避免赌命式预测,从业务场景角度出发,剔除人为影响,才是破题关键。

三、用业务运作避免预测错误

有些场景,能通过业务操作直接把问题消灭掉。这时候就直接用业务手段,不要建模。

比如:

场景1:“销售数据很少,分布很散,如何预测销量?因为货物本身不耐储藏,多进货的话库存损失率会很高”——用团购呀!团购就是解决这个问题的。

场景2:“销售数据很少,少到无法计算价格弹性,业务方又想预测价格弹性,多赚钱”——用拍卖啊!拍卖就是干这个的。

场景3:“新品是全新款,没有数据,咋预测?”——做新品预售/粉丝凭码购买呀。饥饿营销就是干这个的。

场景4:“大促期间备货量如何预测?拿捏不准用户有多少需求?”——10元定金,定金膨胀3倍抵用券,就是干这个的呀。

几乎所有互联网营销模式,从小米到天猫到拼多多,其实都是在对抗因数据不足带来的备货难题。所以别光盯着人家的模型,人家的运营也学学。

四、用基础分析缩小预测范围

所有赌命式预测都有个共同点:一定要不高不低才算准。比如典型的预测销售业绩,如果实际是1000万,他非得要求预测到1000万才算准。这是模型被评价为“不准”的问题根源。

回到业务场景中,其实大部分业务场景不需要这个级别的准确度。大部分时候,业务怕的是突然暴增/暴跌的场景。预测目标与其设定为:“100%精准”,不如设定为:“是否暴增/暴跌超过业务消化能力”。

预测100%精准基本无解,但是发现哪里可能暴涨/暴跌是很容易的。通过基础分析,把不稳定因素区分出来,能大大缩减预测问题的难度(如下图)。

图片

做好基础分析,拆分不稳定因素以后,也更方便挑选模型组合,解决问题(如下图)。

图片

五、用滚动式预测代替长期预测

所有的赌命式预测,预测时间周期都很长。长则一年,短也有一个月。赌的时间太长,前期能收集的数据很少,也无法把业务部门各种中间操作反映出来,因此非常被动。

用滚动预测能很大程度弥补这个缺点。通过日/周滚动预测,既能补充数据缺失,又能反映业务方临时调整带来的效果,一举两得(如下图)。

图片

六、用买定离手模式保护自己

一个好问题+滚动预测,基本上能满足实际工作需求。但作为做预测的人,得学会保护自己,避免业务方反复横条,瞎胡甩锅。

买定离手法是很好办法。预测结果给出以后,买定离手,所有相关业务方不再质疑预测结果,而是基于预测结果做叠加。

谁觉得预测少了,谁自己写请示申请额外货物,并且留下书面证据。到时候是预测得不准,还是业务自己申请多了所以卖不动,看得一清二楚(如下图)。

图片

七、再深层地看预测问题

预测问题的背后,是一个很深层的业务问题:在很多公司,库存积压的损失是直观可见的,货都烂在货仓里。但缺货损失的潜在销量,却没有认真统计。想统计缺货损失很容易,可以让客户交定金预约,可以让客户登记需求量和需求时间。但很多公司业务要么懒,要么蠢,要么不想担责任,总之是没有做。

预售、团购、饥饿营销、订金膨胀、缺货登记……所有的业务手段,需要的不但是运营能力,更需要系统建设支持。显然,对业务来说,比起搞这些系统建设和复杂的运营手段,还是直接甩锅给“模型预测不准”更轻松。因此你要是直接问业务预测需求,他们都会倾向于“不高不低刚刚好”的赌命式预测。

但显然这对数据分析师是不公平的。既然潜在损失无法衡量,现实积压是直观可见的,因此作为数据分析师只要顾好积压损失就能立功。所以才有了以上种种操作办法。​

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

2024-03-26 00:54:42

预测模型数据

2018-06-22 08:13:21

2021-03-12 11:50:08

项目组件 API

2019-08-20 16:58:14

戴尔

2018-02-01 21:34:38

戴尔

2022-05-09 08:37:43

IO模型Java

2022-07-12 14:45:54

达摩院模型

2022-02-23 18:36:11

钓鱼邮件数据泄露网络攻击

2019-05-07 15:49:27

AI人工智能艺术

2012-05-05 09:47:55

乔布斯

2018-04-20 14:35:18

电费电脑收益

2012-03-05 20:57:46

Siri

2019-11-07 21:26:22

iOS 14苹果谷歌

2018-07-04 13:00:58

雷军代码程序员

2020-10-26 15:18:01

大数据APP软件

2023-01-07 17:41:36

线程池并发

2016-07-20 10:01:59

2010-12-03 11:32:22

IT业

2022-11-30 13:54:29

2022-06-01 11:14:42

Java代码技巧
点赞
收藏

51CTO技术栈公众号