Skip to main content
プロダクト は AdCP における中核の販売単位です。本ドキュメントではプロダクトモデル、価格/配信種別、発見方法や構造について説明します。
価格モデル プロダクトはサポートする価格モデルを宣言し、バイヤーはメディアバイ作成時に具体的な価格オプションを選択します。CPM、CPCV、CPP、CPC、CPA、vCPM、定額料金、時間ベース価格の詳細は Pricing Models Guide を参照。

プロダクトモデル

  • product_id (string, required)
  • name (string, required)
  • description (string, required)
  • publisher_properties (list[PublisherPropertySelector], required): このプロダクトが対象とするパブリッシャープロパティ。Property Targeting を参照。
  • channels (list[string], optional): このプロダクトが販売される広告チャネル(例: ["retail_media"]["display", "olv"])。セラーは、リテールメディア・CTV/OLV・マルチチャネルバンドルなど、自明でないチャネルにまたがるプロダクトには channels を宣言すべきです。プロダクトのチャネルは、そのプロパティの supported_channels の和集合のサブセットであるべきです。Media Channel Taxonomy を参照。
  • video_placement_types (list[string], optional): このプロダクトに含まれうる、宣言済みの動画プレースメントタイプ。IAB Tech Lab/OpenRTB 2.6 の video.plcmt 定義を AdCP ネイティブ名で使用: instreamaccompanying_contentinterstitialstandalone。集約プロダクトやアドネットワークプロダクトは複数値を含みうる。これはセラー宣言のディスカバリーメタデータであり、在庫品質や配信コンテキストの独立検証ではありません。
  • audio_distribution_types (list[string], optional): このプロダクトに含まれうる、宣言済みのオーディオ配信タイプ。IAB Tech Lab/OpenRTB 2.6 の audio.feed 定義を AdCP ネイティブ名で使用: music_streaming_servicefm_am_broadcastpodcastcatch_up_radioweb_radiovideo_gametext_to_speech。集約プロダクトやアドネットワークプロダクトは複数値を含みうる。これはセラー宣言のディスカバリーメタデータであり、在庫品質や配信コンテキストの独立検証ではありません。
  • sponsored_placement_types (list[string], optional): カタログ駆動のリテールメディアプロダクト向けの、宣言済みのスポンサープレースメントタイプ: sponsored_searchsponsored_displaysponsored_native。集約プロダクトやアドネットワークプロダクトは複数値を含みうる。これはセラー宣言のディスカバリーメタデータであり、在庫品質や配信コンテキストの独立検証ではありません。
  • social_placement_surfaces (list[string], optional): ソーシャルプロダクト向けの、宣言済みのソーシャルプレースメント面: feedstoriesshort_videoexploresearch。集約プロダクトやアドネットワークプロダクトは複数値を含みうる。これはセラー宣言のディスカバリーメタデータであり、在庫品質や配信コンテキストの独立検証ではありません。
  • format_ids (list[FormatID], conditional): レガシーの名前付きフォーマット参照。プロダクトは format_idsformat_options・またはその両方を含まなければなりません。Creative Formats を参照。
  • format_options (list[ProductFormatDeclaration], conditional): このプロダクトが受け付ける 3.1 以降の正準的なフォーマットオプション宣言。両方のフォーマットフィールドが存在する場合、バイヤーは format_options を優先します。プロダクトレベルのフォーマットは販売可能プロダクトの上限であり、プレースメントレベルのフォーマットはこの集合を狭められますが、プロダクトが受け付けないフォーマットを追加することはできません。バイヤーの FormatOptionRef セレクターは、パブリッシャー宣言のオプションには {scope: "publisher", publisher_domain, format_option_id} を、プロダクトローカルのオプションには {scope: "product", format_option_id} を使います。
  • placements (list[Placement], optional): プロダクト内の特定の公開広告プレースメント。各プレースメントは kindpublisher_ref または seller_inline)と modetargetable または included)を宣言します。セラー非公開の配信オブジェクトはここに公開されません。Placements を参照。
  • shows (list[CollectionSelector], optional): このプロダクトが対象とする番組。パブリッシャーごとにグルーピングされ、各エントリは publisher_domain と、パブリッシャーの adagents.json で番組を参照する collection_ids を持ちます。Collections and installments を参照。
  • episodes (list[Episode], optional): このプロダクトで利用可能な特定エピソード。Collections and installments を参照。
  • delivery_type (string, required): "guaranteed" または "non_guaranteed"
  • exclusivity (string, optional): このプロダクトが排他的アクセスを提供するかどうか。"none"(フィールド未指定時のデフォルト)— 複数の広告主が同時に購入可能。"category" — 業種カテゴリーごとに 1 広告主のみ。"exclusive" — 単独スポンサーシップ。特定の番組やプレースメントに紐付く guaranteed プロダクトで最も関連します。
  • pricing_options (list[PricingOption], required): このプロダクトで利用可能な価格モデルの配列。Pricing Models を参照。
  • delivery_measurement (object, optional): 広告デリバリーを計測する主体 — インプレッションカウントに使用する広告サーバーとビューアビリティベンダー。新規実装は vendors を構造化された BrandRef 配列で埋めます(例: [{ "domain": "googleadmanager.com" }, { "domain": "integralads.com" }])。レガシーの provider 文字列は非推奨です。未指定の場合、バイヤーは自身の計測デフォルトを適用すべきです。Delivery Measurement を参照。
  • outcome_measurement (OutcomeMeasurement, 非推奨): ビジネス成果計測(リフト、ブランドリフト、来店)を宣言するレガシーフィールド。新規実装は成果メトリクスを reporting_capabilities.available_metrics で宣言し、アトリビューション手法とウィンドウを committed_metricsqualifier スロットでピン留めします。1 マイナーの後方互換のため保持され、次のメジャーで削除されます。移行パターンは Commerce Media を参照。
  • creative_policy (CreativePolicy, optional): クリエイティブ要件と制限。
  • is_custom (bool, optional): 特定ブリーフに基づき生成された場合は true
  • expires_at (datetime, optional): is_custom の場合、プロダクトの有効期限。
  • property_targeting_allowed (bool, optional, default: false): バイヤーが get_products のプロパティリストフィルタリングを使ってこのプロダクトを publisher_properties のサブセットに絞り込めるかどうか。false(デフォルト)の場合、プロダクトは「全か無か」— バイヤーはすべてのプロパティを受け入れなければならず、そうでなければ property_list フィルタリング結果からプロダクトが除外されます。Property Targeting を参照。
  • collection_targeting_allowed (bool, optional, default: false): バイヤーがこのプロダクトの shows のサブセットをターゲティングできるかどうか。false(デフォルト)の場合、プロダクトはバンドル — バイヤーはリストされたすべての番組を取得します。true の場合、バイヤーはメディアバイで特定の番組を選択できます。
  • data_provider_signals (list[DataProviderSignalSelector], 非推奨): このプロダクトに既にバンドル/関連付けられたデータプロバイダーシグナルのレガシー/選択不可メタデータ。新規実装は included_signals を使うべきです。
  • included_signals (list[SignalListing], optional): このプロダクトに既に含まれる/バンドルされる/計画されたシグナルの選択不可メタデータ。これらはプロダクトが何であるかを説明するもので、バイヤーはパッケージの signal_targeting_groups では選択しません。
  • signal_targeting_allowed (bool, optional, default: false): このプロダクトがパッケージレベルのシグナルターゲティング面を持つかどうか。編集可能性は signal_targeting_rules で制御されます。
  • signal_targeting_options (list[ProductSignalTargetingOption], optional): このプロダクト向けにバイヤーが選択、またはセラーが適用しうる、インラインのセラー提供シグナル。プロダクトローカルのシグナルオプション、またはセラーが適用を認可されたデータプロバイダーシグナルの場合があります。Signal Targeting を参照。
  • signal_targeting_rules (SignalTargetingRules, optional): 選択可能なシグナルに対する、単一/複数選択の上限などの構成ルール。
  • catalog_types (list[string], optional): このプロダクトがカタログ駆動型キャンペーンでサポートするカタログタイプ。スポンサードプロダクトリスティングは ["product"] を、求人ボードは ["job", "offering"] を宣言します。バイヤーはこのフィールドを通じて同期済みカタログとプロダクトを照合します。Catalogs を参照。
  • catalog_match (object, optional): バイヤーが get_productscatalog を提供する場合、このプロダクトで対象となるカタログアイテムを示します。matched_gtins(クロスリテーラー GTIN マッチ)、matched_ids(汎用アイテム ID マッチ)、matched_countsubmitted_count を含みます。
  • metric_optimization (object, optional): このプロダクトのメトリクス最適化機能。存在する場合、プロダクトが kind: "metric"optimization_goals をサポートすることを示します。Metric optimization を参照。
  • max_optimization_goals (integer, optional): パッケージでこのプロダクトが受け付ける optimization_goals の最大数。未指定の場合、上限は宣言されない。ほとんどのソーシャルプラットフォームは 1 つのみ受け付けます。
  • conversion_tracking (object, optional): コンバージョンイベントトラッキング機能。存在する場合、プロダクトが kind: "event"optimization_goals をサポートすることを示します。Conversion tracking を参照。
  • product_card (object, optional): UI でのプロダクト表示用ビジュアルカード定義。Product Cards を参照。

