検索から購入までのどこでつまずいているかを分析する（SQP）

このページでは、買い物客が Amazon で検索してから購入するまでの流れの、どの段階に弱点があるかを商品 × 検索語句で見つけます。検索されて表示される → クリックされる → カートに追加される → 購入される、という段階のどこで取りこぼしているかが分かるので、広告や商品ページの改善につなげられます。

広告データを使う N-gram で成果の高い検索パターンを分析するが自社の広告内の効率を見るのに対し、このページは Amazon の買い物客全体の検索行動（市場全体）を見る分析です。

このページの基本情報

項目	内容
このページでできること	商品 × 検索語句ごとに、検索から購入までの各段階のうちどこがボトルネックかを一覧化し、伸ばす余地（機会スコア）が大きいものを見つける
対象	市場全体の検索データ（Amazon Brand Analytics 由来の SQP データ）。自社の広告実績ではなく、Amazon ユーザー全体の検索行動が見える
必要なデータ・接続	SQP データを取り込み済みの商品（接続済みアカウントで、対象商品の SQP が取得できていること）
実行範囲	分析のみ（読み取り専用）。このページのプロンプトはファネルの状況を一覧化するだけで、広告設定や商品ページの変更・記録は行いません

SQP（Search Query Performance ＝検索クエリの成果） … 買い物客の「検索 → 表示 → クリック → カート追加 → 購入」という流れを検索語句ごとにまとめた、市場全体のデータ。Amazon Brand Analytics に由来します。
ファネル … 検索から購入までの段階のこと。上流（表示回数）から下流（購入）に向かって数が絞られていく様子を漏斗（ファネル）に例えた言い方です。
ボトルネック … ファネルのうち取りこぼしが大きい段階。分類は「表示回数不足 / クリック率が低い / カート追加率が低い / 購入率が低い」の 4 つです。
機会スコア … その検索語句をどれだけ伸ばせそうか（伸びしろの大きさ）を表す指標。数値が大きいほど、改善したときの効果が大きい候補です。
自社購入シェア … その検索語句での購入のうち、自社商品が占めた割合。市場全体のうち自社が取れたシェアの目安になります。
匿名化率 … 検索語句の一部が匿名化されて提供される割合。匿名化された検索語句は個別には特定できません。【要確認: 匿名化の詳細な条件は Amazon 側の仕様に依存】

こんな時に使います

検索から購入までのどの段階に弱点があるかを、商品 × 検索語句で見つけたい
表示はされているのにクリックされていない、あるいはカートに入っても購入されない、といったボトルネックを特定したい
伸ばす余地（機会スコア）が大きい検索語句を優先的に把握したい
季節要因や中長期のトレンドで、検索ファネルが月ごとにどう動いているかを確認したい
月末レポートを作る前に、貢献度スライドに必要なデータが揃っているかを先に確かめたい

実行前に確認すること

SQP データの有無 … SQP データを取り込めていない商品は分析に使えません。取得済みの商品のみが対象です。
対象商品の指定方法 … 商品は ASIN（例: B0XXXXXXXX）または 社内 ID（Picaro に登録した商品の管理 ID）で指定します。どちらで指定するかを混同しないよう、手元でどちらの番号を使うか決めておきます。
取得できる期間 … Amazon 側のレポート確定までに数日のラグがあり、当日の最新週・最新月はまだ使えません。取得可能な期間リストの最終週・最終月が確定済みの期間です。
データの提供開始時期 … 商品によって SQP データの提供開始時期が異なります。まず利用可能な期間リストを確認してから対象期間を選びます。

プロンプト早見表

やりたいこと	分かること・作られるもの	設定変更	プロンプト
商品ごとに検索ファネルの弱点（ボトルネック）を見つける	商品 × 検索語句別の機会スコア・ボトルネック分類の一覧	変更なし	プロンプト 1
検索ファネルの月ごとの推移を確認する	月次の機会スコア・ボトルネック・前月比の一覧	変更なし	プロンプト 2
レポート作成前に貢献度データが揃っているか確認する	データの有無・行数・匿名化率・代替可否の判定	変更なし	プロンプト 3

