Media Buy Lifecycle

​

概要

• 発見されたプロダクトとパッケージからのキャンペーン作成
• すべてのキャンペーン状態を通じたライフサイクル管理
• 継続的な最適化のための予算とターゲティングの更新
• 一貫した操作によるクロスプラットフォームのオーケストレーション
• 人間参加型のサポートを伴う非同期オペレーション

​

メディアバイのライフサイクルフェーズ

​

1. 作成フェーズ

• パッケージ設定: プロダクトをフォーマット、ターゲティング、予算と組み合わせる
• キャンペーンのセットアップ: タイミング、全体予算、ブランドコンテキストを定義する
• 検証と承認: 任意の人による承認を伴う自動チェック
• プラットフォームへのデプロイ: 広告プラットフォームにまたがるキャンペーン作成

• active ステータスでの即時作成（即時有効化）
• バイヤーがトップレベルの paused: true を渡し、有効化の前提条件がそれ以外は満たされている場合の、paused ステータスでの保留作成
• pending_creatives ステータス（クリエイティブの割り当て待ち）または pending_start ステータス（配信準備完了、フライト日待ち）での遅延作成
• pending_manual タスクステータスによる人間の承認ワークフロー（非同期オペレーションを参照）
• pending_permission タスクステータスによる権限要件（非同期オペレーションを参照）

• Google Ad Manager: LineItem を持つ Order を作成
• Kevel: Flight を持つ Campaign を作成
• Triton Digital: Flight を持つ Campaign を作成

​

2. クリエイティブ供給フェーズ

• プラットフォーム固有のフォーマットサポート（動画、音声、ディスプレイ、カスタム）
• クリエイティブのコンプライアンスのための検証とポリシーレビュー
• ターゲット配信のための特定パッケージへの割り当て

​

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

• ステータストラッキング: キャンペーンが pending_creatives から pending_start、そして active へ遷移する、または配信を保留して作成された場合は paused へ
• クリエイティブの割り当て: クリエイティブライブラリからアセットを添付
• 配信モニタリング: get_media_buy_delivery でペーシングとパフォーマンス指標を追跡
• 問題の解決: 承認の遅延やプラットフォームの問題に対応

​

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

• リアルタイムおよび履歴分析によるパフォーマンスモニタリング
• 予算の再配分とターゲティングの絞り込みによるキャンペーン最適化
• 一貫した分析のために同じターゲティング次元を使う次元別レポート
• パフォーマンスフィードバックループを通じたAI 主導のインサイト

​

キーコンセプト

​

メディアバイの構造

• キャンペーンメタデータ（バイヤー参照、ブランド、タイミング）
• 通貨とペーシング設定を持つ全体予算
• 異なるターゲティング/クリエイティブの組み合わせを表す複数のパッケージ
• 作成、承認、実行の各フェーズを通じたステータストラッキング

​

パッケージの種類

​

パッケージモデル

• 発見結果からの単一プロダクトの選択 - プロダクトを買うときは、プロダクト全体を買います（プロパティターゲティングを使う場合を除く）
• このパッケージ向けに提供されるクリエイティブフォーマット
• ジオ制限、フリークエンシーキャップ、プロパティターゲティングを含む絞り込みのためのターゲティングオーバーレイ
• 全体のメディアバイ予算の一部としての予算配分
• プロダクトの利用可能な価格モデルからの価格オプションの選択
• 予算配信のためのペーシング戦略（even、asap、または front_loaded）
• オークションベースの価格モデルのための入札価格（該当する場合）
• パッケージごとの任意の start_time と end_time を伴うフライトスケジューリング
• 保証付きバイのための**アカウンタビリティ条件** — performance_standards、measurement_terms、cancellation_policy

​

フライトスケジューリング

• 継承: パッケージで start_time または end_time が省略された場合、パッケージはメディアバイの日付を継承します。各フィールドは独立して継承されます——パッケージはメディアバイの end_time を継承しつつ start_time を指定する、またはその逆も可能です。
• 検証: パッケージの日付は親メディアバイの日付範囲内に収まらなければなりません。セラーは start_time が end_time と等しいか、それ以降であるパッケージを拒否すべきです（SHOULD）。
• 重複するフライト: 同じプロダクトの複数のパッケージは、重複する日付範囲を持つことができます。各パッケージは独立した予算を維持します。
• 形式: 素の ISO 8601 の日時——パッケージは "asap" をサポートしません

