2023 年下半年，我接手了一个跨境家居品类的商品分析工作。接手第一周，我拉了一份在售 SKU 清单：1876 个在售商品，其中过去 90 天零销量的有 612 个，占了将近三成；这 612 个商品沉淀在海外仓的库存金额是 340 万元人民币，每个月的仓储费就要烧掉四万多。更让我意外的是，运营团队并不是"没数据"，他们当时有 11 张 BI 看板，从销量、广告、库存到退货，样样都有。真正的问题是：看完这些看板之后，没有人知道该砍哪个品、该给哪个品加预算、该在什么时间点对一个商品下判断。
这就是我今天想聊的核心问题：商品分析真正的难点不在"分析"，而在"管理"，你得先给每个商品定义一个状态，再让状态自动驱动动作。以生命周期为核心搭建分析系统，本质上是把"商品"从一张静态的表格，变成一个会自己流动的状态机。下面我把自己踩过的坑、验证过的判断逻辑、以及最终跑通的那套结构完整写出来。
在展开细节之前，我先把最核心的几个结论摆出来。如果你只记住一段话，那就是这一段。
我把商品分析的定义收窄成三个必须回答的问题：这个商品现在处于什么状态？这个状态下应该做什么动作？做完之后状态有没有变好？第一个是判定，第二个是触发，第三个是回流。
三者缺一，系统就退化成报表。只做判定不做触发，你得到的是一个漂亮的分类标签，运营看完点点头就关掉了；只做触发不做回流，你无法知道策略到底有没有用，下次还会重复犯错；只做回流不做判定，你连"效果"该跟什么基线比较都不知道。
我统计过自己待过的两家公司的看板数量：2021 年 4 张，2022 年 11 张，2023 年 23 张，2024 年 27 张。与此同时，我能追溯到的"因数据而改变的决策"每月大约是 6 到 8 次，四年几乎没有增长。更糟的是平均追溯耗时，从"看到一个异常"到"找到原因"，从 0.5 小时涨到了 9 小时。
原因不复杂：每加一张看板，就多一套口径，多一套口径就多一次对齐成本。看板是加法逻辑，决策是减法逻辑。当报表增长速度是决策增长速度的三倍以上，这套系统其实已经在制造噪声了。
我后来用一条很土的标准去审核每一张看板：这张图上的任何一个异常点位，能不能在 10 分钟内对应到一个具体的、有责任人的动作？如果答案是不能，这张看板就应该下线或改造。
用这条标准，我把 27 张看板砍到了 6 张，同时把 3 张改造成了"带动作提示"的形态。工作量少了一半，月度决策数反而从 7 次涨到了 19 次。这是我第一次真切感受到：商品分析的杠杆不在可视化，在于把数据接到动作上。
我把那半年的过程分成三幕来讲，因为每一幕都代表了一类企业最容易掉进去的坑。
最初的做法非常朴素。我拉了一张大表，让两个运营同事人工判断每个 SKU 处在引入期、成长期、成熟期还是衰退期，规则写在共享文档里：上市 60 天内是引入期，销量连续三个月环比增长超过 15% 是成长期，销量平稳且毛利率高于品类均值是成熟期，连续两个月下滑超过 20% 是衰退期。
第一周很顺利，1876 个 SKU 全部打标完成。第二周开始出问题：新品持续上架，老品状态持续变化，标签以每天三四十个的速度过期。到第三周末，我抽查了 200 个 SKU，发现标签与实际状态不符的有 58 个，错误率 29%。人工打标的真正成本不是第一次打标，而是持续维护。
第二个月我们换了个思路：既然标签会腐烂，那就先把状态"看"清楚。于是做了 12 张看板，覆盖销量趋势、广告投产、库存周转、退货原因、价格带分布等等。数据确实清楚了，但每周例会上运营主管问的问题始终是同一句："所以这周我该干什么？"
这句话把我点醒了。看板解决的是"是什么"，而商品运营每天面对的是"该做什么"。中间缺了一层：把状态翻译成动作的规则。没有这层翻译，看板越全，会议越长，决策越慢。
第三个月我们重做了结构。核心变化有三个：第一，阶段判定从人工改为规则引擎，每天自动跑一次；第二，每个阶段绑定一组"触发条件→动作"的映射；第三，所有执行过的动作在 14 天和 30 天两个节点回流效果，形成闭环。
上线三个月后，最直观的变化是：爆款衰退的识别时间从平均 23 天缩短到 6 天，积压库存金额从 340 万降到 168 万。但我觉得更重要的变化是会议形态，例会上讨论的不再是"这个品卖得怎么样"，而是"这个品被判成了衰退期，触发的清仓动作执行了吗，回流数据说明什么"。
在跟同行交流的过程中，我发现大家踩的坑高度重合。下面六个误区，我至少踩过四个。
这是最普遍的问题。很多团队做生命周期，产出物是一张"商品分类表"：这批是新品，这批是爆款，这批是尾货。分类表的问题在于它是静态的，而商品的状态是动态的、会回退的。
我遇到过真实的回退案例：一个香薰类商品在第四个月被判为衰退期，我们做了清仓；结果第五个月因为某个社交平台的达人视频意外带火，销量反弹了三倍，但库存已经清得只剩两百多件，白白错过了一个窗口。生命周期不是一条单向的直线，而是一个允许回退、允许跳跃的状态图。你的系统如果只支持"一路向前"，就会在回退场景上连续犯错。
我见过把"连续两个月销量下滑 20% 判定为衰退"这条规则应用到所有品类的做法。结果家具类商品被大面积误判，这个品类天然有季节性，两个月下滑 20% 完全正常；而饰品类的真实衰退可能表现为"下滑 8% 但复购率腰斩"。
正确的做法是分品类维护阈值。阈值的颗粒度应该匹配决策的颗粒度，而不是匹配系统的开发便利度。如果品类经理是按一级类目分工的，阈值就按一级类目设；如果按渠道分工，就按渠道设。先问决策怎么分工，再定阈值怎么分。
这个误区通常表现为"我们要做一个商品数据中台"。我参与过一次这样的项目，前期花了四个月做数据治理和建模，等到要接业务的时候，发现没人说得清到底要支持什么决策。项目最后变成了一个数据很全但没人用的平台。
我的建议反过来：先用手工方式跑通一条完整的决策链路，再把这链路自动化。哪怕这条链路只有 20 个 SKU、只覆盖一个品类、判定靠 Excel 公式，只要它能从"判定"走到"动作"再走到"回流"，你就有了系统真正的需求文档。
前面提过，人工打标的错误率会随时间快速上升。我后来做过一次对照：同一批 1876 个 SKU，人工打标和规则引擎打标的结果对比，人工的准确率是 71%，规则引擎是 89%。
更关键的差异在时效和漏报：人工全量打标需要 16 人天，规则引擎跑一次 25 分钟；阶段迁移的漏报率，人工是 34%，规则引擎是 11%。人工打标不是"更准确"，只是"更有解释感"。真正准确的做法是规则引擎兜底 + 人工只处理例外。
我见过一个商品分析报表有 47 个字段。问为什么要这么多，回答是"业务方可能会看"。这种"可能"是最危险的信号。
我的经验值是：每个生命周期阶段，核心指标不超过 5 个。引入期 3 个就够，成熟期最多 5 个。超过这个数量，指标之间会互相打架，运营反而无法形成判断。指标不是越多越严谨，而是越少越能形成共识。
这是文化层面的问题，但它的影响非常实际。如果团队把下架一个商品视为"做砸了"，那么没有人会主动提交淘汰建议，SKU 只会越滚越多。
我们后来在内部改了一个说法：把"淘汰"改叫"毕业"。一个商品完成了它的生命周期贡献，正常毕业，腾出的资源给新品。这个改动的效果出乎意料，第一个季度运营主动提交的毕业建议就有 143 条，是之前被动清理数量的三倍多。
前面讲了不该怎么做，接下来讲我最终验证下来的一套结构。它分成三层：判定层、指标层、触发层。
教科书上的答案是五阶段：引入、成长、成熟、衰退、淘汰。但我在实际落地时发现，阶段数量应该由"你需要几种不同的动作"决定，而不是由理论模型决定。
判断方法很简单：把每个阶段对应的动作写出来。如果两个阶段的动作完全一样，就应该合并。比如"成熟期"和"成长期"如果动作都是"保供给、稳投放"，那就合并成一个"主推期"。反过来，如果你的流量成本波动大，需要区分"早期成长期（值得加预算）"和"后期成长期（应该开始控制投产）"，那就拆成两个阶段。
我最终用的是四阶段：试销期、主推期、维持期、退出期。淘汰动作被并入退出期，因为下架决策和清仓决策在同一个决策会议上完成，没有拆开的必要。
我最终的判定逻辑是三层叠加，而不是单一规则。
第一层是硬规则兜底。比如上市天数、累计销量门槛这类确定性的字段，用于把商品分到"肯定不是主推""肯定该退出"这类区间。
第二层是趋势斜率修正。单纯看占比会漏掉正在快速变化的商品。我常用的做法是同时看 7 日、30 日、90 日三个窗口的销量斜率，用斜率方向而非绝对值来判断动能。
第三层是人工例外。系统每天会输出一个"待确认清单"，通常不超过 20 条，由品类负责人处理。这些例外往往包含系统识别不了的信息，比如供应链即将断供、某个达人下个月有合作计划。
下面是我实际用过的阶段判定配置的简化版本，用 YAML 表达。它的关键设计是每个阶段的判定条件都包含"至少满足一条进入条件"和"不满足任何退出条件"两部分，避免出现商品同时满足两个阶段条件的尴尬情况。
lifecycle_stage_rules:
stage: 试销期
enter_conditions:
any:
field: days_since_launch
op: "="
value: 120
and:
field: growth_7d_vs_30d
op: ">="
value: 1.15
stage: 主推期
enter_conditions:
any:
field: qty_30d
op: ">="
value: 120
and:
field: growth_30d_vs_prev30d
op: ">="
value: 1.10
field: gp_rate_30d
op: ">="
value: 0.28
exit_conditions:
any:
field: growth_30d_vs_prev30d
op: ""
value: 90
stage: 维持期
enter_conditions:
any:
field: qty_30d
op: ">="
value: 40
and:
field: growth_30d_vs_prev30d
op: "between"
value: [0.90, 1.10]
exit_conditions:
any:
field: qty_30d
op: "="
value: 2
and:
field: growth_30d_vs_prev30d
op: "<"
value: 0.75
这是我踩过最深的坑之一。早期我照搬过一份行业报告里的"复购率低于 15% 即进入衰退"的规则，结果在我们自己的品类里，正常商品的复购率中位数只有 11%，这条规则把一半的成熟期商品误判成了衰退期。
后来我改用分位数：取该品类过去 12 个月的历史数据，把阶段阈值设在 P30 或 P70 分位上，并且每季度重新校准一次。这样做的好处是阈值会随着品类自身的价格带、竞争格局变化而自动调整，不需要人工频繁干预。
下面是我最终确定下来的指标矩阵。它的设计原则是：每个阶段的指标必须能直接支撑该阶段的核心决策，而不是覆盖该阶段的所有现象。
| 生命周期阶段 | 核心指标（不超过5个） | 该阶段的核心决策 |
|---|---|---|
| 试销期 | 首单转化率、早期复购率（14日）、单件获客成本、退货率 | 是否给它更多流量、是否进入主推 |
| 主推期 | 30日增速、库存周转天数、毛利率、连带率 | 是否加预算、是否扩品类深度 |
| 维持期 | 毛利率、库存周转天数、缺货率、老客复购占比 | 是否保留、是否优化供应链成本 |
| 退出期 | 清仓速度、毛利衰减幅度、库存资金占用、替代品销量 | 何时降价、何时下架、客户如何迁移 |
注意"替代品销量"这个指标，它是我认为最容易被忽略但最有价值的一个。衰退期的商品往往不是自己消失了，而是被自家另一个商品替代了。如果替代品是自家的，那这个衰退其实是内部结构优化，不需要恐慌；如果替代品是竞品的，那就是真正的流失信号。这两种情况的处理动作完全不同。
触发规则我坚持一个原则：任何一条触发规则，必须同时写清四件事，触发条件、执行动作、责任人、完成时限。缺任何一项，这条规则最终都会失效。
我见过太多"如果 X 则 Y"的规则，因为没写责任人，最后变成了没人执行的会议纪要。下面是我们实际在用的一个触发表片段。
| 触发条件 | 执行动作 | 责任人 | 时限 |
|---|---|---|---|
| 试销期商品 14 日复购率低于 P30 且退货率高于 8% | 暂停付费投放，转入自然流量观察 | 投放负责人 | 2 个工作日 |
| 主推期商品 7 日销量斜率转负且库存周转天数高于 75 天 | 降低补货量至 30 日销量的 0.8 倍，启动预警 | 供应链负责人 | 1 个工作日 |
| 维持期商品毛利率跌破 12% | 评估成本优化方案或提请毕业评审 | 品类负责人 | 5 个工作日 |
| 退出期商品连续 30 天清仓速度低于目标 50% | 进入二级降价或批量折价出货 | 库存负责人 | 3 个工作日 |
回流是整套系统里最容易被砍掉的部分，因为它的价值在当下看不到。但我的经验是：没有回流的系统，三个月后就会退化成拍脑袋。
我的做法是固定两个回流节点：14 天看短期反应，30 天看真实效果。14 天的数据容易受促销波动影响，只能作为方向参考；30 天的数据才具备判断价值。
同时，我会为每个动作保留一个对照组。比如对一个衰退期商品做清仓，我会留出 10% 到 20% 的库存不做降价，用来对比"降价到底多带来了多少销量"。这个做法不严谨，但足够实用，能避免把"整体大盘上涨"误认为是"策略有效"。
前面讲的是一套通用的结构。落到具体工具上，我这两年主要在跨境场景下用数跨境做数据汇总和指标配置这一层，下面讲讲我的实际用法，包括它能解决什么、不能解决什么。
先说清楚分工，这是我认为最重要的一条经验。工具负责把多平台、多店铺、多币种的数据收敛到统一的 SKU 粒度，规则层负责阶段判定和动作触发。把两件事混在一起做，最后一定两头都不好。
我的实际架构分三层：数据层用数跨境做订单、广告、库存、退货的统一汇总，输出一张 SKU 粒度的日表；规则层是我自己写的判定脚本，每天跑一次，输出阶段标签和待确认清单；展示层是两张看板，一张"阶段分布总览"，一张"待确认清单"。
跨境场景最容易出问题的是口径。同一个 SKU 在不同平台的销量计算方式不一样，有的含取消订单，有的不含；库存有的含在途，有的只算可售。我做过一次测试，同一批商品在两种口径下的"库存周转天数"差异最高达到 38%。
我的做法是强制在数据层统一口径，并且把口径定义写成文档挂在看板旁边。口径不统一的系统，比没有系统更危险，因为你会基于错误的数字做出自信的决策。
跨境场景经常有同一款商品在不同站点以不同 SKU 上架的情况。如果只在 SKU 粒度做分析，会出现"单个 SKU 销量下滑判定为衰退，但整个商品组其实在增长"的误判。
我的做法是建立一个商品组映射表，生命周期判定同时看两个层级：商品组决定阶段，SKU 决定动作。比如商品组在成熟期，但其中某个站点的 SKU 在衰退，那就不需要修改商品组的阶段，只需要对这个 SKU 做渠道层面的调整。
这一点是我吃过亏才明白的。退货率对生命周期判定的影响极大，尤其在家居、服饰这类品类。我们曾经有一个商品在 30 日销量上表现很好，被判为主推期并加了投放预算，结果两个月后发现退货率高达 27%，实际净销量是负增长的。
所以我现在强制要求：任何进入主推期判定的商品，都必须先通过退货率门槛。这是一个硬门槛，不参与加权计算。
规则跑起来之后，我观察了六个月的数据，最值得分享的不是准确率提升了多少，而是阶段迁移的时间分布发生了变化。
上线前，商品从"开始衰退"到"被识别出来"平均要 23 天，这 23 天里运营还在按原来的节奏补货。上线后这个时间缩短到 6 天，补货动作基本能在衰退确认前就被拦截。这 17 天的时间差，直接对应的是库存资金的占用周期。
下面是这套系统上线前后，同一品类、同一季节区间的三个核心指标对比。数据来自我们自己的后台，样本是该品类 1876 个 SKU 的滚动 6 个月数据。
| 指标 | 上线前（6个月） | 上线后（6个月） | 变化 |
|---|---|---|---|
| 爆款衰退平均识别时间 | 23 天 | 6 天 | -74% |
| 积压库存资金占用 | 340 万元 | 168 万元 | -51% |
| 新品进入主推期的成功率 | 22% | 37% | +15 个百分点 |
| 月度因数据改变的决策数 | 7 次 | 19 次 | +171% |
我要诚实地说，这些变化不能全部归于系统。同期我们还调整了投放策略和供应链的补货节奏。但"衰退识别时间"和"决策数"这两个指标，我认为系统贡献了主要部分，因为它们直接依赖于判定和触发的速度，而不是预算或渠道的变化。
举一个我印象最深的例子。有一款藤编收纳篮，2024 年 3 月上市，前 45 天日均销量 8 件，被判定为试销期。第 52 天开始，7 日销量斜率转正，30 日增速达到 21%，系统自动迁移到主推期，触发了"提高补货量至 60 日销量 1.2 倍"的动作。
第 118 天，库存周转天数升到 82 天，同时 7 日斜率转负，系统触发预警，补货量被调整到 30 日销量的 0.8 倍。第 143 天，毛利率跌破 12%，进入维持期评估。第 176 天，连续两个月下滑超过 25%，进入退出期，启动清仓。
整个过程里，人工干预只有两次：一次是第 118 天的例外确认（因为当时有一个大促计划），一次是第 176 天的清仓折扣幅度决策。其余判定全部由规则完成。这个商品最终清仓完成率 94%，库存资金回收周期比同类商品短了 19 天。
为了避免误导，我必须说清楚这套结构的局限。
第一，它无法处理"从未有过历史数据"的全新品类。新品类没有历史分位数可用，阈值只能靠人工先设一版，跑三个月后再校准。
第二，它无法识别外部突发事件。比如竞品突然断货、平台规则变化、汇率剧烈波动，这些都会让阶段判定出现系统性偏差。这类情况必须靠人工例外机制兜底。
第三，它无法替代品类负责人的商业判断。系统能告诉你"这个商品销量下滑了"，但无法判断"这个下滑是因为我们主动收缩还是被动流失"。这个判断仍然只能由人做。
商品分析系统的搭建方式，跟你的 SKU 规模、团队人数、数据基础强相关。下面按三种典型情况给出建议。
这个阶段不要做系统，做规则就够了。用 Excel 或在线表格维护一张 SKU 状态表，字段不要超过 12 个，每周手工更新一次。
重点做两件事：一是把阶段判定规则写清楚，二是把每个阶段对应的动作写清楚。哪怕规则只有三条，只要它被稳定执行，价值就远大于一套没人用的系统。
我见过太多小团队花三个月做数据看板，最后发现 SKU 只有 80 个，一张透视表就能看完。这个阶段最大的浪费不是没系统，而是过早投入系统。
这是最适合开始搭系统的区间，也是我前面案例所处的阶段。建议按这个顺序推进。
我建议的时间预算是：第 1 到 2 周做口径统一，第 3 到 4 周做阶段和规则，第 5 周开始试跑，第 6 到 8 周根据试跑结果调整阈值。两个月内一定要让系统跑起来，哪怕规则很粗糙。规则可以在跑的过程中优化，但结构必须尽早立起来。
这个规模下，纯粹靠规则引擎已经不够用了。我的建议是引入第二层判断：用历史数据训练一个阶段迁移的预测模型，作为规则引擎的补充。
具体做法是用过去 24 个月的 SKU 数据，标注每个 SKU 在每个月末的真实阶段，然后用分类模型预测下一个月的阶段迁移概率。规则引擎负责确定性判定，模型负责输出"未来 30 天可能迁移"的概率，两者叠加形成预警。
但我要提醒一点：模型输出必须是概率，不是标签。如果模型直接输出"这个商品下个月会衰退"，运营会盲信；输出"衰退概率 68%"，运营才会去核实。这个区别在实际使用中非常关键。
这两类业务的系统重心完全不同。
新品驱动型（比如快时尚、3C 配件）的核心是试销期的判定速度和淘汰决断力。系统应该重点优化试销期的指标采集频率，从月度缩短到周度甚至日度，同时把"毕业"的门槛设得果断一些。
长尾驱动型（比如家居、五金）的核心是维持期的成本管理和长尾商品的利润挖掘。系统应该重点监控毛利率和库存周转，而不是销量增速，因为长尾商品的销量本来就不该有高增速。
把这两类业务的阈值混在一起用，是很多多品类公司常见的问题。我的建议是至少按一级类目分开维护阈值，如果能按"商品周转特性"分群更好。
系统建设过程中，最难的不是技术，而是取舍。下面是我认为最需要提前想清楚的五组取舍。
自动化程度越高，系统跑得越快，但灵活性越低。我的建议是在阶段判定上高度自动化，在动作执行上保留人工确认。
原因很实际：判定错误的成本是"多看一条待确认清单"，而执行错误的成本可能是"错误清仓了一个正在回升的商品"。这两类错误的不对称性，决定了自动化应该落在哪一层。
具体做法是：判定自动跑，输出阶段标签；动作触发后进入待办清单，由责任人确认后执行。只有严重程度极高的场景（比如库存周转超过 120 天）才允许自动执行。
这是一组必然冲突的取舍。指标越全，判断越准；但指标越全，响应越慢。
我的处理方式是按决策频率分层：高频决策（补货、投放调整）只用 3 到 5 个核心指标，快速响应；低频决策（品类结构优化、供应商谈判）才引入更全的指标体系，允许慢一些。
很多团队的问题在于用低频决策的指标体系去支撑高频决策，结果就是每次补货都要等三天出报表。
这组取舍我给一个比较明确的判断标准：如果数据整合工作量占整个项目的 60% 以上，优先用现成工具；如果规则和策略设计占 60% 以上，可以考虑自建。
大多数中小团队的情况是前者，所以我的实际选择也是用工具解决数据层，自己写规则层。反过来，如果一家公司已经有成熟的数据仓库和口径体系，那自建规则层反而更灵活。
淘汰太激进的风险是误杀，你可能砍掉一个即将回升的商品。淘汰太保守的风险是资源被长期占用，新品没有试错空间。
我倾向于在试销期结束的节点上激进，在维持期的节点上保守。试销期结束还没跑出来的商品，大部分确实跑不出来，果断毕业是对的；而维持期的商品往往利润稳定，即使销量下滑也不该急着砍，应该先做成本优化。
这条取舍背后的判断是：试销期的核心矛盾是"机会成本"，维持期的核心矛盾是"边际利润"。矛盾不同，策略就应该不同。
这是最容易被财务指标掩盖的一组取舍。清仓能快速回笼资金，但如果清仓方式不当（比如大幅降价导致老客不满，或者直接下架导致老客找不到替代品），损失的是长期客户资产。
我的做法是在退出期同时启动"客户迁移"动作：识别出购买过该商品的老客，推送同品类中处于维持期或主推期的替代品，并且给出定向优惠。
这个动作的成本不高，但效果明显。我们做过一次对比，做了客户迁移的商品，其老客在 90 天内的复购率比没做的高出 14 个百分点。商品会毕业，客户不应该跟着流失。
写到这里，我想把整篇文章压缩成三句话。
第一句：生命周期不是一套分类法，而是一个状态机。它的价值不在于告诉你有几种商品，而在于让每个商品的状态变化都能自动触发一个具体动作。没有触发，生命周期就只是标签。
第二句：系统的复杂度应该匹配决策的复杂度，而不是匹配数据的复杂度。SKU 少的时候用表格就够，SKU 多的时候再上工具；指标的多少应该由决策需要决定，而不是由数据可得性决定。
第三句：没有回流的系统会在三个月内退化成摆设。判定、触发、回流，三者必须是一个闭环。闭环不完整，投入越大，浪费越大。
如果你现在正准备开始，我的建议是：不要从搭系统开始，从挑一个品类开始。选一个 SKU 数量在 100 到 300 之间、数据相对干净的品类，用手工方式跑一遍完整的生命周期判定和动作触发，把过程中所有卡点记下来。三周之后，你会发现真正的需求清单已经自己浮出来了，比任何需求评审会都准确。
然后再决定要不要上工具、上什么工具、怎么把规则固化下来。数据层面的整合，我自己的处理方式是用数跨境把多平台店铺的订单、广告、库存拉到统一的 SKU 粒度，剩下的判定和触发逻辑自己写，这个分工在中小团队里跑得最顺。工具会换，但"阶段判定，动作触发，效果回流"这个结构不会变，先把这个结构立起来，比什么都重要。
我们公司现在商品越来越多，运营同学有人按引入、成长、成熟、衰退分四段，有人非要加个淘汰期分五段，开会吵得不可开交。我自己也拿不准，到底哪种分法更合理，会不会分错了后面整套系统都白搭？
阶段数量没有标准答案，关键看你的业务是否需要为'退出'单独设一套动作。如果滞销品只需要从在售列表移除、没有残值回收或客户迁移的复杂流程，四阶段（引入、成长、成熟、衰退）就够了；如果涉及清仓定价、替代品引导、老客迁移、退市审批等独立动作，就把淘汰期拆出来做第五段。
判断依据是：某个阶段是否有专属指标和专属策略。两者都没有，就不要单独设阶段，否则只会让系统变复杂、人工标注负担加重。实操上建议先用四阶段跑一个季度，把每次'退市动作'单独记一张表，如果这张表三个月内积累了足够多的重复流程，再升级到五阶段。
我们SKU有几千个，现在全靠运营每周手动拉表、人工判断哪个品进入衰退期，一到月底就加班到半夜还经常判错。我很想知道有没有办法让系统自己判断阶段，但又担心规则太死板会误伤一些特殊商品。
自动判定完全可以做，核心是'规则引擎+阈值+趋势'三层叠加，而不是单一阈值。具体做法：第一层用绝对值卡硬边界，比如连续N周销量为零直接进淘汰候选；第二层用趋势判断，比如近4周销量环比连续下滑且跌幅超过设定比例，标记为衰退预警；第三层用相对表现，比如该品在同品类中的排名百分位跌破某个位置。
三层同时满足才自动切换阶段，只满足一层则进入人工复核池，避免误伤。阈值不能照搬行业通用值，要用你自己历史数据回测：把过去12个月已经'事实上衰退'的商品捞出来，看它们在衰退前的指标表现，反推出适合你品类的阈值。
系统上线初期建议自动判定只做'建议'，由人工确认后再生效，跑两三个月校准准确率后再逐步放开自动执行。
我们看板上一口气堆了三四十个指标，结果每次开会大家各看各的，谁也说不清这个品现在到底该补货还是该清仓。我想知道每个阶段真正该盯的指标是哪几个，怎么用少数几个指标就支撑决策。
指标不是越多越好，而是每个阶段只保留'能直接触发动作'的三到五个核心指标。引入期盯试销转化率、首购获客成本、首月复购率，用来判断要不要加大铺货；成长期盯销量增速、复购率、库存周转天数，用来判断要不要追加备货和投放；成熟期盯毛利率、缺货率、客单价，用来判断要不要保利润、稳供应；
衰退期盯清仓速度、毛利衰减幅度、替代品分流比例，用来判断降价还是下架。判断标准很简单：一个指标如果不能直接对应'补货、促销、清仓、下架'中的某个动作，就不该出现在阶段性看板上，可以放进明细页备查。
实操上建议每个阶段做一张独立的阶段看板，商品切换阶段时自动切换到对应看板，这样开会时所有人看的是同一套指标，决策效率会明显提升。
我们花了不少力气做出阶段判定，报表也挺好看，但判定成衰退期之后，采购照旧下单、运营照旧不动作，最后系统成了摆设。我很想知道从'判定结果'到'实际执行'中间这一段到底怎么打通，有没有可复制的做法。
策略落地的关键是建立'触发条件→动作→责任人→回流验证'的闭环，缺一环都会停在报表上。具体做法：第一步把每个阶段对应的动作写成明确的触发规则，比如商品自动进入衰退期后，系统自动生成一张清仓任务单，指定责任人和完成时限；
第二步把任务单推送到采购、运营、供应链各自的日常工具里，而不是只留在分析看板，让相关人不得不在自己的流程里处理；第三步设置回流验证，比如清仓任务完成后两周，系统自动对比清仓速度和毛利回收情况，判断这次策略是否有效，并把结果回写到商品档案里。
判断闭环是否跑通的标准是：每个阶段的判定结果，是否都能在一个工作日内转化为一条带责任人和截止时间的任务。如果做不到，说明缺的不是分析能力，而是任务分发机制。建议先用一个品类做试点，把闭环跑顺再复制到全品类。
读者评论
文章里看板数量翻倍但决策数不涨那段太真实了。我们公司也是BI看板越做越多，每周例会都在看数，但真正因为数据改变的动作很少，问题就出在数据没接到人身上。
把淘汰改叫毕业这个点子很妙。我们团队就是没人愿意提下架，都觉得是自己做砸了，SKU越滚越多。换个说法确实能降低心理门槛，值得试试。
人工打标准确率71%那个对比数据很有说服力。我们之前也是靠运营手动更新商品状态，一开始还行，两个月后基本就烂尾了，维护成本被严重低估。
分品类设阈值这点深有体会。我们做服装和家居共用一套衰退判定规则，结果家居那边因为季节波动被判了一大批衰退，实际销量后面又回来了，误杀很严重。
先手工跑通一条决策链路再上系统，这个建议很中肯。我们之前上来就想做中台，做了大半年数据模型，最后发现根本没人用，因为一开始就没想清楚要支持什么决策。