Skip to main content
Media buy は AdCP における広告キャンペーンの完全なライフサイクルを表します。AdCP:Buy プロトコルは、複数の広告プラットフォームにわたって、初期作成から継続的な最適化までを統一インターフェースで管理します。

​
概要

AdCP のメディアバイ管理は次を単一インターフェースで提供します:
  • キャンペーン作成: 発見したプロダクトやパッケージから組成
  • ライフサイクル管理: すべてのキャンペーン状態を通した管理
  • 予算とターゲティング更新: 継続的な最適化
  • クロスプラットフォーム調整: 一貫したオペレーション
  • 非同期オペレーション: Human-in-the-Loop を含む

​
メディアバイのフェーズ

​
1. 作成フェーズ

create_media_buy を使い、発見済みプロダクトをアクティブなキャンペーンに変換します。
  • パッケージ構成: プロダクトにフォーマット・ターゲティング・予算を組み合わせる
  • キャンペーンセットアップ: タイミング、全体予算、訴求するオファリングを定義
  • 検証と承認: 自動チェックと必要に応じた人手承認
  • プラットフォーム展開: 広告プラットフォームにキャンペーンを作成
このフェーズでは以下が起こり得ます:
  • pending_activation 状態で即時作成
  • pending_manual 状態による人手承認ワークフロー
  • pending_permission 状態による権限付与待ち
プラットフォーム対応の例:
  • Google Ad Manager: Order と LineItem を作成
  • Kevel: Campaign と Flights を作成
  • Triton Digital: Campaign と Flights を作成

​
2. クリエイティブアップロードフェーズ

作成後は sync_creatives でクリエイティブ資産を登録します。
  • プラットフォーム別フォーマット対応（動画・音声・ディスプレイ・カスタム）
  • バリデーションとポリシーチェック
  • 特定パッケージへの割り当て

​
3. 有効化・配信フェーズ

アクティブなキャンペーンを監視・管理します。
  • ステータス追跡: pending_activation から active への遷移
  • クリエイティブ割り当て: クリエイティブライブラリの資産を紐づけ
  • 配信監視: get_media_buy_delivery でパフォーマンスを追跡
  • 問題解決: 承認遅延やプラットフォーム課題への対応

​
4. 最適化とレポートフェーズ

AdCP の包括的なレポートを用いて継続的に性能監視と最適化を行います。 主な活動:
  • パフォーマンス監視: リアルタイム/履歴分析
  • キャンペーン最適化: 予算再配分やターゲティング改善
  • ディメンションレポート: 同一ターゲティング軸での整合的な分析
  • AI インサイト: パフォーマンスフィードバックループによる洞察
最適化戦略や標準指標の詳細は Optimization & Reporting を参照。

​
キーコンセプト

​
メディアバイの構造

メディアバイは次を含みます:
  • キャンペーンメタデータ（buyer_ref、訴求オファリング、期間）
  • 全体予算（通貨・ペーシング方針）
  • 複数パッケージ（異なるターゲティング/クリエイティブの組み合わせ）
  • 状態管理（作成・承認・実行フェーズを通じたトラッキング）

​
パッケージモデル

パッケージはメディアバイの構成要素です:
  • 単一プロダクトの選択: プロダクトを買うとその全体を購入
  • クリエイティブフォーマット: 当該パッケージに提供するフォーマット
  • ターゲティングオーバーレイ: プロダクト既定に対する追加ターゲティング
  • 予算配分: 全体予算のうちこのパッケージに充てる額
  • 価格オプション: プロダクトが提供する価格モデルの選択
  • ペーシング戦略: 予算配分の配信方針（even/asap/front_loaded）
  • 入札価格: オークション型の価格モデルで必須

​
クリエイティブ割り当てとプレースメントターゲティング

プロダクトが複数プレースメントを定義する場合でも、買い付けは常にプロダクト全体です。クリエイティブはプレースメント単位で割り当て可能です。 ポイント:
  • パッケージはプロダクト全体を購入 - プレースメント単位での部分買いは不可
  • プレースメントターゲティングは クリエイティブ割り当てレイヤーのみ
  • placement_ids がないクリエイティブは、プロダクト内の すべてのプレースメント に配信
ワークフロー例:
  1. プロダクトがプレースメントを定義:
{
  "product_id": "news_site_premium",
  "placements": [
    {
      "placement_id": "homepage_banner",
      "name": "Homepage Banner",
      "format_ids": [{"agent_url": "...", "id": "display_728x90"}]
    },
    {
      "placement_id": "article_sidebar",
      "name": "Article Sidebar",
      "format_ids": [{"agent_url": "...", "id": "display_300x250"}]
    }
  ]
}
  1. バイヤーがパッケージを作成（プロダクト全体を購入）し、プレースメント別にクリエイティブを割り当て:
{
  "product_id": "news_site_premium",
  "creative_assignments": [
    {
      "creative_id": "creative_homepage",
      "placement_ids": ["homepage_banner"]
    },
    {
      "creative_id": "creative_article",
      "placement_ids": ["article_sidebar"]
    }
  ]
}
  1. 1 つのクリエイティブを全プレースメントに割り当てる（placement_ids 省略）:
{
  "product_id": "news_site_premium",
  "creative_assignments": [
    {
      "creative_id": "creative_universal"
      // placement_ids なし = プロダクト内の全プレースメントに配信
    }
  ]
}
ユースケース:
  • フォーマット別プレースメント: ホームは 728x90、サイドは 300x250
  • A/B テスト: プレースメントごとにクリエイティブを変えて検証
  • ジオターゲティング: DOOH などでロケーション別クリエイティブを配信
  • デイパート: 時間帯ごとに異なるクリエイティブ
Media Products - Placements で詳細を参照。

​
ライフサイクルステート

メディアバイは予測可能な状態を遷移します:
  • pending_activation: 作成済み、プラットフォームセットアップ待ち
  • pending_manual: 人手承認待ち
  • active: 配信中
  • paused: 一時停止
  • completed: 配信終了

​
コアオペレーション

​
メディアバイの作成

作成プロセスでは次を処理します:
  • プロダクト検証: 発見したプロダクトがまだ利用可能か確認
  • フォーマット適合性チェック: パッケージ間のクリエイティブ要件を検証
  • 予算配分: 複数パッケージへの予算割り当て
  • プラットフォーム連携: 複数アドサーバーへのキャンペーン生成

​
メディアバイの更新

以下の変更をサポートします:
  • 予算調整: 増減を反映
  • ターゲティング更新: オーディエンス条件の改善
  • パッケージ変更: プロダクトやフォーマットの追加/削除
  • スケジュール変更: 期間延長や短縮

​
ステータス管理

キャンペーン状態の遷移:
  • アクティベーション要求: 保留中キャンペーンの開始
  • 一時停止/再開: キャンペーン制御
  • 完了処理: 正常終了のハンドリング
  • エラー回復: 失敗時のリカバリ

​
レスポンスタイム

メディアバイ操作では一貫したステータスシステムと予測可能な時間が用いられます。
  • create_media_buy: 即時〜数日
    • completed: 単純なキャンペーンは即時作成
    • working: 検証・セットアップで 120 秒以内
    • submitted: 人手承認が必要な複雑案件は数時間〜数日
  • update_media_buy: 即時〜数日
    • completed: 予算変更など即時反映
    • working: ターゲティング更新が 120 秒以内
    • submitted: パッケージ変更など承認が必要な場合（数時間〜数日）
  • get_media_buy_delivery: 約 60 秒（集計処理）