Metric optimization

kind: "metric"optimization_goals をサポートするプロダクトは、metric_optimization に機能を宣言します。メトリクスゴールにはイベントソースやコンバージョントラッキングの設定は不要 — セラーがこれらのメトリクスをネイティブに追跡します。

Conversion tracking

kind: "event"optimization_goals をサポートするプロダクトは、conversion_tracking に機能を宣言します。セラーレベルの機能(サポートされるイベントタイプ、UID タイプ、アトリビューションウィンドウ)は get_adcp_capabilities で宣言されます。
完全な最適化ゴールのリファレンスは Conversion Tracking & Optimization Goals を参照。

価格モデル

パブリッシャーは各プロダクトでサポートする価格モデルを宣言し、バイヤーはメディアバイ作成時に利用可能なオプションから選択します。このアプローチにより:
  • 1 プロダクトに複数価格モデル - 同一在庫を異なる価格体系で提供可能
  • 複数通貨対応 - パブリッシャーは pricing_options エントリごとにサポート通貨を宣言します。バイヤーはディスカバリー時に filters.pricing_currencies を使ってメディアプロダクトの取引通貨を絞り込むことができ、購入時にはサポートされた通貨を使用しなければなりません
  • 柔軟な価格設定 - CPM、CPCV、CPP(GRP ベース)、CPA などをサポート

サポートされる価格モデル

  • CPM (Cost Per Mille) - 1,000 インプレッションあたりのコスト(従来型ディスプレイ)
  • CPC (Cost Per Click) - 広告クリックあたりのコスト
  • CPCV (Cost Per Completed View) - 動画/オーディオ 100% 再生完了あたりのコスト
  • CPV (Cost Per View) - パブリッシャー定義の閾値での視聴あたりのコスト
  • CPA (Cost Per Acquisition) - コンバージョンイベント(購買、リード、登録等)あたりのコスト
  • CPP (Cost Per Point) - GRP あたりのコスト(TV/オーディオ)
  • Flat Rate - 配信量に関わらず固定費
  • Time - キャンペーン期間に応じてスケールする時間単位(日、週、月)あたりのコスト

PricingOption 構造

各価格オプションの例:
オークション型(fixed_price なし)の場合、floor_price を最低入札制約として、任意の price_guidance をパーセンタイルのヒントとして使用します。入札ベースのオークションモデル(cpmvcpmcpccpcvcpv)では、max_bid をブール値シグナルとして含めることができ、bid_price が確定価格からバイヤー上限モードに切り替わることを示します:

Delivery Measurement

プロダクトは利用可能な場合、計測プロバイダーを宣言すべきだ:
一般的なプロバイダーの例:
  • "Google Ad Manager with IAS viewability"
  • "Nielsen DAR for P18-49 demographic measurement"
  • "Geopath DOOH traffic counts updated monthly"
  • "Comscore vCE for video completion tracking"
  • "Self-reported impressions from proprietary ad server"
guaranteed プロダクトは、購入レベルでアカウンタビリティ義務を定義する performance_standardsmeasurement_termscancellation_policy も宣言できます。Accountability を参照。

Outcome Measurement オブジェクト

成果計測を含むプロダクト(リテールメディアで一般的)の例:

CreativePolicy オブジェクト

クリエイティブ要件や制限を定義します:

Placements

プロダクトは、在庫内の特定の公開広告プレースメントを任意で宣言できます。プレースメント ID はパブリッシャースコープです。プレースメントがパブリッシャーの adagents.json のプレースメント宣言に存在する場合、プロダクトのプレースメントは kind: "publisher_ref"publisher_domainplacement_id でそのエントリを参照します。この場合、パブリッシャー宣言が名前やその他の公開メタデータを解決するため、プロダクトは name を省略してよい。公開のパブリッシャー宣言が存在しない場合、セラーエージェントは kind: "seller_inline" と、namedescription・フォーマット・タグなどのバイヤー向けフィールドを持つインラインプレースメントを定義します。その placement_id は依然としてパブリッシャー名前空間で解釈され、publisher_domain が省略された場合はセラーエージェント自身のパブリッシャー名前空間で解釈されます。パブリッシャー参照がパブリッシャーホストの adagents.json から解決されたか、コミュニティ管理のフォールバックファイルから解決されたかは、リゾルバーのメタデータであり、別個のプレースメント種別ではありません。
  • kind: "publisher_ref" - 指定パブリッシャーの adagents.json から解決される、パブリッシャースコープのプレースメント参照。publisher_domain が必要。
  • kind: "seller_inline" - セラーエージェントがインラインで定義する、公開のバイヤー向けプレースメントメタデータ。name が必要。
  • publisher_domain - 参照されるプレースメントを定義する adagents.json を持つドメイン。新しいマルチパブリッシャープロダクトは、プレースメント名前空間を明示するため含めるべきです(SHOULD)。
  • placement_id - パブリッシャー名前空間におけるプレースメント ID。バイヤーは creative_assignments[].placement_refspublisher_domain とともに参照します。レガシーの placement_ids 文字列は単一パブリッシャーの文脈でのみ一意です。
  • mode: "targetable" - バイヤーはクリエイティブ割り当てやプロダクト内のプレースメント選択時に、このパブリッシャースコープのプレースメントを参照してよい。
  • mode: "included" - 公開プレースメントはプロダクトの記述された構成の一部だが、バイヤーは placement_id で選り好みできない。
  • video_placement_types - OLV その他の動画プレースメントの宣言済み動画プレースメントタイプ。具体的なプレースメントは通常1値を宣言し、集約プレースメントは複数を宣言しうる。
  • audio_distribution_types - ラジオ、ストリーミングオーディオ、ポッドキャスト、ゲームその他のオーディオプレースメントの宣言済みオーディオ配信タイプ。
  • sponsored_placement_types - カタログ駆動のリテールメディアプレースメントの宣言済みスポンサープレースメントタイプ。
  • social_placement_surfaces - ソーシャルプレースメントの宣言済みソーシャルプレースメント面。
  • パブリッシャー参照ルール - パブリッシャー参照のプロダクトプレースメントは、パブリッシャーの adagents.json{publisher_domain, placement_id} に解決されます。
  • 非公開在庫ルール - セラー非公開の配信オブジェクト、アドサーバーマッピング、ソース/オリジンの詳細は get_products の外に置かなければなりません。
  • クリエイティブ割り当て - 異なるクリエイティブを targetable なプレースメントに割り当て可能。
  • プレースメントターゲティングの省略 - placement_refs もレガシーの placement_ids も持たないクリエイティブは、パッケージ内のすべてのバイヤーターゲット可能なプレースメントで配信され、セラーは included-only の配信構成を引き続き制御します。
  • 可能なら登録済み ID を使う - パブリッシャーが adagents.json で正準的な placements を宣言している場合、プロダクトプレースメントはそのカタログ ID を placement_id として使うべきです(SHOULD)。
  • レジストリの意味論を保持 - プロダクトが登録済みプレースメントを参照する場合、それは同じプレースメントを指します。プロダクトは format_idsformat_options を狭めたり、運用上の詳細を追加したりできますが、プレースメントの意味を非互換に変えるべきではありません。
  • タグはプロダクトレベルでも有用 - プロダクトプレースメントはグルーピング用に tags を持てます。プレースメントがパブリッシャーレジストリ由来の場合はレジストリのタグと整合すべきです。
