Amazon のデータ分析：まず事実・推算・自分の判断を分ける

「Amazon のデータ分析」はたいていツールの問題として扱われます。どのソフトを使うか、どの指標を見るか。

しかし実際に壊れる場所はほとんどツールではありません。性質のまったく異なる三種類のデータが一枚の表に入り、同じものとして扱われることです。

三種類、三段階の信頼度

高くつく誤りは、二つ目が一つ目として使われることです。

販売数予測 API のフィールド名は estDailySales と estMonthSales であり、est は API 自身が付けた印です。プラットフォームはどの商品についても販売数を公開していないため、どこかで見た「月間 2,965 個」は調べた数字ではなく計算された数字です。桁を並べるには十分ですが、仕入れの根拠にはできません。この層の詳細はAmazon の販売数データで分かること・分からないことにあります。

三つ目が前二つに混ざるのは逆向きの誤りです。「このカテゴリには機会がありそうだ」と「このカテゴリの販売数の 83% は三年以上前の Listing に渡っている」を同じ列に書けば、三か月後にどちらがデータの発言だったか誰にも分からなくなります。

問いからデータを探す

分析の出発点は問いであって、ダッシュボードではありません。よくある問いはそれぞれ別のデータに対応します。

問いから始めるほうが、ダッシュボードを開いて規則性を探すより確実です。 ダッシュボードは最も動いた指標に注意を引きますが、最も動いたものはたいていノイズです。

全体に効く一つの記録規則

何を分析するにせよ、各行に二つを残してください。それがどの種類か（事実・推算・判断）、そしていつ取得したか。

タイムスタンプは最も省略されやすく、省略の代償が最も大きいものです。取得時刻が無ければ三か月後にその表がまだ使えるか判断できません。順位も価格もレビュー数も日々動きます。

当方が配っている表がいずれも取得日を独立した列にしているのもこのためです。商品リサーチ表、競合分析表、レビュー分析表。

公開データでは絶対にできない三つ

どんなツールを使っても、次の三つは取得できません。公開側に存在しないからです。

自社のアカウントデータ。 実際の注文数、広告費、検索語レポート、在庫 —— これらはセラーセントラルの認可データです。公開 API が扱うのは市場側で、両者は補完関係にあり代替にはなりません。

競合のアカウントデータ。 同じ理由で、相手のアカウントからしか見えません。競合の正確な販売数やバックエンド検索語を提供すると謳うものは、中身が推算です。

因果。 データは順位が落ちた、転換が下がったと教えますが、なぜかは教えません。原因は自分の変更記録と突き合わせる必要があり、だからリスティングを編集したときに時刻を残すことがどの分析ツールより役に立ちます。

この境界がどこから来るのか、なぜモデルがそれを越えて答えられないのかはAI が Amazon のデータに答えられない理由にあります。同じ認可の境界がデータを三つの塊に分ける仕組みはAmazon のデータはどこから来るのかにまとめてあります。

データを見る段階から API を呼ぶ段階へ

手作業の照会が高くつくのは、繰り返しになってからです。判断は単純で、毎週同じことを始めたら —— 同じ条件で絞り、同じ項目を書き出し、同じ式を当てる —— 定時ジョブにする頃合いです。

46 の API の用途別分類はAmazon データ API 完全ガイドに、導入前に決めることは導入前に決めておく五つのことにあります。定時実行の結果を前週と比較できる形にする方法はAmazon データ分析レポートの作り方で扱っています。

よくある質問

初心者はどの指標から見るべきですか。 指標から始めないでください。答えたい問いを一つ書き出し、そこから必要なフィールドを逆算します。そうすると大半の指標が自分の問いと無関係だと分かります。

ツールによって数字が合わないときは。 まず三点を揃えます。サイト、カテゴリ階層、取得時刻。この三つを揃えてなお残る差が定義の差です。価格・BSR・評価数といった公開項目は一致すべきで、販売数が一致しないのは正常です。

どれくらいの頻度で見直すべきですか。 データが動く速さに合わせます。価格とクーポンは日次、順位は週次で見て初めて意味があり、カテゴリ構造は月次か四半期。データの動きより速い頻度で見れば、見えるのはノイズだけです。

このデータをそのままモデルに渡してよいですか。 渡して構いませんし、分類はモデルに向く作業です。ただし出力は「判断」の種類に置かせ、元の事実と推算の列は残してください。モデルの結論とデータ自体は分離可能でなければなりません。