プロンプト 1: 商品ごとに検索ファネルの弱点を見つける

SQP 対象の商品と取得できる期間を順に確認したうえで、検索から購入までの各段階の機会スコアとボトルネックを、商品 × 検索語句で算出します。

こんな時に使う — どの検索語句で、どの段階（表示・クリック・カート追加・購入）を取りこぼしているかを見極めたいとき。

実行前に必要な情報 — 特になし（対象商品と期間は AI が候補を出してから選べます）。表示件数（例では上位 30 件）。

SQP分析を実行したい。以下の手順で:

1. SQPデータが取れる商品候補を一覧し、対象商品を1つ選ぶ
   - 一覧が返す crawl_status は SQP データの有無を示さない。値に関わらず対象にしてよい
2. 対象商品の利用可能な週次期間を取得する
3. 直近の確定週を決める
   - 一覧の最終週を候補とし、同じ週で別商品を1件試し、自社インプレッションが桁落ちしていないかを確認する
   - 対象商品だけ極端に小さい場合は「実際の露出減」と「データ未確定」を区別して明記する（推測で埋めない）
4. その確定週で上位30件のファネル分析（インプレッション → クリック → カート追加 → 購入）を実行し、
   機会スコアとボトルネック分類を出す
   - 総件数と取得件数を突き合わせ、網羅率を明記する
   - 自社値が 0 のものは「未取得」ではなく「実測 0」として区別する

集計から除外するもの:
- Amazon の集約プレースホルダークエリ（「ノーブランド品」など、特定商品を指さない語）
- 検索ボリュームが {{最小検索ボリューム（例: 1000）}} 未満のクエリ（母数不足で機会スコアが不安定なため）

判定基準（返ってきたボトルネック区分をすべて割り当てること。2区分に収まらない場合は区分名のまま報告する）:
- 露出不足（exposure_gap）→ 入札/予算/プレースメント調整を検討
- クリック転換不足（click_gap）→ 検索語句/クリエイティブ側の要因分析へ
- カート追加不足（cart_gap）→ 商品ページ（価格・画像・レビュー・バリエーション）の要因分析へ
- 購入転換不足（purchase_gap）→ 価格競争力・在庫・配送条件の確認へ
- 優位維持（defend）→ 現状維持。入札を下げない監視対象として記録

最後に次の4点を出力してください。
1. データ前提 — 対象商品・対象週・総件数/取得件数と網羅率・除外したクエリ数・確定週の判断根拠
2. 推奨アクション — 除外後の機会スコア上位3件について、対応方針（露出強化 / CVR改善 / 商品ページ改善 / 現状維持）を
   対象・理由（ファネルのどの段が落ちているか）とともに示す
3. 実行方法 — 露出強化は、提案内容をユーザーが確認・承認したうえで入札変更として反映する。CVR改善はN-gram分析へ渡す
4. 測定 — {{評価日（例: 4週間後）}}に同商品・同条件で再実行し、ボトルネック区分の改善有無と
   自社インプレッションシェアの変化を確認する

変更できる条件 — 表示件数（例: 上位 30 件）／対象商品／対象週。

返ってくる内容 — 商品 × 検索語句ごとに、機会スコア × 自社購入シェア × ボトルネック分類（表示回数不足 / クリック率が低い / カート追加率が低い / 購入率が低い）を並べた一覧表。

設定変更 — 分析のみ。広告設定や記録は変更しません。

次にすること — 機会スコアが高い語句は入札単価を調整するの承認フローで入札引き上げを検討します。自社広告内の検索パターンと突き合わせたい場合は N-gram で成果の高い検索パターンを分析するを使います。

プロンプト 2: 検索ファネルの月ごとの推移を確認する

週次よりも長いスパンで、商品の検索ファネルが季節要因や中長期トレンドでどう動いているかを月単位で把握します。

