销量预测接口返回的字段叫 estDailySales 和 estMonthSales。
est 是 estimated。接口在字段名这一层就承认了它是推算值。 这不是免责声明，是一条应该改变你用法的信息：平台从不公开任何商品的真实销量，所以你在任何工具、任何插件、任何报告里看到的"月销 2965 件"，都是算出来的，不是查出来的。
值得先弄清楚的是：它是怎么算出来的，以及这决定了哪些结论能下、哪些不能。
BSR 接口暴露了整个模型
三个销量相关接口里，最能说明问题的是 BSR 销量预测，路径 POST /v1/amazon/sales/prediction/bsr。
它的输入是：marketplace、bsr、categoryId。
注意这里面没有 ASIN。 你不需要告诉它是哪个商品，只要告诉它"美国站、这个类目、排名 1024"，它就返回 estDailySales 和 estMonthSales。
这意味着模型本身就是一条曲线：给定类目，排名映射到销量。 商品是什么、卖多少钱、标题写得好不好，都不进入这个计算。
理解这一点之后，很多事情就解释得通了：
- 为什么同一个 ASIN 在不同工具里的月销数字不一样——不同的曲线，同一个排名
- 为什么类目之间不能直接比——每个类目是一条独立的曲线，玩具类目的第 1000 名和汽配类目的第 1000 名不是一回事
- 为什么排名波动会让销量估算大幅跳动——排名是唯一的输入
三个接口各自解决什么
| BSR 销量预测 | ASIN 销量预测 | ASIN 销量趋势 | |
|---|---|---|---|
| 路径 | /v1/amazon/sales/prediction/bsr | /v1/amazon/sales/prediction/asin | /v1/amazon/asin/sales-trend |
| 输入 | bsr + categoryId + marketplace | asin | asin + marketplace |
| 返回 | estDailySales、estMonthSales、itemList | asinDetail 加 dailyItemList、monthItemList | asin 对象加 salesTrendPoints |
| 用来做什么 | 把排名换算成量级，批量粗筛 | 单品的日序列和月序列 | 月度序列，含父体子体拆分 |
选择顺序很简单：手上只有排名就用第一个，有 ASIN 且要看时间序列就用第二个，要区分父体子体就用第三个。
ASIN 销量预测接口输入 ASIN，返回商品明细加日、月两组销量序列，含完整请求和响应字段表一个细节：ASIN 接口的字段名没有 est
BSR 接口返回的是 estDailySales，而 ASIN 接口的 dailyItemList 里那一项就叫 sales，monthItemList 里也是 sales。
字段名变了，数据的性质没变。 它仍然是推算值。有一个很直接的证据：dailyItemList 的每一行同时带着 bsr 和 sales 两个字段——输入和输出摆在同一行里。
所以在你自己的表里，建议统一加一列标注，而不是依赖字段名。哪个数字是事实、哪个是推算，应该在你的数据模型里显式存在：
| 字段 | 性质 | 说明 |
|---|---|---|
price、averagePrice | 事实 | 页面公开，可直接引用 |
bsr | 事实 | 平台公开的排名 |
ratings、rating | 事实 | 评分数和评分值 |
sales、estDailySales、estMonthSales | 推算 | 由 BSR 换算 |
amount、parentSalesRevenue、childSalesRevenue | 推算 | 推算销量 × 价格，两层误差 |
最后一行值得单独看。 销售额是推算销量再乘价格，误差是叠加的。如果你的判断只需要量级，用它没问题；如果要拿它做利润测算，那是在两层估算之上再做一层假设。
最常见的比较错误：父体和子体
ASIN 销量趋势接口的 salesTrendPoints 里，同时有这四个字段：
parentUnitSales：父体销量childUnitSales：子体销量parentSalesRevenue：父体销售额childSalesRevenue：子体销售额
一个有 8 个颜色的服装 listing，父体销量是这 8 个变体的合计，子体销量是你查的那一个颜色。
拿 A 商品的父体销量去比 B 商品的子体销量，误差可以是好几倍，而且这个错误不会报错，只会给你一个看起来很合理的结论。竞品分析里的"这个款比我们卖得好得多"，相当一部分是这么来的。
规则很简单：同一列比同一列。 要么都用父体，要么都用子体，并且在表头写清楚用的是哪一个。
能做的三件事
一、同类目内横向排序。 曲线相同，相对关系可靠。判断"这 20 个竞品里谁在前面"是这类数据最擅长的。
二、判断量级。 日销 10 件和日销 500 件是不同的生意，这个区分不需要精确值。
三、看方向。 用 dailyItemList 或 salesTrendPoints 看一段时间的走势——即使绝对值有偏差，上升还是下降通常是可信的，因为偏差在同一条曲线上是同向的。
不能做的三件事
一、当成进货依据的承诺。 推算值告诉你这个位置大概什么量级，不告诉你你到了那个位置能卖多少。
二、跨类目直接比。 不同类目是不同的曲线，排名数字可比，销量推算不可比。要比就比类目内的排名百分位。
三、拿去对账。 你自己的真实销量在卖家后台和 SP-API 里，是精确的授权数据。用推算值去核对自己的账，是用估算去校验事实。这两类数据的分界，亚马逊数据 API 怎么选里有完整说明。
落到表里怎么标
如果你在做选品表，亚马逊选品调研表怎么填那篇讲了整张表的结构。就这一项而言，只需要三条：
- 销量列加后缀或标色，让它在视觉上不同于价格和 BSR
- 每一行记录取数时间——排名变了，推算值就变了
- 表头注明父体还是子体
做到这三条，半年后回看这张表时，你还能判断哪些数字可以引用。
常见问题
为什么不同工具的月销数字不一样？ 因为换算曲线不同。排名是公开的、一致的，曲线是各家自己的。数字有差异是正常的，量级应该接近；如果量级都对不上，先确认两边看的是不是同一个类目层级。
推算的准确度有多高？ 取决于类目和排名区间。头部排名的样本密集，推算相对稳；长尾排名样本稀疏，波动大。不要指望一个统一的误差率。
能拿到竞品的真实销量吗？ 不能。真实销量只在卖家自己的后台和授权数据里。任何声称能提供竞品精确销量的说法，本质上仍是推算。
父体和子体该用哪个？ 看你的问题。判断这个款整体是否值得做，用父体；判断某个颜色或尺码是否值得备货，用子体。关键是全表统一。