去年下半年我帮一个做家居品类的卖家复盘旺季表现，他给我看了一张自己画的销量趋势图，结论是"这个爆款在 10 月中旬开始衰退，应该砍掉"。我打开他的后台数据看了一眼，发现 10 月 12 日到 10 月 26 日之间，这个 SKU 的 FBA 可售库存一直是 0，补货的 1200 件直到 11 月 3 日才完成上架。也就是说，那条所谓"衰退曲线"根本不存在，它是被断货硬生生切出来的一段空白。这个案例让我意识到一个问题：绝大多数亚马逊卖家在做趋势观察时，默认自己看到的是"需求曲线"，但实际上看到的往往是"库存约束下的可售曲线"。
这两者之间的差距，足以让一个正确的选品判断变成错误的清仓决定。
这篇文章我想系统拆解一件事：在亚马逊软件业务的技术栈里，库存管理模块和趋势观察模块为什么不是两个平行系统，而是上下游关系。我会先给出结论，再用我自己经手的几个案例说明这个结论是怎么被验证的，然后讲清大多数人踩的四个误区、我判断这类问题的三层采样模型，最后给出不同规模卖家可执行的行动方案和取舍逻辑。文中会以数跨境（https://shukuajing.jiushuyun.com/?
utm_source=seo&utm;_plan=est&utm;_unit=gys）作为外部趋势数据源的具体例子，说明库存数据怎么和外部趋势数据做联调。
如果只能记住一句话，我希望是这句：库存管理决定了趋势观察的采样频率和样本质量，它是趋势系统的采集层，而不是它的下游执行层。很多人把库存管理理解成"卖出去之后怎么补货"的运营动作，但在数据链路里，库存状态其实是在需求被记录之前就已经介入的一道过滤器。
一个消费者在亚马逊搜索页看到你的商品、点进去、加购、下单，这一整套行为只有在"可售库存大于 0"的前提下才会变成一个可以被统计的事件。库存为 0 的时候，消费者依然有需求，但系统里不会产生任何记录。这就是统计学里说的截断数据（censored data），只不过在电商场景下，截断它的不是统计方法，而是库存水位。
我做过一个粗略的对照测算：在一个有稳定广告投放的 SKU 上，把断货期间的日均自然搜索流量和断货前后的数据做对比，流量并没有下降，加购率也没有明显下降，唯一归零的是转化事件。这意味着需求仍在，只是被库存闸门挡住了。
这一点经常被忽略。很多工具的后台报表是每小时刷新一次，看起来数据很"实时"，但如果你的库存数据是从 FBA API 每 6 小时拉一次、海外仓的库存靠人工每周导一次表格，那么你的趋势模型实际上是在用一个 6 小时甚至 7 天的采样周期去描述一个按小时变化的需求过程。报表刷新频率是显示层的参数，库存回传频率才是采集层的参数，两者完全不是一回事。
我见过最极端的例子是一个卖家，自发货仓的库存靠运营每天早上手填一个 Excel，填完之后再导入工具。结果是这个 SKU 在趋势图上呈现出一种规律的"锯齿状"波动，每 24 小时一个峰谷。他一度以为这是某种周期性需求，后来发现那只是人工填表的时间戳造成的采样伪影。
这是一个我反复验证过的判断：无论你的选品模型多先进、外部数据源多丰富，趋势判断的准确率上限都被库存数据质量锁死。原因很简单，外部数据告诉你"这个品类在涨"，但只有库存数据能告诉你"你自己的这条曲线为什么长这样"。
外部趋势数据描述的是市场，内部库存数据描述的是你在市场里的采样姿势。采样姿势不对，市场再涨，你的曲线也可能是平的甚至向下的。
要理解这个绑定关系，得先看亚马逊卖家的库存结构到底有多复杂。这跟国内电商的库存模型完全不是一个量级，复杂度直接决定了数据链路的脆弱点在哪里。
一个中等规模的亚马逊卖家，库存节点通常包括：FBA 在库可售、FBA 待上架、FBA 不可售（客户退货待处理）、海外仓在库、国内仓在库、在途海运/空运、以及 FBA 与海外仓之间的调拨中。同一批 3000 件货，在数据系统里可能被拆成 6 条以上记录，每条记录的更新频率和更新方式都不一样。
FBA 的数据靠 API 同步，通常几小时内可见；海外仓取决于服务商是否提供接口，有的提供，有的只能给一份日报表；在途货物往往靠人工登记提单和预计到港时间；退货待处理这一块最难，因为它涉及亚马逊的退货处理周期，从买家发起退回到商品重新变成可售，中间可能有 3 到 15 天的黑箱期。
这是我在做数据对齐时踩过的最大的坑。以一笔订单为例，它至少涉及四个时间点：买家下单时间、库存扣减时间、订单入账时间、如果发生退货还有退货上架时间。这四个时间在亚马逊的系统里并不是同一时刻。
库存扣减可能在下单后几分钟内完成，但订单数据进入你的 ERP 或者分析工具，可能是 2 小时甚至第二天。如果你用订单表的时间戳去关联库存表的时间戳，就会出现"某天库存突然减少但当天订单为 0"的鬼数据。这类错误在趋势模型里会表现为一个虚假的尖峰或深谷。
我处理过一个案例，某 SKU 在趋势图上每隔 7 天出现一次销量小高峰，排查了两周才发现，原因是数据同步任务设定在每周一凌晨执行全量对账，对账时会补录前一周的延迟订单，全部打在周一这个时间戳上。
做欧洲站的卖家通常有 5 到 9 个站点，北美至少 3 个。同一款产品在不同站点的库存是独立管理的，但从产品生命周期的角度看，它是一个整体。如果你只看单站点的趋势，会看到很多"局部衰退"；如果把多站点合并看，可能是一个整体平稳甚至上升的产品。
更麻烦的是欧洲的泛欧计划，库存会在各国之间自动调拨。这意味着德国站的库存下降不一定是德国需求上升，可能是系统把货调去了法国。如果你把这种调拨当成需求信号，补货决策就会严重失真。
第一个案例就是开头提到的家居卖家，断货 14 天被读成产品衰退，他准备清仓的时候我拦下来了。补货上架后两周，这个 SKU 的日均销量恢复到断货前的 92%，证明需求基本没变。
第二个案例相反，是一个做厨房小家电的卖家。他在 9 月提前压了三个月的货到 FBA，结果 10 月的销量曲线一路向上，他判断这是一个爆发性趋势，追加了第二批订单。实际情况是，那波增长里有相当一部分来自于他自己的站内秒杀和优惠券，以及一次竞品断货带来的流量溢出。补贴停掉、竞品恢复供货之后，销量回落到原来的 40% 左右。
第三个案例最隐蔽。一个服装类卖家发现某款式的退货率从 8% 涨到 19%，同时销量在涨。他的工具把销量和退货分开统计，趋势模型只看销量，于是判定这是增长款。但把退货率折算之后，这个款式的净销量其实在下降。问题出在退货库存没有被及时纳入可售库存，这批货在系统里既不算已售也不算在库，成了一笔"幽灵库存"。
这四个误区我在不同卖家身上反复见到，它们看起来都是常识判断，但每一条都会系统性地扭曲趋势结论。
这是最根本的一条。销量是需求经过库存约束、价格约束、流量约束之后的结果变量，它是一个被多重条件筛选过的量。在库存充足、价格稳定、广告投放不变的情况下，销量可以近似看作需求；一旦任何一个条件改变，这个近似就失效了。
更准确的说法是：销量是需求的下界，而不是需求的估计值。真实需求总是大于或等于观测到的销量，缺口就是在断货、限购、涨价期间被压抑掉的那部分。做趋势判断时，如果你把销量直接当作需求，你会系统性地低估那些经常断货的爆款，同时高估那些靠补贴维持的伪爆款。
组织分工上确实常常这么分：库存归供应链，选品归运营。但在数据层面，这个分工是错的。选品决策依赖趋势判断，趋势判断依赖需求估计，需求估计依赖库存约束的还原。这条链路一旦被组织边界切断，选品团队拿到的就是一份未经还原的销量数据。
我见过的最健康的做法是，把"库存健康度"作为选品评审的一个前置指标。也就是说，在讨论一个产品要不要加大投入之前，先看它的历史库存健康度，判断它的销量数据是否可信。库存健康度差的产品，销量数据要打折看。
这是从传统零售带过来的思维惯性。在亚马逊场景下，周转天数过低意味着极高的断货风险，而断货的代价不只是那几天的销量损失，还包括 Listing 权重的下滑、广告质量分的下降、以及竞争对手趁虚而入抢走的自然排名。
我自己的经验区间是：对于稳定款，库存周转天数控制在 45 到 70 天比较合适；对于趋势上升款，可以放宽到 90 天；对于测试款，反而应该压低到 30 天以内，快速验证。这个分档不是拍脑袋，是考虑了海运周期、亚马逊上架周期、以及排名恢复周期之后的综合结果。
很多卖家认为，趋势观察就是看市场在涨还是跌，所以只要外部数据够全就行，自己内部的库存数据只是执行层面的东西。这个逻辑的问题在于，外部数据回答的是"这个市场值不值得进"，但回答不了"我现在进的姿势对不对"。
举个具体的例子。外部数据显示某个细分类目连续三个月搜索量上升，你决定加大投入。但如果你自己的库存数据显示，你这三个月里有一半时间处于断货状态，那么你过去的"市场表现"是被压制的，你无法判断自己在正常供货情况下能拿到多少份额。外部趋势给出的是机会大小，内部库存给出的是你的承接能力，两者缺一不可。
讲完误区和背景，我想给出一套我自己在用的判断框架。这套框架的核心思路是：把从真实需求到趋势结论的过程，拆成三层采样，每一层都有明确的失真来源和修正手段。
事件层采集的是最原始的业务事件，下单、取消、退货、入库、调拨、丢失、损坏。这一层的目标不是准确，而是完整和不重复。判断标准只有一个：每一个业务事件是否被记录了恰好一次，且带有准确的发生时间戳。
这一层最常见的故障是重复计数和漏记。重复计数通常来自多系统并行写入，比如 ERP 和工具同时从亚马逊拉订单，如果没有幂等设计，同一笔订单会被记两次。漏记通常来自接口失败重试机制的缺失，或者海外仓这类非标准数据源的传输中断。
我在这一层会做两件事：一是建立唯一事件 ID 规则，把亚马逊订单号、退货单号、入库单号作为主键；二是对每类事件记录两个时间戳，业务发生时间和系统入库时间。后者用来监控数据延迟，前者用来做趋势计算。
状态层本质上是一个重放过程：把事件按时间顺序依次应用，还原出任意时刻的库存状态。这一层的关键在于状态的维度设计。我建议至少拆分出五个维度：可售、待上架、不可售、在途、已锁定（被订单占用但未发货）。
很多工具的库存字段只有一个"库存数量"，这在单一节点场景下勉强够用，但一旦涉及多节点就会失效。因为在途库存不能用来满足当前需求，待上架库存也不能，只有可售库存能。如果把三者加总当成"总库存"来做趋势分析，你会严重高估自己的供货能力。
-- 库存状态还原的核心逻辑（示意） -- 按时间顺序应用事件，逐条推导库存状态 WITH events AS ( SELECT sku, node, event_time, event_type, qty FROM inventory_events WHERE event_time >= '2024-01-01' ), state_series AS ( SELECT sku, node, event_time, SUM(CASE WHEN event_type = 'inbound_available' THEN qty WHEN event_type = 'order_shipped' THEN -qty WHEN event_type = 'return_restocked' THEN qty WHEN event_type = 'transfer_out' THEN -qty WHEN event_type = 'transfer_in' THEN qty WHEN event_type = 'damaged' THEN -qty ELSE 0 END) OVER (PARTITION BY sku, node ORDER BY event_time ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW) AS available_qty FROM events ) SELECT * FROM state_series ORDER BY sku, node, event_time;
这段逻辑看起来简单，但在真实数据里会遇到大量边界情况：同一时刻的多个事件顺序如何确定、跨节点的调拨如何配对、退货商品从不可售转为可售的触发条件是什么。这些细节决定了状态层是否可信。
到了这一层，才轮到滑动窗口、季节性分解、异常检测这些常规方法上场。但我要强调一个顺序问题：必须先修正库存截断，再做趋势拟合。如果跳过第二步，直接对原始销量做拟合，模型会把断货期的零值当成真实需求，拟合出的曲线会严重偏离。
修正方法有两种。一种是需求上界法，把断货期的销量替换为"同店相似 SKU 在同期的人均需求 × 流量"，得到一个估计值。另一种更保守，直接给断货期打上标记，在趋势模型里做缺失值处理，不参与斜率计算。我一般建议的关键产品用前者、常规产品用后者，因为前者引入的估计误差也可能是系统性的。
（1）趋势计算一律使用业务发生时间，不使用系统入库时间。系统入库时间只用来监控数据健康度，不参与任何趋势指标的计算。
（2）跨节点调拨必须配对。调出节点和调入节点的调拨事件必须用同一个调拨单号绑定，在配对完成前，这批货只能计入"在途"，不能同时计入两个节点的在库库存。
（3）退货商品的状态转换必须有明确的触发事件。从"不可售"转为"可售"必须由亚马逊的重新上架事件触发，而不能由理论处理周期推算。我见过太多系统用"退货后 7 天自动转可售"这种规则，结果和亚马逊的实际行为严重脱节。
上面讲的是方法，接下来讲我实际怎么操作。我通常会把工作分成两步：先用外部趋势数据确定"市场层面发生了什么"，再用内部库存数据解释"我自己的曲线为什么长这样"。外部这一层，我常用的数据源之一是数跨境（https://shukuajing.jiushuyun.com/?utm_source=seo&utm;_plan=est&utm;_unit=gys），下面具体讲我怎么用它。
做任何趋势判断之前，我会先确认一件事：市场本身是在涨还是在跌。这一步的意义在于建立参照系。如果市场整体在涨而你的产品在跌，问题在产品或运营；如果市场整体在跌而你的产品持平，反而说明你的相对份额在提升。
这一步我会关注三类信号：类目整体搜索量走势、头部 Listing 的数量和排名变动、以及新进入者的数量。数跨境这类跨境数据平台的价值在于，它能把这些分散在不同站点的信号汇总起来，让你不必在多个后台之间来回切换。
需要说明的是，外部数据的价值在于提供参照，不在于替代你的内部数据。我会把它当成一个"坐标系原点"，而不是"答案本身"。
拿到市场基线之后，我会把自有 SKU 的销售曲线叠加到市场曲线上，然后逐段问一个问题：这段偏离是需求造成的，还是库存造成的？
判断方法很直接：把断货天数、促销天数、跟卖天数作为标记变量，在时间轴上标注出来，看销售曲线的每一个拐点是否能被这三个变量之一解释。如果某个拐点无法解释，那它才可能是真实的需求变化。
当需求曲线被还原出来之后，动作就很明确了。如果修正后的需求曲线平稳或上升，那么原来的"衰退"结论作废，应该做的是加快补货节奏，而不是清仓。如果修正后的需求依然在下降，那才是真的产品问题。
我在这个环节会做一张对照表，把每个 SKU 的观测趋势、修正后趋势、库存健康度、建议动作放在一起，作为决策依据。
| SKU 类型 | 观测趋势 | 修正后趋势 | 库存健康度 | 建议动作 |
|---|---|---|---|---|
| 断货干扰型 | 明显下降 | 基本持平 | 差（断货占比 > 15%） | 加快补货，暂不做清仓决策 |
| 补贴拉动型 | 快速上升 | 温和上升或持平 | 中（周转天数 < 30） | 逐步减少补贴，观察自然销量 |
| 真实增长型 | 稳步上升 | 同样上升 | 好（断货占比 < 3%） | 加大投入，放宽库存周转天数上限 |
| 真实衰退型 | 下降 | 同样下降 | 好 | 收缩采购，考虑迭代或退出 |
| 退货侵蚀型 | 上升 | 净销量下降 | 中（退货未及时入账） | 先修产品问题，暂停追加订单 |
我把过去两年经手的 60 多个 SKU 按库存健康度和趋势判断准确度做了一个分布观察，结果呈现出比较清晰的分层。库存健康度高的 SKU，趋势判断的准确率集中在 80% 以上；库存健康度低的 SKU，准确率普遍低于 50%，而且错误方向大多是"把平稳误判为衰退"。
方法讲完了，接下来分场景给建议。我按卖家规模和业务复杂度分成三类，每类的优先级完全不同。
这个阶段的卖家不需要复杂的库存系统，需要的是把最基础的几件事做对。我会建议按下面这个顺序来：
这四步做完，趋势判断的可靠性会有明显提升，而且几乎不增加成本。
这个阶段的核心矛盾是多节点数据不一致。我的建议是把重心放在数据链路的规范化上，而不是急着上算法。
这个阶段的问题已经不是数据能不能拿到，而是数据量太大导致信噪比下降。我会把重点放在分层治理上。
任何方案都有代价，我想把这几个取舍讲透，因为很多卖家在做技术选型时只看到收益，忽略了成本结构的不同。
库存数据要做到小时级同步，需要频繁调用接口，成本和复杂度都会明显上升。对于日销量在 100 单以下的 SKU，小时级同步几乎没有意义，因为单笔订单的波动远大于趋势信号本身。对于日销量上千单的爆款，小时级同步才有价值。
我的建议是按 SKU 分层设置同步频率，而不是全局统一。用 20% 的成本覆盖 80% 的关键 SKU。
颗粒度越细，看到的东西越多，但噪声也越多。按小时看销量，你会看到大量的随机波动；按周看，趋势清晰但反应慢。这是一个没有最优解的问题，只能根据决策周期来选。
判断标准是：数据的颗粒度应该匹配你的决策周期，而不是匹配你的技术能力。如果你的补货决策是按周做的，那么周级颗粒度就是合适的；如果你是按天补货的，那才需要日级甚至小时级。
自建的优势是灵活、数据完全自主，劣势是开发和维护成本高，而且需要持续跟进亚马逊接口的变化。采购的优势是开箱即用，劣势是数据结构固定，可能无法满足特殊场景。
我的判断分界线是：如果你的业务模式比较标准，采购更划算；如果你有特殊的库存结构（比如大量组合商品、定制化包装、多平台共享库存），自建的长期成本可能反而更低。但要注意，自建不是一次性投入，接口变更、数据量增长、人员流动都会带来持续成本。
多站点卖家常纠结的一个问题是：库存和趋势分析应该做成全站点统一视图，还是各站点独立。统一视图的好处是能看到全局，坏处是会掩盖站点之间的差异；独立分析的好处是精细，坏处是看不到跨站点的联动。
我的做法是双轨并行：全局视图用于战略层判断，比如这个品类整体要不要加大投入；单站点视图用于执行层判断，比如这个站的库存应该补多少。两个视图用同一套底层数据，只是聚合维度不同。
| 取舍维度 | 倾向 A 方案 | 倾向 B 方案 | 分界判断依据 |
|---|---|---|---|
| 同步频率 | 小时级同步 | 日级同步 | 单 SKU 日销量是否超过 300 单 |
| 数据颗粒度 | 日粒度 | 周粒度 | 补货决策的执行周期 |
| 建设方式 | 自建 | 采购 | 是否存在非标准库存结构 |
| 分析视图 | 全局统一 | 单站点独立 | 决策层级（战略 or 执行） |
回到最初那个问题：库存管理为什么影响趋势观察？我的答案是，因为它决定了需求被记录的方式。趋势观察想还原的是真实需求，而真实需求在变成可观测数据之前，必须穿过库存这道闸门。闸门开多大、什么时候开、记录是否及时，全都写在了库存数据里。
我想强调三个在这场拆解中反复出现的判断。第一，销量是需求的下界，不是需求的估计值，任何直接用销量做趋势外推的做法都隐含了"库存充足"这个强假设。第二，库存数据的质量决定了趋势结论的置信度上限，这个上限不会因为算法先进而提高。第三，多节点库存的不一致是趋势噪声的最大单一来源，比促销干扰和竞品溢出加起来还要严重。
如果这些判断成立，那么对亚马逊软件业务的评估标准也应该随之调整。评价一个库存管理模块，不应该只看它能不能生成补货建议，而应该看它的数据是否可以被趋势模型直接消费，事件结构是否完整、时间戳是否可靠、状态维度是否拆分清晰、多节点是否一致。评价一个趋势观察模块，也不应该只看它的图表是否好看，而应该看它有没有能力识别库存截断并做修正。
下一步可以这样做。如果你现在手上就有正在运营的 SKU，挑三个你最关心的，去后台导出过去 12 个月的每日可售库存和每日销量，把它们叠在一张表里，标出所有库存为 0 或接近 0 的日子。然后问自己一个问题：如果把这些日子从趋势里剔除，我原来的结论还成立吗？我猜有相当一部分人会发现，自己过去某个"明智的决策"其实是建立在一段并不存在的曲线上。
这个动作花不了两个小时，但它能帮你避免的，可能是几万甚至几十万的库存损失。
我一开始也以为库存就是仓储和补货的事，跟看类目大盘、看销量趋势没多大关系。直到我按周拉销量曲线做选品复盘，发现同一个ASIN的曲线大起大落，跟竞品走势完全对不上，才意识到问题可能出在库存上。
钩子在“可售库存”这个变量上。平台展示的销量、BSR、排名都是结果指标，只要库存断供，销量会立刻掉，但需求可能压根没变。判断依据是：把时间轴按周切开，给每个ASIN标注期末可售天数和断货日期，如果销量下滑周与断货周的重叠率超过60%，这条下滑就该判定为供给问题而不是需求问题。
做法是先建一张周表，字段至少含周次、销量、期末可售天数、断货天数，再画“销量，可售天数”双轴图，肉眼就能分出哪些下跌是缺货造成的。只有剔除这类被污染的周，剩下的曲线才是可用于趋势判断的有效样本。
这是我最纠结的点。断货两周，销量掉了40%，团队里有人说需求不行要砍品，有人说只是没货，砍了会误伤。到底该按原始数据看，还是手工修正一下？
要剔，但不能直接删周，否则会把季节性和大促节奏一起删掉。可执行的做法是补一个“断货调整销量”口径：调整销量等于实际销量除以当周库存覆盖率，库存覆盖率等于实际可售天数除以7。举例，某周只卖了3天货、销量300件，覆盖率约0.43，调整后约700件，用这个值再去看趋势。
判断依据再补两条：连续断货超过14天的ASIN，任何趋势结论都要先打问号，等数据补齐再定；断货周要单独标注而不是静默处理，复盘时必须能看见“这里是因为缺货”。长期把断货率压在5%以内，趋势观察的稳定性会明显好转。
后台和各类软件里库存字段一大堆，周转、可售天数、冗余、库龄、绩效分，全看又看不过来。我只想知道做趋势判断必须保留哪几个，口径怎么定。
做趋势观察留四个就够：可售天数、库存周转天数、断货天数与断货率、冗余及超龄库存占比。口径要统一：可售天数按“期末可售库存除以近28天日均销量”算，用28天而不是7天，避免大促后日均虚高导致误判；周转天数按“平均库存除以销货成本”的口径，跨月对比时全程用同一套公式。
判断标准可以这样设：可售天数低于30天视为偏紧，此时趋势判断先怀疑供给；30到60天算健康；超过90天且动销率同步下滑，才更可能是需求端出了问题。冗余和超龄占比的抬头往往比销量下滑早2到4周出现，是很实用的领先信号。
我经常遇到这种情况：第三方软件显示某ASIN月销800，后台订单报表自己算出来是650，差了一大截。做趋势分析时被这个差异搞得很不踏实，不知道以谁为准。
先分清口径再谈信谁。差异通常来自四类：统计时区、是否含未发货和取消订单、是否含在途与预留库存、多站点是否合并计算。实操上选一个基准，以平台后台的订单或结算报表为准，因为它是最终结算口径；然后取同一时间窗、同一站点、同一币种去核对软件数值。偏差在5%以内可视为口径噪音，直接使用；
超过15%说明软件侧大概率是估算值（常见于用排名反推销量的模型，且取的是类目均值），这时只能拿它做横向排序，不能用它的绝对值去判断趋势拐点。更稳的办法是自己每周固定时间落一次原始订单快照，所有趋势结论都基于自己那份快照来算，外部工具只用来交叉验证。
读者评论
文中说库存回传频率决定采样频率，这点我深有体会。我们自发货库存靠人工每天更新，趋势图确实有明显的人为锯齿，后来改成一天两次同步才好看一点。不过对小团队来说，把FBA、海外仓、在途、退货全部做到小时级对齐，成本可能比选品本身还高，得先抓最影响决策的那个节点，别一上来就追求全链路实时。
把销量当需求下界这个说法我认同，但实际落地时很难还原断货期间的真实需求。广告点击和加购能代理一部分，可自然流量、复购和站外流量很难拆干净。另外退货库存的‘幽灵库存’问题，我们是用净销量加退货上架时间做修正，效果有限，因为退货上架时间本身就不可控。所以我觉得库存数据质量决定趋势上限是对的，但别把修正模型想得太精确。
多站点合并看趋势这点我有不同看法。欧洲泛欧调拨确实会干扰单站判断，但不同站点的需求节奏、竞争格局和税率都不一样，强行合并可能把局部真实衰退掩盖掉。我现在是单站点看库存约束，合并看生命周期，两个口径同时保留。还有周转天数不是越低越好，断货造成的Listing权重和广告质量分下滑，恢复起来比多备一点货的仓储费贵多了。