Skip to main content
クリエイティブライブラリ内のクリエイティブをブラウズ・フィルタリングします。フォーマット、ステータス、コンセプト、タグ、日付範囲、ダイナミック変数によるフィルタリング、ページネーション、オプションのフィールドエンリッチメントをサポートします。 クリエイティブライブラリをホストするすべてのエージェント — クリエイティブエージェント(広告サーバー、クリエイティブ管理プラットフォーム)およびクリエイティブを管理するセールスエージェント — が実装します。 レスポンスタイム: ~1秒(シンプルなデータベースルックアップ)

概要

主な機能:
  • フォーマット、ステータス、タグ、日付、アサインメント、コンセプト、変数でフィルタリング
  • 作成日、更新日、名前、ステータス、アサインメント数でソート
  • 大きなライブラリのためのカーソルベースのページネーション
  • アサインメント、配信スナップショット、アイテム、ダイナミッククリエイティブ最適化(DCO)変数をオプションで含めます
  • レスポンスサイズを削減するために特定のフィールドのみを返す
  • クリエイティブコンセプトでフィルタリング(サイズ/フォーマットをまたぐ関連クリエイティブのグループ)
  • DCO クリエイティブを見つけてダイナミックコンテンツスロットを確認します

リクエストパラメータ

スキーマ: creative/list-creatives-request.json

コアパラメータ

データ含有オプション

フィルタリングオプション

filters オブジェクトは以下のオプションの組み合わせ可能なフィルターをサポートする: * アサインメント関連フィルターはセールスエージェント固有。スタンドアロンクリエイティブエージェントはこれらを無視します。
アーカイブ済みクリエイティブはデフォルトで除外されます。 結果にアーカイブ済みクリエイティブを含めるには、statuses 配列に明示的に "archived" を含めます。サスペンドされたクリエイティブはアーカイブされていません。認可が期限切れの公開済み投稿の参照のような、回復可能なオフラインのクリエイティブを特に含めたい場合は "suspended" を含めます。
公開済み投稿の参照プロダクトでは、list_creatives はセラーが検査を認可されている下流のパブリッシャーのアイデンティティに限定されます。プロダクトが publisher_identity のような 2 つ目のプラットフォーム接続を必要とし、それが欠けている場合、セラーは error.details.missing_connections[] を伴う AUTHORIZATION_REQUIRED を返すべきです。list_creatives をグローバルなプラットフォーム投稿検索として提示すべきではありません。

ソートオプション

昇順または降順でさまざまなフィールドでソートする:
利用可能なソートフィールド:
  • created_date - クリエイティブが作成された日時(デフォルト)
  • updated_date - クリエイティブが最後に変更された日時
  • name - クリエイティブ名(アルファベット順)
  • status - 承認ステータス
  • assignment_count - パッケージアサインメント数

ページネーション

カーソルベースのページネーションで結果セットのサイズを制御する:

レスポンスフォーマット

スキーマ: creative/list-creatives-response.json レスポンスはオプションのエンリッチメントを持つクリエイティブデータを提供します:

クリエイティブごとのフィールド

価格

include_pricing=true かつ account が提供された場合、各クリエイティブにはアカウントのレートカードから pricing_options が含まれます:
バイヤーは、請求の検証のために、適用された pricing_option_idbuild_creative レスポンスから)を report_usage で渡します。ベンダーは複数のオプションを提供できます——ボリューム/コミットメントのティア、コンテキスト固有のレート(プレミアム vs 標準のプレースメント)、または異なるプロダクトラインの完全に異なる価格モデル。これはシグナルコンテンツ標準が使うのと同じパターンです。

配信スナップショット

include_snapshot=true の場合、各クリエイティブには「このクリエイティブはアクティブか?」「最後にいつ配信されたか?」などの運用上の質問のための軽量な配信スナップショットが含まれます。これはアナリティクスではない — 詳細なパフォーマンスデータには get_creative_delivery を使用します。

パージされたトゥームストーン

クリエイティブが creative.purged を介して purge_kind: soft で破棄されると、セラーはパージのタイムスタンプから 30 日間トゥームストーンを保持します。トゥームストーンは、リクエストが include_purged: true を設定した場合にのみ list_creatives に現れます:
トゥームストーンの status フィールドは、パージ前の値で凍結されます(上記の例では、"approved" はパージ直前のクリエイティブの状態であって、現在の主張ではありません)。バイヤーはクリエイティブを消滅したものとして扱わなければなりません(MUST): 割り当て、配信操作、デリバリーの読み取りはもう適用されません。purge ブロックの存在が明確なシグナルです。 ハードパージされたクリエイティブ(purge_kind: hard、GDPR 第 17 条 / CCPA / 同等法の下での法的消去に使用)はトゥームストーンを保持しません。creative.purged ウェブフックが唯一のシグナルです。根拠については snapshot-and-log § ルール 4 の除外を参照してください。

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