こんな時に使う — 検索ファネルの弱点が一時的なものか、それとも継続している傾向かを、月ごとの推移で確かめたいとき。

実行前に必要な情報 — 対象商品（ASIN または社内 ID）。表示件数（例では上位 30 件）。

商品 {{対象商品ASIN（例: B0XXXXXXXX）}} について、月単位でSQP推移分析を実行して。

手順:
1. 商品候補一覧から対象ASINのproduct_idを特定する（SQP分析はASINではなくproduct_idを要求するため）。
2. 月次の利用可能期間を確認する。期間候補の最新月が実行日を含む月（月の途中）である場合は、その1つ前を「最新の確定月」として使う。月次候補が非連続（欠落月がある）な場合は、その旨を明記する。
3. 月次データが2ヶ月未満の場合のみ週次（直近12週）にフォールバックし、その旨を明記する。
4. 最新の確定月と、その前月の2ヶ月を取得する。**取得は上位100件で行い、レポートには上位30件を表示する**（表示件数を絞ると前月のベースラインが欠落し、前月比が算出できないクエリが増えるため）。
5. 最新確定月について、機会スコアとボトルネック分類を出す。
6. 2ヶ月をクエリ単位で突き合わせ、Impression Shareの前月比（pt差）を自分で算出する。

データの扱い（必須）:
- レスポンスのChangeBps系（ctrChangeBps / atcChangeBps / cvrChangeBps）は「自社ASIN値 − 市場全体値」のギャップであり、**前月比ではない**。前月比として使わないこと。Impression Shareには差分フィールドが存在しないため、2ヶ月分から自分で算出すること。
- 前月のデータに存在しないクエリは「判定不能」と明記する。**0や「悪化なし」として扱わない。**
- 「ノーブランド品」等のAmazon側の集約プレースホルダーは実行可能な検索語句ではないため、アクション対象から除外する（機会スコアが上位でも同様）。
- 市場全体の検索ボリューム・インプレッションの前月比も併記し、Impression Shareの低下が「市場拡大による希釈」か「自社露出の絶対減」かを区別する。

判定基準:
- ボトルネックが「露出不足」→入札/予算調整の検討対象として明示
- 前月比でImpression Shareが{{悪化閾値（例: -1pt）}}超で悪化→「要対応」

最後に次の3点を出力してください。
1. 推奨アクション — 「要対応」の場合は露出強化（入札/予算調整）の対象・理由を示す。あわせてガードレールとしてCVR（自社ASINのCVR）の前月比を確認し、CVRが悪化している局面では対象を優先度上位に限定するか増額を見送る条件を明示する
2. 実行方法 — 提案内容をユーザーが確認・承認したうえで入札変更として反映するか、またはCVR改善が必要ならN-gram分析へ渡す（本プロンプトは分析のみで、入札・予算の変更は実行しない）
3. 測定 — {{評価日（例: 翌月）}}に同分析を再実行し、Impression Share（Primary KPI）とCVR（Guardrail KPI）とボトルネック区分の変化を確認する

変更できる条件 — 対象商品（ASIN または社内 ID で指定）／表示件数（例: 上位 30 件）／対象月。

返ってくる内容 — 月次の検索語句ごとに、機会スコア × 自社購入シェア × ボトルネック × 前月比を並べた一覧表。

設定変更 — 分析のみ。広告設定や記録は変更しません。

次にすること — トレンドが確認できた語句は入札単価を調整するや除外キーワードを追加するの承認フローで対応を検討します。

プロンプト 3: レポート作成前に貢献度データが揃っているか確認する

月末レポートを生成する前に、貢献度スライドに必要な SQP・広告データが揃っているかを、軽い処理で先に確認します。

こんな時に使う — レポート生成に時間をかける前に、対象期間のデータが十分あるか、匿名化でデータが薄くなっていないかを確かめたいとき。

実行前に必要な情報 — 対象期間と比較期間（例では当月と前月）。