{
  "start_time": "2026-03-01T00:00:00Z",
  "end_time": "2026-03-31T23:59:59Z",
  "packages": [
    {
      "product_id": "prod_premium_display",
      "pricing_option_id": "cpm_usd_fixed",
      "budget": 2000,
      "start_time": "2026-03-01T00:00:00Z",
      "end_time": "2026-03-07T23:59:59Z"
    },
    {
      "product_id": "prod_premium_display",
      "pricing_option_id": "cpm_usd_fixed",
      "budget": 2000,
      "start_time": "2026-03-08T00:00:00Z",
      "end_time": "2026-03-14T23:59:59Z"
    },
    {
      "product_id": "prod_premium_display",
      "pricing_option_id": "cpm_usd_fixed",
      "budget": 2000,
      "start_time": "2026-03-22T00:00:00Z",
      "end_time": "2026-03-28T23:59:59Z"
    }
  ]
}

​

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

• パッケージはプロダクトを買う - プロダクトレベルの placements[].mode が、どのパブリッシャースコープのプレースメントがバイヤーにターゲティング可能かを示します
• プレースメントのアイデンティティはパブリッシャースコープ - パブリッシャー参照のプレースメントは、パブリッシャーの adagents.json に対して {publisher_domain, placement_id} として解決されます
• インラインプレースメントも引き続き許可 - 公開のパブリッシャープレースメント宣言がない場合、セールスエージェントは name、フォーマット、公開のバイヤー向け詳細を持つインラインプレースメントを定義できます。その placement_id は、名前付きのパブリッシャー名前空間で、または単一パブリッシャーのレガシー文脈で publisher_domain が省略される場合はセラーエージェント自身のパブリッシャー名前空間で解釈されます
• パッケージのインベントリスコープは、選択したプロダクト、プロダクトの絞り込み、またはセラーがサポートするパッケージターゲティングサーフェスに由来します。creative_assignments[].placement_refs は、すでにスコープ内にあるプレースメントの間でクリエイティブをルーティングするだけです
• placement_refs も placement_ids も持たないクリエイティブは、パッケージ内のすべてのバイヤーがターゲティング可能なプレースメントで配信されます
• placement_refs とレガシーの placement_ids の両方が存在する場合、placement_refs が優先され、セラーは placement_ids を無視します
• mode: "included" のプレースメントはプロダクトの公開構成の一部であり、creative_assignments[].placement_refs で参照できません
• マルチパブリッシャープロダクトには placement_refs を使います。placement_ids は、プレースメント名前空間が曖昧でない場合にのみ、レガシーの略記として残ります
• パブリッシャーは、adagents.json の authorized_agents[].placement_ids またはガバナンス下の placement_tags を使って、特定のプレースメントについてエージェントを認可できます。セラーは販売を認可されたパブリッシャー参照のプレースメントのみを返すべきです

1. プロダクトがターゲティング可能なプレースメントを返す:

{
  "product_id": "network_premium",
  "placements": [
    {
      "kind": "publisher_ref",
      "publisher_domain": "daily-pulse.example",
      "placement_id": "homepage_banner",
      "name": "Homepage Banner",
      "mode": "targetable",
      "format_ids": [{"agent_url": "...", "id": "display_728x90"}]
    },
    {
      "kind": "publisher_ref",
      "publisher_domain": "metro-report.example",
      "placement_id": "homepage_banner",
      "name": "Homepage Banner",
      "mode": "targetable",
      "format_ids": [{"agent_url": "...", "id": "display_728x90"}]
    },
    {
      "kind": "seller_inline",
      "publisher_domain": "daily-pulse.example",
      "placement_id": "article_sidebar",
      "name": "Article Sidebar",
      "mode": "targetable",
      "format_ids": [{"agent_url": "...", "id": "display_300x250"}]
    },
    {
      "kind": "seller_inline",
      "publisher_domain": "daily-pulse.example",
      "placement_id": "sponsorship_lockup",
      "name": "Sponsorship lockup",
      "mode": "included"
    }
  ]
}

2. バイヤーがパッケージを作成（プロダクト全体を買う）し、各プレースメントに異なるクリエイティブを割り当てる:

{
  "product_id": "network_premium",
  "creative_assignments": [
    {
      "creative_id": "creative_daily_pulse",
      "placement_refs": [
        {
          "publisher_domain": "daily-pulse.example",
          "placement_id": "homepage_banner"
        }
      ]
    },
    {
      "creative_id": "creative_metro_report",
      "placement_refs": [
        {
          "publisher_domain": "metro-report.example",
          "placement_id": "homepage_banner"
        }
      ]
    }
  ]
}

3. または、一つのクリエイティブをすべてのターゲティング可能なプレースメントに割り当てる（placement_refs と placement_ids を省略）:

{
  "product_id": "network_premium",
  "creative_assignments": [
    {
      "creative_id": "creative_universal"
    }
  ]
}

• フォーマット固有のプレースメント: ホームページは 728x90、サイドバーは 300x250
• A/B テスト: 異なるプレースメントで異なるクリエイティブをテスト
• ジオターゲティング: 異なる DOOH スクリーンのロケーションに異なるクリエイティブ
• デイパーティング: 朝と夜のプレースメントに異なるクリエイティブ

​

プロパティターゲティング

{
  "product_id": "flexible_news_network",
  "targeting_overlay": {
    "property_list": {
      "agent_url": "https://governance.example.com",
      "list_id": "pl_brand_safe_2024"
    }
  },
  "budget": 50000
}

• property_targeting_allowed: true のプロダクトについてのみ有効
• パッケージは、プロダクトの publisher_properties と property_list の交差で配信されます
• 省略した場合、パッケージはプロダクトのすべてのプロパティで配信されます
• property_targeting_allowed: false のプロダクトに対して提供された場合、セラーはバリデーションエラーを返すべきです（SHOULD）

​

ライフサイクル状態

create_media_buy ──┬──▶ pending_creatives ──▶ pending_start ──▶ active
                   ├──▶ active ──(pause)──▶ paused
                   └──▶ paused (when created with paused: true)

paused ──(resume)──▶ active
active ─────────────▶ completed (terminal)
paused ─────────────▶ completed (terminal)

pending_creatives ──▶ rejected (terminal)  — seller rejects during setup
pending_start ──────▶ rejected (terminal)  — seller rejects during setup

Any non-terminal ──── update(canceled: true) ──▶ canceled (terminal)

• pending_creatives: 承認済みだがクリエイティブが未割り当て——バイヤー側のアクションが必要（ライブラリを持つセラーには sync_creatives、インライン専用のセラーにはインラインの packages[].creatives を使用）。パブリッシャー側やガバナンス側の承認キューではありません: セラーはすでにバイを受理しており、欠けているのはバイヤーのクリエイティブ送信だけです。
• pending_start: 配信準備完了、フライト日待ち

• active: 実行中でインプレッションを配信している
• paused: バイヤーまたはセラーによって一時的に停止された。有効化の前提条件をそれ以外は満たす場合、トップレベルの paused: true でバイを直接 paused として作成することもできます。クリエイティブの欠如や将来のフライト日のようなセットアップのブロッカーは、解消されるまで依然として pending_creatives または pending_start として表面化し、その後、作成時の保留が paused として可視になります。
• completed: 終了——フライトが終了、ゴールが達成、または予算が消化された
• rejected: セラーによって断られた（終端）
• canceled: 自然な完了の前に終了した。バイヤーとセラーのどちらが起点かを判断するには cancellation.canceled_by を確認します。

{
  "media_buys": [{
    "media_buy_id": "mb_12345",
    "status": "active",
    "revision": 3,
    "valid_actions": ["pause", "cancel", "update_budget", "update_dates", "update_packages", "add_packages", "sync_creatives"],
    "packages": [...]
  }]
}

​

コアオペレーション

​

メディアバイの作成

• 発見されたプロダクトがまだ利用可能であることを保証するプロダクトの検証
• パッケージをまたいでクリエイティブ要件を確認するフォーマット互換性
• 複数のパッケージにまたがって支出を配分する予算の分配
• 複数のアドサーバーにまたがってキャンペーンを作成するプラットフォームの調整

​

メディアバイの更新

• 支出の増減のための予算調整
• オーディエンスパラメータを絞り込むターゲティングの更新
• キャンペーンのタイミングを延長または短縮するスケジュールの変更
• キャンペーンレベルの配信制御のための一時停止/再開

​

メディアバイのキャンセル

{
  "media_buy_id": "mb_12345",
  "canceled": true,
  "cancellation_reason": "Campaign strategy changed"
}

{
  "media_buy_id": "mb_12345",
  "packages": [
    {
      "package_id": "pkg_67890",
      "canceled": true,
      "cancellation_reason": "Underperforming — reallocating budget"
    }
  ]
}

