Skip to main content

アカウント状態

AdCP のアカウントはステートフルなコンテナです。バイヤーがセラーのプラットフォームでキャンペーンを実行する前に、アカウントに状態を構築します: プロダクトカタログ、クリエイティブアセット、オーディエンスリスト、コンバージョントラッキング。各状態には独自の同期タスク、独自の承認ワークフロー、独自のライフサイクルがあります。 これは AdCP の以前のバージョンとは異なります。以前はアカウントが請求の参照であり、ほとんどの操作がステートレスでしました。AdCP 3.0 では、アカウントがすべてを結びつける中心的なオブジェクトです。

状態ドメイン

アカウントは6つのカテゴリの状態を保持し、それぞれが専用のタスクで管理されます: 各同期タスクは同じパターンに従います:
  • アップサートセマンティクス — アイテムは ID でマッチされ、新しければ作成、存在すれば更新
  • ディスカバリーモード — アイテム配列を省略してアカウントに既存のものを確認
  • 非同期承認 — プラットフォームはアクティベート前にアイテムをレビューすることがあります
  • アイテムごとのステータス — 個別アイテムは独立して成功または失敗できます

セットアップシーケンス

典型的なバイイングワークフローは依存関係の順でアカウント状態を構築します。各ステップは前のステップが完了していることが必要です:

1. アカウントを確立します

sync_accounts はバイヤーが誰で、どのように支払うかを宣言します。セラーは関係を認め、ステータスと請求条件を返します。

2. カタログを同期します

sync_catalogs はプロダクトデータをアカウントで利用可能にします。フォーマットは assets 配列の catalog アセットタイプを通じて必要なカタログタイプを宣言するため、バイヤーはクリエイティブを送信する前に適切なフィードを同期します。
プラットフォームは各フィードを取得して検証します。アイテムは承認、拒否、または警告付きでフラグされることがあります — Google Merchant Center がプロダクトリスティングをレビューするのに似ています。

3. イベントソースを設定します

sync_event_sources はコンバージョントラッキングを設定して、プラットフォームが広告露出に結果を帰属させられるようにします。

4. ガバナンスを設定します

sync_governance はアカウントにガバナンスエージェントを登録します。設定されると、ガバナンスをサポートするセラーはメディアバイを確定する前に check_governance を呼び出します。
稼働中のアカウントでガバナンスエージェントを変更すると、すべてのアクティブキャンペーンに影響します。ガバナンスエージェントが削除されると、セラーはそのドメインについて check_governance の呼び出しを停止します。新しいエージェントが追加されても、既存のキャンペーンは遡及的に検証されません。更新されたガバナンス設定を通るのは新しいトランザクションのみです。

5. クリエイティブを同期します

sync_creatives は、ステップ 2 で同期されたカタログを参照するクリエイティブアセットを送信します。カタログ駆動フォーマットの場合、クリエイティブの catalogs フィールドはアイテムをインラインで埋め込む代わりに、catalog_id で同期されたカタログを参照します。

6. オーディエンスをアップロードします

sync_audiences はターゲティング用のファーストパーティオーディエンスリストをアップロードします。送信前にメンバーはハッシュ化されます。

7. キャンペーンを作成します

すべての状態が整ったら、create_media_buy が同期された状態を参照するキャンペーンを活性化します:

ディスカバリー

すべての同期タスクはディスカバリーモードをサポートします: アイテム配列なしでタスクを呼び出して、アカウントに既存の状態を確認します。これはバイイングエージェントがセラーがブランドについて既に知っていることを学ぶ方法です。
これが重要な理由: セラーはすでに他のソースからブランドデータを持っている可能性があります — 小売業者はコマースプラットフォームからブランドのプロダクトカタログを持っているかもしれないし、パブリッシャーは以前のキャンペーンからクリエイティブを持っているかもしれません。ディスカバリーにより、バイヤーはすべてを再アップロードするのではなく、既存の状態の上に構築できます。

承認ワークフロー

同期タスクは多くの場合非同期です。プラットフォームはアイテムをアクティブにする前にレビューする必要がある場合があります:
  • カタログ: プロダクトリスティングはコンテンツポリシーチェックを経ます。アイテムは承認、拒否、または警告付きでフラグされることがあります。
  • クリエイティブ: 生成クリエイティブは人間の承認が必要です。従来のクリエイティブはポリシーレビューが必要な場合があります。
  • オーディエンス: プラットフォームはハッシュ化された識別子をユーザーベースと照合する時間が必要です。
  • イベントソース: コンバージョントラッキングはピクセル検証が必要な場合があります。
すべての同期タスクは処理完了時のウェブフックコールバック用に push_notification_config をサポートします。長時間実行する操作の場合、プラットフォームは非同期ステータス更新(working、input-required、submitted)を返し、バイヤーがポーリングするかウェブフックで受け取ります。

状態の依存関係

一部の状態は他の状態に依存します。プラットフォームはこれらの依存関係を強制します:
  • クリエイティブはカタログを参照するcatalog_id: "product-feed" を使用するクリエイティブは、そのカタログが最初に同期されていることが必要
  • キャンペーンはクリエイティブとオーディエンスを参照するcreate_media_buy は参照された creative_ids とオーディエンス ID がアカウントに存在することが必要
  • イベントソースは最適化を可能にする — パッケージの最適化ゴールはアトリビューション用にイベントソースを参照します
依存関係が欠けている場合、プラットフォームは最初に何を同期する必要があるかを説明するエラーを返します。

ステートレス vs ステートフル操作

すべてのものがアカウント状態を必要とするわけではありません。一部のタスクはステートレスクエリです: パターン: 発見はステートレス、実行はステートフル。アカウントなしでセラーのインベントリを閲覧できます。購入するにはアカウントが必要です。

関連ドキュメント