周一早上九点半，经营会刚开了十分钟。
大屏上只有一条很短的折线：周六 100，周日 80。负责人拿笔在最后一个点上画了个圈。
“掉了 20%，哪个渠道出问题了？”
运营同事开始翻活动日历，产品经理去问支付有没有报警，数据分析师则盯着那两个数字，没有马上接话。
不是他不知道怎么算环比。恰恰相反，这个环比太容易算了。难的是：周日为什么一定要和周六比？
如果一家店每周六都比周日热闹，周日低 20% 也许只是正常节奏；如果上个周日、上上个周日都在 96 左右，这个 80 才值得紧张。再往前一步，若周六刚好有大促、周日又遇上门店缺货，那么“跌了 20%”甚至把三个问题揉成了一个数字。
经营会上最危险的，不是没有数字，而是拿到一个数字后，过早替它写好了故事。
文中的 100、80 等数值用于说明判断方法，不对应某家真实公司的经营结果。
环比回答了变化，没有回答异常
从周六的 100 到周日的 80，变化率确实是 -20%。这句话在数学上没有毛病。
但“异常”不是一个单点属性。它永远隐含着第二句话：
相比什么正常状态，这个值偏离了多少？
前一天只是众多参照物里最顺手的一个。它适合回答“比昨天怎样”，不一定适合回答“今天是否不正常”。
零售销量、外卖订单、内容阅读、客服进线，常常有明显的星期规律。周一和周五不同，工作日和周末不同，周六和周日也未必相同。预测领域有一个很朴素的方法叫“季节性朴素法”：预测当前时点时，直接采用上一个相同季节位置的观测值。对于按天数据，这个“相同位置”往往就是上周同一天，而不是昨天。
它并不高级，却提醒分析师一件重要的事：先找可比对象，再谈偏离。
第一种基线：最近几个同星期日
遇到“周日比周六低 20%”，我会先拉出最近 4—8 个周日。
不是为了做一套复杂模型，而是先回答一个最便宜的问题：
这个周日，和它自己的同类相比，表现怎样？
可以先算三组数：
- 最近几个周日的中位数；
- 当前周日与中位数的差值和差异率；
- 最近周日自身的波动范围。
为什么先看中位数，而不是只看平均数？
因为这几周里可能夹着一次直播、一场暴雨或一轮大促。一个特别高的周日会把平均数往上拽，随后每个普通周日看起来都像“下滑”。中位数没有那么容易被单次尖峰带走，适合做第一眼筛查。
假设最近六个周日是 95、98、94、97、96、99，这次是 80。它相对周六低 20% 只是表面，真正值得追问的是：它也明显低于自己的周日常态。
反过来，如果最近六个周日本来就在 78—84 之间，那么 80 并不稀奇。此时更该解释的是周六为什么高，而不是周日为什么低。
这一层的好处是快。只要日粒度数据可靠，十分钟就能给出第一版判断。
它的限制也很清楚：最近几个同星期日未必真的可比。节假日调休会让“星期日”变成工作日，暑期和开学季也会悄悄换掉客群。于是还需要第二种基线。
第二种基线：日历和经营条件都可比的日期
同样写着“星期日”，背后的生活可能完全不同。
一个是普通周末，一个是春节返程日；一个有全站满减，一个原价销售；一个库存充足，一个主力商品下午两点就断货。把它们放在一起平均，像把雨天和晴天的客流混成一条线，再问今天为什么偏了。
所以第二步不是继续算，而是给日期加注释。
至少标出这些条件：
- 星期几，以及是不是调休；
- 法定节假日、长假前后和发薪日；
- 活动类型、补贴力度和覆盖渠道；
- 门店营业时长、库存可售率和渠道故障；
- 季节、天气等确实会影响业务的外部因素。
这一步看起来像给日历贴便签，实际是在定义“谁有资格互相比较”。
分析师可以先做一个很小的可比日期表：
| 日期 | 星期 | 节假日/调休 | 活动 | 库存与渠道 | 是否纳入基线 |
|---|---|---|---|---|---|
| 本周日 | 周日 | 普通周末 | 无 | 正常 | 当前值 |
| 上周日 | 周日 | 普通周末 | 无 | 正常 | 是 |
| 上上周日 | 周日 | 长假最后一天 | 满减 | 正常 | 否，单独解释 |
| 三周前周日 | 周日 | 普通周末 | 无 | 主力品缺货 | 否，单独解释 |
表里最有价值的一列不是“活动”，而是“是否纳入基线”。
因为只要选择标准没有写出来，人很容易事后挑数据：想证明异常，就挑几个高点；想证明正常，就挑几个低点。把可比条件提前写清楚，讨论才不会随着会议气氛移动。
这一层还能纠正一个常见误会：同比天然比环比科学。
去年同日也可能落在不同星期，春节、促销和天气也可能错位。同比提供了更长的时间视角，却不自动保证可比。真正有意义的同比，应该尽量做星期对齐、节假日对齐和经营条件说明。
第三种基线：模型给出的预期区间
当业务量更大、季节规律更复杂时，只看几个历史同星期日还不够。
这时可以让时间序列模型把几类信息拆开：
- 长期趋势：业务是在增长、收缩，还是换了平台期；
- 周期规律：每周、每月或每年的重复节奏；
- 节假日和活动：某些日期会带来稳定影响；
- 外部变量：促销、价格、库存、门店数等可提前知道的条件。
模型给出的最好不是一个孤零零的预测值，而是一段预期区间。
比如模型认为这个周日的合理范围是 90—102，实际是 80，那么它可以进入异常候选；如果合理范围本来就是 76—92，80 仍在正常波动里，就不该因为和周六相差 20% 而拉响警报。
注意，我说的是“异常候选”，不是“事故结论”。
预期区间也会出错。历史数据太少、业务规则突然改变、活动字段漏标，都可能让区间失真。以 Prophet 为例，它可以显式建模周度、年度季节性以及节假日影响，也会输出预测的不确定性区间；但官方文档同样提醒，不确定性依赖对未来趋势变化的假设，并不天然等于业务世界里的确定概率。
因此第三种基线适合扩大筛查，不适合代替调查。模型负责告诉你“这里不太像过去”，分析师仍要判断“发生了什么”。
三种基线不是三选一，而是三道由便宜到昂贵的门
不少团队听到“异常检测”，第一反应是上模型。其实多数经营会不需要从最昂贵的一步开始。
更稳妥的顺序是：
- 同星期基线：先排除最明显的星期效应；
- 可比日期基线：再排除节假日、活动、库存和渠道条件差异；
- 预期区间基线：对长期、大规模指标做持续筛查。
第一道门几分钟能做，第二道门需要业务日历，第三道门需要稳定的数据与维护责任。
如果第一道门已经说明 80 落在最近周日的正常范围里，就没有必要急着宣布故障。如果第一、二道门都显示异常，再让模型和明细定位参与，会议会少很多空转。
这也改变了汇报方式。
不要只在群里发：
周日销量环比下降 20%，请关注。
可以改成：
周日销量 80，较周六下降 20%；但周六不是同类基线。与最近 6 个普通周日中位数 96 相比，下降约 17%，并低于最近波动范围。已排除促销差异，正在核查库存、渠道和门店营业情况。
后一句更长，却把“事实、基线、判断和下一步”分开了。读者知道哪里已经确认，哪里仍在调查，不必从一个百分比里猜整件事。
别让异常阈值变成一条祖传红线
很多看板里有一条很整齐的规则：环比跌 10% 变黄，跌 20% 变红。
它的问题不是简单，而是对所有日期一视同仁。
一个波动很小的指标，跌 8% 也许已经少见；一个周末起伏很大的指标，跌 20% 仍可能正常。同一条阈值套在两个指标上，结果往往是一个漏报，一个天天报警。
阈值至少应该与基线波动一起看。轻量做法可以用中位数和四分位距，或中位数绝对偏差，给每个星期位置建立自己的常态范围。等数据量和使用频率足够，再引入更完整的预测区间。
这里没有一个适合所有公司的固定数字。窗口太短，容易被最近一次活动带偏；窗口太长，又会把已经变化的经营状态当成旧常态。窗口应该结合业务节奏，并在规则旁写明版本和生效时间。
“阈值是多少”不是纯数学问题，它还取决于误报和漏报的代价。
支付成功率掉一点，可能要立刻调查；内容阅读量少一点，晚半天确认也未必有损失。把指标的重要性、响应时限和负责人一起写进异常规则，才知道报警之后由谁做什么。
明天就能做的 3 个动作
如果你手上正好有一张“昨日环比异常”看板，不必先重做整套系统。
动作一：给异常卡片补一列“所用基线”
不要只展示变化率。至少写清：
- 当前值；
- 对比值；
- 基线类型；
- 差值与差异率；
- 是否超出常态范围。
只要“基线类型”这一列出现，很多把周日和周六硬比的结论会自己露出来。
动作二：做一张最小业务日历
先不用追求完整。
从最近 90 天开始，补上节假日、调休、主要活动、渠道故障和严重缺货。每次复盘再增加一个确实影响判断的字段。三个月后，这张日历往往比一段漂亮的异常检测代码更有用。
动作三：把会议结论拆成四格
用一张表记录：
| 实际值 | 使用的基线 | 当前判断 | 待核查原因 |
|---|---|---|---|
| 80 | 最近 6 个普通周日 | 异常候选 | 库存、渠道、门店营业 |
这样做的好处，是不把“看见偏离”和“找到原因”写成同一件事。
会后如果发现主力商品缺货，更新原因；如果最后证明只是历史基线被大促抬高，就更新判断。记录会留下分析过程，而不是只留下一个红色箭头。
真正专业的那句话，常常是“还不能这么比”
经营会喜欢快答案。屏幕上的红色数字也很会催人。
但分析师的价值，不是比别人更快地念出“下降 20%”，而是知道这个百分比在哪些条件下才有意义。
周日比周六低，只说明两个相邻日期不同。它可能是异常，也可能是星期规律、活动退潮、库存变化，甚至只是周六特别高。
下次在经营会上再遇到红色箭头，不妨先让它等几分钟。拉出最近几个同星期日，在日历上圈掉大促和缺货日，再看它有没有落到预期区间之外。做完这些，你可能还是不能立刻说出原因，却能更诚实地说清：这是正常起伏、异常候选，还是已经确认的事故。
数据最终还是要回到人过的日子。周末、假期、发薪日、下雨天，都不是曲线上的噪点。那句“还不能这么比”听着不够痛快，却常常比一条仓促的结论更专业。
我叫石头，在数据行业里摸爬滚打了十几年，也见过不少红色箭头最后只是参照物选错了。这里写的，就是这些教训——我觉得值得说出来的那部分。