• キャンセルは取り消し不可です——キャンセルされたメディアバイとパッケージは再有効化できません
• セラーはキャンセルをエラーコード NOT_CANCELLABLE で拒否してもかまいません（MAY）（例: 契約上の義務、印刷生産中のオーダー）
• キャンセルされたパッケージは、同じメディアバイ内の他のパッケージに影響を与えません。すべてのパッケージがキャンセルされた場合、add_packages をサポートするセラーは、バイヤーが update_media_buy の new_packages を通じて新しいパッケージを追加することを許可します。そうでない場合、バイヤーはメディアバイを明示的にキャンセルすべきです（SHOULD）。
• セラーはメディアバイまたはパッケージをキャンセルしてもかまいません（MAY）（例: ポリシー違反、インベントリの引き上げ）。セラー起点のキャンセルは cancellation.canceled_by: "seller" を設定し、オーケストレーターへのウェブフック通知をトリガーしなければなりません（MUST）。

​

パッケージのライフサイクル

• paused: 一時的に停止——paused: false で再開可能
• canceled: 恒久的に停止——取り消し不可
• creative_deadline: クリエイティブのアップロードや変更のためのパッケージごとの期限。この期限の後、クリエイティブの変更は CREATIVE_REJECTED で拒否されます。

​

ステータス管理

• 保留中のキャンペーンを開始する有効化リクエスト
• キャンペーン制御のための一時停止/再開の操作
• バイヤー起点の終了のためのキャンセル
• 成功したキャンペーンのクローズのための完了処理
• 失敗した操作のためのエラーリカバリ

​

レスポンスタイム

• create_media_buy: 即時から数日
  • completed: 即座に作成される単純なキャンペーン
  • working: 120 秒以内の処理（検証、セットアップ）
  • submitted: 数時間から数日を要する複雑なキャンペーン（人による承認）
• update_media_buy: 即時から数日
  • completed: 即座に適用される予算変更
  • working: 120 秒以内のターゲティング更新
  • submitted: 承認を要するパッケージ変更（数時間から数日）
• get_media_buy_delivery: 約60秒（データ集計）
• パフォーマンス分析: 約1秒（キャッシュされたメトリクス）

• completed: 操作が完了、結果を即座に処理
• working: 処理中、120 秒以内の完了を期待
• submitted: 長時間実行の操作、ウェブフックを提供するか tasks/get でポーリング

​

ベストプラクティス

​

キャンペーンプランニング

• プロダクトディスカバリーのブリーフで定義した明確な目標から始める
• 異なるオーディエンス/クリエイティブの組み合わせを中心にパッケージ構造をプランニングする
• プロダクトの価格ガイダンスに基づいて現実的な予算を設定する
• パブリッシャーのワークフローで承認の時間を確保する

​

継続的な管理

• ターゲットに対する配信を保証するために日次のペーシングをモニタリングする
• 最適化の機会のために週次でパフォーマンスをレビューする
• 配信を乱さないためにターゲティングを段階的に更新する
• オーディエンスの疲労を防ぐためにクリエイティブを定期的に刷新する

​

予算管理

• 最初は保守的に配分し、その後パフォーマンスに基づいて増やす
• 高パフォーマンスのパッケージのために予算を確保する
• オーディエンスの可用性と価格の季節性を見越す
• 異なるターゲティングアプローチにまたがって支出効率をモニタリングする
• 予算管理: 予算が更新されると、システムは CPM に基づいてインプレッションを自動的に再計算します

​

技術的実装

• 一時停止/再開の戦略: メンテナンスにはキャンペーンレベルの制御を、最適化にはパッケージレベルを使う
• パフォーマンスモニタリング: 定期的なステータスチェックと配信レポートがキャンペーンを軌道に乗せ続けます
• 非同期設計: 長時間実行の操作を適切に扱うようにオーケストレーターを設計する
• タスクトラッキング: 保留中のタスク ID のために永続的なストレージを維持する
• ウェブフック統合: リアルタイムの更新のためにウェブフックを実装する
• ユーザーへの伝達: 保留状態をエンドユーザーに明確に伝える

​

エラーハンドリング

​

非同期オペレーションと人間参加型

​

人間参加型（HITL）オペレーション

1. 操作リクエスト: オーケストレーターが任意の変更タスクを呼ぶ
2. 保留レスポンス: サーバーがタスク ID とともに pending_manual ステータスを返す
3. タスクのモニタリング: オーケストレーターがポーリングするか、ウェブフックを受け取る
4. 人によるレビュー: パブリッシャーがレビューして承認/拒否する
5. 完了: 承認時に元の操作が実行される

​

HITL タスクの状態

pending → assigned → in_progress → completed/failed
                  ↓
              escalated

​

オーケストレーターの要件

1. pending_manual と pending_permission を通常の状態として扱う
2. 保留中の操作を追跡するためにタスク ID を保存する
3. 指数バックオフを伴うリトライロジックを実装する
4. 操作の最終的な拒否を適切に扱う
5. リアルタイムの更新のためにウェブフックコールバックをサポートする（推奨）

