Skip to main content

コレクションリスト管理

コレクションリストは、「これらのコレクション、これらの基準でフィルターされた」を表現する管理された、キャッシュ可能なアーティファクトです。プロパティリスト と並行しますが、技術的表面(ドメイン、アプリ)ではなくコンテンツプログラム(番組、シリーズ、ポッドキャスト)で動作します。

アーキテクチャ

コレクションリストは セットアップ時リソース です。ガバナンスエージェントによって一度解決され、セラーによってキャッシュされ、ガバナンスエージェントへのランタイム呼び出しなしに配信決定で使われます。

タスク概要

ベースコレクションソース

コレクションリストは、3 つのパターンで選択されたコレクションのベースセットで始まります:

distribution_ids

プラットフォーム非依存の識別子でコレクションを選択します。クロスパブリッシャー除外の主要メカニズム — IMDb ID は、どの CTV プラットフォームが運ぶかにかかわらずプログラムを識別します。

publisher_collections

パブリッシャーの adagents.json 内の特定のコレクションをコレクション ID で選択します。パブリッシャーの内部識別子が既知のときに使います。

publisher_genres

ジャンル基準に一致するパブリッシャーのすべてのコレクションを選択します。特定のパブリッシャーからコンテンツカテゴリー全体を除外するときに使います。
base_collections が省略されると、リストはガバナンスエージェントのコレクションデータベース全体に対してフィルターを適用します。

フィルター

フィルターはベースコレクション選択の後、解決されたリストを狭めます: Include 対 exclude: include フィルターは allowlist、exclude フィルターは blocklist です。両方が同じ次元に存在するとき、include が最初に適用され、次に exclude がさらに狭めます。 例: genres_include: ["drama", "comedy"]genres_exclude: ["crime"] を持つリストは、まずドラマとコメディのコレクションのみを含め、次に crime としてタグ付けされたものを削除します。["drama", "crime"] とタグ付けされたコレクションは除外されます — exclude フィルターが勝ちます。["sports"] とタグ付けされたコレクションは include フィルターによって除外されます(許可されたセットにない)。 コンテンツレーティングはメタデータフィルターであり、コンテンツ評価ではありません。 content_ratings_exclude: [{ system: "tv_parental", rating: "TV-MA" }] は TV-MA として 宣言された すべてのコレクションを除外します。個別のエピソードを評価しません — それは コンテンツ標準 です。 ジャンル分類 はバイヤーとセラー間のジャンルマッチングを正規化します。サポートされる分類: iab_content_3.0iab_content_2.2gracenoteeidrapple_genresgoogle_genresrokuamazon_genrescustomcustom 値はパブリッシャー定義の分類のエスケープハッチです — バイヤーとセラーが帯域外で語彙を交渉します。

create_collection_list

ガバナンスエージェントに新しいコレクションリストを作成します。 Request:
Response:
auth_token は作成時にのみ返されます。それを保存してください — それはセラーにこのリストをフェッチする認可を与えます。

get_collection_list

解決されたコレクションを伴うコレクションリストを取得します。セラーはリストをフェッチしキャッシュするためこれを呼びます。 Request:
Response:
カバレッジギャップ は、フィルターされた次元のメタデータが欠けているにもかかわらずリストに含まれたコレクションをレポートします。この例では、tt9999905 は含まれましたがジャンルメタデータがありません — ガバナンスエージェントはそれがジャンルフィルターに一致することを確認できませんでした。 キャッシング: セラーは解決されたコレクションをキャッシュし cache_valid_until の後に再フェッチすべきです。デフォルトキャッシュ期間は 168 時間(1 週間)です。コレクションメタデータはプロパティメタデータより頻繁に変わらないからです。

update_collection_list

既存のコレクションリストを変更します。base_collectionsfilters はパッチではなく完全な置き換えです。

list_collection_lists

アカウントのコレクションリストをリストします。解決されたコレクションではなくメタデータのみを返します。

delete_collection_list

コレクションリストを削除します。キャッシュされたコピーを持つセラーは webhook 更新の受信を停止します。

Webhook

コレクションリストの解決されたコレクションが変わるとき(新しいプログラムが一致、レーティング更新、プログラム削除)、ガバナンスエージェントは webhook 通知を送ります:
Webhook はサマリーのみを含みます — 受信者は更新されたエントリーのため get_collection_list を呼ばなければなりません。受信者は処理前に signature を検証しなければならず(MUST)、同じ変更イベントのリトライ配信が無視されるよう idempotency_key で重複排除しなければなりません(MUST)。