mode は 2026年5月25日時点で新規送信者に必須です。2026年11月25日に終了する6か月の移行期間中、バイヤーは placements[] エントリが mode を省略するレガシープロダクトを許容し、それらのプレースメントをクリエイティブ割り当て用に targetable として扱ってよい。2026年11月25日以降、バイヤーは mode の欠如に対して fail closed すべきです。 パブリッシャーは、adagents.jsonauthorized_agents[].placement_ids または authorized_agents[].placement_tags を使って、特定のプレースメントに対してエージェントを認可できます。セラーエージェントは、自身が販売を認可されたパブリッシャー参照のプレースメントのみを返すべきです。

動画プレースメントタイプ

動画プロダクトは video_placement_types をプロダクトレベル、プレースメントレベル、またはその両方で宣言できます。語彙は IAB Tech Lab/OpenRTB 2.6 の video.plcmt 定義に従いますが、AdCP は OpenRTB のワイヤー名ではなく読みやすいフィールド名・値名を使います: このフィールドは配列です。販売可能プロダクトが複数のプレースメントタイプを集約できるためです。例えば OLV ネットワークプロダクトは instreamaccompanying_content の両方を含み、個々の targetable なプレースメントは1タイプに絞られる、といったことがあります。プロダクトとプレースメントの両宣言が存在する場合、プロダクトレベルの配列は、セラーがそのプロダクトの下で配信しうる動画プレースメントタイプの和集合であるべきです。 これはディスカバリーのシグナルであり、検証の主張ではありません。バイヤーは get_products.filters.video_placement_types で要求タイプを満たせるプロダクトをフィルタリングできますが、セラーは、計画/購入時に配信を instream 在庫へ制約できない限り、instream 専用フィルターに対して混在した非ターゲット可能なバンドルを返すべきではありません。

オーディオ配信タイプ

オーディオプロダクトは audio_distribution_types をプロダクトレベル、プレースメントレベル、またはその両方で宣言できます。語彙は IAB Tech Lab/OpenRTB 2.6 の audio.feed 定義に従いますが、AdCP は OpenRTB の数値コードではなく読みやすいフィールド名・値名を使います: このフィールドは、バイヤー向けの radiostreaming_audiopodcastgaming チャネル内の実行・配信の詳細を説明します。チャネル名を変えるものではなく、認可可能な在庫サーフェスに紐付く adagents.jsonproperty_type の意味論を変えるものでもありません。フィールドが配列なのは、販売可能プロダクトが複数のオーディオ配信タイプを集約できるためです。両宣言が存在する場合、プロダクトレベルの配列は、セラーがそのプロダクトの下で配信しうるオーディオ配信タイプの和集合であるべきです。 これはディスカバリーのシグナルであり、検証の主張ではありません。バイヤーは get_products.filters.audio_distribution_types で要求タイプを満たせるプロダクトをフィルタリングできますが、セラーは、計画/購入時に配信を要求されたオーディオ配信タイプへ制約できない限り、混在した非ターゲット可能なバンドルを返すべきではありません。

スポンサープレースメントタイプ

カタログ駆動のリテールメディアプロダクトは sponsored_placement_types をプロダクトレベル、プレースメントレベル、またはその両方で宣言でき、スポンサープレースメントがリテーラーサーフェスのどこにレンダリングされるかを区別します: これらの値は、source_catalog スロットが必須のカタログ駆動 sponsored_placement 正準の下でのプロダクトのプレースメントサーフェスを説明します。オフサイトのプレースメントはカタログにキー付けされないため、オフサイト値は意図的に除外されています。フィールドが配列なのは、販売可能プロダクトが複数のサーフェスを集約できるためです。両宣言が存在する場合、プロダクトレベルの配列は、セラーがその下で配信しうる和集合であるべきです。 これはディスカバリーのシグナルであり、検証の主張ではありません。バイヤーは get_products.filters.sponsored_placement_types で要求タイプを満たせるプロダクトをフィルタリングできますが、セラーは、計画/購入時に配信を要求タイプへ制約できない限り、混在した非ターゲット可能なバンドルを返すべきではありません。

ソーシャルプレースメント面

ソーシャルプロダクトは social_placement_surfaces をプロダクトレベル、プレースメントレベル、またはその両方で宣言でき、ソーシャルプレースメントがレンダリングされるアプリ内サーフェスを区別します: フィールドが配列なのは、販売可能プロダクトが複数のサーフェスを集約できるためです。両宣言が存在する場合、プロダクトレベルの配列は、セラーがその下で配信しうる和集合であるべきです。 これはディスカバリーのシグナルであり、検証の主張ではありません。バイヤーは get_products.filters.social_placement_surfaces で要求サーフェスを満たせるプロダクトをフィルタリングできますが、セラーは、計画/購入時に配信を要求サーフェスへ制約できない限り、混在した非ターゲット可能なバンドルを返すべきではありません。

プレースメントとのフォーマット優先順位

プロダクトレベルの format_idsformat_options は、プロダクト全体が受け付けるクリエイティブフォーマットを定義します。プレースメントレベルの format_ids または format_options(プロダクトプレースメントにインラインで返されるか、公開のパブリッシャープレースメント宣言から継承されるかを問わず)は、その特定のプレースメントについてプロダクト全体の集合を狭めるだけです。 プロダクトとプレースメントの両フォーマット宣言が存在する場合、バイヤーはそのプレースメントの実効的な受け入れフォーマットをそれらの積集合として計算します。レガシーの format_ids については、まず canonicalv1_format_ref、または正準マッピングレジストリを通じて名前付きフォーマットを正準宣言へ射影します。射影後に生の (agent_url, id) 値を比較してはいけません。レガシーの 300x250 ディスプレイ ID と、width: 300height: 250 を持つ正準的な image 宣言は互換です。3.1 以降の format_options については、パブリッシャー宣言のオプションを {publisher_domain, format_option_id} で照合し、publisher_domain が省略された場合はプロダクトローカルのオプションを format_option_id で照合し、それ以外は、プレースメントパラメータがプロダクト宣言を狭める同じ format_kind の宣言と照合します。 プロダクトのゲーティングは等価マッチングより厳格です。プロダクトまたはプレースメントが widthheightduration_ms_exact、または尺の範囲などの固定制約を宣言する場合、バイヤーが選択したフォーマットまたはクリエイティブマニフェストはそれらの制約を宣言し満たさなければなりません。広い要求(寸法のない format_kind: "image"、尺のない video_hosted)は、固定サイズや固定尺のプロダクトを満たしません。範囲については、満足とは包含を意味します: 範囲ベースの要求は、それが許すすべての値がプロダクトの受け入れ範囲内に収まる場合にのみプロダクトを満たします。重なりだけでは不十分です。正確な尺は、その正確な値が範囲内に収まる場合に範囲を満たします。逆は許されます: 別のプロダクト制約が除外しない限り、広いプロダクト宣言は特定の 300x250 画像や30秒動画を受け入れられます。format matching vs product satisfaction を参照。 プレースメントがフォーマット宣言を持たない場合、プロダクトレベルのフォーマットを継承します。プロダクトレベルの宣言に存在しないプレースメント専用のフォーマットは、プロダクトのクリエイティブ契約の拡張ではなくセラーの適合性エラーです。バイヤーはそのフォーマットに対して fail closed し、受け入れられたものとして扱うべきではありません。

Placement オブジェクト構造

例: プレースメント付きプロダクト

メディアバイ作成時に、バイヤーは異なるクリエイティブを別プレースメントに割り当てられます。
詳細は Creative Assignment and Placement Targeting を参照。

コレクションとインストールメント

番組はフォーマットやプレースメントと並ぶ、プロダクトの第三の次元です。プレースメントが広告の「どこに」表示されるかを、フォーマットが「どのように見えるか」を表すのに対し、番組は「コンテンツコンテキスト」— 視聴者が見ているプログラムを表します。プロダクトに showsepisodes を宣言することで、バイヤーは在庫購入時に特定の番組やエピソードをターゲティングできます。 完全なモデル、例、ターゲティングの詳細は Collections and installments を参照。

Exclusivity

exclusivity フィールドは、プロダクトがその在庫への排他的アクセスを提供するかどうかを示します。未指定の場合はデフォルトで "none" Exclusivity は、広告主がブランド分離やコンテンツアソシエーションの独占権を求める、特定の番組やプレースメントに紐付く guaranteed プロダクトで最も関連します。

