コンテンツにスキップ

Amazon DSP の配信実績を分析する

このページでは、Amazon DSP(Demand-Side Platform)の配信実績を分析できます。Sponsored Ads とは別の広告プロダクトである DSP は、管理単位も用語も異なり、キャンペーン / 広告グループではなく オーダー / ラインアイテム で管理します。DSP を配信しているアカウント専用のページです。

項目内容
このページでできることAmazon DSP の配信トレンド確認・オーダー / ラインアイテム別の成果分解・クリエイティブ疲労の兆候検知・DSP 込み / 抜きの TACoS 比較を一覧化する
対象Amazon DSP のみ。Sponsored Ads(SP / SB / SD)は別ページ(下記の note を参照)
必要なデータ・接続Picaro に連携された DSP レポートデータ(DSP を配信しているアカウント)。取得できるのはオーダー / ラインアイテム単位のインプレッション・クリック・注文・売上・CTR / CVR / ROAS・new-to-brand の週次 / 月次トレンド
取得できないものクリエイティブ単体の実績、フリークエンシー、オーディエンス別の内訳、CPM・ディールなどの DSP 詳細指標は取得できません
実行範囲分析のみ(読み取り専用)。DSP の入札・予算・クリエイティブ差し替えなどの設定変更は Picaro からは行えず、Amazon DSP コンソールでの操作になります
  • 直近数ヶ月の DSP 配信全体のトレンドを確認し、悪化している指標を早めに見つけたい
  • ラインアイテム別に成果を分解して、予算配分の見直しポイントを探したい
  • 配信を続けて CTR が落ちている(クリエイティブ疲労の疑いがある)ラインアイテムを検知したい
  • DSP が全体の広告効率(TACoS)に与えている影響を、DSP 込み / 抜きで分離して見たい
  • 接続先のアカウント … DSP を配信しているアカウントが対象です。複数アカウントを扱う場合は、対象アカウントが合っているか先に確認します。
  • DSP レポートの連携 … Picaro に DSP レポートデータが連携されている必要があります。
  • 対象期間 … 「直近 6 ヶ月を月次」「過去 12 週を週次」など。当日・前日のデータは未確定のことがあるため、確定済みの直近期間が安全です。
  • 売上の集計基準 … DSP 売上は DSP アトリビューション基準で、ダッシュボードの総売上とは基準が異なります(上記 caution を参照)。
やりたいこと分かること・作られるもの設定変更プロンプト
DSP 全体の配信トレンド(月次 / 週次)を確認する指標別の推移表とトレンド判定変更なしプロンプト 1
ラインアイテム別に成果を分解する(オーダーは絞り込み条件)成果の良し悪しの判定つき一覧変更なしプロンプト 2
クリエイティブ疲労(CTR の持続的低下)の兆候を検知する疲労の疑いラインアイテムの一覧変更なしプロンプト 3
DSP 込み / 抜きの TACoS を比較する込み / 抜き TACoS と差分・解説変更なしプロンプト 4

プロンプト 1: DSP 全体の配信実績の推移を確認する

Section titled “プロンプト 1: DSP 全体の配信実績の推移を確認する”

DSP 配信全体のインプレッション / クリック / 注文 / 売上 / CTR / CVR / ROAS / new-to-brand(NTB: ブランド新規顧客)の推移を月次または週次で確認します。

こんな時に使う — DSP 配信全体の状態を月次 / 週次で把握し、悪化している指標を早めに見つけたいとき。

実行前に必要な情報 — DSP レポート連携済みのアカウント。対象期間・粒度(既定は直近 6 ヶ月を月次)。

直近 6 ヶ月の Amazon DSP のパフォーマンストレンドを月次で出して。
インプレッション / クリック / 注文 / 売上 / CTR / CVR / ROAS / new-to-brand の推移を表で。
悪化している指標があれば指摘して。

変更できる条件 — 対象期間・粒度(例: 直近 12 週を週次で)。

返ってくる内容 — 月(または週)× 指標の推移表と、悪化・改善している指標のトレンド判定。売上は DSP アトリビューション基準の値です。

設定変更 — 分析のみ(読み取り専用)。DSP の設定変更はしません。

次にすること — 気になる指標があれば、プロンプト 2 でラインアイテム単位に分解します。