ライブスポーツ

ライブスポーツは最大の CTV ブランドセーフティ懸念の 1 つです。コレクションリストは event_series 種類を通じてそれを処理します:
これは特定のスポーツプログラムを Gracenote ID(スポーツには SP プレフィックス)で除外し、すべての格闘技イベントシリーズを構造的に除外します。event_series 種類フィルターは、リストがスポーツについてのドキュメンタリーシリーズではなくライブイベントプログラミングをターゲットすることを保証します。

Security considerations

コレクションリストは配信決定をゲートするため、auth_token と webhook コールバックは明示的なライフサイクルルールを必要とします。Security の一般的な制御が適用されます。コレクションリスト固有のルール: auth_token のスコープ、失効、ログ衛生。 各トークンは正確に 1 つの list_id を認可します。トークンをリスト間で再利用しないでください。ガバナンスエージェントはリストを受け取るセラーごとに明確なトークンを発行しなければなりません(MUST) — 共有トークンは関係ごとに失効できず、単一の侵害への唯一の応答をリスト全体のローテーションにします。トークンはログ、キャッシュキー、メトリックラベルに書き込まれてはならず(MUST NOT)、get_collection_list からのエラーレスポンスは提示されたトークンをエコーしてはなりません(MUST NOT)。 delete_collection_list とセラーごとの失効は異なります:
  • 通常の削除または関係終了: トークンは後続の get_collection_list 呼び出しを即座に失敗させなければなりません(MUST)が、キャッシュされた解決を持つセラーは cache_valid_until までキャッシュから提供し続けてもよい(MAY)。自然な関係終了は侵害ではありません。
  • 侵害駆動の失効: ガバナンスエージェントはキャッシュ無効化をシグナルしなければなりません(MUST)。セラーがまだ完了するアクセスを持つ次のポーリングで削減された cache_valid_untilnow 以下)を返すか、キャッシュされたコピーが破棄されるよう change_summary がリストバージョンが無効化されたことを伝える collection_list_changed webhook を発行します。予定された TTL まで侵害されたコンテンツをセラーキャッシュに残すことは許容されません。
Webhook URL 検証。 update_collection_listwebhook_url は、他の任意のバイヤー提供コールバック URL と SSRF 等価です。正準の Webhook URL validation (SSRF) ルールを適用してください — HTTPS のみ、検証された IP 範囲(::ffff:0:0/96 を含む IPv4 と IPv6)、接続ピン留め(DNS 再解決だけでなく)、リダイレクトフォローなし、サイズとタイムアウト上限。 Webhook 署名アルゴリズム。 webhook 署名は 標準 webhook 署名ルール に従わなければなりません(MUST)。デフォルトで、RFC 9421 webhook コールバックプロファイル が適用されます: ガバナンスエージェントは、自身の brand.json の agents[] エントリーの jwks_uri で公開された adcp_use: "request-signing" 鍵で署名します。非推奨の webhook-signing 鍵は互換性ウィンドウ中受理されたままです。サブスクライブするセラーは、tag="adcp/webhook-signing/v1" でカバードコンポーネント @method@target-uri@authoritycontent-typecontent-digest を検証します。非推奨の HMAC-SHA256 フォールバックは、サブスクライブするセラーが webhook 登録で authentication.credentials を投入するときのみ適用されます。そのパスは Legacy HMAC-SHA256 fallback ルールに従い、そのパスの任意のボディ signature フィールドは便宜コピーです — 受信者はヘッダーに対して検証しなければならず(MUST)、ボディ値を信頼してはなりません(MUST NOT)。 Distribution-ID 入力。 ガバナンスエージェントは永続化前に識別子形式を検証すべきで(SHOULD)(IMDb: ^tt\d+$、EIDR: 10.5240/...、Gracenote: ベンダープレフィックス)、リスト肥大化 DoS を防ぐためリスト変更にアカウントごとのレート制限を強制すべきです(SHOULD)。未解決の識別子を黙って落とすのではなく coverage_gaps に表示します。

セラーとコレクションリストを共有する

パターンは プロパティリストの共有 に一致します:
  1. ガバナンスエージェントにコレクションリストを作成
  2. 作成レスポンスから auth_token を保存
  3. ターゲティングオーバーレイで collection_list または collection_list_exclude を渡す
  4. セラーが auth トークンを使って解決されたリストをフェッチしキャッシュ
  5. リストが変わると webhook がセラーに通知