Skip to main content
メディアバイの現在の運用状態(設定、クリエイティブ承認ステータス、不足アセット、オプションのほぼリアルタイム配信スナップショット)を取得します。 応答時間: 約1秒

結果のスコープ

セールスエージェントは、認証済みアカウントが所有するすべてのメディアバイを返さなければなりません(MUST)。そのバイがどのように作成されたか——AdCP の create_media_buy 経由、セラー自身の API 経由、手動トラフィッキング経由、レガシーまたはサードパーティのシステム経由——は問いません。スコープはアカウントの所有権であり、作成のサーフェスではありません。ここで返される media_buy_id は、認証済みの呼び出し元がアクセスできるセラーのアドサーバー上の任意のオーダーを識別します。 get_media_buys が返すメディアバイはすべて、その valid_actions にあるすべてのタスクから到達可能でなければなりません(MUST)。セールスエージェントは、元々 AdCP 経由で作成されたものではないことを理由に、バイを読み取り専用としたり、隠したり、更新を拒否したりしてはなりません(MUST NOT)。ビジネス上の理由(契約上の義務、プラットフォームの制約、ポリシー)でアクションが利用できない場合、セラーはそのアクションのみを valid_actions から省略しなければなりません(MUST)——セット全体を省略してはならず、単に AdCP の外で作成されたという理由だけで省略してもなりません。AdCP 外のバイを体系的に空の valid_actions で返すセラーは非準拠です。そのパターンは、バイを隠しているのと区別がつきません。 呼び出し元からインベントリを分離する必要があるセラーは、アカウント内ではなくアカウント境界で行わなければなりません(MUST)。アカウントの所有権と作成サーフェスを参照してください。 リクエストスキーマ: /schemas/v3/media-buy/get-media-buys-request.json レスポンススキーマ: /schemas/v3/media-buy/get-media-buys-response.json

リクエストパラメータ

*media_buy_ids は結果を特定のメディアバイに絞り込む。どちらも指定しない場合、クエリはスコープベースとなり status_filterpagination を使用します。 media_buy_ids を指定した場合、暗黙的なステータスフィルタリングは適用されない。特定のバイをステータスでフィルタリングしたい場合は status_filter を明示的に渡すこと。

レスポンス

現在のステータス、クリエイティブ承認状態、オプションの配信スナップショットを含むメディアバイの配列を返します:

メディアバイオブジェクト