プロンプト 2: オーダー × ラインアイテム別に成果を分解する

Section titled “プロンプト 2: オーダー × ラインアイテム別に成果を分解する”

DSP の管理単位である ラインアイテム(配信設定の単位。広告グループに相当)ごとに成果を分解し、良し悪しを特定します。オーダー(Sponsored Ads のキャンペーンに相当)は絞り込み条件として使えますが、分解の軸はラインアイテム単位です。

こんな時に使う — 成果の良い / 悪いラインアイテムを特定し、予算配分の見直しポイントを洗い出したいとき。

実行前に必要な情報 — 対象期間(既定は過去 3 ヶ月)。特定のオーダー(絞り込み条件として)に絞ることもできます。

直近{{対象期間(例: 過去3ヶ月)}}のDSP配信を、ラインアイテム単位でパフォーマンス分解してください(オーダーは絞り込み条件としてのみ使用し、一覧取得はしない)。
【手順】
1. 取得経路
- ラインアイテム別の明細は `call_picaro_api` で POST `/dsp-report/dsp-performance`
(body: amazon_account_id, frequency, from_date, to_date)を使う。
応答の `data[]` のうち `type="Line item"` の配列が明細。
- **`get_dsp_trend` は明細取得には使わない。** このツールは期間バケットしか返さず、
`dsp_line_item_ids` は絞り込み条件であってラインアイテム軸の出力ではない。
2. 網羅率を必ず算定して冒頭に明示する(このAPIは total_count も truncated フラグも返さない)
- **対象期間を1ヶ月ずつに分割して取得する。**複数月を一括指定すると応答が
転送上限で silently 切断され、明細が欠落する。
- 各月について「Line item 行の広告費合計 ÷ 同期間の `get_dsp_trend` の spend」を計算し、
網羅率として明示する。95%未満の月は「明細が欠落している」と明記し、その月を
判断根拠に使わない。
3. 指標の単位と定義を確認・明示する
- **ROAS の単位**: `get_dsp_trend` の `totals.roas` は比率、`rows[].roas` と
`/dsp-report/dsp-performance` の `roas` は%(100倍)。倍率に統一して表記する。
- **CVR は使わない**: DSP の CVR は分子にビュースルー注文を含むのに分母がクリック数のため
100%を超える。転換率として解釈できないので判定に使わず、CPA と ROAS で判定する。
- **帰属モデル**: `/dsp-report/dsp-structure` でビュースルー経由/クリック経由の内訳を取得し、
ビュースルー比率を明示する。DSPのROASをクリック帰属媒体(SP/SB/SD)と同じ表に並べない。
4. 判定基準(「ROAS上位/下位N%」を単純適用しないこと)
- まず**広告費0のラインアイテムを判定対象から除外**する(停止済みで残存帰属だけが立つ行があり、
ROAS昇順で下位を占めるが減額対象になり得ない)。除外した行数と売上は別掲する。
- さらに**広告費が期間合計の3%以上の行のみ**を意思決定対象とする(広告費が数円〜数千円の行は
ROASが数万%に振れ判断に耐えない)。対象行が広告費の何%をカバーするか明示する。
- 対象行のROASを**期間全体のROAS(売上合計÷広告費合計)と比較**して好調/不調を判定する。
- 比率を出すたびに分子と分母を明示する。
5. 実行対象のIDを解決する
- `/dsp-report/dsp-performance` は**ラインアイテムIDを返さず名称のみ**で、名称は重複しうる。
- `call_picaro_api` POST `/bigquery/dsp-report/filter-data` でID・名称一覧を取得し、
`get_dsp_trend` に `dsp_line_item_ids=["<ID>"]` を渡して広告費・売上が明細行と一致するかで
IDを確定させる。**一意に特定できなかった行はその旨を明記する。**
6. 好調・不調それぞれについて「予算をX%増額/減額」の具体案を提示する。
【データ境界】
・`get_data_ingestion_status` で DSP report の確定日を確認し、未確定日(当日等)を期間に含めない。
・DSPの広告費は `/dsp-report/dsp-performance` の `spend` を使い、**どのツールから取得したかを明記する**。
 `get_amc_ntb_by_asin` の ad_spend(DSP行は0)と `total_dsp_spend`(全行同一の定数)は使わない。
