販売数予測 API が返すフィールドは estDailySales と estMonthSales という名前です。
est は estimated。API はフィールド名の段階で、それが推算値であることを認めています。 これは免責文ではなく、使い方を変えるべき情報です。プラットフォームはどの商品についても実際の販売数を公開しません。つまりどのツール、どの拡張機能、どのレポートで見た「月間 2,965 個」も、調べた数字ではなく計算された数字です。
先に確かめる価値があるのは、それがどう計算されているか、そしてそこから何を言えて何を言えないかです。
BSR の API がモデルそのものを露出させている
販売数に関わる三つの API のうち、最も分かりやすいのは BSR 販売数予測、POST /v1/amazon/sales/prediction/bsr です。
入力は marketplace、bsr、categoryId。
ここに ASIN が無いことに注目してください。 どの商品かを伝える必要はありません。「米国サイト、このカテゴリ、順位 1024」と伝えるだけで estDailySales と estMonthSales が返ります。
つまりモデルは一本の曲線です。カテゴリを決めれば、順位が販売数に対応する。 商品が何か、いくらか、リスティングの文章が良いかは、この計算に入りません。
これが分かると、いくつものことが説明できます。
- 同じ ASIN の月間販売数がツールごとに違う理由 —— 曲線が違い、順位は同じ
- カテゴリ間で比較できない理由 —— カテゴリごとに独立した曲線であり、おもちゃの 1,000 位と自動車用品の 1,000 位は別物
- 順位が動くと推算が大きく振れる理由 —— 入力が順位だけだから
三つの API の役割
| 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 販売数予測 APIASIN を入力すると商品詳細と日次・月次の販売数系列を返します。リクエストとレスポンスの全フィールド表付き細部：ASIN 側のフィールド名には est が付いていない
BSR の API は estDailySales を返しますが、ASIN の API では dailyItemList の中の項目は単に sales、monthItemList でも sales です。
名前は変わっても、数字の性質は変わりません。 どちらも推算値です。直接の証拠がレスポンスにあります。dailyItemList の各行は bsr と sales の両方を持っています —— 入力と出力が同じ行に並んでいるわけです。
ですから自分の表では、フィールド名に頼らず列で印を付けてください。どれが事実でどれが推算かは、データモデルの中に明示的に存在すべきです。
| フィールド | 性質 | 補足 |
|---|---|---|
price、averagePrice | 事実 | ページ上の公開情報。そのまま引用可 |
bsr | 事実 | プラットフォームが公開する順位 |
ratings、rating | 事実 | 評価数と評価値 |
sales、estDailySales、estMonthSales | 推算 | BSR から換算 |
amount、parentSalesRevenue、childSalesRevenue | 推算 | 推算販売数 × 価格で、誤差が二重 |
最後の行は単独で見る価値があります。 売上額は推算した販売数に価格を掛けたもので、誤差が重なります。規模感を見るだけなら問題ありませんが、利益計算の土台にするなら、二段の推算の上にもう一段の仮定を積むことになります。
最も多い比較ミス：親と子
販売トレンド API の salesTrendPoints には、この四つが並んでいます。
parentUnitSales：親の販売数childUnitSales：子の販売数parentSalesRevenue：親の売上額childSalesRevenue：子の売上額
8 色展開のアパレルなら、親の販売数は 8 バリエーションの合計、子の販売数は照会したその 1 色です。
商品 A の親の販売数と商品 B の子の販売数を比べれば、数倍ずれることがあります。 しかもエラーにはならず、もっともらしい結論だけが出てきます。競合分析でよく出る「この商品はうちより遥かに売れている」は、相当な割合がこれです。
規則は単純です。同じ列どうしで比べる。 親で統一するか子で統一するかを決め、どちらを使ったか列名に書いてください。
このデータで確実にできる三つ
同一カテゴリ内での並べ替え。 曲線が同じなので相対関係は信頼できます。「この 20 件の競合のうちどれが上か」はこのデータが最も得意とするところです。
規模感の判断。 日 10 個と日 500 個は別の商売で、この区別に精度は要りません。
方向の把握。 dailyItemList や salesTrendPoints で一定期間の推移を見ます。絶対値がずれていても、上昇か下降かはたいてい信頼できます。同じ曲線上では誤差が同じ向きに出るからです。
できない三つ
仕入れ判断の裏付けにすること。 推算値はその位置がどれくらいの規模かを示すだけで、あなたがそこに到達したらいくつ売れるかは示しません。
カテゴリをまたいで直接比べること。 カテゴリごとに曲線が違うため、順位の数字は比較できても販売数の推算は比較できません。比べるならカテゴリ内の順位パーセンタイルにしてください。
自社の帳簿と突き合わせること。 自社の実売はセラーセントラルと SP-API に正確な認可データとして存在します。推算値で自分の帳簿を検算するのは、事実を推測で確かめる行為です。この境界はAmazon データ API の選び方で詳しく扱っています。
表にどう落とすか
リサーチ表を作っているなら、Amazon 商品リサーチ表の埋め方が表全体の構成を扱っています。この項目に関しては三点で足ります。
- 販売数の列に接尾辞か色を付け、価格や BSR と見た目で区別する
- 各行に取得時刻を残す。順位が動けば推算値も動くため
- 親か子かを列名に明記する
この三点を守れば、半年後にこの表を見返したときも、どの数字が引用できるかを判断できます。
よくある質問
なぜツールごとに月間販売数が違うのですか。 換算曲線が違うからです。順位は公開されていて共通ですが、曲線は各社独自のものです。多少の差は正常で、規模感は近いはずです。規模感すら合わない場合は、まず双方が同じカテゴリ階層を見ているか確認してください。
推算の精度はどれくらいですか。 カテゴリと順位帯によります。上位は標本が密で比較的安定し、ロングテールは標本が疎で振れます。一律の誤差率を期待しないでください。
競合の実際の販売数は取得できますか。 できません。実売はそのセラー自身のアカウントと認可データの中にしかありません。競合の正確な販売数を提供すると謳うものも、中身は推算です。
親と子のどちらを使うべきですか。 問いによります。その型を手掛けるべきか判断するなら親、ある色やサイズを仕入れるべきか判断するなら子。重要なのは表全体で統一することです。