各レベルの使用場面

  • none: プログラマティック在庫、ランオブネットワーク、オープンオークションプロダクト。複数の広告主が同じ在庫を共有するのが前提。
  • category: 競合分離が重要なポッドキャストや CTV スポンサーシップ。1 コレクションに 1 自動車ブランド、1 インストールメントに 1 フィンテックブランド — ただし競合しない複数の広告主が同時に購入可能。
  • exclusive: 単一のコレクションまたはイベントの単独スポンサーシップ。広告主はそのコンテンツに関連付けられる唯一のブランドとなります。
パブリッシャーは shows を持つ guaranteed プロダクトには exclusivity を含めるべきです。"none" の暗黙のデフォルトはコレクションレベルの在庫には曖昧 — バイヤーはパブリッシャーが共有在庫を意図しているのか、単にフィールドを省略したのかを判断できません。

コンテンツスポンサーシップパターン

delivery_type: "guaranteed"exclusivity: "exclusive"shows を組み合わせたプロダクトはコンテンツスポンサーシップを表す — 広告主は特定コンテンツの唯一のスポンサーとなります。これはポッドキャストのタイトルスポンサーシップ、CTV コレクションスポンサーシップ、イベントベースのテイクオーバーの標準パターンです。
カテゴリー排他性は、パブリッシャーがネットワーク全体で競合ブランドを分離しながら、競合しない複数の広告主には販売するマルチコレクションバンドルで機能する:

Property Targeting

property_targeting_allowed フラグは、バイヤーが get_products のプロパティリストフィルタリングを使ってプロダクトをその publisher_properties のサブセットに絞り込めるかどうかを示します。

動作

  • property_targeting_allowed: false(デフォルト): プロダクトは「全か無か」。バイヤーの property_list にプロダクトのプロパティがすべて含まれていない場合、そのプロダクトは結果から完全に除外されます。
  • property_targeting_allowed: true: バイヤーは property_list に一致するプロパティにプロダクトを絞り込める。プロパティとバイヤーのリストに何らかの積集合がある場合、プロダクトは結果に含まれます。

ユースケース

全か無かプロダクトproperty_targeting_allowed: false):
バイヤーが site_asite_b のみを含む property_listget_products を呼び出すと、バイヤーのリストにすべてのプロパティが含まれていない(site_c が欠落)ため、このプロダクトは除外される フレキシブルプロダクトproperty_targeting_allowed: true):
バイヤーが techsports のみを含む property_listget_products を呼び出すと、積集合があるためこのプロダクトは含まれる。バイヤーはその後このプロダクトを購入し、パッケージの targeting_overlay.property_list を通じて一致するプロパティのみをターゲティングできます。

Signal Targeting

プロダクトは、異なる意味を持つ三つのシグナルフィールドを使います:
  • data_provider_signals は、プロダクトに既にバンドル/関連付けられたデータプロバイダーシグナルの非推奨のレガシー/選択不可メタデータです。新規実装は included_signals を使うべきです。
  • included_signals は構造化された選択不可の面です。シグナルが既にプロダクトにバンドル/含有/計画されている場合に使います。プロダクトごとのターゲティング価格もセラーのアクティベーションハンドルも持ちません。
  • signal_targeting_options はインラインの選択可能/構成可能な面です。セラー提供のシグナルがパッケージに現れうるもので、プロダクトが商品固有のメニュー、価格、アクティベーションハンドル、デフォルト/固定の選択、グルーピングのヒント、または brief/refine で選択されたサブセットを公開する必要がある場合に使います。
Product.signal_targeting_allowedsignal_targeting_rules は、シグナル構成に関する正準的なプロダクト契約です。get_signals は正準的な広域シグナルディスカバリー面です。ホールセールプロダクトは、インラインの signal_targeting_options なしで signal_targeting_allowed: true を使い、選択可能なシグナルフィードは get_signals を呼ぶようバイヤーに伝えられます。brief/refine のレスポンスは、関連サブセットや商品固有のオーバーライドとしてインラインの signal_targeting_options を返せます。セラーは、それらのシグナルをこのプロダクトの外でも発見可能にしたい場合を除き、プロダクトローカルのオプションを get_signals で公開する必要はありません。セラーは、signal_targeting_options または signal_targeting_rules を返すときは常に signal_targeting_allowed: true を設定しなければならず(MUST)、バンドルされているがパッケージのシグナルグループとして表現されないシグナルには signal_targeting_options ではなく included_signals を使わなければなりません(MUST)。 シグナルは、特徴値に似た、名前付きのターゲット可能な次元です。シグナル定義は value_typebinarycategorical、または numeric)を宣言し、時とともにより豊かなメタデータを持ちうる。プロダクトのシグナルリスティングは、明示的な解決スコープを持つ signal_ref を使います: { "scope": "product", "signal_id": "..." } はリスティングが定義するプロダクトローカルのシグナルを、{ "scope": "data_provider", "data_provider_domain": "...", "signal_id": "..." } はデータプロバイダーが公開する adagents.json の signals[] で定義されたシグナルを、{ "scope": "signal_source", "signal_source_url": "...", "signal_id": "..." } はソースネイティブなシグナルを指します。signal_ref.scope は来歴ではなく解決パスであり、権威ある拡充情報はセラー、シグナルソース、またはデータプロバイダーのシグナル定義に存在します。scope: "product" の場合、プロダクトが定義の境界であるため、プロダクトリスティングは namevalue_type を含まなければなりません(MUST)。scope: "data_provider" または scope: "signal_source" の場合、signal_ref で十分であり、インラインの名前・説明・値型・範囲・手法は文脈的であって権威的ではありません。get_signalsget_products の両方で公開されるプロダクトローカルのシグナルについては、signal_ref.signal_id は同じシグナルに対するセラーの get_signals.signals[].signal_ref.signal_id と一致しなければなりません(MUST)。 シグナルターゲティングの構成は、セラー全体の get_adcp_capabilities ではなく各プロダクトに宣言されます。一つのセラーが、異なる include/exclude やグルーピング上限を持つ異なるアドサーバーやプラットフォームに支えられたプロダクトを販売しうるためです。バイヤーは、構成しようとしている特定のプロダクトからインラインの signal_targeting_optionssignal_targeting_rules を読むべきです。
  • signal_targeting_allowed: false(デフォルト): シグナルはプロダクト条件にバンドルされ、パッケージレベルのシグナルグループとしては表現されません。バイヤーは提供されたままプロダクトを購入し、パッケージ上でシグナルグループを選択したりエコーで受け取ったりしません。
  • signal_targeting_allowed: true: プロダクトはパッケージレベルのシグナルターゲティング面を持ちます。ホールセールディスカバリーでは、インラインの signal_targeting_options が省略される場合、バイヤーは get_signals を使って選択可能なシグナルフィードを発見します。brief/refine の結果では、セラーは関連サブセットや商品固有のオーバーライドとしてインラインの signal_targeting_options を含めてよい。
  • signal_targeting_rules: 任意のストアフロント構成ルール。セラーが任意、必須、単一選択、相互排他、固定、セラー計画、またはグループ化されたシグナル選択を表現する必要がある場合に、resolution_modelselection_modemin_selected_signalsmax_selected_signalsmax_selected_per_groupselection_group_rulesmax_signal_targeting_groupsmax_signals_per_targeting_group を使います。resolution_model: "direct_targeting" は、選択されたシグナルがパッケージ在庫にターゲティング述語として適用されることを意味します。resolution_model: "seller_planned" は、選択されたシグナルが計画入力であり、セラーが商品固有の在庫・タイミング・可用性・リーチ・ペーシングの制約に対して解決することを意味します。バイヤーはシグナル選択を下位の在庫やスケジュールの判断に分解しようとすべきではありません。selection_mode: "required" は、少なくとも min_selected_signals(省略時は 1)を意味します。すべての明示的なパッケージレベルのシグナル選択はグループ化された式の形状を使います: トップレベルの operator: "all" と、include グループには operator: "any"、除外グループには operator: "none" を使う子グループ。selection_modefixed の場合、バイヤーは default_selected シグナルを読み取り専用として表示します。セラーは、バイヤーが targeting_overlay.signal_targeting_groups を省略してもそれらのシグナルを適用します。selection_group_rules が存在する場合、各子グループは正確に一つの selection_group と一つのターゲティングモードのシグナルを含まなければならず(MUST)、バイヤーは各 (selection_group, targeting_mode) ペアにつき最大一つの子グループを送らなければなりません(MUST)。セラーは、重複・混在・折りたたまれた子グループを拒否しなければなりません(MUST)。
  • activation_status: "requires_activation": バイヤーがセラーの受け入れるアクティベーションキーを既に持っていない限り、get_products だけではシグナルを選択するのに不十分です。プロダクトオプションは signal_agent_segment_id を含まなければならず(MUST)、バイヤーは activate_signal を通じてシグナルをアクティベートし、セラーがパッケージで要求する場合はアクティベーションキーを含めます。