【Guardrail】
・予算変更等の書き込み操作は実行しない。
・Guardrail KPI: CPA / Orders に加え、**網羅率**と**ビュースルー帰属比率**を必ず出力する。
最後に次の3点を出力してください。
1. 推奨アクション — 対象ラインアイテムごとの増額/減額幅・理由(ROAS/CPA、分子分母付き)・優先度(広告費インパクト順)・確信度・リスク。DSPはビュースルー帰属を含みインクリメンタリティが測定できないことを確信度の根拠に含める
2. 実行方法 — 提案内容をユーザーが確認・承認したうえで入札変更として反映する。渡す前に手順5でIDを確定させる
3. 測定 — 実行14日後に同じ経路でROASとCPAを再取得し、「施策の効果測定」で改善ならKeep、悪化ならRevertと判定する

変更できる条件 — 対象期間/対象とするオーダー(絞り込み条件)の範囲。

返ってくる内容 — ラインアイテム × 売上 / ROAS / CTR / CVR × 良し悪しの判定と検討ポイントの表(オーダーは絞り込み条件としてのみ使用)。提案は検討材料であり、実際の予算・配信変更は Amazon DSP コンソールで行います。

設定変更 — 分析・提案のみ(読み取り専用)。

次にすること — 実際の予算・配信の変更は Amazon DSP コンソールで手動で行います。


プロンプト 3: クリエイティブ疲労の兆候を検知する

Section titled “プロンプト 3: クリエイティブ疲労の兆候を検知する”

DSP はバナー / 動画などのクリエイティブを同じオーディエンスに繰り返し配信するため、時間の経過とともに CTR が徐々に低下する「クリエイティブ疲労」が起きやすい広告です。Picaro ではクリエイティブ単体の実績は取得できないため、ラインアイテム単位の CTR 週次トレンドから疲労の兆候を検知します。

こんな時に使う — 配信を続けて CTR が落ちているラインアイテムを見つけ、クリエイティブ差し替えを検討したいとき。

実行前に必要な情報 — なし(そのまま使えます)。低下幅の基準(例では 25%)は調整できます。

過去 12 週の DSP のラインアイテム別 CTR トレンドを週次で出して。
CTR がピーク週から 25% 以上低下し、直近 3 週連続で低下しているラインアイテムを
「クリエイティブ疲労の疑い」としてリスト化して。
配信期間の長さも併記して。

変更できる条件 — 低下幅の基準(例: 25%)/対象期間(例: 過去 12 週)。25% としているのは、週次の CTR は季節や曜日構成でも 1〜2 割程度は変動するため、それを超える持続的な低下だけを疲労の兆候として扱うためです。

返ってくる内容 — ラインアイテム × ピーク週 CTR × 直近 CTR × 低下率 × 連続低下週数 × 配信期間の表。疲労の疑いがあるラインアイテムは、Amazon DSP コンソールでのクリエイティブ差し替え・ローテーション見直しの検討対象になります。

設定変更 — 分析のみ(読み取り専用)。

次にすること — 疲労の疑いがあるラインアイテムのクリエイティブ差し替え・ローテーション見直しは、Amazon DSP コンソールで行います。


プロンプト 4: DSP 込み / 抜きの TACoS を比較する

Section titled “プロンプト 4: DSP 込み / 抜きの TACoS を比較する”

DSP を配信しているアカウントでは、TACoS(総売上に対する広告費比率)を「DSP 込み」と「DSP 抜き」の両方で見ることで、DSP が全体の広告効率に与えている影響を分離できます。

こんな時に使う — DSP が全体の広告効率にどれだけ効いているかを、DSP 込み / 抜きの TACoS で分離して見たいとき。

実行前に必要な情報 — なし(そのまま使えます)。対象期間(例: 先月、過去 3 ヶ月を月次で)。