3.1 の語彙に関する注記。 get_media_buys はライフサイクルの状態をネストされた media_buys[].status フィールドで返します(深さ 1 にネストされているため、エンベロープとの衝突はありません)。create_media_buyupdate_media_buy の成功レスポンスは、同じ状態をトップレベルの media_buy_status フィールドで返します(エンベロープのタスクステータス status との衝突を避けるため 3.1 で追加)。3.1 では同じ列挙に対して二つのフィールド名が存在し、この連鎖は 4.0 で統合されます(#4905)。呼び出しをまたいで状態を保持するバイヤーは、両者を同じ論理的な値として扱うべきです。全体像についてはマイグレーション › media_buy_statusを参照してください。

パッケージオブジェクト

クリエイティブ承認オブジェクト

クリエイティブライブラリを持たずに inline_creative_management を表明しているセラーの場合、creative_approvals は、パッケージに現在割り当てられているインラインクリエイティブの承認状態を読み戻す唯一の標準化されたサーフェスです。creative_idapproval_status、任意の rejection_reason をレポートしますが、create_media_buyupdate_media_buy で送信された完全な CreativeAsset のペイロード、プレースメントのルーティング、ウェイト、過去のリビジョンは含みません。インライン専用のセラーと連携するバイヤーは、自分たちが送信したクリエイティブ本体を保持しておくべきです。 クリエイティブの修正は approval_status: "rejected" と特定の rejection_reason で表現されます。クリエイティブ編集のためのパッケージレベルの input-required ステータスは存在しません。修正済みのライブラリアセットは sync_creatives で、修正済みのインライン専用パッケージアセットは update_media_buypackages[].creatives でアップロードすること。

履歴エントリオブジェクト

履歴エントリは追記専用です——セラーは既に出力したエントリを変更または削除してはなりません(MUST NOT)。呼び出し元はリビジョン番号でエントリをキャッシュしてもかまいません(MAY)。 revision は、セラーが状態を変更する変更または更新を適用した場合にのみ増加します。読み取り、バリデーションのみの呼び出し、完全に冪等な再実行では、履歴エントリは作成されず、リビジョンも増えません。バイヤーは、返されたリビジョンを、状態変更を意図した次の update_media_buy 呼び出しのためのトークンとして扱うべきです。 confirmed_at は配信ステータスのタイムスタンプではありません。セラーのコミットを記録するものであり、その後の一時停止/再開、アクティベーション、完了、キャンセル、レポーティングの変更を通じて安定したままです。

スナップショットオブジェクト

not_delivering は、パッケージが予定されたフライト期間内にあるにもかかわらず、少なくとも1回分の staleness サイクルでゼロインプレッションを記録したことを意味します。実装者はパッケージ起動から staleness_seconds が経過するまで not_delivering を返してはなりません — 最初の数分間インプレッションのない新しいパッケージは想定内であり、問題ではありません。このステータスに基づいて行動する前に、start_time を確認してパッケージがフライト期間内にあることを確認すること。 金額フィールドは次の通貨優先順位を使用します: snapshot.currency -> package.currency -> media_buy.currency

ウェブフックアクティビティ

include_webhook_activity: true の場合、返される各メディアバイは、セラーからバイヤーの登録済みエンドポイントへの最近のレポーティングおよびヘルスのウェブフック発火を記述する webhook_activity 配列を持つことがあります(MAY)。これは永続チャネルのウェブフック契約におけるバイヤー側のデバッグ用サーフェスです——バイヤーはこれを使って、セラーのログに対するオペレーターレベルのクエリを必要とせずに、パブリッシャーが発火したか、バイヤーのゲートウェイが何を返したか、リトライがまだ進行中かを確認します。 レコードの形状、リクエストフィールド名、スコープ、保持期間の下限、三状態の存在、カーディナリティのルールは、このサーフェスを採用する AdCP のリソース全体で統一されています。リソース横断の規範的な節については、スナップショット/ログ契約のページのウェブフックアクティビティログのパターンを参照してください——以下のルールは、それをメディアバイの呼び出し箇所向けに再掲し、メディアバイ固有のケイパビリティゲートを追加したものです。 このサーフェスは、配信レポートの通知タイプ(scheduledfinaldelayedadjusted)とヘルスの通知タイプ(impairment)の両方を対象とします。いずれも同じウェブフック配信契約と、同じバイヤー側のデバッグ上のニーズを共有します。 ステータスのセマンティクス:
  • success — 2xx ステータスのレスポンスを受信。http_status_code に値が入ります。
  • failed — 2xx 以外のステータスのレスポンスを受信。http_status_code に値が入り、error_message がレスポンスを説明します。
  • timeout — セラーが設定したタイムアウト内にレスポンスがありませんでした。http_status_code は null。運用上の意味: バイヤーのエンドポイントには到達できるが、遅いか過負荷である。
  • connection_error — HTTP レスポンスの前に DNS、TLS、またはソケットが失敗しました。http_status_code は null。運用上の意味: バイヤーのエンドポイントに到達できないか、設定が誤っている。
  • pending — 試行が実行中またはリトライのためにキューに入っています。completed_at は null。後続の試行は同じ idempotency_key と増加した attempt で現れます。
レコードのカーディナリティ: 試行ごとに 1 レコード。初回試行で成功した発火は attempt: 1 の単一レコードとして現れます。3 回試行のリトライの軌跡(例: 2 回失敗して 1 回成功)は、idempotency_key を共有する 3 レコードとして現れます。 スコープ(規範的):
  • webhook_activity呼び出し元プリンシパルにスコープされなければなりません(MUST)。複数のバイヤープリンシパルがアカウントレベルのアクセスを通じて同じメディアバイを閲覧できる場合、各プリンシパルは自分自身のエンドポイントを対象とする発火のみを見ます。
  • このフィールドを公開するセラーは、各レコードの completed_at から少なくとも 30 日間、レコードを保持しなければなりません(MUST)——successfailedtimeoutconnection_error の各結果(いずれも completed_at に値が入ります)にわたって一律にです。まだ pending ステータスのレコードでは、試行が終了するまでは fired_at から起算し、その後 completed_at から 30 日間に移行します——リトライの軌跡が途中で消えることはありません。この下限を守れないセラーは、より短いウィンドウを返すのではなく、フィールドを完全に省略しなければなりません(MUST)。三状態の存在セマンティクスは、セラーにきれいなオプトアウトを、バイヤーには依拠できる単一の保証を与えます。
  • このサーフェスはデバッグの補助であり、完全な監査ログではありません。webhook_activity_limit を超えた古い発火のためのカーソルはありません——完全な履歴が必要なバイヤーは、自分たちの側でウェブフックのレコードを永続化しなければなりません。
三状態の存在セマンティクス: 宣言した propagation_surfaceswebhook が含まれないセラーは、フィールドを省略しなければなりません(MUST)。include_webhook_activity: true でオプトインしても、それは上書きされません。 予期しない省略の診断。 発火があるはずなのにフィールドが省略されていた場合、チケットを起票せずに原因を切り分けられる観測点が二つあります。(1) このバイに対する自分の push_notification_config の登録状態を確認する——登録されていなければ、それが原因です。(2) get_adcp_capabilities を通じてセラーの capabilities.media_buy.propagation_surfaces を確認する——webhook が不在なら、それが原因です。両方とも問題なければ、残る原因は「セラーが発火履歴を永続化していない」であり、これはセラー側のギャップなのでオペレーターへのチケットを起票する価値があります。 プライバシー:
  • url フィールドはクエリ文字列とフラグメントが除去されており、セラーは共有シークレットに見えるパスセグメント(高エントロピーのランダムな素材、UUID/トークン状のもの)を伏せるべきです(SHOULD)。
  • リクエストとレスポンスのボディはこのフィールドでは公開されません。将来の include_webhook_payloads 拡張が、より厳格な認可制御のもとでそれらを追加する可能性がありますが、ここではスコープ外です。
  • error_message はサーバー側の分類文字列のみです——リクエストヘッダー、レスポンスボディ、バイヤーエンドポイントのスタックトレースは決して含みません。

ウェブフック配信の問題を診断する

有効なアクションのマッピング

valid_actions 配列は、メディアバイの現在の状態でどの操作が許可されているかをエージェントに伝えます。セラーはこのフィールドを含めるべきです(SHOULD)。ステータスごとに期待される値: セラーはビジネスルールに基づいてアクションを省略してもかまいません(MAY)(例: メディアバイにキャンセルを妨げる契約上の義務がある場合に cancel を省略する)。 クリエイティブの変更について、valid_actions にある sync_creatives はレガシーなクリエイティブ変更のアクションラベルであり、sync_creatives タスクが存在する証明ではありません。セラーが表明しているクリエイティブの経路を使用してください: creative.has_creative_library: true のセラーでは sync_creativescreative_assignments、インライン専用のセラーでは update_media_buypackages[].creatives です。

一般的なユースケース

クリエイティブ承認ステータスの確認

スナップショットを使った配信モニタリング

キャンペーン配信準備チェック

スナップショットと get_media_buy_delivery の比較

「現在のキャンペーン状態は何か?」という質問には get_media_buys を使い、「ある期間にキャンペーンがどのように機能したか?」には get_media_buy_delivery を使うこと。 ステータスの分類は両タスクのライフサイクルフィルター(pending_creativespending_startactivepausedcompleted)で共有されています。get_media_buy_delivery はウェブフックコンテキストで追加のレポーティング専用ステータス(reporting_delayedfailed)を返すことがあります。

データの鮮度

スナップショットの staleness_seconds はプラットフォームによって異なる: プラットフォームがバッチレポーティングのみの場合、セラーエージェントは適切な staleness_seconds を設定して最新のキャッシュデータを返すべきです。 include_snapshot: true でパッケージの snapshot が省略されている場合、snapshot_unavailable_reason を確認すること:
  • SNAPSHOT_UNSUPPORTED: セラーがこの統合でパッケージスナップショットをサポートしていません
  • SNAPSHOT_TEMPORARILY_UNAVAILABLE: スナップショットパイプラインが遅延または低下しています。後でリトライすること
  • SNAPSHOT_PERMISSION_DENIED: 呼び出し元がそのパッケージのスナップショットメトリクスを閲覧する権限を持っていません

ページネーション

大きなペイロードを避けるため、広範なステータスクエリにはカーソルページネーションを使用すること:
  • リクエスト: pagination.max_results(1〜100、デフォルト50)と オプションの pagination.cursor を設定します
  • レスポンス: pagination.has_more を読み取り、true の場合は pagination.cursor を次のリクエストに渡します
  • ID指定クエリ(media_buy_ids)は、IDセットが非常に大きい場合を除きページネーションを省略してよいです

エラーハンドリング

次のステップ

  • 不足クリエイティブのアップロード: ライブラリを持つセラーには sync_creatives を、インライン専用のセラーには update_media_buypackages[].creatives を使うこと
  • ゼロ配信の調査: delivery_status: "not_delivering"start_time を確認してフライトがアクティブであることを確かめ、次に update_media_buy を使って価格やターゲティングを調整すること
  • 詳細レポーティング: 日付範囲レポーティングや日別内訳には get_media_buy_delivery を使うこと
  • キャンペーンの最適化: セラーに結果を共有するには provide_performance_feedback を使うこと