各シグナルオプションの allowed_targeting_modes は、購入時のどの子グループ演算子が有効かを制御します: "include"operator: "any" に、"exclude"operator: "none" に対応します。selection_group は、max_selected_per_groupselection_group_rules のような上限のための、プロダクト定義の構成可能性バケットです。パッケージの signal_targeting_groups.groups[] 内の特定の子グループへのポインタではありません。あるターゲティングモードについてオプションが一つの子グループ内で自由に OR 結合できる場合は同じ selection_group を使います。オプションが別個の AND 節として表現されなければならない場合——例えば、一つのアドサーバーに支えられ、同じ子式に折りたためないオーディエンスセグメントとキーバリューターゲティングの両面を公開するプロダクト——は異なる selection_group 値を使います。異なる selection_group 値だけでは記述的です。グループ境界が検証に影響する場合、セラーは selection_group_rules を公開すべきです。
プロダクトは、パッケージレベルのシグナルターゲティング面を開かずに、含有された選択不可のシグナルを開示することもできます:
ここでバイヤーは、参照先プロバイダーの adagents.json の signals[] を通じて Pinnacle Data のシグナル定義を検査・検証できますが、create_media_buy でそのシグナルを追加・削除することはできません。 大きな、またはアカウント固有のシグナルメニューを持つホールセールプロダクトは、すべてのオプションをインライン化する代わりに、バイヤーを get_signals へ誘導できます:
この形状では、signal_targeting_allowed が true でインラインの signal_targeting_options が返されないため、バイヤーは候補シグナルを発見するために get_signals を呼びます。支出をコミットする前に、バイヤーは対象プロダクトについて get_products を呼ぶか、候補の signal_ref エントリと意図する include/exclude モードで filters.signal_targeting を使って、プロダクトの適格性を確認すべきです(SHOULD)。その後、バイヤーは選択した signal_ref エントリを packages[].targeting_overlay.signal_targeting_groups で渡します。セラーは選択されたシグナルがそのプロダクトとアカウントで利用可能であることを検証しますが、ストアフロントは、サポートされないシグナルの組み合わせが create_media_buy ではなくプロダクトディスカバリーで失敗するように、まず get_products を使うべきです。 購入時、パッケージレベルの signal_targeting_groups は、選択された signal_ref、値の式、任意のセラー実行ハンドル(signal_agent_segment_id)、およびシグナルが独自の価格を持つ場合はシグナルの pricing_option_id を運びます。単純な include のみの選択は operator: "any" の一つの子グループとして表現されます。グループ化された包含/除外は、(A OR B) AND NOT (C) のように追加の anynone グループを使います。これは、メディアプロダクト自体を価格付けするパッケージの pricing_option_id とは別です。signal_targeting_options[].pricing_options のプロダクトスコープのシグナル価格は、そのプロダクトについて権威的です。より広い get_signals の価格は、プロダクトが価格を省略しない限り、デフォルトのディスカバリービューです。セラーは、バイヤーの編集なしに適用した固定/デフォルト選択を含め、適用されたすべてのパッケージシグナルグループを結果のパッケージ状態でエコーしなければなりません(MUST)。 プロバイダーが公開するシグナルについては、signal_ref.data_provider_domain が上流のデータプロバイダーを識別し、signal_ref.signal_id がそのプロバイダーの adagents.json の signals[] にある公開シグナル定義を識別します。来歴の検証が必要なバイヤーは、そのドメインの adagents.json を取得し、セラーがそのシグナルまたはそのタグについて authorized_agents に現れることを確認できます。プロダクトローカルのシグナルには scope: "product"signal_id を使います。その ID は選択されたプロダクト/パッケージのコンテキスト内でのみ意味を持ちます。 バックエンドの実行種別はシグナルのアイデンティティの一部ではありません。GAM に支えられたセラーは、オーディエンスセグメント、キーバリュールール、その他のカスタムターゲティングプリミティブを通常の signal_ref オプションとして公開できます。それらのシグナルがプラットフォームで一つの OR 節に結合できる場合は同じ selection_group に入れます。別々の節を要する場合は別々の selection_group に入れ、ストアフロントが (selection_group, targeting_mode) ごとに一つの子グループを構成するように selection_group_rules を公開します。 線形放送オーディオのスケジュールのようなセラー計画の guaranteed プロダクトでは、選択されたオーディエンスは可搬でも、プランは可搬でない場合があります。その場合、共有オーディエンスが複数プロダクトに現れるなら scope: "data_provider" シグナルとして公開し、セラーがそのオーディエンスを時間ベースのアベイルやリーチ目標に対して解決するプロダクトでは resolution_model: "seller_planned" を設定し、オーディエンス選択がパッケージに必須の場合は selection_mode: "required" または selection_group_rules[].selection_mode: "required" を使います。選択されたシグナルが通常のターゲティング述語として適用される非保証プロダクトでは、デフォルトの resolution_model: "direct_targeting" を使い、ホールセールのシグナルメニューをインラインで重複させるべきでない場合はプロダクトを get_signals へ向けます。 seller_planned モデルは、継続的にオークションされるのではなく、事前にスケジュールされ時間制約のある可用性で制約されるあらゆる供給タイプに適用されます: ライブスポーツ、政治番組、テントポール放送は、線形放送オーディオと同じパターンに従います。

カスタム/アカウント固有のプロダクト

サーバーは汎用カタログを提供しつつ、以下も返せる:
  • Account-Specific Products: 特定クライアント向けまたは交渉済みのプロダクト
  • Custom Products: is_custom: trueexpires_at タイムスタンプを持つ動的生成プロダクト

プロダクトの例

標準 CTV プロダクト(複数の価格オプション)

オークション型ディスプレイプロダクト

計測付きリテールメディアプロダクト

Product Cards

プロダクトカードは、UI でプロダクトを視覚的に示すための定義です。パブリッシャーは、カードフォーマットと必要アセットを含むカード定義を任意で提供できます。

カードタイプ

パブリッシャーは少なくとも Standard カードを、必要に応じて詳細カードも提供すべきです。 Standard Card (product_card):
  • プロダクトのグリッド/リスト表示向けコンパクトカード(300x400px)
  • Retina 向けに 2x 密度画像をサポート
  • プロダクトを素早く視覚的に把握
Detailed Card (product_card_detailed, 任意):
  • ヒーローカルーセルとテキスト説明を並べたレスポンシブレイアウト
  • 下部に Markdown 仕様セクション
  • メディアキットのような詳細ドキュメント

構造

カードの描画

カード表示には 2 つの方法があります。
  1. preview_creative を使用: カードフォーマットとマニフェストを渡してレンダリング
  2. 事前レンダリング: パブリッシャーがカードを生成し、静的に配信
インフラに合わせて動的生成と静的ホスティングを選択できます。

標準カードフォーマット

AdCP リファレンスクリエイティブエージェントは次の 2 種の標準カードフォーマットを定義します:
  • product_card_standard (300x400px) - プロダクトブラウズ用コンパクトカード
  • product_card_detailed (レスポンシブ) - カルーセルと詳細仕様を含むリッチカード
パブリッシャーはブランドに合わせたり、独自の特徴を強調したりするためにカスタムカードフォーマットを定義できます。 Note: 標準カードフォーマットの定義はプロトコル仕様ではなく creative-agent repository で管理されています。

プロダクトカードを含めるべき場面

プロダクトカードは任意だが、次のケースで推奨されます:
  • 強いビジュアルアイデンティティを持つプロダクト(番組、イベント、媒体など)
  • プレミアムプロダクトで、見た目が価値向上につながる場合
  • 複雑なプロダクトで、ビジュアルハイライトが理解を助ける場合
  • 特定オーディエンスを狙う際、ビジュアルで訴求したい場合
