三年前我把一个累计销量排进店铺前 5 的收纳盒定成了主推款，备货 8000 件，结果上架第三周开始日销从 60 单掉到 12 单，两个月后变成清仓链接，最后算下来连仓储费都没赚回来。复盘时我把它的历史数据拉成一条曲线才发现：在我做选型决策的那个时点，它的销量已经连续 11 周环比下滑，只是累计总量太漂亮，把这条下滑曲线完整地盖住了。这件事让我彻底改掉了自己的选品习惯，不是看一个商品卖了多少，而是先看它还在不在卖得动。
这篇文章讲的，就是我把销量趋势从"事后参考指标"提到"选型前置门槛"之后，重新搭起来的一套商品分析运营框架，包括判断顺序、拆解方法、真实案例、适用边界，以及在不同数据条件下应该怎么取舍。
先给结论，不绕弯子。这套框架的核心不是增加了几个指标，而是改变了做决策的先后顺序。传统做法是先算总量、再排序、再拍板、最后跟踪；我现在做的是先用趋势过滤、再做基本面校验、再小步验证、最后才谈资源倾斜。顺序一变，被淘汰的候选品数量会大幅上升，但主推款的失败率会明显下降。
大部分选品表格里，"趋势"是一列可加分的字段。一个商品累计销量高、毛利高、退货率低，即使趋势在跌，综合评分可能还是排在前列，然后被选为主推。这种做法的问题在于：趋势下跌是一个否决性条件，不是一个可以靠其他维度补回来的扣分项。
我给自己定的规则很粗暴：近 8 周滚动销量斜率连续为负、且累计跌幅超过 25% 的商品，无论它的累计销量多高、毛利多厚，一律不进主推池。它可以留在常规货架吃自然流量，但不配拿到额外的推广预算和库存深度。原因很简单，把一个正在衰退的品推成爆款，本质上是在跟趋势对赌，而趋势的胜率远高于运营技巧。
很多团队不缺指标，缺的是顺序。指标堆积的结果是"每个维度都还行，但说不上来到底行不行"。我现在的判断顺序是固定的四步，前一步不过，后面不进入：
这套顺序最大的好处是把决策成本压到前面。前两步只需要数据，不需要开会；只有通过前两步的少数商品才值得占用团队讨论时间。我自己的团队实测，选型会议的平均时长从 3 小时压缩到 50 分钟左右，参与人数从 7 人降到 4 人。
整套商品分析运营框架我拆成四个环节：数据准备 → 趋势识别 → 选型决策 → 复盘迭代。这不是唯一正确的结构，只是我自己跑通了、并且能稳定复现的一种结构。它的特点是把"趋势识别"单独拎出来当一个环节，而不是嵌在指标计算里。
很多团队会把趋势识别和数据分析混在一起做，结果就是每次都要重新讨论"用什么周期、怎么算斜率"，口径反复漂移。单独设一个环节，意味着这部分规则要固化下来，写成文档，所有人用同一套算法。这是后面所有判断能互相对齐的前提。
我做的类目偏家居日用和跨境小件，客单价不高，SKU 数量多，季节性和平台流量节奏都很明显。这个背景下，累计销量这个指标的说服力会特别强，也特别危险。
第一个场景是前面说的收纳盒。它的累计销量在店铺排第 4，但这个数字是过去 18 个月累加出来的，其中 60% 来自上一年的一次平台大促。到我做决策的时候，它的自然销量已经连续 11 周下滑。我看的是总量，漏掉的是方向。
第二个场景是一款宠物饮水机。它的近 8 周数据非常漂亮，斜率陡峭向上，我判断它是"上升加速型"，直接给了 3 倍库存和站内广告预算。上架第二个月发现，那波上涨完全来自一个竞品断货，竞品补货后销量两周内回到原位。趋势的形态是对的，但趋势的成因判断错了，结果一样亏。
第三个场景更隐蔽。一款厨房小工具，近 12 周销量平稳，方向基本走平，按趋势过滤规则应该进"维持"档。但我忽略了它的波动率：它的周销量在 40 件到 260 件之间来回跳，标准差极大。这种品看起来平稳，实际是促销脉冲叠加出来的假平稳，一旦停止促销就会塌下来。
这个道理说出来很浅，但真正在表格里做决策的时候，人的注意力会被大数字吸走。累计销量回答的是"这个商品曾经被验证过吗"，趋势回答的是"它现在还在被验证吗"。两个问题都重要，但在选型这个场景里，后者的时效性权重更高。
电商的竞争格局变化速度快，一个品类的窗口期往往只有几个月。用一个横跨 12 到 18 个月的总量指标去指导未来 60 天的资源投放，时间尺度本身就是错配的。
如果团队符合下面任意两条，我认为这套框架的优先级应该排在其他优化项之前：SKU 数量超过 300 个、主推款资源集中度高（前 10 个 SKU 贡献 60% 以上营收）、有明显季节性、退货率高于类目均值、库存周转天数超过 60 天。
反过来，如果公司只有几十个 SKU、每个品都有人工盯盘、决策周期很短，那么趋势判断可以直接靠人脑完成，未必需要把它固化成一套流程。工具化的前提是决策量大到人的直觉覆盖不过来。
我在同行交流里见过很多种"已经考虑趋势了"的做法，但其中相当一部分其实是把趋势用错了位置。下面四种是最常见的。
这是最基础的错误。排序法的隐含假设是"历史总量可以预测未来表现"，这个假设在稳定类目里勉强成立，在快速变化的类目里基本失效。更麻烦的是，排序会让人产生"我在用数据做决策"的错觉，实际上只是把拍脑袋换成了拍表格。
我自己的替代做法是：把累计销量降级为参考字段，不出现在排序键里，避免它继续影响视觉判断。
大促月销量冲高是必然的，问题在于很多人把这条冲高的曲线读成了"增长"。判断方法是把促销期数据单独剔除，看自然期销量的走向。如果自然期在跌、只有促销期在涨，那说明这个商品的增长其实来自折扣深度，不是需求扩张。
我给自己设了一个警示线：促销依赖度（促销期销量占当月总销量比例）连续两个月超过 45%，这个商品就不进入加注名单，只做维持。
自家商品销量下跌，有三种完全不同的原因：类目整体在衰退、竞品抢走了份额、自己的运营动作出了问题。这三种原因对应三种完全不同的对策，但如果只看自家数据，你根本无法区分。
我在宠物饮水机那次失误之后加了一条硬规则：任何进入主推池的商品，都必须核对类目大盘和头部竞品的同期趋势。自家跌、大盘跌，是行业问题，可以维持；自家跌、大盘涨，是竞争力问题，要立刻排查；自家涨、大盘跌，要警惕是不是短期断货红利。
选型不是一次性动作。一个商品在被选中之后，它的趋势判断应该继续更新，而不是等到季末复盘才发现误判。我现在的做法是给每个主推款设一个 14 天的观察窗口，窗口结束时用实际表现去反推：当初的趋势判断是对的还是错的。
这个动作看起来只是加了个跟踪表，但它带来的最大收益是修正判断规则。跑够 3 个季度之后，你会知道自己类目里"斜率多少才算真正的上升加速""多长的观察窗口才够"，这些都是别人给不了的、只属于你自己类目的参数。
趋势这个词太抽象，必须拆成能落到数字上的信号，否则永远只能靠感觉说"看起来在涨"。我拆成三个主要信号加一个辅助信号。
方向回答"在涨还是在跌"，用近 8 周滚动销量的环比正负号判断。斜率回答"涨得多快、跌得多快"，用线性回归的斜率值除以均值做归一化，得到百分比形式的周变化率。拐点回答"趋势什么时候反转的"，用移动平均线交叉或者斜率符号变化来捕捉。
辅助信号是波动率。一个方向向上但波动率极高的商品，实际上很难做库存规划，你无法确定下周是 40 件还是 260 件。波动率高的品更适合小批量高频补货，不适合一次性压库存。
趋势算不准，八成不是算法问题，是数据准备没做干净。我在这一环固定做四件事：
这四件事听起来都是苦活，但它们决定了后面所有判断的可信度。我见过太多团队花大力气搭看板，却因为口径没统一，看板上的趋势线根本不能用来做决策。
具体算法我只用两种，够用且不易出错。
第一种是移动平均 + 斜率。用 8 周滚动平均平滑掉周内波动，再对平滑后的序列做线性回归取斜率。它的优点是直观、抗噪、容易解释；缺点是滞后，通常在真实拐点出现后 2 到 3 周才会反映出来。适合做库存和资源分配这类不能频繁反复的决策。
第二种是同比对照。用去年同期做基线，识别季节性。它的优点是天然剥离季节因素，缺点是要求商品至少有 12 个月历史，且类目结构没有发生大变化。适合强季节类目。
两种算法都有各自的盲区，所以我是组合着用：先看移动平均判断方向，再用同比判断这个方向是不是季节性的。如果移动平均在跌但同比是正的，那可能只是季节性回落，不必恐慌；如果移动平均在跌且同比也在跌，那才是真衰退。
— 商品趋势判断的核心指标定义（示意，按自家数据仓库字段调整）
WITH weekly AS (
SELECT
sku_id,
week_start,
SUM(paid_qty) AS qty, -- 统一为支付口径
SUM(is_promotion_day) AS promo_days -- 标记促销天数
FROM dwd_order_item
WHERE week_start BETWEEN :start AND :end
GROUP BY sku_id, week_start
),
smoothed AS (
SELECT
sku_id,
week_start,
qty,
AVG(qty) OVER (
PARTITION BY sku_id ORDER BY week_start
ROWS BETWEEN 7 PRECEDING AND CURRENT ROW
) AS qty_ma8, -- 8 周移动平均
AVG(qty) OVER (
PARTITION BY sku_id ORDER BY week_start
ROWS BETWEEN 7 PRECEDING AND CURRENT ROW
) / NULLIF(AVG(qty) OVER (PARTITION BY sku_id), 0) AS qty_index,promo_days
FROM weekly
)
SELECT
sku_id,
week_start,
qty,
qty_ma8,
REGR_SLOPE(qty_ma8, ROW_NUMBER() OVER (PARTITION BY sku_id ORDER BY week_start))
/ NULLIF(AVG(qty_ma8) OVER (PARTITION BY sku_id), 0) AS slope_pct, -- 归一化斜率
STDDEV(qty) OVER (PARTITION BY sku_id) / NULLIF(AVG(qty) OVER (PARTITION BY sku_id), 0)AS cv — 波动系数
FROM smoothed;
这段代码的重点不在写法，而在两个字段：slope_pct 用来做方向判断，cv 用来做波动稳定性判断。把它们固化成视图之后，任何商品都能在 1 分钟内算出趋势画像，不需要每次重新讨论。
把上面的信号组合起来，就是我在用的四步顺序。它的价值在于每一步都有明确的止损条件，不会出现"再观察观察"的模糊状态。
第四步之前的很多判断，光靠自家数据是做不完的，尤其是"类目大盘是否同步向上"这一条。跨境类目的情况更复杂，因为类目结构、平台流量节奏、竞品动作都不在自家后台里。我现在的做法是固定用数跨境（官网：https://shukuajing.jiushuyun.com/?utm_source=seo&utm;_plan=est&utm;_unit=gys）来补这部分外部证据。
我用它主要拉三类数据：类目大盘的搜索与销量趋势、头部竞品的销量曲线、以及自家商品在平台内的排名变动。这三类数据刚好补上自家后台的三个盲区，行业景气度、竞争格局、相对位置。
举一个具体例子。前年第四季度，我有一款厨房称重器连续 6 周销量下滑，按自家数据的判断是"运营出了问题"，团队准备加投广告救回来。在把类目大盘和头部竞品的同期趋势拉出来对齐之后，结论完全变了：整个细分品类的搜索热度在下滑，头部竞品的销量同样在跌，而且跌幅比我们还大。这说明问题不在运营，在品类需求本身。如果当时按原计划加投，大概率是把预算砸进一个正在萎缩的池子里。
再说一个正向案例。今年年初我在看一个户外小配件，自家数据只有 3 个月的试销记录，样本太短，趋势判断不可靠。我的处理流程是：
结论是：类目在涨，但头部竞品的斜率已经在收窄，说明增长在减速；同时价格带在下移，促销依赖度上升。这个组合意味着"可以进，但不能压重仓"。
最终我给的是小批量试单加 2 周验证窗口，而不是一次性大货。后来的实际表现也确实如此：销量能起，但毛利被价格战压得比预期薄了将近 8 个百分点。如果只看自家那 3 个月的漂亮曲线，我大概率会把它定成主力款。
下面这组数据来自我自己经手的两个店铺样本（已脱敏，口径统一为支付口径、自然周对齐），对比的是同一批候选品在两种选型口径下的结果。样本量不算大，仅供参考，不代表行业普遍水平。
| 选型口径 | 主推款 90 天达成率 | 滞销库存占比 | 平均清仓周期 | 选型决策耗时 |
|---|---|---|---|---|
| 累计销量排序 | 38% | 27% | 74 天 | 约 16 小时/次 |
| 近 8 周趋势排序 | 61% | 14% | 45 天 | 约 11 小时/次 |
| 趋势 + 类目景气度校验 | 72% | 9% | 33 天 | 约 13 小时/次 |
值得注意的是第三行：加上外部类目校验之后，决策耗时反而比第二行上升了 2 小时，因为多了外部数据核对的动作。但滞销占比从 14% 降到 9%，清仓周期从 45 天缩到 33 天。多花的这 2 小时，换来的是库存端的实质性改善，这笔账我认为是划算的。
趋势判断完之后，还需要一个交叉维度来决定资源给谁。我用的坐标是趋势斜率（横轴）和毛利贡献（纵轴），气泡大小代表库存深度。这个二维定位比单一排序有用得多，因为它直接对应四种不同的处置动作。
同一套框架在不同数据条件下的执行方式差别很大。下面按四种常见情况分别给出具体动作。
新品没有销量趋势可看，这时候不要硬套趋势框架，而是用代理指标做趋势判断：点击率、加购率、收藏量、详情页停留时长、搜索词的曝光增长。这些指标的共同点是反应快，能在销量起来之前给出方向信号。
我的通过标准是：连续 7 天加购率高于同类目新品均值，且搜索曝光周环比为正。满足就进入小步验证，给 2 周预算；不满足就继续观察，不追加任何资源。
成熟品的趋势判断要更关注拐点。这个阶段的商品销量基数大，绝对波动看起来不大，但一旦进入衰退，惯性也大，掉头很慢。我一般会用同比 + 移动平均双线对照，只要两条线同时转负，就启动降级流程，把推广预算转移到上升品。
需要提醒的是，成熟品的退出要有节奏。直接砍掉会损失掉它的自然流量和搜索权重，比较稳的做法是先减推广、再减库存深度、最后进入清仓，整个过程留出 6 到 8 周缓冲。
SKU 数量一多，趋势判断必须工具化，靠人工看表格一定会漏。这个阶段的重点不是把算法做得更复杂，而是把口径和规则固化成可自动运行的流程：统一的数据表、固定的滑动窗口、自动生成的趋势画像、按规则自动分档。
我建议的落地顺序是：先统一口径（1 周），再固化趋势计算（1 周），再做自动分档（1 周），最后接入选型流程（1 周）。一个月能跑通第一版，不需要一次性做到完美。
如果团队连数据仓库都没有，所有数据都散在平台后台和 Excel 里，那么不要一上来就追求自动化。可以先做一个"半手工版"：每周固定从后台导出一次销量数据，贴进一张固定模板，用现成的函数算出 8 周移动平均和斜率，人工标注趋势档位。
这套半手工流程每次大概花 2 到 3 小时，但已经能覆盖前面说的核心判断。先跑通逻辑，再谈工具，顺序反过来会浪费大量时间。
框架给的是判断逻辑，但真正难的是取舍。下面四组矛盾是我在实操中反复遇到的，每一组我都给出自己的倾向，但都不认为它是唯一答案。
遇到趋势向上但毛利薄的品，和趋势走平但毛利厚的品，我的选择取决于这个商品的战略角色。如果它承担的是拉新和流量入口，选趋势；如果它承担的是利润贡献，选毛利。
最忌讳的是同一个商品被赋予两种角色。这会导致推广策略左右摇摆：为了拉新就压价，压价之后毛利更薄，最后变成既没赚到钱也没沉淀下用户。
短窗口（4 到 8 周）反应快、噪声大，适合高频类目和快速调整；长窗口（12 周以上或同比）更稳、更滞后，适合低频和强季节类目。我的默认配置是短线做动作、长线做判断：用 8 周窗口决定这个月给多少预算，用同比数据决定这个品类的整体策略。
不要用短窗口做长期承诺。我见过团队因为 4 周的漂亮数据就签了半年的包销协议，后面趋势反转，直接变成库存负担。
这是成本最高的一组取舍。我用一个简单的对比表来辅助决策，把每种处置方式的资金占用、预期收益和最坏情形都列出来，避免只看到好的一面。
| 处置方式 | 追加资金 | 预期 90 天毛利 | 最坏情形 | 适用条件 |
|---|---|---|---|---|
| 加注 | 42 万元 | +58 万元 | -21 万元 | 趋势上升加速、毛利结构健康、类目景气度向上 |
| 维持 | 8 万元 | +19 万元 | -6 万元 | 趋势走平或斜率收窄、毛利尚可、无明确衰退信号 |
| 清仓 | 0 元 | -9 万元 | -14 万元 | 趋势明确向下、库存深度超 60 天、继续持有成本高于折价 |
| 淘汰 | 0 元 | -12 万元 | -12 万元 | 无毛利空间、退货率异常、供应链无法支持 |
这张表的用法是：先确认自己能不能承受最坏情形。如果加注的最坏情形会挤占其他品类的现金流，那即使趋势再好，也应该降到"维持"档，分批观察。我看到过太多团队是在趋势判断正确的前提下亏钱的，原因就是仓位下得太重。
自动化能解决覆盖率问题，人工判断能解决特殊情况。我的分界线是：规则明确、可量化的部分交给自动化（趋势方向、斜率、波动率、分档），需要结合上下文的部分留给人（为什么跌、竞品在做什么、供应链是否有变化）。
把所有判断都自动化的结果，是系统会机械地执行错误规则；把所有判断都留给人工的结果，是 SKU 一多就漏。比较好的平衡是：系统给出分档结论和依据，人只需要在异常分档上做二次确认，并在季度复盘时修正规则参数。
移动平均确实有滞后，这是它的固有代价。缓解方式有两个：一是缩短窗口，用 6 周或 4 周做快速预警，用 12 周做确认；二是叠加代理指标，把点击、加购、搜索曝光的变化作为前置信号。我自己是用代理指标做预警、用移动平均做确认，两者结合起来滞后能缩短到 1 到 2 周。
小类目的解法通常不是延长窗口，而是扩大统计单元：把同类属性、相近价格带的多个 SKU 合并成一个商品组来计算趋势，样本量自然就够了。这样做的前提是这些 SKU 面向同一批用户、满足同一类需求。
可以，但指标要换。内容型商品的"销量"应该换成曝光量、完播率、复访率这类等效指标，趋势判断的逻辑不变：看方向、看斜率、看拐点。核心思想是通用的，具体指标必须跟着业务形态调整。
我自己的经验是：第一版规则上线后，第一个完整季度就能看到滞销库存占比的变化，两个季度之后主推款达成率的提升才会明显。原因是趋势判断改善的是选品质量，而选品到销售结果之间有备货、上架、推广的滞后链条。如果一个方法号称一周见效，那它优化的多半是执行效率，不是判断质量。
这套框架最核心的一句话是：销量趋势不是给商品打分的一列分数，它是决定这个商品能不能进入下一轮讨论的门槛。这个位置一换，整套选型逻辑的性质就变了，从"选出最高的那几个"变成"先排除明显不行的那些"。
另一个我想强调的观点是，趋势判断的价值有一半来自"知道自己会错在哪"。这套方法不适合没有历史数据的新品、不适合样本量极小的长尾类目、不适合促销节奏完全混乱的时期。主动说清这些边界，比宣称方法论万能更有用，因为只有知道边界，你才知道什么时候该信它、什么时候该信自己的直觉。
如果你打算从下一个选品周期开始用这套方法，我建议的行动顺序是：这一周先把销量口径统一，把促销日、断货日标记出来；下一周用 8 周移动平均算出所有在售 SKU 的趋势斜率；再下一周做一次历史回测，看看如果当初用趋势过滤，会淘汰掉哪些品、又会留下哪些品。
这次回测最有价值的地方不在于验证方法对不对，而在于你会亲眼看到自己过去一年有多少资源投在了正在衰退的商品上。看到这个数字之后，把趋势纳入选型这件事，就不需要任何人再来推动你了。
我之前选品都是拉一整年的销量总量，再筛出排名靠前的商品。但上架后发现有些品刚开始还有单，两周后就开始掉，我怀疑是不是我看的时间跨度太长了，把早就过气的品也算进来了。到底看多久的数据才合适？
没有统一的天数，取决于你的商品动销周期和运营节奏。判断口径分三层：一是看近7天和近14天的环比方向，用来捕捉短期拐点，适合快消、服饰等高频品类；二是看近30天与上一个30天的斜率变化，用来判断中短期趋势是否在加速或减速，适合大多数标品；三是看去年同期做季节性校准，避免把季节因素误读成趋势。
实操上不要只用一个窗口，至少同时拉近7天、近30天、去年同期三组数据，如果三组方向一致，趋势判断可信度最高；如果短期上升但30天和去年同比都在下滑，大概率只是短期波动或活动余温，不建议重仓。另外要注意，时间跨度必须和你的补货周期对齐。
如果补货周期是15天，那近7天的数据样本太薄，容易被单日大单扭曲，这种情况下以近30天为主、近7天为辅更稳。
我遇到过一个品，平时一天十几单，某天突然冲到两百多单，我以为是爆款苗头，赶紧加库存主推，结果一周后回落到个位数，库存全压手里了。后来又遇到几次类似情况，现在看到销量突然拉起来都会犹豫，不知道到底该不该信。
判断方法是用"剔除活动口径"重算一遍。具体做法：把大促日、优惠券生效日、直播场次、达人带货日标记为异常日，单独拉出来，然后用剩余的自然日数据重新算趋势。如果剔除活动后，自然流量下的日销从十几单提升到了三四十单，说明是真实趋势改善；
如果剔除后还是十几单甚至更低，那增长就是活动带来的，属于一次性冲量，不能作为选型依据。还有一个辅助信号：看加购率和搜索词进店量的变化。活动冲量通常表现为下单量暴涨但加购率不变或下降，用户是被价格推着走的；真实趋势起来时，加购率、收藏率、搜索进店量通常会同步抬升。两个信号一起看，误判率会明显降低。
我现在选品时会把候选商品放在一张表里对比，但经常出现几个品的趋势方向都差不多的情况，都是上升、斜率也接近，这时候我就卡住了，不知道该主推哪个、哪个放次要位置，凭感觉选又怕选错。
在趋势方向一致时，用"斜率+拐点新鲜度+稳定性"三个维度排序。第一，比斜率，同样30天窗口内，日销从20涨到60的品，斜率比从40涨到55的品更陡，优先选斜率大的，因为它代表增长动能更强。
第二，比拐点新鲜度，上升拐点出现在最近7天内的品，比拐点出现在25天前的品更值得投入，前者还在趋势早期，后者可能已经接近平台期。第三，比稳定性，用日销的标准差除以均值算变异系数，系数越小说明增长越平滑，越适合稳定投放，系数大的品容易大起大落，适合短周期冲量而不适合长期主推。
实操建议做成一张打分表：斜率、拐点新鲜度、稳定性各占权重，加总后排序。不用追求绝对精确，目的是把"凭感觉"换成"有先后顺序"，哪怕权重设置粗糙，也比拍脑袋稳定。
我负责的类目里经常要上新品，很多新品根本没有历史销量数据，用趋势判断完全无从下手。但团队又要求选品必须有数据支撑，我就很纠结，这种情况下是不是只能靠经验赌一把？
新品确实不适用历史销量趋势，但可以换一套代理指标来近似趋势判断。第一，看同类目、同价位带、同人群的老品在上架后前30天的销量爬坡曲线，把新品的首周表现和这条基准曲线做对比，高于基准说明有潜力。
第二，看新品的加购、收藏、搜索进店量增速，这些是先行指标，通常比销量更早反映趋势变化，加购增速连续两周为正且加速，是积极信号。第三，看小批量测试期的复购和退货率，退货率明显高于类目均值说明商品本身有问题，趋势再好也不该放量。
实操上把新品单独放一条选型通道，不套用老品的趋势门槛，而是设定"观察期+小步验证"规则：先用小预算投放7天，设定一个最低加购增速和退货率红线，达标再进入下一轮加量，不达标就停。这样既不用赌，也不至于因为没有历史数据就完全放弃数据判断。
读者评论
趋势作为前置门槛这点很认同。SKU一多，累计销量确实会掩盖下滑拐点，等主推资源投下去才发现已经晚了。不过文里的漏斗和斜率规则更适合决策量大的团队，小团队SKU少、盯盘紧，未必需要固化成流程。
促销峰值剔除自然销量这个做法很实用，很多品看起来在大促月爆发，其实促销依赖度已经很高。但要注意平台归因口径，如果自然流量和广告流量分不清，促销依赖度可能算不准，反而会误判趋势。
四步判断顺序和14天跟踪能减少无效讨论，方向、斜率、拐点也比“感觉在涨”靠谱。可执行难点在口径统一，不同人算周期和斜率很容易吵架，最好先把算法写死再做选型。