​

標準メトリクス

• impressions: 広告閲覧回数
• spend: 通貨で使われた金額
• clicks: クリック数（該当する場合）
• ctr: クリック率（clicks/impressions）

• conversions: ポストクリック/ビューのコンバージョン
• viewability: ビューアブルインプレッションの割合
• completion_rate: 動画/音声の完了率
• engagement_rate: プラットフォーム固有のエンゲージメントメトリクス

​

プラットフォーム固有の考慮事項

​

Google Ad Manager

• Order は複数の LineItem を含められます
• LineItem はパッケージと 1:1 でマップします
• 高度なターゲティングとフリークエンシーキャップ
• クリエイティブ承認プロセスが必要
• レポート: 包括的な次元別レポート、リアルタイムおよび履歴データ、高度なビューアビリティメトリクス

​

Kevel

• Campaign は Flight を含みます
• Flight はパッケージと 1:1 でマップします
• リアルタイム判断エンジン
• カスタムクリエイティブテンプレートをサポート
• レポート: リアルタイムレポート API、カスタムメトリクスのサポート、柔軟な集計オプション

​

Triton Digital

• 音声広告に最適化
• Campaign は異なるデイパートのための Flight を含みます
• 強力なステーション/ストリームのターゲティング機能
• 音声のみのクリエイティブサポート
• レポート: 音声固有のメトリクス（完了率、スキップ率）、ステーションレベルのパフォーマンスデータ、デイパート分析

​

高度な分析

​

クロスキャンペーン分析

• 複数のキャンペーンにまたがるポートフォリオのパフォーマンス
• オーディエンスの重複とフリークエンシー管理
• キャンペーン横断の予算配分の最適化

​

予測インサイト

• 履歴データに基づくパフォーマンス予測
• AI 分析からの最適化の推奨
• 先を見越した調整のためのトレンド予測

​

統合パターン

​

発見からメディアバイまで

1. get_products を使ってインベントリを見つける
2. キャンペーン目標に合致するプロダクトを選ぶ
3. 適切なターゲティングとフォーマットでパッケージを設定する
4. create_media_buy でメディアバイを作成する

​

クリエイティブ統合

1. 選択したプロダクトからフォーマット要件を理解する
2. クリエイティブ管理を使ってアセットを準備する
3. キャンペーン作成中または更新を通じてクリエイティブを割り当てる
4. クリエイティブのパフォーマンスをモニタリングし、必要に応じて刷新する

​

パフォーマンス最適化

1. get_media_buy_delivery で配信を追跡する
   • リアルタイムの配信メトリクスとペーシング分析をモニタリングする
   • 最適化の機会のためにパッケージレベルのパフォーマンス内訳を得る
   • 異なるターゲティングアプローチにまたがってパフォーマンスを追跡する
2. パッケージとターゲティングにまたがってパフォーマンスを分析する
   • 詳細なインサイトのために次元別レポートを使う
   • AI 主導の最適化のためにパフォーマンスインデックススコアをモニタリングする
   • 高パフォーマンスと低パフォーマンスのセグメントを特定する
3. update_media_buy でキャンペーンを更新する
   • 高パフォーマンスと低パフォーマンスのパッケージ間で予算を再配分する
   • パフォーマンスデータに基づいてターゲティングを調整する
   • 低パフォーマンスのパッケージを一時停止し、成功したものをスケールする
4. パフォーマンスデータとビジネス成果に基づいて反復する
   • パフォーマンスデータを最適化アルゴリズムにフィードバックする
   • ターゲティングとクリエイティブの割り当てを継続的に絞り込む
   • 成功した戦略を類似のキャンペーンにまたがってスケールする

​

最適化のベストプラクティス

1. 頻繁にレポートする: 定期的なレポートが最適化の機会を高めます
2. ペーシングを追跡する: 過少/過剰配信を避けるためにターゲットに対する配信をモニタリングする
3. パターンを分析する: 次元にまたがるパフォーマンスのトレンドを探す
4. レイテンシを考慮する: 一部のメトリクスはアトリビューションの遅延を持つことがあります
5. メトリクスを正規化する: パフォーマンス比較のために一貫したベースラインを使う

​

関連ドキュメント

• プロダクトディスカバリー - メディアバイのためのインベントリの発見
• タスクリファレンス - 完全な API ドキュメント
• クリエイティブ - クリエイティブアセットの管理
• オーケストレーター設計ガイド - 実装のベストプラクティス