メディアキットのような詳細ドキュメントを提供したい場合は detailed カードを使用してください。

クライアント描画ガイドライン

UI でプロダクトを表示する際のフォールバック順:
  1. product_card があるpreview_creative で描画、または事前レンダリング画像を表示
  2. どちらもない → テキストのみ(プロダクト名 + 説明)を表示
  3. カード描画に失敗 → テキストのみ表示にフォールバック
利用可能なメタデータにかかわらず、一貫したユーザー体験を提供できます。

プロポーザル

パブリッシャーはプロダクトと一緒に プロポーザル(予算配分付きの構造化メディアプラン)を返すことができます。バイヤーは定義された経路を通じて実行できます。コミット済みプロポーザルは直接実行され、ドラフトプロポーザルはまず finalize が必要です。

プロポーザルとは

プロポーザルは、提案予算配分とともにプロダクトをグルーピングした推奨購入戦略です。従来の営業担当が行っていたようなメディアプランニングの知見をエンコードします。 主な特徴:
  • 実行可能: 返されたプロポーザルはそのライフサイクルを通じて購入可能です。proposal_status: "draft" はまず finalize が必要なことを、proposal_status: "committed"expires_at 前に proposal_id を指定して create_media_buy で実行することを意味します。
  • 予算非依存: 配分をパーセンテージで保持するため、任意の予算にスケール可能
  • フォーキャスト付き: プロポーザルと配分にはデリバリーフォーキャストを含めることができ、バイヤーが購入前に期待されるパフォーマンスを評価するのに役立つ

プロポーザル構造

tags フィールドで配分を次元別に集計できる:
  • チャネル別: desktop (50%) + mobile (20%) + in-app (30%) = 100%
  • 言語別: German (40%) + French (60%) = 100%

プロポーザルの反復

プロポーザルは buying_mode: "refine"refine 配列を使って改善できます。プロポーザルを ID で参照すると、セラーは更新された配分、フォーキャスト、価格を含む更新版プロポーザルを返します:
完全なワークフローと例は get_products refinement を参照。

プロポーザルの実行

コミット済みプロポーザルを実行するには、create_media_buyproposal_idtotal_budget を指定します:
パブリッシャーは配分パーセンテージをパッケージに変換する:
  • ch_desktop_de: 20% × $50,000 = $10,000
Finalize はセラーのコミットステップです: 価格、条件、可用性、およびあらゆるインベントリホールドを確定します。これはバイヤーの受諾ではありません。create_media_buy(proposal_id) が受諾/実行のステップです。セラーは、ドラフトのプロポーザルを実行しようとする試みを PROPOSAL_NOT_COMMITTED で拒否します。create をリトライする前に、refine モードで action: "finalize" を指定して get_products で finalize してください。
  • ch_desktop_fr: 30% × $50,000 = $15,000
  • など
複数ラインアイテムの複雑なキャンペーンを単一のプロポーザル実行に簡略化できます。

プロポーザルを返す場面

パブリッシャーは次の場合にプロポーザルを含める:
  • ブリーフに特定の配分戦略(チャネル配分、言語配分など)が求められます
  • キャンペーン目標に基づく戦略的ガイダンスを提供できます
  • 複数プロダクトを組み合わせた方が効果的
パブリッシャーは通常、wholesale モード(バイヤーがターゲティングと配分を自ら指示します)ではプロポーザルを省略します。また、ブリーフがマルチプロダクト戦略を示唆しない場合も同様です。 プロポーザルは任意 — 配分ガイダンスが不要ならプロダクトのみ返しても構わない。refine モードでは、バイヤーがプロポーザルエントリを含めなかった場合でも、セラーは改善されたプロダクトと並んでプロポーザルを返してもよい。プロポーザルはセラーの提案であり、配分とキャンペーン最適化は主にオーケストレーター(バイヤーサイドエージェント)の責任です。

デリバリーフォーキャスト

パブリッシャーはプロポーザルと個別配分にデリバリーフォーキャストを添付し、バイヤーが予算をコミットする前に期待されるパフォーマンスを評価するのに役立てることができます。 各フォーキャストには 1 つ以上の ForecastPoint の points 配列が含まれます。スペンドカーブでは、各ポイントは予算レベルとメトリクス範囲(low/mid/high)をペアにします——予算の昇順に並べた複数ポイントは、配信がスペンドに応じてどのようにスケールするかを示します。可用性フォーキャストでは、ポイントは予算を省略し、要求されたターゲティングと日付に対する利用可能な総在庫を表します。 メトリクスキーは 2 つの語彙から来る:
  • デリバリー/エンゲージメント: forecastable-metric 列挙値(impressions、reach、clicks、spend、views、completed_views、grps など)
  • 成果: event-type 列挙値(purchaseleadapp_installadd_to_cart、有料サブスクリプションには subscribe、無料の継続的オプトインには follow など)
これにより、セラーはデリバリー(「120 万インプレッション」)と成果(「1,800 件の購買」)の両方を 1 つのフォーキャストで予測できます。各フォーキャストはその手法を宣言する:
  • estimate — 過去の平均やヒューリスティクスに基づく概算
  • modeled — 予測モデルや過去データから導出
  • guaranteed — 予約済み在庫に裏付けられた契約上のコミット配信水準
各メトリクス値は ForecastRange オブジェクトです。点推定には mid を、範囲には lowhigh を、またはその三つすべてを提供します。最低限、mid か、lowhigh の両方のいずれかが存在しなければなりません。 フォーキャストポイントは、セラーが国別、リージョン別、プレースメント別、デバイス別、オーディエンス別、シグナル値別、またはプレースメント×国やプロダクト×シグナルのような交差ごとの可用性を公開する必要がある場合、dimensions を運べます。dimensions は配列です。各項目は一つの kindgeoplacementdevice_typedevice_platformaudiencesignal)を宣言し、ターゲティングや配信レポートと同じ正準的な識別子——地理には geo_level/geo_code、プレースメントには placement_ref、シグナルバケットには signal_ref に加えて signal_value/presence——を使います。メトロの行は metro-systemnielsen_dmauk_itl1uk_itl2eurostat_nuts2custom)の system 値を使い、ネイティブな郵便の行は country に加えて postal-system の国ローカルな system 値(例: US / zipGB / outwardZA / postal_code)を使います。一方で us_zip のような非推奨の国融合型の郵便システムは互換性のため引き続き受け付けられます。国とリージョンの行は system を省略します。一つのポイントに複数の次元項目が現れる場合、そのポイントはそれらの制約の交差を表します。次元の順序に意味はありません。バイヤーは (forecast_range_unit, budget があれば, product_id があれば, kind でソートした dimensions) から行の同一性を正規化します。セラーは一つのポイントで同じ kind を繰り返してはなりません(MUST NOT)。複数の geo・placement・audience・signal のスライスが必要な場合は、代わりに複数のポイントを出すべきです。これにより、セラーがすべての国・プレースメント・シグナル値ごとに別個のプロダクトを作ることを強いられず、次元別の可用性を一つのプロダクトまたはプロポーザル内に保てます。次元の行は pricing_options から独立しています。プロダクトの価格オプションは、依然としてプロダクトがどう購入されるかを説明します。 フォーキャストポイントは、標準のデリバリーメトリクスと並んで計測を意識したフォーキャストを含めることができます:
  • viewabilityget_media_buy_deliveryviewability ブロックを反映しますが、数値は ForecastRange オブジェクトを使います。セラーは、プロダクトが対応する配信ビューアビリティを報告できる場合にのみフォーキャストビューアビリティを出すべきです(SHOULD)。MRC と GroupM の行は互換ではないため、フォーキャストビューアビリティ値が存在する場合は常にフォーキャストの standard が必須です。配信の viewability.standard は 3.x 互換のため任意のままですが、埋めるべきです(SHOULD)。
  • vendor_metric_values はベンダー定義メトリクスの配信レポートを反映しますが、valuemeasurable_impressions は ForecastRange オブジェクトを使います。セラーは、プロダクトが reporting_capabilities.vendor_metrics で宣言するベンダーメトリクスのみをフォーキャストすべきです(SHOULD)。

フォーキャスト範囲単位

