旺季选品通常从一个问题开始：今年这个节日会卖什么？
但对大多数卖家来说，更该先问的是另一个：旺季过去之后，没卖完的货怎么办。 季节性商品的销量不是均匀分布在一年里的，而仓储、资金占用和清货损失是均匀地按月计算的。旺季越尖，淡季压着的库存越重。
所以这篇的顺序是：先确认季节性真的存在且年年重复，再算它有多集中，然后看新进场的 Listing 能不能分到这份量，最后才决定在哪个月做决定。选品的通用方法见把选品当成排除过程，这里只处理时间这一个维度。
第一步：用多年月度数据找出爬坡开始的月份
关键词趋势接口按月返回一个关键词的历史序列，示例从 2017 年 1 月开始：
curl --request POST \
--url https://ecommercedataapi.com/v1/amazon/keyword-research/trends \
--header "Content-Type: application/json" \
--header "X-API-Key: ${ECOMMERCE_DATA_API_KEY}" \
--data '{
"marketplace": "US",
"keyword": "wireless charger"
}'每一行是一个月，关键字段：
| 字段 | 含义 |
|---|---|
time | 月份，格式是 "2017年01月" 这样的字符串，不是日期类型 |
search | 该月搜索量 |
purchase / purchaseRate | 购买量与购买率 |
yearlyGrowth / chainGrowth / threeMonthGrowth | 同比、环比、三个月增长率 |
要找的不是峰值月，是曲线开始爬坡的那个月。 峰值月的量最大，但那时候入场已经晚了——决策点应该比爬坡月再提前一个你自己的备货周期（生产、头程、入仓加起来）。
而且要看它是不是年年重复。 把至少两三年的同一段月份叠在一起看。每年都在同一个月开始爬、同一个月见顶，才是季节性；只出现过一次的尖峰，更可能是一阵流行，不能当成明年还会来的旺季。
两个读数时的坑：
- 关键词字段名是
keyword。以前拼错的keywrod仍会返回，取值相同，旧代码不受影响； time是中文格式的字符串，排序或画图前要先解析成日期，直接按字符串排序在跨年时会出错。
第二步：用同比判断今年这个季节会比去年大还是小
季节确认存在之后，下一个问题是今年的量级。
看旺季开始前几个月的 yearlyGrowth，不要看 chainGrowth。 对季节性词来说，环比在爬坡期每年都会大涨，这个涨幅是季节带来的，不是需求真的变大了。同比拿今年的同一个月和去年的同一个月比，季节因素被抵消掉，剩下的才是需求本身的变化。
同一组字段也能事后诊断排名下滑——那个用法见关键词排名监控；这里用它往前看。
两处数值要小心：
- 序列最前面的月份没有去年可比。 示例里 2017 年 1 月和 2 月的
yearlyGrowth都是 0——这个 0 的意思是"没有基数"，不是"零增长"； - 同一行里有两种记法。 按示例推算，
purchaseRate: 8.31是百分数（1085 ÷ 13059 ≈ 8.31%），而chainGrowth: 0.01是小数（13148 ÷ 13059 − 1 ≈ 0.0068）。把它们放进同一张表之前先统一单位。
第三步：算季节集中度——一年的量有多少挤在旺季
这是最能决定"做不做"的一步，也是最常被跳过的一步。
从关键词层面下到具体商品：挑类目里几个代表性 ASIN，用ASIN 销量趋势接口取逐月数据。返回的 salesTrendPoints 每个月一行，包含 month、price、averagePrice、parentUnitSales、childUnitSales、parentSalesRevenue、childSalesRevenue。
curl --request POST \
--url https://ecommercedataapi.com/v1/amazon/asin/sales-trend \
--header "Content-Type: application/json" \
--header "X-API-Key: ${ECOMMERCE_DATA_API_KEY}" \
--data '{
"marketplace": "US",
"asin": "B08GHW4TBS"
}'季节集中度的算法很简单：
季节集中度 = 旺季那几个月的销量之和 ÷ 全年销量这个比值越高，意味着你的库存越需要在很短的窗口里卖掉。它直接换算成风险：
- 集中度低：季节性只是加分项，淡季照样有量，库存压力小；
- 集中度高：一年的生意压在几个月里，备货量一旦判断偏多，剩下的货要熬到明年或降价清掉。
两个口径问题：
- 父体和子体要分开。
parentUnitSales是整个变体家族的量，childUnitSales是这一个子体的量。用父体量去比另一个单体商品，会把对方的量放大变体数倍。完整解释见销量数据能拿到什么、拿不到什么； - 销量是估算值。 用它算"集中度"这种比值是可靠的，因为同一个模型的系统误差在分子分母里会部分抵消；把绝对销量当成备货数量就不可靠。
同时看 price 和 averagePrice 的逐月变化：如果旺季的量是靠大幅降价换来的，那份量不是你按原价能拿到的。
第四步：看新进场的 Listing 能不能分到旺季的量
季节确实存在、量也够，还剩一个问题：这份量会不会全被老品拿走。
上架趋势接口按 Listing 上架年份分组，每组返回 year、products、units、revenue、unitsRatio。要注意它的时间单位是年，不是月——它看不出季节性，回答的是另一个问题：最近一两年上架的商品，分到了多少销量。
- 近一两年上架的组
unitsRatio很低 → 旺季的量几乎都被老 Listing 拿走，新品为了旺季入场很难分到； - 近一两年上架的组占比可观 → 这个类目持续有新玩家成功进入，旺季入场有机会。
这个接口需要类目节点路径 nodeIdPath。节点 ID 各站点不通用，用类目节点接口查到你所在站点的路径再填进去。上架时间的存量结构（按"3 年以上"这类年龄段）另见类目分析。
用类目曲线和站外曲线交叉验证
关键词曲线只代表一个词。两条曲线可以用来检查它有没有代表性：
类目层面：商品需求趋势接口对一个类目节点返回 items 序列，每项是 date 和 glanceViews（浏览量）。它反映整个类目的需求节奏，不依赖某一个词。如果类目曲线和你选的关键词曲线形状差得很远，说明这个词可能不代表这个类目的主要需求，要多看几个词。
站外层面：谷歌趋势接口返回 items（time 为时间戳、value 为热度值），googleProp 可以选网页搜索 web 或购物搜索 shoppingCart，monthly 控制是否按月。站外热度可以作为交叉验证：站内外同时显示同一个季节节奏，结论更稳。但不要把它当成站内需求的领先指标来下定论——两者的关系因品类而异，需要你自己用历史数据对一遍。 Google Trends API 页面对参数和边界有更详细的说明。
三件这套数据做不到的
不知道你的备货周期。 数据能告诉你爬坡从哪个月开始，但"应该提前几个月下单"取决于你的工厂、头程方式和入仓排期。这个数只能你自己填。
不知道今年会不会有突发变量。 历史曲线假设今年和往年大体相似。新的平台规则、物流变化、竞品大促都可能让今年偏离。同比能提示方向，不能预言结果。
不替你承担清货成本。 集中度算出来是一个比例，旺季后剩下的每一件货要付多少仓储、要降多少价，取决于你的成本结构。
常见问题
只有一年历史的新词能判断季节性吗？ 不能可靠判断。季节性的定义就是重复，一年的数据分不清是季节还是一次性流行。可以先看它所属类目的需求曲线，再看同类老词的多年曲线作参考。
季节集中度多少算高？ 没有通用阈值，要和你自己的资金周转和仓储成本一起看。更实用的做法是把几个候选品的集中度排在一起比较，而不是盯着一个绝对值。
旺季入场的决策点具体是哪个月？ 爬坡开始的月份，再往前减去你的完整备货周期。每个品类的爬坡月不同，每个卖家的备货周期也不同，所以这个月份只能按你自己的数据算出来。
能不能只看峰值月的销量来决定备货量？ 不建议。峰值月的量是估算值，而且决定备货量的应该是整个季节窗口的总量和你能接受的剩余库存，不是单个月的峰值。