Skip to main content

ロール別ガバナンスプロトコル

AdCP のガバナンスは共有された制御ループです。バイサイドのガバナンスエージェントが、計画または実行されたアクションが許可されるかを決めます。バイヤーエージェントがガバナンスコンテキストを取得し運びます。セラーは作業を実行する前にそのコンテキストを検証し、結果を監査証跡に返します。

ロール

バイサイドフロー

  1. sync_plans でキャンペーンプランを作成または更新する。
  2. セラーに実行を求める前に、intent フェーズのために check_governance を呼ぶ。
  3. 返されたガバナンスコンテキストをセラーリクエストに添付する。
  4. 実行詳細が返ってきたら、ワークフローが要求する場合、execution フェーズのために再度 check_governance を呼ぶ。
  5. 結果をポールまたは購読し、ガバナンス監査証跡を保持する。
バイヤーが計画の真実を所有します。バイヤーが予算、オーディエンス、セラー、フライト日、製品選択、または目的を変更する場合、プランを更新するか新しいガバナンス決定をリクエストしなければなりません。

セルサイドフロー

  1. ガバナンスコンテキストを持つリクエストを受け取る。
  2. 実行前に署名付きガバナンスコンテキストを検証する。
  3. トークンを期待されるプラン、呼び出し元、セラー、フェーズ、操作にバインドする。
  4. 欠けた、期限切れの、失効した、リプレイされた、または不一致の署名付きコンテキストを PERMISSION_DENIED で拒否する。
  5. セラーが結果レポートに責任を持つとき、report_plan_outcome を通じて確認された配信または支出をレポートする。
セラーはバイヤーポリシーをゼロから再解釈しません。それはバイヤーのガバナンスエージェントがこの正確な実行を認可したことを検証し、実際に何が起こったかをレポートします。 GOVERNANCE_DENIED は、バイサイドのガバナンスエージェントが計画または実行されたアクションに対して実際の拒否を返したときのみ使います。

check_governance ペイロード規律

最も一般的な実装バグは、フェーズに必要なフィールドを省略する部分的なチェックを送ることです。 intent チェックは通常以下を必要とします:
  • plan_id
  • caller
  • 提案されたセラーまたはオペレーターのアイデンティティ
  • 予算とペーシングの意図
  • ターゲティングとポリシー関連の制約
  • 既に選択されているときは製品またはパッケージ参照
execution チェックは通常以下を必要とします:
  • plan_id
  • caller
  • セラーアイデンティティ
  • 実行される具体的なパッケージ、クリエイティブ、ターゲティング、日付、予算
  • 配信フェーズをチェックするときは配信または実行メトリック
  • タスクが継続性を要求するときは以前のガバナンスコンテキストまたは相関識別子

テストすべきこと

  • 有効なプランが intent チェックを通過する。
  • プランがそのセラーを認可しない限り、セラースワップが失敗する。
  • sync_plans がプランを更新するまで、予算増加が失敗する。
  • リプレイされたガバナンストークンが失敗する。
  • 期限切れまたは失効したトークンが失敗する。
  • 認可されたプラン外の配信レポートが失敗するか監査所見を生成する。

練習プロンプト

このケースのためのガバナンステストを設計してください:
Pinnacle Media は Nova Snacks のためのファミリーセーフな CTV パッケージを購入したい。バイヤープランは支出を USD 75,000 に制限し、2 つの承認済みセラーのみを許可する。セラーが異なるセラーアイデンティティでより高予算のパッケージを返す。
期待される回答:
  • バイヤーは実行前にプランを更新または拒否する。
  • ガバナンス intent チェックは未承認のセラーまたは予算超過のパッケージを拒否すべき。
  • セラーは元のセラーまたは予算にバインドされたコンテキストで実行してはならない。
  • 監査ログは拒否理由と試みられた実行事実を示すべき。