Skip to main content
AdCP 3.0 提案 - これらのタスクは AdCP 3.0 向けに開発中です。
Tasks: プロパティリストの作成・更新・取得・列挙・削除。 プロパティリストは静的セットと動的フィルターを組み合わせた管理リソースです。解決時にフィルターが適用され、最終的なプロパティ集合が得られます。

アーキテクチャ: セットアップ時に処理(リアルタイムではない)

Property lists are designed for setup-time operations, not real-time bid decisions:
これにより次が可能になります:
  • 静的リスト: 承認済みプロパティのキュレーション
  • 動的リスト: 国・チャネル・スコア閾値など条件に合致するプロパティ
  • ハイブリッドリスト: ベースセットをフィルターで修正

タスク概要

Property List Structure

A property list contains:

Brand

すべてのフィルターを手動で指定する代わりに、ブランド参照を提供して、あなたが誰かに基づいてガバナンスエージェントが適切なルールを適用するようにします:
エージェントはブランドのアイデンティティを解決し、専門領域に応じてルールを適用します:
  • Consent agent は対象ブランドのターゲットオーディエンスに基づいて COPPA 要件を適用
  • Brand safety agent はブランドの業種からコンテンツカテゴリを推定
  • Sustainability agent はブランドプロフィールから要件を適用
ブランド参照には標準の core/brand-ref スキーマを使用します。ガバナンスエージェントはドメインを解決してブランドの brand.json ファイルからアイデンティティを取得します。

Webhooks

Configure webhooks via update_property_list to receive notifications when the resolved list changes. Important: Webhooks provide notification only. They tell you that the list has changed, but do not stream the updated properties. After receiving a webhook, you must call get_property_list to retrieve the updated property set.

Webhook Flow

Webhook Payload

The webhook payload includes counts but NOT the actual properties. This keeps payloads small and avoids redundant data transfer when recipients may not need the full list immediately.

Webhook Use Cases

  1. Buyer agent aggregation: Receive updates from multiple specialized agents, intersect results
  2. Seller cache invalidation: Know when to re-fetch the compliant property list
  3. Alerting: Notify when significant changes occur to compliance status

Filters

Filters are applied when the list is resolved (via get_property_list):

Feature Requirements

Feature requirements reference features discovered via get_adcp_capabilities. Each agent exposes different features (mfa_score, carbon_score, coppa_certified, etc.). For quantitative features (scores, ranges):
For binary features (true/false):
For categorical features (enum values):

Handling Missing Coverage

When a property doesn’t have data for a required feature, you can control the behavior with if_not_covered:
When if_not_covered: "include" is used, the response includes a coverage_gaps field showing which properties were included despite missing data:
This transparency helps agencies distinguish between properties that passed a requirement vs. those that couldn’t be evaluated.

Required Filters

Every property list must include at least:
  • One country in countries_all (ISO 3166-1 alpha-2 code, case-insensitive)
  • One channel in channels_any (display, video, audio, etc.)
These are required because governance agents need to know which jurisdiction and context to evaluate properties against.

Filter Logic

The filter field names make the logic explicit:
  • countries_all: Property must have feature data for ALL listed countries.
  • channels_any: Property must support ANY of the listed channels.
  • feature_requirements: Property must pass ALL requirements (AND).

Base Properties

base_properties is an array of property sources to evaluate. Each entry is a discriminated union with selection_type as the discriminator:
Each entry must include selection_type: If base_properties is omitted, the agent queries its entire property database for properties matching the filters. See the base-property-source schema for the full specification.

create_property_list

Create a new property list.

Request

Response

Dynamic List (Filters Only)

Create a list that dynamically queries the governance agent’s database (no base_properties - uses agent’s full coverage):

update_property_list

Modify an existing property list.

Request - Update Filters

Request - Replace Base Properties

Request - Add Exclusions

Response


get_property_list

Retrieve a property list with optional resolution of filters.

Request - Get Resolved Properties

Response

The response returns a compact list of identifiers only (not full property objects) for efficiency. Only identifiers that pass the feature requirements are included - no scores or metadata.
The auth_token is only returned when the list is created via create_property_list. Store it securely - you’ll need it to share access with sellers.

Request - Get Metadata Only

Response (Metadata Only)


list_property_lists

List all property lists accessible to the authenticated principal.

Request

Response


delete_property_list

Delete a property list.

Request

Response


Integration with Other Tasks

Using Lists in score_properties

Reference a property list instead of passing properties inline:

Using Lists in Media Buys

Pass property lists to media buy creation:

Error Codes

Caching and Refresh

The get_property_list response includes caching guidance: Typical flow for orchestrators/sellers:

Usage Notes

  1. Setup time only: Governance agents are not in the real-time bid path; resolve lists during campaign setup
  2. Local caching: Orchestrators/sellers must cache resolved properties locally for bid-time decisions
  3. Refresh on schedule: Re-fetch lists based on cache_valid_until (typically every 1-24 hours)
  4. Dynamic vs Static: Use filters-only lists when you want the agent to maintain the property set; use base_properties when you need explicit control
  5. Pagination: Large lists may require multiple requests with cursor-based pagination
  6. No score leakage: Raw scores are kept internal to governance agents; responses contain pass/fail lists, not scores