期間 {{対象期間（例: 2026-04-01〜2026-04-30）}}、比較期間 {{比較期間（例: 2026-03-01〜2026-03-31）}}で
貢献度データの事前確認を実行して。目的は本番の貢献度分析・レポート生成を走らせる前に
「データが足りているか」を判定することなので、次の3状態を必ず区別して報告して。

A) データ有り（分析可能）
B) データ無し（実測でゼロ）
C) 取得できなかった（タイムアウト／ページ打ち切り／未取込）

手順:
1. get_data_ingestion_status で対象期間・比較期間の取込状況を確認する。
   rollup_status が fully_missed / partially_missed / in_progress の日付、および
   out_of_range の日付を日付単位で列挙する。確定していない日を含む期間は
   「未確定日を含む」と明記し、除外したならその旨も書く。
   ★ rollup_status は、大半のレポートが completed でも no_data を返すことがある
     （配信実績のないレポート種別が混じると日全体が no_data になる）。
     rollup_status だけでその日を「データ無し」と断定せず、レポート別の status を見て
     「完了したレポート数 / 総レポート数」と未取得のレポート名を名指しで示すこと。
2. precheck_contribution_data を実行する（max_pages を明示的に指定すること）。
   ★ 応答の rows は「取得したサンプル行数」であって母集団の件数ではない。
     rows が max_pages×200 と一致する場合は打ち切られているので
     「rows = 取得サンプル数（打ち切りあり）」として報告し、
     rows の大小でデータの有無を判定しない。
   ★ totalImpressions が 0 なら、rows が何行あってもデータ無し(B)と判定する。
3. 母集団の総件数を list_search_term_performance の total_results /
   search_term_total_pages_available / search_term_fetch_truncated、および
   analyze_search_term_contribution の total_items から取得し、
   「サンプル数 / 母集団総数（カバー率%）」の形で必ず併記する。
4. 匿名化された検索語句の割合は rowsWithoutSearchTerm / rows で算出し、
   「サンプル基準・母集団の下限推定値」であることを明記する
   （貢献度降順のサンプルのため母集団の実際の匿名化率はこれより高くなる）。
   max_pages を変えると値が動く点も添える。
   この下限推定値が {{閾値（例: 50%）}} を超えた場合は、母集団ではさらに高いことが確実なので
   その時点で「データ不足」と判定してよい。超えない場合は「閾値未満（ただし下限推定のため
   母集団では超える可能性あり）」と書き、閾値未満であることを分析続行の根拠にしない。
5. 代替データ（ラベル別集計等）で補えるかを、上の実測値に基づいて可否で示す。

判定と接続:
- B または C に該当する場合は「データ不足」と明記し、何が・どの期間で・
  どの状態(B か C か)不足しているかを日付単位で示したうえで、代替データでの代用可否を提示する。
  C の場合に「データが無い」とは書かない。
- A の場合のみ、次のプロンプト {{接続先（例: レポートを作成するプロンプト）}} に渡せる形で、
  対象期間・比較期間・カバー率・匿名化率（下限推定）・除外した日付を引き継ぎサマリとして出力する。

変更できる条件 — 対象期間／比較期間。

返ってくる内容 — データの有無 × 各期間の行数 × 匿名化率 × 代替データで補えるか、と、次の 3 段階の判定。

準備完了 … そのままレポートを生成できる状態。
要確認 … 生成はできるが、匿名化率やデータ量に注意が必要な状態。
実行不可 … データが不足していてレポートを生成できない状態。

設定変更 — 分析のみ。広告設定や記録は変更しません。

次にすること — 判定が「準備完了」ならレポートを作成するに進みます。「実行不可」の場合は、対象期間を広げるか、プロンプト 2 の代替案でデータの取れる期間に合わせます。

検索から購入までのどこでつまずいているかを分析する（SQP）

このページの基本情報

こんな時に使います

実行前に確認すること

プロンプト早見表

プロンプト 1: 商品ごとに検索ファネルの弱点を見つける

プロンプト 2: 検索ファネルの月ごとの推移を確認する

プロンプト 3: レポート作成前に貢献度データが揃っているか確認する

関連カテゴリ