目的: DSPが広告費対効果全体(TACOS)に与える影響を判断し、DSP予算配分を検討するため、
{{対象期間(例: 当月MTD)}}と{{比較期間(例: 前月同日数窓)}}のTACOS(DSP込み/抜き)を比較してください。
【データ取得(必ずこの順で行い、TACOSを自前で計算しないこと)】
1. 総売上・広告費・TACOSはPicaroから取得します。ユーザーに総売上を入力させないでください。
`/bigquery/advertising-metrix`(call_picaro_api, POST, frequency=daily または monthly)を
対象期間・比較期間それぞれについて**個別に**呼び、次をそのまま使ってください。
- total_sales(総売上・税抜)
- ad_spend(広告費。DSPを含まない)
- tacos_with_dsp / tacos_without_dsp(BEが返す計算値。両者は同一の総売上を分母に持つ)
- ad_revenue / acos(Guardrail用)
2期間を1回の呼び出しの previous_value で済ませないこと。previous_value は
「同日数の直前窓」であって前暦月ではなく、period_tooltip の期間ラベルが実体とずれる
ことがあります。必ず期間ごとに個別呼び出しし、応答の from_date / to_date が
要求と一致していることを確認してください。
2. `get_data_ingestion_status` で対象期間の取込状況を確認し、未確定日を含む場合は
「未確定を含む暫定値」と明記してください。当月は月途中のため確定月として扱わないこと。
3. DSPの配信実態(インプレッション・費用・ROAS・new-to-brand)は `get_dsp_trend` を使います。
ただし **frequency=monthly は未完了の当月を返しません**(period_count=0 /
status=empty / warnings=["dsp_no_rows"])。当月を見るときは frequency=weekly を使い、
週バケットが暦月境界と一致しないこと(月初・月末の欠落日数)を明記してください。
**行が空でも「DSP費用0」「DSP未実施」と断定しないこと。** 未取得・0・nullを区別すること。
また rows[] の cvr / ctr / roas は totals と桁が異なる(rows は百分率、totals は比率)ため、
比率は totals 側を使ってください。
【比較の条件(必須)】
- 2期間は**同一日数・同一暦位置の窓**に揃えてください(例: 当月1〜N日 vs 前月1〜N日)。
月全体と月途中を直接比較しないこと。揃えられない場合は比較せず、その理由を書いてください。
- DSP込みTACOSとDSP抜きTACOSは**同一の総売上(分母)**を用いた値であることを確認し、
DSP attributed sales を総売上に加算しないでください。
- 検算: (tacos_with_dsp − tacos_without_dsp) × total_sales ≒ DSP広告費 となることを確認し、
一致しなければ数値を提示せず不一致として報告してください。
【出力(必須項目)】
1. 対象期間・比較期間の実日数と、取込ステータス(確定/未確定)
2. 期間ごとの表: 総売上 / 広告費(DSP抜き)/ DSP広告費 / TACOS(DSP抜き) / TACOS(DSP込み) /
DSP寄与pt(= 込み − 抜き)/ 広告経由売上 / ACoS
3. **比率変化が分母由来か分子由来かの判別**(必須):
- 総売上の変化率と広告費の変化率を併記する
- 「分母を比較期間の水準に固定した場合のTACOS」を計算し、実際の変化と対比して
分母由来分と分子由来分を分離して示す
- 分母(総売上)の縮小によるTACOS悪化を、広告効率の悪化として報告しないこと
4. 判断: 判断基準 {{TACOS悪化の閾値(例: 0.5pt)}} に照らし、DSP予算を維持/増額/縮小の
いずれにすべきかと、その根拠。閾値に該当しても、悪化が分母由来である場合はその旨を
明示し、DSPを要因と断定しないこと。
5. Guardrail: ACoSと広告経由売上が悪化しない範囲での変更案。DSPのROASと
new-to-brand(新規顧客獲得)への影響も併記すること。
6. 数値の制約を明記: TACOSは小数第2位丸めであること、広告費の税区分が未確定で
ACoSとTACoSのうち一方が税基準を跨ぐこと(JPアカウント)、確定済み期間も
re-crawl/backfillで再計上されうること。
DSP予算の変更は、提案内容をユーザーが確認・承認したうえで入札変更として反映してください。次月に再測定し、
「施策の効果測定」でKeep(維持)かRevert(差し戻し)かを判断してください。

変更できる条件 — 対象期間(例: 先月、過去 3 ヶ月を月次で)。

返ってくる内容 — 期間ごとの DSP 込み TACoS / DSP 抜き TACoS / 差分と、DSP の寄与についての解説。

設定変更 — 分析のみ(読み取り専用)。

次にすること — 戦略レベルの予算配分の検討は 広告戦略を立案する を参照します。