include_webhook_activity: true の場合、返される各クリエイティブは、そのクリエイティブにスコープされた最近の発火——creative.status_changedcreative.purged の配信——の webhook_activity[] 配列を運びます。これは「パブリッシャーは発火したか? 自分のエンドポイントは受信したか? リトライの軌跡はクリーンか?」というバイヤーのデバッグ用サーフェスです——get_media_buyswebhook_activity[] と同じ形状と契約です。完全な規範的契約(保持、三状態の存在、リクエストフィールドの慣例)についてはウェブフックアクティビティログのパターンを参照してください。 これらの発火にサブスクライブするには、sync_accounts を介してアカウントに notification_configs[] エントリを登録します。セラーは、event_types[] にそのタイプを含む各エントリに対してサブスクライバーごとに発火します。この読み取りの webhook_activity[] は、実際に何が発火したかのバイヤー側のデバッグログです。 三状態の存在が適用されます:
  • フィールドが省略 — セラーはこの読み取りでウェブフックアクティビティを公開しない。
  • [] — セラーはフィールドを公開するが、このクリエイティブについて保持ウィンドウ内に発火がない。
  • 空でない — 実際のレコード、新しい順、webhook_activity_limit(最大 200)で上限。
エンドポイントのログには idempotency_key で相関させます。各レコードの notification_type が発火の種類を判別します:
バイヤーは「発火が届かなかった」を、次を組み合わせて診断します: (a) list_accounts.accounts[].notification_configs[] 上のサブスクライバー登録状態——正しい URL が正しい event_types[] でアクティブか?——と (b) get_adcp_capabilities を介したセラーのケイパビリティ宣言——セラーは自分がサブスクライブしたイベントタイプをサポートするか?。webhook_activity のフィールド省略だけでは、「セラーがログを公開しない」と「発火が起きなかった」を区別できません。

バイヤーのハンドラー(エンドツーエンド)

バイヤーの creative.status_changed 用ウェブフックハンドラーは、各発火を creative_id を介してライブラリの状態と相関させ、idempotency_key で重複排除し、権威あるスナップショットのために list_creatives を再読み込みします(snapshot-and-log ルール 3 に従う):
このハンドラーが避ける二つの落とし穴: (1) ウェブフックのペイロードから直接状態を適用すること(順序と再発行がペイロードを非権威的にします)、(2) 重複排除をスキップすること(セラーは 2xx 以外でリトライし、見逃しイベントの警告で再発行します)。

アカウント要件

ライブラリをホストするクリエイティブエージェントはバイヤーがクリエイティブをクエリする前にアクセスを確立できるよう accounts プロトコルsync_accounts / list_accounts)を実装すべきです。これはセールスエージェントがメディアバイのために使用するのと同じ accounts プロトコルだ — 別バージョンはない。メディアバイのために accounts プロトコルを既に実装しているセールスエージェントは追加対応不要です。

使用例

変数を含むコンセプトスコープのクエリ

特定のコンセプト内のすべての承認済みクリエイティブを DCO 変数定義と共にリスト:

フォーマット固有のクエリ

コンセプトをまたいで特定のフォーマット ID に一致するクリエイティブを検索:

DCO クリエイティブの検索

パーソナライズキャンペーン用のダイナミックコンテンツ変数を持つクリエイティブを検索:

フィールド制限クエリ

選択ドロップダウン用の最小限のクリエイティブデータを取得:

ライブラリヘルスチェック

休眠しているアセットを特定するために配信スナップショットと共にアクティブなクリエイティブを検索:

関連タスク

  • get_creative_delivery - 日付範囲、バリアント内訳、完全な配信メトリクスを含む詳細なパフォーマンスアナリティクス
  • build_creative - ライブラリクリエイティブからマニフェストをビルドするか、ゼロから生成します
  • sync_creatives - クリエイティブライブラリをホストするすべてのエージェントでクリエイティブアセットをアップロードして管理します
  • list_creative_formats - サポートされているクリエイティブフォーマットを発見します
  • preview_creative - クリエイティブマニフェストのプレビューを生成します