Amazon キーワード順位の監視：三層に分け、集計から入って掘り下げる

キーワード順位監視の最初の版はたいていこうなります。逆引きで取れた語を全部保存し、毎日回し、データベースに書き込む。

一か月後に分かることが二つあります。表は非常に大きくなり、そして誰も見ません。 毎日変わる二千行の数字は具体的な問いに答えませんし、順位はもともと揺れるので、どの変化に対応すべきかも判別できないからです。

使われる監視は層に分かれています。

各層が答えるもの

順序が重要です。まず集計、異常なら掘り下げ、掘る前に市場で除外する。 単語層から始めると、誰も見ない大きな表に戻ってしまいます。

集計層：五つの数字で足りる

流入キーワード統計 API は ASIN 単位の集計値を返します。月に一度記録するのに最も向く層です。

月に 1 行、年に 12 行。それでも傾向は読めます。面積が広がっているか縮んでいるか、自然の分がそれに追随しているか。

そのまま計算できる数字

この三つを見てください。1848 + 1414 = 3262 で、総数 2685 より 577 多い。

この超過分はデータの誤りではありません。自然枠と広告枠の両方を取っている語です。一つの語が両側に掲載されうるため、二つの計数が重複して数えます。

二重掲載の語数 ≈ ranks + ads − keywords

この数字は月次で記録する価値があります。「すでに自然順位で上位なのに広告費も払っている」候補群そのものだからです。止めるべきとは限りませんが、理由のある判断であるべきです。その扱い方はAmazon キーワードの最適化にあります。

badgeCount はさらに細分されます。ns 自然検索、ac Amazon's Choice、er 編集推薦、fs 4 星、sb ブランド広告、sv 動画広告、ad SP 広告。ns と ad の比を記録するほうが、どちらの絶対値よりも多くを語ります。 露出のうち勝ち取った分と買った分の割合だからです。

単語層：掘り下げるときだけ

集計層に異常が出たときに個別の語を見ます。逆引きの各語は rankPosition と adPosition を持ち、それぞれ page、index、position に分かれ、updatedTime も付きます。

時系列比較の二原則。

page ではなく position を使う。 1 ページの件数は固定ではなく、ページ番号は比較できません。

updatedTime を必ず一緒に保存する。 順位は標本であり、タイムスタンプの無い順位は二週間後に使えるか判断できません。

フィールドの読み方はAmazon ASIN のキーワード逆引きで詳しく扱っています。 順位が上がった後にそれが見合うかは、その語の 1 ページ目のクリックの分かれ方で決まります。キーワードを 1 ページ目に載せるを参照してください。

市場層：まずここで除外する

最も飛ばされやすく、その不在が最も多くの誤読を生む層です。

ある語の順位が下がったとき、本能はリスティングの変更を疑います。しかしもう一つの可能性があります。その語自体の検索需要が落ちていて、自分の位置は動いていない。

キーワードトレンド API は語ごとの時系列を返します。

chainGrowth と yearlyGrowth は一緒に読みます。二種類の下落を分離するからです。

• 前期比マイナス、前年同期比は横ばい → おそらく季節性。昨年の同時期もこうだった
• 両方マイナス → その語の需要が実際に縮小中。自分のせいではないが、語を替える必要がある
• 両方横ばいで自分の位置だけ下落 → ここで初めて自分の問題

この手順を飛ばす代償は具体的です。 季節的に落ちている語のためにタイトルを書き換え予算を増やし、二か月後に需要が勝手に戻る。そして誤った結論が有効な施策として記録に残ります。

実装上の細部を一つ。この API のレスポンスフィールドの綴りは keyword ではなく keywrod です（リクエストパラメータは keyword）。フィールド名で値を取るときに注意してください。

頻度と呼び出し量

この層分けなら、全件日次に比べて一桁少なく済みます。

• 集計層：ASIN ごとに月 1 回
• 市場層：特定の語を判断するときだけ、語単位で
• 単語層：集計に異常があるときだけ、関係する語だけ

比較すると、ASIN 20 件を全件日次で逆引きすればページ送りを除いても月 600 回超。層分けなら集計層は月 20 回です。

順位を日次で見張る意味は小さいものです。日次の解像度ではノイズが信号を大きく上回り、集計層の変化は月次で見て初めて方向が出ます。

このデータにできない三つ

自社のバックエンド検索キーワードレポートは取得できません。 それはセラーアカウントの認可データで、ここで使うのはすべて公開側です。

順位が動いた理由は説明できません。 データが示すのは変化量までで、原因は自分の変更記録と突き合わせる必要があります。だからリスティングを編集したときに時刻を残すことが、どんな監視の仕組みより役に立ちます。

手動検索では API の順位を再現できません。 検索結果は位置情報、ログイン状態、過去の行動に左右されるため、手で「検証」しても信頼できない数字が二つ増えるだけです。鮮度は updatedTime で判断してください。

よくある質問

どれくらい下がったら本当に下がったと言えますか。 一律の閾値はありません。集計層で自分の変動幅を先に作るのが現実的です。三か月連続で記録し、その幅を外れたときだけ掘り下げます。

何語を監視すべきですか。 集計層は選ぶ必要がありません。すでに全件の集計です。単語層では実際に運用している数十語だけを見てください。二千語ではありません。

どれくらいの頻度で取得すべきですか。 集計層は月次、市場層は判断するときに。日次監視は、広告を回して日次で入札を調整しているのでなければ見返りが小さいです。

サイトごとに分けて監視すべきですか。 分けてください。検索量、競争の強さ、言い回しはサイトごとに独立しています。三つの API すべてに marketplace があります。まとめて一枚の表にしないでください。