forecast_range_unit フィールドは、コンシューマーが points 配列をどう解釈するか — カーブが表す軸 — を伝える:
  • spend(デフォルト)— 予算レベルの昇順ポイント。標準的な予算カーブ。
  • availability — 各ポイントは、要求されたターゲティングと日付に対する利用可能な総在庫を表します。予算は省略され、metrics.spend で推定コストを表します。guaranteed および直接販売の在庫で一般的。
  • reach_freq — リーチ/フリークエンシーターゲットの昇順ポイント。パブリッシャーがフリークエンシー目標に応じてコストがどのようにスケールするかを示す放送計画で使用。
  • weekly / daily — メトリクスは期間ごとの値。Budget はキャンペーン総スペンドを指します。weekly で頻度 3.2 は週 3.2 回の接触を意味します。
  • clicks / conversions — 成果ターゲットの昇順ポイント。目標ベースの計画で使用(例: 「コンバージョン目標を教えてくれれば予算を伝える」)。
  • package — 各ポイントは別個の在庫パッケージ(例: Good/Better/Best のティア)を表します。ポイントはスペンドカーブ上のレベルではなく、異なる在庫構成を持つ別個のプロダクトです。放送 TV、オーディオ、DOOH のセラーが使用します。
スペンドカーブとリーチ/フリークエンシーカーブは同一データを含む場合がある — 違いはパブリッシャーの意図です。スペンドカーブは「異なる予算で何が買えるか」を示し、リーチ/フリークエンシーカーブは「異なるフリークエンシー目標を達成するのにいくらかかるか」を示します。コンシューマーはどちらのカーブも双方向に読み取れる。 時間単位(weeklydaily)はメトリクスの解釈を変える。範囲単位なし(または spend)の場合、頻度 3.2 はキャンペーン全体で 3.2 回の接触を意味します。weekly の場合は週あたり 3.2 回を意味します。 フォーキャストは 2 つのレベルで表れる:
  • プロポーザルレベル: メディアプラン全体の集計フォーキャスト
  • 配分レベル: 個別ラインアイテムのプロダクトごとフォーキャスト
配分レベルのフォーキャストは、オーディエンス重複とフリークエンシーキャッピングにより、プロポーザルレベルのフォーキャストに加算されない場合があります。両方が存在する場合、プロポーザルレベルのフォーキャストが総デリバリー推定の権威となります。 クロスチャネル計画では、フォーキャストは reach_unit(個人、世帯、デバイス、アカウント、Cookie)を宣言し、バイヤーがパブリッシャー間でリーチを比較できるようにします。GRP ベースのフォーキャスト(地上波 TV、ラジオ)は、CPP 価格と同じパターンに従い、ターゲットデモを指定するために demographic_systemdemographic を使用します。 フォーキャストが第三者計測に基づく場合、measurement_source フィールドは、数値を生成するのにどのプロバイダーのデータが使われたかを宣言します。これはデモ表記を指定する demographic_system とは別物です——measurement_source は誰のデータがフォーキャスト数値を生成したかを識別します。フォーキャストは、Nielsen のデモコード(demographic_system: "nielsen")を使いつつ、インプレッション数値は VideoAmp 由来(measurement_source: "videoamp")という場合があります。 フォーキャストが第三者計測に基づくセラーは、measurement_source プロバイダーが数えた配信を表すために measured_impressions を使います。これは、広告サーバーまたはファーストパーティの推定配信を表す impressions とは別物です。この二つのメトリクスは保証とは独立しています——measured_impressions は guaranteed と non_guaranteed の両方のフォーキャストに現れうる:
  • 保証付き放送: method: "guaranteed" + measured_impressions + measurement_source: "nielsen" — セラーは Nielsen が計測した配信を契約上コミットする
  • 非保証 CTV: method: "modeled" + measured_impressions + measurement_source: "videoamp" — VideoAmp が計測した推定値、契約上のコミットなし
  • プログラマティックディスプレイ: method: "modeled" + impressions — 広告サーバーのカウント、第三者通貨は不要
セラーは、バイヤーが第三者計測の数値と広告サーバーの推定値の両方を必要とする場合、同じポイントに measured_impressionsimpressions の両方を含められます。 ポッドキャストのセラーは、IAB Podcast Measurement ガイドラインに従い、impressions の代わりに、または並べて、主要な配信通貨として downloads を使います。

予算カーブ

予算の昇順で並べられた複数のフォーキャストポイントは、メトリクスがスペンドに応じてどのようにスケールするかを示し、バイヤーが最適な投資レベルを見つけるのに役立つ:
カーブは収穫逓減を明らかにする — 予算を $50K から $100K に倍増してもリーチは 2 倍でなく約 56% 増に過ぎません。バイヤーはこれを交渉やパブリッシャー間の予算再配分に活用できます。

可用性フォーキャスト

guaranteed および直接販売の在庫では、フォーキャストは可用性チェックです——このプレースメントに、このターゲティングで、このフライト期間にどれだけの在庫が存在するか。利用可能な在庫はバイヤーの支出額に依存しないため、予算は省略されます。セラーは、利用可能な在庫の推定コストを表すために metrics.spend を含められます:
バイヤーエージェントは、利用可能なインプレッションを予算要件と比較して過少配信を特定できます。バイヤーが $10K の予算全額を消化するために $20 CPM で 500,000 インプレッションを必要とし、フォーキャストが mid 400,000 を示す場合、バイヤーは $2K の予算を他へ配分しなければならないと分かります。

次元別の可用性と計測

セラーは、国別、プレースメント別、シグナル値別、プレースメント×国、プロダクト×シグナル、その他の次元的交差ごとの可用性を、同じプロダクト上のフォーキャストポイントとして公開できます。複数の dimensions 項目を持つポイントは、列挙されたすべての制約の交差を表します。行は、複数国のプレースメント×国の行や、一つのプロダクトベースラインのシグナル値の行のように、同じ次元粒度を使う場合に比較可能です。セラーが行が完全で重複のないパーティションを形成すると明示的に文書化しない限り、バイヤーは行を合計してはなりません(MUST NOT)。 単一のポイント内では、次元項目は OR ではなく AND されます。セラーは kind ごとに複数の項目を出してはならず(MUST NOT)、バイヤーは順序や繰り返しから OR の意味論を推測してはなりません(MUST NOT)。一つのポイント内の二つの geo 国の行のような繰り返しの同位値は、セラーの適合性の問題です。 impressionsclicksspendmeasured_impressionsviewable_impressions のようなカウントまたは通貨のメトリクスのみがロールアップの候補であり、宣言された完全で重複のないパーティション内でのみです。リーチ、フリークエンシー、レート、平均、viewability.viewable_rateviewability.viewed_secondsvendor_metric_values[].value は、セラーまたは計測ベンダーが明示的なロールアップ手法を公開しない限り、加算的ではありません。vendor_metric_values[].measurable_impressions のようなベンダーメトリクスのカバレッジカウントは、他のカウントと同じパーティションルールに従います。 これにより、国別プロダクトやプレースメント別プロダクトへの展開を避けつつ、バイヤーエージェントが必要とするプランニングの行を提供できます:
各ポイントは別個のプロダクトではなく、フォーキャスト内の一行です。バイヤーは、国×プレースメントのアベイル、ビューアビリティの見込み、ベンダー計測のフォーキャストを比較しつつ、購入作成時にはプロダクトの通常の価格オプションから選択できます。 バイヤーエージェントは、選んだ次元の行を既存の購入時サーフェスを通じて購入に変換します:
  • kind: "geo" の行は、geo_level とセラーのサポートに応じて packages[].targeting_overlay.geo_countriesgeo_regionsgeo_metrosgeo_postal_areas にマップします。国の行は ISO 3166-1 alpha-2 の geo_code を、リージョンの行は ISO 3166-2 の geo_code を使います。メトロの行は対応するターゲティング system 列挙を含み、ネイティブな郵便の行は country に加えて国ローカルの system を含みます。
  • kind: "device_type"kind: "device_platform" の行は、セラーがデバイスターゲティングをサポートする場合に対応するターゲティングオーバーレイフィールドにマップします。
  • kind: "audience" の行は、そのプロダクトでオーディエンスが選択可能な場合にのみ audience_include またはシグナルターゲティングにマップします。情報提供のオーディエンス行はプランニングシグナルであり、自動的なターゲティングハンドルではありません。
  • kind: "placement" の行は、まずプロダクトのリファインメントまたはセラーがサポートするパッケージのプレースメントターゲティングにマップします。dimensions[].placement_ref はフォーキャスト行が説明する在庫スライスを識別します。それ自体は購入パッケージを狭めるものではなく、バイヤーは creative_assignments[].placement_refs のショートカットとして扱うべきではありません(SHOULD NOT)。バイヤーがそのプレースメントのみを買いたい場合、プロダクトがそのプレースメントを mode: "targetable" として公開するか、バイヤーはリファインされたプロダクト/プロポーザルを要求すべきです。creative_assignments[].placement_refs は、購入の在庫スコープが確立された後のクリエイティブルーティング面にすぎず、それ自体は購入在庫を狭めません。プレースメント次元を持つプロポーザルレベルのフォーキャストポイントは、プレースメントが一つの配分のプロダクトにマップする場合は product_id を含めるべきです。プロダクトコンテキストがない場合、プロポーザルレベルのフォーキャスト上のプレースメント行は、直接実行可能な選択ではなく情報提供のプランニング行です。
