电商库存为库存设定“半衰期”，自动衰减可用承诺
凌晨2点17分，我被值班同事的电话吵醒，“爆款SKU 27183超卖了47单，客服已经在道歉了，但系统的可用库存还显示有货。”检查后台发现，晚上11点后OMS最后一次库存同步停留在23:07，之后WMS完成了两波出库，但OMS的缓存数据直到凌晨2点都没刷新。展示给消费者的数字是“186件”，实物只剩139件。这47单注定要发不出。挂断电话后我打开系统日志，那条23:07的库存记录像块墓碑一样躺在那里。这件事直接促使我开始认真思考一个问题：为什么我们默认一条库存记录可以永久有效？为什么不能像对待鲜奶一样，给库存数据一个清晰的保质期，一旦过期就自动降低其可信度，从而减少对外承诺？这就是“库存半衰期”模型的现实起点。核心结论是：库存数据天然会随时间贬值，承认这种贬值并主动管理“可用承诺”的置信度，比追求虚无缥缈的“实时准确”更具工程价值。下面展开讲。
从业10年，我问过至少50个同行一个问题：你们认为自己的库存数据实时吗？说“实时”的人里，超过80%在追问具体场景后会改口说“秒级延迟”。但秒级延迟在高并发场景下足够致命。以2019年双11当天为例，某头部服饰品牌在头一小时内产生了12万笔订单，OMS、WMS、ERP之间的数据往返延迟平均为2.7秒，峰值达到11秒。在11秒的窗口期内，一批商品可能被多个订单同时锁定，超卖是数学必然。更麻烦的是，绝大多数中小商家用的标准化OMS根本无法支撑实时库存回传，普遍采用每分钟或每5分钟批量同步策略。以5分钟为间隔，一条库存记录从“被扣减”到“被展示为已扣减”，最坏情况会延迟近10分钟。10分钟里，一个流量爆款可以卖出上百单。这些单子都会变成超卖客诉。
很多从业者混淆了“仓库里实际有多少”和“我应该对外承诺多少”这两个概念。实物库存是定数，可用承诺是变数。可用承诺 = 实物库存 × 置信系数。置信系数取决于数据新鲜度、补货通道状态、退货池水位等。传统的做法要么把置信系数设成100%（盲目乐观），要么设成一个固定的折扣（比如永远只展示80%库存），这都粗糙且反直觉。更科学的做法是让置信系数随数据年龄自然递减，这就是半衰期模型。
下图展示了我从不同规模商家后台拿到的实际数据延迟分布抽样，可以看出延迟超过3分钟的订单比例惊人。
安全库存应对的是需求波动和补货不确定性，但它假设所有库存数据在刷新前都是可信的。可现实的“数据腐败”不是平滑的，而是骤降，一条库存记录可能在系统显示有货的下一秒就变成了零（因为被其他渠道出库了）。安全库存无法阻止在刷新间隙产生的超卖。半衰期模型则从时间维度主动降级，把“不可知的风险”变成“可计算的衰减”，系统预测能力提升一个台阶。
放射性元素的半衰期指原子核衰变到一半的时间。在库存场景，我把“库存半衰期”定义为：一条库存记录的“置信度”衰减到50%所需的时间。注意，衰减的不是库存数量本身，而是我们对这个数字的信任程度。一条刚被WMS成功扣减并写回OMS的记录，置信度接近100%，我几乎可以确定仓库里确实还有这么多。1小时后，如果期间没有新的同步，这条记录可能已经落后于实际出库了，我可能只愿意相信它原有数字的80%。两个半衰期之后，我只敢相信25%。这种指数衰减速比线性降级更贴近现实，因为出库速度通常不是线性的，且后续订单的增量也在加速消耗库存。
我们内部在构建半衰期模块时用的是一段非常简单的代码，核心是时间差乘以衰减因子。具体公式：
可用承诺库存 = 原始库存数字 × e^(-λ · Δt)
λ = ln(2) / T½
其中 T½ 是设定的半衰期（分钟），Δt 是距离上一次库存同步的分钟数。
实际落地时，考虑到大多数电商系统的前端缓存策略，我们通常不使用指数函数的浮点运算，而是预计算一张“置信度查找表”，把不同Δt间隔的折扣系数硬编码进去。原因是：避免每次请求都计算e指数，响应性能和业务理解成本都更低。下表是我们为一个客户预置的标准衰减矩阵（T½ = 30分钟）：
重要的事说三遍：半衰期模型不修改原始库存数字，只修改“可用承诺”。原始库存数字保留供后台人员做采购、调拨使用；前台展示给消费者、甚至给客服系统接单的，必须是经过衰减后的可用承诺。很多团队第一次实施时直接覆盖了原字段，导致仓管看到“怎么库存变少了”的误报，这是要避的第一个坑。原始与可用必须分开存储。
半衰期是承认“同步不够快”并做补偿的手段，而不是偷懒不做同步的理由。我曾见过一个团队把半衰期设成5分钟，同时仍然用15分钟批量的同步机制。这就产生矛盾：数据每15分钟才刷一次，但半衰期5分钟意味着一条记录等到下一次同步时，置信度已经降到12.5%了，可用承诺几乎归零。这直接导致大量可以正常履约的订单被系统拒绝，营收损失。正确的做法是：半衰期设定的周期应该与数据同步频率对齐，或者比同步周期略长。比如每5分钟同步一次，半衰期设为10-15分钟比较合理，确保数据在两次同步中间仍然有较高的置信度。
这是最隐蔽的坑。当发生超卖或者售后换货时，WMS可能产生负库存记录（比如系统显示有3件，但实际捡货后发现是残次品，扣回去变成-1）。负库存记录进入半衰期模型会发生什么？原始数字是-1，衰减后可用承诺变成-0.5或者-0.25，如果前端代码不处理负数，就会展示为0或显示异常。更严重的是负值会向衰减后的更负方向走，导致系统“休克”。我们的处理方式是增加一个clip步骤：任何原始库存数字为负数时，直接返回可用承诺为0，不经过衰减公式。同时触发异常告警，由人工介入。
不同品类的销售速度、补货频率差异巨大。生鲜的可用库存半衰期可能只有15分钟，数码配件是2小时，预售商品可能是24小时。我见过一家全品类商家把半衰期统一设为60分钟，结果是生鲜类目可用承诺严重虚高（超卖），而预售类目可用承诺过低（压制销量）。所以必须要按SKU的分组来配置，至少按照“发货时效+补货周期”分层。下面是我整理的一个常见分层参考：
| SKU类型 | 典型特点 | 推荐半衰期（T½） | 同步频率建议 |
|---|---|---|---|
| 高动销标品（日化、零食等） | 日销量大，补货高频（每日或隔日） | 10-20分钟 | 1-3分钟 |
| 低动销长尾品 | 月销量少，库存稳定 | 2-6小时 | 15-30分钟 |
| 预售/定制商品 | 库存锁定后不频繁变动 | 24-48小时 | 按需同步，或每日一次 |
| 生鲜/短保品 | 保质期短，出库随机性强 | 5-10分钟 | 实时推送（秒级） |
| 海外购/跨境 | 补货周期以周计 | 6-12小时 | 每小时一次 |
有些团队上线半衰期模型后就放松了对同步优化、库存纠错、人工干预的投入。这是本末倒置。半衰期只是把“不可预测的超卖”变成了“可预测的可用承诺降级”，但降级本身仍有成本，可用承诺低了，销量损失就大。我们曾经做过一个测试：将半衰期从30分钟收窄到10分钟后，当日超卖率下降了62%，但当日销量也下降了11%。这是必然的取舍。因此半衰期不能孤立使用，必须搭配动态调参、A/B测试、实时告警等机制。
我总结了一个决策模型，基于三个因子：
将三个因子的得分代入下面这个矩阵（我们内部叫“DTR打分卡”），阈值清晰。
手动给每个SKU设参数是不现实的，尤其SKU动辄上万。我的做法是：先按DTR得分对SKU聚类，同一聚类内的SKU共享一个半衰期。然后通过在线A/B测试，对不同聚类探索最优值。具体来说：
这套流程在一个年GMV 30亿的客户那里运行了6个月，超卖率下降了41%，而销量损失只增加了3%，净收益非常显著。
主营坚果零食，SKU约1200个，日订单量高峰期突破2万。问题：每日因库存延迟导致的超卖客诉在150-200单，客服团队需要花大量时间处理补发或补偿。库存同步频率为5分钟一次的定时脚本。我们介入后，首先分析了他们的数据表现：
我们将1200个SKU分为3类：高动销（日均订单>100）、中动销（30-100）、低动销（<30）。分别设定半衰期15分钟、30分钟、60分钟。同步频率对高动销改为实时推送（使用Webhook），中低动销保持5分钟轮询但增加了缓存旁路策略。同时保留了原始库存与可用承诺两个字段，前端展示实时衰减后的数字。实施过程出现了我前面说的“负库存”问题，通过增加clip逻辑修复。另外，我们设计了一张置信度查找表，避免每次计算的开销。
上线后跟踪了30天，核心指标如下：
除了数字，运营团队的工作方式变了：之前每天早晨需要花1小时人工核对库存差异并修正，现在半衰期自动压低了异常数据的可信度，系统很少展示明显错误的数字，核对工作量降为每周20分钟。而客服团队从道歉补发中解放出来，更多精力去处理真正的售后问题。这件事让我相信，半衰期模型的核心价值不是消灭超卖，因为超卖在电商里永远不可能为零，而是把不确定性从人的大脑里转移到系统的计算层，让人更少做判决，更多做决策。
没有自研发能力，依赖第三方OMS。大多数SaaS不提供半衰期系数设定，怎么办？我自己用过的方法是“人肉模拟半衰期”：在ERP里新增一个自定义可用库存字段，写一个定时脚本（甚至用vba调用API）每小时计算一次，将原始库存乘以一个手动配置的衰减系数。虽然粗，但成本极低。建议：先尝试从最爆款的3-5个SKU开始，每天在高峰期前手动打折，效果立竿见影。积累信心后再谈自动化。
取舍：人力成本低但精度差，可能错失高峰期的部分订单。适合试水。
推荐搭建一套简易的中间层，在OMS和前端展示之间加一个“承诺管理服务”。这个服务维护每个SKU的衰变参数，通过查找表实时给出可用承诺。同步频率优化到分钟级。需要投入约1-2名开发人员2周时间。关键点：必须保留衰减前的真实库存给采购、仓库使用，展示系统只消费衰减后的承诺库存。
取舍：需要开发投入，但可适用大多数SKU。如果SKU超过5000，需要按分组配置，不宜逐SKU设置。
已经在做库存预测、需求感知、数据中台。半衰期模型可以作为“数据可信层”的一个模块嵌入。另外可以探索更精细的参数，比如基于实时销量趋势动态调整λ值。如果某商品销量突然激增，系统自动将半衰期从30分钟缩为10分钟，直到销量回落。这种动态策略我们在一家服饰客户验证过，超卖率下降了58%，且销量损失控制在0.8%以内。
取舍：系统复杂度高，需要实时特征平台支持。适合技术成熟、库存节奏快的公司。
回到那个凌晨的电话。如果半衰期模型当时已经上线会怎样？系统会感知最后一条库存同步已经过去了3小时，可用承诺自动降低到原始数字的12.5%（假设T½=60分钟），前台展示从186件变成23件（原始139件，12.5%的置信度，约等于17件，取整）。超卖的47单中，至少有30单会因为在页面看到库存不足而被消费者放弃下单，剩下17单仍然可能超卖（因为置信度仍有误差），但规模已大为降低。配合实时告警，我们可以在2分钟内手动关闭链接，不会让超卖继续滚雪球。
库存管理这个词，我认为正在被一个更广的概念替代，“承诺管理”。你承诺给消费者的每一个“有货”，背后都绑着一个置信度。承认数据会变质，主动给承诺设保质期，是成熟供应链的核心能力。半衰期模型不是一个炫技的算法，它是一句提醒：如果你不能做到百分百实时，就不要假装数据永远新鲜。
下一步你可以做什么？
如果你已经跑通了半衰期，欢迎来找我聊聊踩过的更深的坑。在库存数据治理这件事上，没有一劳永逸，只有持续降熵。
我在电商公司做运营，经常听技术同事提“半衰期”，听起来像是物理概念。我知道安全库存，但半衰期是另一种算法吗？它到底怎么管库存的？跟传统方法比好在哪？
先说我自己的经历：2019年我在一家日销5000单的化妆品电商负责供应链，那时我们用的是固定安全库存法，每个SKU设一个最低水位，低于就补货。但问题来了：爆款SKU的库存数据在促销期间严重滞后，OMS显示有货但仓库实际已空，导致超卖。
后来我接触了“半衰期”概念，它本质上不是管实物库存，而是管“可用承诺”的置信度。传统安全库存关注的是“仓里还有多少”，半衰期关注的是“这个库存信息还能信多久”。举个例子：实物库存100件，但系统最后一次更新是2小时前，我把它的置信度设为60%，那么对外承诺就是60件。
这种做法的本质区别在于：它承认数据天生有延迟，并主动对陈旧数据做惩罚性降级，而不是假设数据永远准确。我落地后的效果是：超卖率从4.5%降到0.8%，而且客服客诉减少70%。所以半衰期不是取代补货策略，而是优化销售端的承诺展示。
我知道要给不同商品设不同的衰减速度，但具体数值怎么定？是按销量分还是按补货周期分？有没有一个现成的表格可以直接抄？我负责的SKU有300多个，不想一个一个试。
我踩过最大的坑就是所有SKU用同一个衰减周期。2020年夏天我们卖冷饮和T恤，冷饮保质期短且补货频率高，T恤动销慢且补货周期长。结果一刀切用了2小时半衰期，冷饮因为库存信息频繁更新，置信度几乎不降，没问题；但T恤因为每天只更新一次，2小时后置信度跌到50%，导致很多顾客看到库存不足就不下单。
后来我按两个维度做矩阵：补货频率（高/中/低）和动销率（高/中/低），给出9个档位的T值（半衰期小时数）。具体表格如下：高动销+高频补货设为1小时（如生鲜、爆款日化），中动销+中频补货设为4小时（如标准家电），低动销+低频补货设为24小时（如配件、预售品）。
这是经过两轮A/B测试优化后的经验值：第一轮试了2/4/8小时，超卖率降了但展示库存过低损失了12%的转化；第二轮调成1/4/24小时，转化损失降到3%，超卖率稳定在0.5%以下。注意：这个矩阵每季度要重新校准，因为动销率会变。建议先用Excel跑模拟，再上线。
我们团队上线了半衰期模型，代码也写好了，衰减函数用的指数衰减，参数也调了。但运行一周后超卖率比之前还高，客诉也多了。是不是这个模型本身有问题？还是我们哪里用错了？
你遇到了典型的“伪灵药效应”。我2021年帮一家母婴电商做咨询时也见过同样的问题。拆解下来三个坑最常见：第一，把数据采集时间当成了数据产生时间。你的系统记录"库存更新于10:00"，但实际出库发生在9:55，只是系统延迟了5分钟。
半衰期应该基于"业务事件发生时间"而非"系统落库时间"，否则衰减会滞后。第二，没有处理负库存。当发生超卖或者退货时，库存可能瞬间为负，半衰期模型如果直接拿负值做衰减，置信度会变成负数，导致承诺量异常。正确的做法：在衰减前先对负库存做"归零或加总安全缓冲"处理。第三，衰减粒度太粗。
你可能按整个仓库设半衰期，但仓库里有热区（拣货频率高的货架）和冷区。热区的库存信息更新快，半衰期应该短（比如30分钟），冷区的信息更新慢，半衰期反而要长（比如6小时），否则冷区的货会因长期不更新被过度衰减，造成库存假性短缺，而超卖往往发生在热区。我们当时调整后，把客户超卖率从3.2%降到1.1%。
所以先检查这三个地方，大概率能解决问题。
我老板听说半衰期模型能降超卖，让我们全品类推广。但我直觉觉得不是所有商品都适用，像我们做高客单价定制家具，库存数据本来就很准，有必要加衰减吗？求指点。
半衰期模型不是万能药，我在四家公司推过，经验是：三种场景效果极其显著，两种场景反而有害。先说最优场景：1）预售+海外购，补货周期超过7天，库存信息一旦过时误差巨大。我们用半衰期后，一款日本化妆品的超卖率从15%降到2%。
2）全渠道库存共享（线上线下一盘货），门店POS与电商系统同步往往有小时级延迟，半衰期能在数据同步间隙防止超卖。3）大促秒杀场景，流量瞬间爆发，缓存数据极易失效，半衰期能快速降级承诺保护库存。
不适合的场景：A）高客单价定制化商品（如定制家具），库存数据往往人工确认且实时性高，加衰减反而会人为压低销量，我们用A/B测试发现收益为负。B）纯直营且系统实时性极高（如自研系统T+0同步），半衰期带来的保护很小，但会造成操作复杂度提升，得不偿失。
结论：先跑一个月A/B测试，对比有/无半衰期的超卖率和转化率，如果超卖率改善不足20%且转化率下降超过5%，就不适合。别全量推广，先选典型品类验证。
读者评论
文章提出的“库存半衰期”概念很有启发，用指数衰减模拟数据置信度确实比固定折扣更科学。但实际落地中，中小商家同步频率低，半衰期设太短会导致可用承诺过低影响销量，设太长又无法控制超卖，平衡点需要精细化调参。
作为运营，我最关注那个DTR打分卡。高频变动的SKU哪怕毛利高也要压短半衰期，这一点颠覆了传统“高价品放宽”的直觉。但文中提到A/B测试滚动优化，对团队技术能力要求不低，小商家未必能执行。
案例中的超卖率下降41%、销量仅损失3%很有说服力。但负库存clip处理这个坑确实隐蔽，负值进入衰减模型会雪崩，如果不加保护，系统可能直接崩溃。建议文中强调预处理步骤。
我认为半衰期不能替代同步优化，这点很关键。有些团队把模型当万能药，放松了技术基建。实际上，缩短同步周期、改进缓存刷新机制才是根治，半衰期只是权宜之计。
不同品类半衰期差异巨大，生鲜5-10分钟、预售24-48小时，统一参数就是灾难。表格里的推荐值很有参考价值，但具体数值应该基于历史数据动态调整，而不是静态设定。