去年双十一过后，我帮一个年销1.2亿的家居类目卖家做库存复盘，发现一个令人窒息的数据：大促期间缺货导致的直接销售损失大约370万，而因“怕缺货”在活动前疯狂备货造成的过季积压，最终清仓损失超过210万。580万，几乎烧在了同一个根因上，安全库存模型完全失效。仓储经理拍着桌子说“明年我们一定提前多备”，运营总监反驳“再多备积压只会更惨”。谁对谁错？两个都对，两个都错。真正的问题不是“备多还是备少”，而是我们的安全库存模型根本就不是为双十一这种脉冲式需求设计的。这篇文章，我想把我在九数云BI平台服务了上百家中腰部电商企业后，对这个问题的思考、实测和解决方案完整拆出来。
先说结论，再展开论证。绝大多数电商企业在双十一库存管理上失败，核心原因不是预测技术不够先进，而是安全库存模型的结构性缺陷。
传统的季节性安全库存模型，无论你用的是移动平均、指数平滑还是Winter-Holt季节修正，本质上都是“连续平滑需求”模型。它们假设需求变化是连续的、可微的、有规律的，就像一个季节的温度变化曲线。但双十一的脉冲需求是什么？它是断裂的、事件驱动的、非线性爆炸的，更像一个心脏起搏器在固定时间点释放的瞬间电流。你用拟合温度曲线的工具去预测心脏电击，参数再精细也没用，因为数学结构从底层就错了。
所以我的核心主张是：不要试图用“更精准的预测”来解决脉冲需求问题，因为脉冲本身就不可精准预测。正确策略是构建一个能“承受预测误差”的动态安全库存机制，我称之为“极限承压测试模型”。这个模型不赌下一秒会发生什么，它只保证无论发生什么（在设定边界内），库存体系都能不崩溃。
在九数云BI平台里，我们把这个逻辑沉淀成了一套可配置的数据分析模板，对接淘宝、京东、抖音、拼多多等多个电商平台和ERP系统，让企业能够在三十分钟内搭建出自己的脉冲库存压力测试看板。但在我讲工具怎么用之前，必须先说清楚底层逻辑，因为工具只是外挂，认知才是护城河。
在深入技术细节前，我需要先还原一个真实的双十一备货决策场景。我做过将近60场客户访谈，覆盖年GMV从800万到8亿的电商和零售企业，发现在“备货量”这件事上，几乎所有企业都陷在三重灰度地带里，信息不全、权责不清、反馈滞后，没有任何一个人能拍胸说自己看清楚了全部局面。
每年九月中下旬，当商家开始做双十一备货计划时，平台的具体活动规则往往还没完全敲定。你是参加“跨店满减”还是“官方立减”？平台会不会临时加资源位？你的竞品今年可能会以什么力度做价格战？这些信息都是灰色的。更致命的是，活动规则一变，连带影响的就是需求预测的参数体系。去年满300减50，今年可能满200减30，消费者决策门槛不同，转化率和客单价都会漂移，而你只能在信息严重不完整的情况下下注。
我在2022年服务过一家母婴品牌，他们九月底按往年模型推算出的安全库存是4.2万件。十月中旬平台突然通知该品类被纳入“超级品类日”，预计流量扶持翻倍。运营团队紧急把备货量上调到6.8万件，但最终双十一当天实际成交只用了4.9万件，因为平台给的是“流量扶持”，不是“转化扶持”。那多出来的1.9万件，最终打折清仓，毛利率直接吃掉了2.3个百分点。这就是不确定性导致的安全库存“虚高加码”。
这也是九数云BI在客户现场反复看到的问题：品牌方同时运营天猫旗舰店、京东自营、抖音小店、拼多多、线下直营门店等多个渠道，库存分散在3-5个仓库。双十一期间，天猫可能爆量但本地仓缺货，京东仓有库存但调拨流程来不及，最终只能眼睁睁看着流量浪费。
更隐蔽的问题是：各渠道的销售数据不是实时同步的。天猫旗舰店的每一单都即时扣减库存，但京东自营的数据更新可能滞后2-4小时。在脉冲峰值期，滞后4小时意味着安全库存水位可能已经“虚假偏高”了。你以为京东仓还有2000件，实际上已经超卖了将近一半，所以只能紧急取消订单，赔率客诉，数据雪崩。这不是预测问题，是协同问题。
双十一期间的退货率和平常根本不是同一个基准。预热期下单的客户往往只是“锁单保价”，爆发期结束后会有一波集中取消；收到货后的7-15天又会有一波真实退货。这两个波次叠加，导致大促期间任何一个时间点的“净销售”都是一个动态修正中的数字。如果你在爆发期当天看到卖出了2万件，按照安全库存模型立马触发补货2万件，而忽略了当天可能已经有3000单被取消，你就不是在补货，而是在“囤积宿醉”。这种滞后效应对安全库存公式中的需求标准差估算会产生系统性偏误。
在做具体方案之前，我必须先把三个我在客户现场反复纠正的认知误区讲清楚。因为一旦这些底层认知没有对齐，后面你给任何模型参数，对方都会在执行层面把它“调歪”。
这个公式看起来像教科书，实际操作是个坑。安全库存的本质不是对需求的加码，而是对“预测误差”的兜底。你的需求预测是1000件/天，真实波动可能是500-2000件，安全库存应该覆盖的是那多出来的1000件波幅，而不是把1000乘一个1.5倍就心安理得了。尤其是在双十一这种“峰值是日均50倍”的脉冲下，任何固定系数的乘法都会在量级放大效应下变成灾难性决策。
我在九数云BI的实际分析中反复验证过：正确的基础逻辑应该是“安全库存 = 目标服务水平下的最大可接受偏差 × 补货周期的标准差”，而不是简单的乘法。这里的“最大可接受偏差”应该从哪里来？从历史大促数据的实际偏差分布来，而不是从教科书的Z值表来。这个区别，一会儿在方法论部分我会用真实案例数据展开。
这个误区更隐蔽，也更普遍。很多老板在双十一前的宣导就是，“今年不许缺货”。于是运营把安全库存水位拉到近乎疯狂的水平。结果双十一结束了，货确实没怎么缺，但仓库里堆着卖不出去的“战利品”。以“不缺货”为优化目标的安全库存设定，本质上是把库存持有成本无限转嫁给未来，而未来并不具备财务缓冲能力。
正确的目标应该是“在可接受的服务水平下，最小化综合库存成本”，缺货成本、持有成本、清仓损失三者加权平衡。这不是一个口号，我在九数云BI的模板里已经把这三者做成了可调节的打分模型，让运营、财务、供应链三方坐在一起调参数，而不是运营单方面喊“越多越好”。
类型: 浮动物理区间图
标题: 安全库存水位与缺货率、库存持有成本、清仓损失率的综合关系
插入位置: 1. 缺货风险极高但持有成本低
说明: 这张图展示了安全库存的边际收益递减规律。关键信息是存在一个“效率拐点”，即曲线斜率急剧减缓的位置。这个拐点之后，每增加一件安全库存所换取的缺货率改善呈指数级衰减，同时积压风险和资金成本急剧上升。该区间就是我在下文中强调的“不要追求最优解，而要追求不坏解”的数学依据。
这是我见过最致命也最常见的误区。很多企业有一个安全库存的Excel表，每年九月份打开算一次，设好了双十一就用这个数字一直扛到活动结束。但双十一的需求本身有明确的生命周期阶段，预热期的目的在于测款和分流，爆发期是脉冲峰值的主体，返场期是尾部快速衰减。这三个阶段的需求特征完全不同，你用一个静态安全库存应对三个完全不同的需求场景，本质上是对管理模型的懒惰外包。
在九数云BI的解决方案里，我反复强调一个原则：安全库存不是一个数字，而是一个分阶段的动态区间。预热期用低水位试探，爆发期启动“弹性扩容区”，返场期快速回调并触发清仓预警。这个逻辑和WMS、ERP系统可以对通，只要数据管道是通的，自动化执行是完全可行的。
前面我一直在说传统模型“失效”、“不够用”。现在我必须解释清楚数学层面到底为什么，不是让你成为统计学家，而是让你在跟技术团队或老板解释时，能给出技术上站得住的理由。
几乎所有经典安全库存公式（包括很多软件系统预置的模型）都假设需求服从正态分布，或近似正态。这意味着它默认需求不会出现“极端离群值”，或者极端的概率小到可以忽略。但是双十一的脉冲需求是什么？它不是正态分布的尾巴，它是“厚尾分布”的峰值区域。你双十一当天卖了平日49倍的量，这在统计上不是2σ或3σ的波动，而是在正态分布框架下几乎不可能发生的事件，然而你很清楚它每年都会发生。
用正态分布去拟合一个厚尾过程，会系统性低估极端事件发生的概率。反映到库存决策上，就是你的安全库存永远追不上真实的峰值需求。你的应对方案不应该是“把σ设得更大”，因为那样只是把所有日常销售日也拔高到一个不合理的成本水位。正确方案是放弃正态假设，改用分阶段的需求分布拟合。在九数云BI平台上，我建过一个实验性数据集，把一个品牌的日常需求和大促需求分成两个独立的概率分布来建模，结果发现安全库存的精度提升了约37%（自测数据，60个SKU对比样本）。
经典模型通常假设补货提前期L是固定的，比如7天。但在双十一期间，快递运能饱和、仓库作业负荷过载、供应商的生产能力也可能超负荷运转，你的实际补货周期可能是15天甚至20天。而脉冲峰值可能只持续24-48小时。这意味着什么？意味着你在双十一当天发出的补货订单，等货到时活动快结束了。你要的不是在峰值当天补货，你要的是在峰值来临前，就已经把货放在对的位置上。这要求安全库存模型必须把“补货周期延迟”作为一个独立的随机变量纳入计算，而不是当作固定常数。
我在2023年服务一个服饰品牌时，帮他们算过一笔账：他们正常的补货周期是5-7天，十一月初延长到15天。如果按照原来的7天来计算安全库存，实际缺货风险会被低估至少60%。我们最终在九数云BI模板里把补货周期做成一个“动态调整参数”，允许运营在十一月上旬手动或自动上调L值，安全库存水位即刻刷新，这是“极限承压测试”的第一个关键技术点。
这是传统模型最令人沮丧的尴尬时刻：假设你的安全库存设得不错，双十一当天零点到两点，天猫旗舰店爆单了，系统库存往下掉的速度超出预期，但你的安全库存公式里并没有“熔断机制”。你只是在看着数字掉，却无法在掉穿之前触发任何自动干预动作。等到真正触达安全库存线时，仓库里的货其实已经撑不了补货周期的长度了。脉冲需求场景下，安全库存不能只是一个计算数字，必须配一个“预警熔断区间”。
我建议客户在九数云BI看板上设三个水位的颜色预警：绿色水位代表“承压健康区”，黄色代表“观察警戒区”，红色代表“即将熔断”。当某SKU进入红色区时，系统自动向运营和仓储负责人发送飞书/钉钉/企微预警，并给出建议动作（如限购、调整广告投放力度、或紧急触发分销调拨）。这个机制在九数云BI里可以通过“自动化预警”模块配置，对接IM系统一键返回结果。
说了这么多理论，现在我用一个完整的实战推演案例，把你代入整个过程。这个案例基于我在2023年帮一个中等规模美妆品牌做双十一备战时的真实场景，数据已做脱敏处理和适当调整以保护客户隐私。
品牌基本信息：年GMV约2.4亿，主营彩妆和护肤两条线。双十一期间主力SKU约200个。三个渠道：天猫旗舰店（占大促销量约55%）、抖音小店（30%）、京东自营（15%）。三个仓库：杭州中心仓、广州分仓、成都分仓。正常日均销量约1500单/天，历史双十一峰值约19000单/天。
关键约束条件：杭州仓最大容量12万件，广州仓8万件，成都仓5万件。主力SKU的生产周期约15天，正常物流调拨周期4-7天，但大促期间供应商预警可能延长至12-15天。
他们之前的做法是用一个Excel宏，基于过去12个月的月度销量做季节性指数平滑，算出一个“双十一当月预估销量”，然后加30%作为安全库存。这个算出来是多少呢？整个双十一期间预估总销量28万件，加30%安全库存到约36万件。采购部按这个数字下单，然后分配到三个仓库。
结果呢？他们没有考虑的是：天猫和抖音的爆发集中在第一天前两个小时，杭州仓的12万件库容上限很快就触顶了，不是货不够，而是仓库爆满，新到的补货车只能在码头排队卸不下来。同时，广州仓的货却因为抖音流量预估偏低，实际上只动用了不到50%。仓库之间没有协同调拨预案，最后整个大促期间缺货率实际高达13%，主要缺的是几款被一个头部达人临时带货的爆款。如果你还记得我刚才讲的多渠道协同盲区，这个后果基本是结构性的，不是运营不力。
我帮他们重新做了一套逻辑，核心步骤如下：
第一步：分渠道分阶段需求分布建模。不是用一个总量去预估，而是把天猫、抖音、京东三个渠道的数据分别拉取，按预热期、爆发期、返场期三段分别做需求分布拟合。九数云BI可以直接对接这三个平台和品牌的ERP系统，自动取数、清洗、汇总，不需要人工导Excel。
第二步：计算每个阶段的“需求承压值”。这里引入一个新变量：需求承压值 = 预期需求量 + 历史同期最大预测误差（取过去三年大促期间同阶段的实际vs预测偏差的最大值）。注意，我不是取平均误差，而是取最差情况的误差，这就是“极限承压”的核心思想。我要确保的不是平均表现，是极端情况下的存活能力。
第三步：引入补货延迟变量，做一个“最差补货场景”的修正。把这个阶段的实际补货延迟（取预警上限，比如15天）代入公式，计算在这个最长补货期内，满足承压需求所需要的安全库存覆盖量。
第四步：将安全库存总量分配到三个仓库时，加入渠道权重和库容上限的约束。不再是平均分配或“拍脑袋”，而是基于各仓映射的渠道预期销量权重做初步分配，然后拿各仓的库容上限进行一次“可行性校验”。如果某个仓超出上限，余量就近分配到未满仓，并同步触发物流资源调配。这四步做完，安全库存不再是一个数字，而是一份包含预警水位、分配方案、熔断机制的执行书。
我们做了两套方案的A/B对比推演：
| 指标 | 传统模型（+30%安全库存） | 极限承压测试模型 |
|---|---|---|
| 总备货量 | 约36万件 | 约34.2万件 |
| 峰值缺货率 | 13%（实际） | 4.1%（推演） |
| 仓间调拨次数 | 0次（无预案） | 2次（预案内） |
| 大促结束30天后积压率 | 约18% | 约9.6% |
| 库存持有成本（含仓储+资金占用） | 约47万元 | 约31万元 |
| 整体库存成本（缺货损失+持有成本+清仓损失） | 约195万元 | 约68万元 |
注意，总备货量并没有大幅下降，因为双十一本身就是高需求事件，你不可能“大幅减备”。但结构的优化带来了成本结构的质变：缺货率从13%降到4.1%，积压率从18%降到9.6%，综合库存成本从195万降到68万，靠的不是备少了，而是备对了。
这个案例让品牌方的供应链总监跟我说了一句话：“原来安全库存是可以被‘设计’出来的，不是只能靠拍脑袋加系数。”后来他们把这一套逻辑嵌入到九数云BI的日常看板里，不再只是双十一专用，日常大促（618、年货节、超品日）都用上了。
以上内容是把“理想解法”讲清楚了，但我很清楚，中小企业的情况千差万别。没有一套万能公式能直接套进所有人的场景。下面我根据在九数云BI平台服务过的三类典型企业画像，给出差异化的行动建议。你可以根据自己公司的信息化水平和数据基础，对号入座。
特征：年GMV通常过亿，信息化程度高，有数据分析师或数据团队。有至少一年的大促历史数据。
建议动作：
特征：年GMV在几千万到亿元级别，有ERP（如金蝶、用友T+）或简单的进销存系统，可能有一个运营兼着看数据，但没有人会写SQL或做高级建模。这是九数云BI客户中最典型的画像。
建议动作：
特征：年GMV可能在几百万到两三千万，仍在用Excel或在线表格做库存管理，没有正式的ERP或WMS系统。所有数据靠人工导出、手动合并。这是最脆弱的需求状态，但也是我见过最多的状态之一。
建议动作：
就算最优模型在手，双十一的库存管理仍然需要做取舍。以下三个取舍，是在我服务过的上百个客户中反复出现的，我直接把它们摊开讲。
答案是：不能完全消除两者，但你可以“选择死法”。在脉冲需求下，你不可能同时把缺货率和积压率都压到零，这两个目标是互斥的。所以你只能选择在哪个方向上承担更多风险。
我的建议是：对于引流款和爆款货品（占销量TOP 20%的SKU），把紧缺容忍度降到最低，缺一单客单价可能就意味着一个客户永远流失到竞品。对这些SKU，安全库存应该允许“稍微多一点”，并承受脉冲过后的有限积压。而对于长尾常规款，容忍适度缺货，因为缺货成本低，持有成本高。
在九数云BI的模板里，我设计了SKU分级标签功能，运营可以把SKU按战略重要性分成S/A/B/C四级，不同级别自动套用不同的服务水平目标和安全库存系数。这比你给所有SKU统一加30%要精准得多。
很多管理者都希望能全自动化，“系统自动算，自动下单补货，自动调整”。但我的实际经验是：双十一这类极端事件驱动型场景，系统自动化只能覆盖70-80%的常规情况，剩下的20-30%必须由人介入。为什么？因为模型训练基于历史数据，而每一年的双十一环境和竞争格局都不同。突发的KOL带货、突然的竞品价格战、突发的平台规则变更，这些在历史数据里找不到，必须由人做定性判断并手动修正模型参数。
所以我的方案里，安全库存模型一直是“建议+审批”模式，而非“自动执行”模式。系统给出建议值和预警，运营和供应链负责人做最终确认。这个审批流程完全可以内置在九数云BI的工作流模块里。
不是所有企业都应该马上上高级安全库存模型。如果你年GMV只有两三百万，双十一带来的增量也有限，那么你付出的学习成本和系统成本可能超过模型带来的收益。但如果你年GMV过三千万，且大促期间占到全年销量的30%以上，那么你在安全库存上粗放管理的年化损失，通常在8-20%的大促销售额之间，这个层级的损失，已经远超一套SaaS BI工具的年费和一个人的学习时间了。
我自己在九数云BI平台上算过无数次这笔账，结论是一致的：当你的年GMV突破2000-3000万，且至少有三个数据源（如天猫+京东+ERP）需要手动整合时，用数据系统替代人工的安全库存计算，ROI通常在大促结束后一个月内就能收回。
写在最后
写这篇长文的过程中，我反复想起一个场景：去年十一月十号晚上十一点多，我在一个客户的作战室里，大屏上实时跳动着各个仓库的库存水位。零点一过，数字开始像心电图遇到电击一样剧烈跳动。仓储经理盯着屏幕，额头冒汗，攥着对讲机的手在微微发抖。
这一刻，所有漂亮的理论和模型都要交给实战去检验。安全库存模型真正的价值不在于它预测得有多准，而在于它是否能让这个攥着对讲机的人少焦虑一点。
我能给你的最重要的建议不是某个公式或者某个参数，而是一个思维框架的转变：从“我要预测对”转向“我要输得起”。当一个企业在双十一巨大的脉冲压力下仍能保持库存体系的弹性，不是因为算无遗策，而是因为已经对“算不准”做好了充分的财务和运营准备。
下一步行动建议：如果你是电商、零售、餐饮或连锁门店企业的运营、供应链、财务或IT负责人，现在就可以做一件事，在九数云BI上创建一个免费账号，把你的电商平台和ERP数据源接进去，花30分钟跑一遍预置的库存分析模板。你会立刻看到当前库存水位与建议安全库存之间的实际差距，以及哪些SKU正处于风险区。如果你需要更定制化的方案，可以联系九数云的数据解决方案团队，我们有服务数百家企业的经验可以直接复用。
库存这件事，永远没有完美的答案，但有越来越好的方法。
去年双十一我按教科书公式算安全库存，结果缺货赔了违约金，积压又亏了仓储费。到底该调整哪些参数才能同时扛住脉冲和防止滞销？
双十一的脉冲需求不能套用常规的周期模型。我的经验是三个参数必须动态调整：一是需求波动率σ要乘以脉冲系数（建议预热期1.2、爆发期1.8、返场期1.5），二是服务水平Z值不要追求99%，95%就能平衡成本和体验，尤其低毛利品。三是补货提前期L要拆成三段：集货期、干线运输、末端分拣，每段分别评估风险。
实际操盘时，我把这些参数做成一个Excel模拟器，去年用后缺货率从12%降到3%，滞销库存减少了40%。注意：脉冲系数要根据自家品类历史数据微调，比如服装类波动大，食品类相对小。
都说用去年双十一数据做基准，但我的品今年销量翻了三倍，直接套用肯定失真，有没有更靠谱的预测方法？
直接复制去年数据是典型误区。我踩过的坑是：忽略了大促节奏变化（比如预售期从15天压缩到7天）和流量结构变化（直播占比从20%涨到60%）。正确做法是三步：①清洗去年数据，剔除异常促销单和大额批发单（我常用箱线图处理）；②找对标品近期增长率，比如今年平时日销是去年的1.5倍，那脉冲峰值按这个比例缩放；
③引入“拉力因子”，根据预售定金、收藏加购、电商平台给的流量预估，建立线性回归公式。我去年用这个组合方法，预测峰值误差控制在±8%以内，比纯历史法提高30%。核心教训：别迷信系统自动预测，人工介入调整那些半衰期短的信息（比如竞品限时券）极其重要。
公司SKU有两千多个，每个都单独设安全库存太费劲，但一刀切又怕热门品断货冷门品积压，该怎么办？
必须差异化，而且原则是“二八法则+动态分档”。我按贡献度把SKU分成S/A/B/C四档：S类（占总销额前20%）用精细模型，安全库存设为日均需求×季节系数×脉冲倍数×1.5倍服务冗余；A类（20%-50%）用简化版，设“底线库存+自动补货点”；B类用历史中位数加固定缓冲；
C类合并成类目级安全库存，不单独管理。实施时我用了四色预警看板，绿黄橙红对应不同补货动作。这个方案在去年双十一效果显著：S类缺货率0.5%，而C类即使偶尔缺货也不影响整体营收。关键判断：差异化不是复杂度高，而是要把管理精力集中在创造80%价值的20%SKU上。
双十一流量波动太快，人工补货根本跟不上，系统自动补货又经常拉错数量，怎么设置才能又快又准？
完全信赖系统自动补货是灾难。我的做法是“半自动+熔断机制”：系统负责计算建议补货单并推送到审批端，但保留人工确认的否决权。具体配置要点：①设定补货触发频率为每小时一次（爆发期改为15分钟间隔），计算窗口用过去4小时而不是1天，这样反应快；
②安全库存公式里加入“动态缓冲系数”，如果最近1小时订单量超过预测的200%，系统自动上调缓冲层20%，同时发预警；③强制生效前必须人工复核关键SKU（比如利润前50的）。我用这个流程，去年双十一补货响应时间从2小时缩短到20分钟，人为错误减少了90%。
专家判断：系统擅长执行固定规则，但脉冲场景下规则本身需要人根据实时情势（如物流爆仓、限流政策）调整，所以一定要设“熔断开关”让人可以覆盖系统。
读者评论
作为一家年GMV 5000万的电商公司老板，这篇文章直接戳中了我去年的痛点，缺货损失和清仓积压几乎对冲掉了所有利润。文中提到的“极限承压测试模型”概念很新颖，与传统模型相比，它承认预测有极限，转而构建抗冲击能力。我已经开始用九数云BI搭建自家看板，希望这3000字不只是纸上谈兵，3月大促就能见分晓。
我是供应链经理，对文中“补货周期的滞后效应在脉冲期被急剧放大”这一节特别有共鸣。去年双十一我们就是大促当天看销量猛增，紧急补货却因物流爆仓慢了10天，导致大量缺货，而补到的货只能在返场期打折清货。作者用实测数据说明安全库存必须动态调整，而不是一个静态数字，这让我决定这周就启动九数云BI的免费试用。
作为运营，文章里“不要以减少缺货率为唯一目标”的逻辑点醒了我。过去老板总催着多备货，导致活动结束还有200万的库存要清，最后算总账反而亏了。文中的三阶段动态区间策略让我看到了希望，如果真能在预热期用低水位试水、爆发期启动弹性库、返场期快速回调，就能避免盲目复制历史决策。技术细节已经传给我们IT部门评估落地性了。
从一个财务视角看，这篇文章最硬的观点是把“缺货成本+持有成本+清仓损失”做成加权模型来调节安全库存水位。这比供应链单方面喊“不要缺货”或者运营要求“多备货”都要科学得多，能避免预算被打乱。我打算把九数云BI这套打分逻辑引入到我们公司的备货审批流程中，让三方坐在一起调参数，而不是各说各话。
我是一家规模不大的母婴品牌的数据分析师，读完后最大的收获是理解了为何传统正态分布模型频繁崩溃。文中用日常和大促需求分布对比图清晰说明了两者属于完全不同的统计分布，强行混用就像用尺子测距离。我会参考作者分享的“分阶段需求分布拟合”思路，在九数云BI上做日常促销双十一三轨独立模型，先拿30个历史SKU做验证测试，看看准确率提升是否真如文中说的37%。