kind: "signal" の行は、正準的な signal_ref に任意の signal_value を加えてシグナルバケットを説明します。シグナルが供給された値で利用可能な行には presence: "present" を、明示的な非存在バケットには signal_value: null を伴う presence: "absent" を使います。signal_id は、囲むオブジェクトが既にシグナルを一意に識別している場合(単一の get_signals 項目の直下にネストされたカバレッジフォーキャストなど)の省略記法にすぎません。プロダクトレベルのフォーキャストはプロダクトコンテキストに ForecastPoint.product_id を使います。別個のプロダクト次元項目を追加しないでください。 購入後、バイヤーは get_media_buy_delivery.reporting_dimensionsgeodevice_typedevice_platformaudienceplacement)で一次元の周辺分布を検証し、パッケージの committed_metricsperformance_standards、報告された viewability / vendor_metric_values を通じて計測の見込みを照合します。標準の配信レポートは現在、プレースメント×国やプロダクト×シグナルのような次元横断の交差を返しません。それらの交差について正確な購入後の照合が必要なセラーは、セラー固有のレポート面、または将来の標準的な交差機能を公開しなければなりません。

GRP デモグラフィクス付き CTV

TV およびオーディオのフォーキャストは、ターゲットデモを指定するために demographic_systemdemographic を使用し、フォーキャストが誰のオーディエンスデータに対してモデル化されているかを宣言するために measurement_source を使用します:
measurement_source: "nielsen" は、GRP とインプレッションの数値が Nielsen データに対してモデル化されていることをバイヤーエージェントに伝えます。reach_unit: "households" は、この CTV パブリッシャーがリーチを個人ではなく世帯で計測することをバイヤーに伝える。reach_unit: "devices" を報告するディスプレイパブリッシャーは異なるものを計測しており、バイヤーは 2 つのリーチ数を直接比較すべきではありません。 measurement_sourcedemographic_system は異なりうる点に注意してください。CTV パブリッシャーが Nielsen のデモ表記(demographic_system: "nielsen"demographic: "P18-49")を使いつつ、基盤となるオーディエンスデータは VideoAmp 由来(measurement_source: "videoamp")という場合があります。デモグラフィックシステムは表記を指定し、計測ソースはどの数値がフォーキャストを生成したかを指定します。

成果フォーキャスト付きリテールメディア

リテールメディアパブリッシャーはデリバリーメトリクスとコンバージョン成果の両方を予測できます。成果メトリクスキーは event-type 値を使用します:
ここで impressionsclicksforecastable-metric 値、purchaseadd_to_cartevent-type 値です。どちらも ForecastRange(low/mid/high)を使用し、同じメトリクスマップに共存します。

配分レベルフォーキャスト

プロポーザルに配分ごとのフォーキャストが含まれる場合、バイヤーは各プロダクトを独立して評価できる:
この例では配分フォーキャスト(900 + 600 = 1,500 件の購買)がプロポーザルフォーキャストと偶然一致しているが、通常はそうならない — オーディエンス重複とフリークエンシーキャッピングにより、全体は部分の和より小さくなることが多い。プロポーザルレベルのフォーキャストが総デリバリーの権威となります。

放送オーディオスポットプラン

放送およびオーディオパブリッシャーは、各配分に daypart_targets を持つスポットプランプロポーザルを返し、forecast_range_unit: "weekly" で週次フリークエンシー予測を行うことができます。このパターンにより、パブリッシャーが最適化問題を解く — バイヤーがフリークエンシー目標を指定すると、パブリッシャーがそれを達成するプランを返します:
各フォーキャストの forecast_range_unit: "weekly" は、すべてのメトリクスが週次値であることをバイヤーに伝える — 頻度 3.2 はキャンペーン全体でなく週あたり 3.2 回の接触を意味します。Budget($75K)はキャンペーン総スペンドです。 各配分の daypart_targets はパブリッシャーが推奨する時間帯を指定します。これは targeting でのハードな daypart 制約と同じ構造 — ここではバイヤーが制約するのでなく、パブリッシャーがスポットプランを規定しています。 配分レベルのリーチは、同じリスナーがモーニングドライブとアフタヌーンドライブのスポットを両方聴く可能性があるため、プロポーザルレベルに加算されない(180K + 120K + 80K > 280K)。プロポーザルレベルのフォーキャストはこの重複を考慮しています。

放送 TV パッケージフォーキャスト

放送 TV のセラーは、可変の支出レベルでのインプレッションではなく、別個の在庫パッケージを提供します。forecast_range_unit: "package" は、各ポイントが支出カーブ上の位置ではなく別個のパッケージであることをバイヤーに伝えます。各ポイントには label が含まれ、バイヤーエージェントが個々のパッケージを識別・参照できます。放送局はデイタイムローテーター、プライムアクセス+デイタイムのバンドル、フルプライムパッケージを提供する、といったことがあります:
各ポイントは別個のパッケージ——異なるデイパート、ユニットタイプ、フライト構造——を表し、同じプロダクトの三つの支出レベルではありません。label フィールドにより、バイヤーエージェントは交渉時や特定オプションの要求時にパッケージを名前で参照できます。measurement_source: "nielsen" は、インプレッションと GRP の数値が放送局自身の計測ではなく Nielsen データに対してモデル化されていることをバイヤーエージェントに伝えます。measured_impressions メトリクスは Nielsen が数えた配信を表します——method: "modeled" と組み合わさると、これらは Nielsen が計測した推定値です。それらを契約上のコミットメントにするには、セラーは代わりに method: "guaranteed" を使います。 放送の買い方の形がプロダクトの形を決めます:
  • ネットワークまたはレップファームのパッケージ: 一つのセラーが注文をコミットし、複数の市場やアフィリエイトにわたって履行する場合、一つのセラープロダクトとしてモデル化します。アフィリエイトは履行サーフェスであり、独立した AdCP のホップではありません。
  • ローカルスポットまたはステーショングループの在庫: 在庫が別個の放送局、ステーショングループ、市場セラーによって販売される場合、別個のプロダクトまたはパッケージとしてモデル化します。
  • 市場ごとのシンジケーション: 在庫を販売しコミットする当事者でモデル化します。複数のセラーが別々にコミットする場合、バイヤーはメディアバイをまたいでそれらの配信レポートを集約します。
スポット、ユニット、または在庫が予約/スケジュールされる場合は delivery_type: "guaranteed" を使います。過去のオーディエンス範囲には forecast.method: "modeled" を使い、forecast.method: "guaranteed" は、セラーが記載範囲外の配信をメイクグッドすることを契約上コミットする場合にのみ使います。最終的な計測インプレッションが過去の範囲や第三者計測の精算に依存するというだけで non_guaranteed を使わないでください。 パッケージが同じ在庫プールを共有し、量やミックスのみが異なる場合は、一つのプロダクト上で package フォーキャストポイントを使います。それらが根本的に異なる在庫(重複のない異なる番組、プロパティ、デイパート)を表す場合は、それぞれ独自のフォーキャストを持つ別個のプロダクトを作成します。 同じ在庫を複数の計測通貨(例: Nielsen と VideoAmp の両方)で表すセラーは、measurement_source ごとに一つずつ、別個の DeliveryForecast オブジェクトを提供すべきです。

ディスカバリーとの統合

プロダクトは自然言語でキャンペーンブリーフにマッチさせる Product Discovery プロセスで見つけ、特定後に create_media_buy で購入します。

関連情報