メジャメント分類
メジャメントは 1 つではなく 3 つのものです。それらを 1 つのバケットとして扱うことが、メジャメント RFC（SSAI、アイデンティティ喪失、AI コンテンツプロベナンス、クリーンルーム）のほとんどの混乱と、配信レスポンスのほとんどのスキーマ肥大化の源です。AdCP はそれらを意図的に分離します。 3 つの層 — メトリック、検証、アトリビューション — は異なる質問に答え、異なる当事者によって証明され、プロトコルの異なる場所に存在し、異なる速度で進化します。3 つの層
1. メトリック — 「起こったか?」
配信事実: インプレッション、完了、quartile、クリック、支出、リーチ、フリークエンシー。リーチとフリークエンシーは明示的なreach_window 宣言（cumulative / period / rolling）を運び、バイヤーが値を行全体で合計できるか知れます。
標準とベンダーメトリックフローの両方にわたる完全なケイパビリティ → コミットメント → 最適化 → 配信の絵については、メトリックライフサイクル を参照。同じ (vendor, metric_id) キーが、ベンダー証明メトリックのすべての表面 — ディスカバリー、最適化ケイパビリティ、レポートケイパビリティ、パッケージコミットメント、最適化目標、パフォーマンス標準、配信値 — を通じて流れます。
セラーが真実の源泉です — セラーが広告をサーブしイベントをカウントします。業界カウント規約（MRC、IAB）が何がインプレッションとして資格を持つか、何が動画ビューを完了するか、どう重複排除するかを定義します。AdCP はセラーがこれらのカウントをどう露出するかを標準化します。それらが何をカウントするかを再定義しません。
1 つのニュアンス: available-metric.json の一部のメトリック（ROAS、CPA、コンバージョン、conversion_value、units_sold）はセラーレポートだが アトリビューション由来 です — セラーがバイヤー供給のイベントソースにアトリビューションモデルを実行し結果をレポートします。それらは、すべての DSP とリテールメディアプラットフォームが今日それらを露出する場所だから配信レポートに存在しますが、基盤となる真実のイベントはバイヤー証明です。これらを 「配信を通じて表示されたアトリビューション」 として読み、純粋な配信事実として読まないでください。セラーの数値はバイヤーのイベントに対するセラーのアトリビューションモデルを反映します。バイヤー側グラウンドトゥルースに対する照合は依然としてアトリビューション境界に属します。
AdCP では、メトリックは配信レポートを通じて流れます:
get_media_buy_delivery— 現在の配信状態provide_performance_feedback— バイヤー側観測パフォーマンス- 最適化とレポート — レポートが最適化目標にどう接続するか
2. 検証 — 「適切にカウントされたか?」
品質証明: ビューアビリティ、無効トラフィック（IVT）、ブランドセーフティ、geo 精度、コンテキスト適合性、広告コンテンツプロベナンス。 検証の全ポイントは、それがセラーの言葉 でない ことです。バイヤーは、独立した当事者がインプレッションが品質しきい値を満たしたことを確認できるよう、まさにサードパーティ測定ベンダー（Moat、IAS、DoubleVerify）と契約します。検証は配信環境を生き延びる実行パスを要求します — 歴史的にはクライアント側で動く OMID と VPAID。SSAI では、サーバー側回避策としての SIVA。 AdCP では、検証はベンダーのbrand.json 測定エージェントレコードにアンカーされ、バイライフサイクル全体で構造化表面を持ちます:
- ディスカバリー。 バイヤーは
get_productsでrequired_performance_standards（「DoubleVerify による 70% MRC ビューアビリティ」）、required_metrics、required_vendor_metricsで製品をフィルターします。セラーはreporting_capabilities.available_metrics、vendor_metrics、committed_metrics_supportedケイパビリティフラグ経由でサポートを宣言します。 - コミットメント。
performance-standard.jsonがmetric+threshold+standard（例: MRC 対 GroupM ビューアビリティ）+vendorをバイコントラクトにバインドします。ベンダーはベンダーのbrand.jsonagents[type='measurement']レコードに解決するBrandRefです。パフォーマンス標準がコミットされると、クリエイティブはそのベンダーからのtracker_scriptまたはtracker_pixelアセットを含まなければなりません（MUST） — プロトコルがパスを強制します。committed_metricsはcreate_media_buyでパッケージのレポートコントラクトをスナップショットし（閉じたavailable-metric.jsonenum からの標準メトリックとBrandRefにアンカーされたベンダー定義メトリックの両方を運ぶ統一された判別された配列、各エントリーがcommitted_atでタイムスタンプ付き）、バイの寿命の間追加のみです。 - 実行。 クリエイティブマニフェスト は、サードパーティベンダーがイベントを記録するよう配信時に発火するトラッカーとマクロ（
vast_tracker、daast_tracker、ユニバーサルマクロ）を運びます。それらがクライアント側かサーバー側で発火するかはセラーの実装詳細です。バイヤーのコントラクトはパスではなくメトリックにあります。 - レポート。 閉じた
available-metric.jsonenum に卒業した標準検証メトリック（例:viewability）は、delivery-metrics.jsonの専用配信スカラーを通じて流れます。非卒業のベンダー定義メトリックは、カバレッジ分母としてのmeasurable_impressionsとともにvendor_metric_valuesを通じて流れます。ベンダーアトリビューションは、配信行自体ではなく、committed_metricsとperformance_standards.vendor経由でコントラクトレベルでアンカーされます。missing_metricsは、セラーがコミットされたメトリックを配信しなかったときアカウンタビリティギャップを表示します —committed_metricsが存在するとき、照合は正確でタイムスタンプ対応です。不在のとき、missing_metricsはコミットメントタイムスタンプフィルターなしで製品のライブavailable_metricsにフォールバックしギャップを過小レポートします。バイヤーはcommitted_metricsの不在を 「監査グレードのコントラクトなし」 として扱うべきで（SHOULD）、「クリーンな配信」 ではありません。
brand.json agents[type='measurement']（BrandRef アンカー）経由で発見可能で、メトリックカタログ（metric_id、standard_reference、accreditations[]、unit、methodology_url、methodology_version）はエージェントの get_adcp_capabilities レスポンスの measurement ブロックの下でサーブされます。brand.json がディスカバリーポイント。エージェントがカタログをサーブします。
卒業した検証メトリック
検証メトリックは標準化の異なる速度で進化し、プロトコルはそのグラデーションのどこに位置するかに基づいて異なるレベルの構造サポートを与えます:- Tier 1 — 卒業。 業界公開、MRC または同等認定。複数の競合する標準が存在しうる。閉じた
available-metric.jsonenum の専用エントリー、delivery-metrics.jsonの専用構造化ブロック、（標準が相互に互換でないとき）曖昧性解消のためのcommitted_metricsのqualifierスロットを得る。ビューアビリティ は今日の正準 Tier 1 メトリック — MRC と GroupM は実質的に異なるしきい値を定義しqualifier.viewability_standard経由のスキーマ強制曖昧性解消を要求。 - Tier 2 — ベンダー拡張。 業界公開標準のないベンダー定義メトリック。セラーは
reporting_capabilities.vendor_metrics経由でレポートサポートを、vendor_metric_optimization.supported_metrics経由で最適化サポートを宣言。値はvendor_metric_values経由で流れる。目標はkind: "vendor_metric"でoptimization_goals経由でベンダーにバインド。アイデンティティはベンダーのBrandRefにアンカーされカタログはベンダーの測定エージェントケイパビリティに存在。アテンションスコア、パネルベースブランドリフト、パネルデモグラフィック、インプレッションごと排出量 が今日ここに位置。 - Tier 3 — 主張。 構造化ベンダーアイデンティティまたは標準担持者証明のない製品上のフリーフォームクレーム。BrandRef パターンに先行し、漸増的に上方に再構築されている。
qualifier スロット、専用配信スカラー、パフォーマンス標準バインディング）は再利用可能なテンプレートです: ビューアビリティは最初のインスタンスで、ビューアビリティ固有のカスタム形状ではありません。
クローズドループトポロジー: セラーを測定エージェントとして
卒業したメトリックフレーミングは、デフォルト測定トポロジーが セラーがサーブ、サードパーティが検証 — DV/IAS がビューアビリティを証明しパブリッシャーの広告サーバーがインプレッションをカウント — であると仮定します。それは依然として従来の CTV、ビデオ、ディスプレイの支配的パターンです。しかし 2 つのチャネルクラスは異なるデフォルトを持ちます:- リテールメディアクローズドループ: Walmart Connect、Kroger Precision、Amazon DSP、Criteo Retail Media。リテーラーは自身の表面で広告をサーブし、自身の表面でクリックを観測し、自身の表面でコンバージョン（ロイヤルティカード、ログイン、POS）を観測します。セラーは測定ベンダーでもあります。トラストモデルはサードパーティ独立性ではなくリテーラーのファーストパーティデータアセットに基づきます。
- AI ネイティブチャネル: ChatGPT と他のエージェンティック会話表面は、広告を会話ストリームに直接注入します（サーバー側）。クリックナビゲーションはセラーが制御するアプリ内 webview で起こります。コンバージョンアトリビューションは、マーチャントのプロパティにデプロイされたセラー提供 SDK（OpenAI には
oaiq.min.js）を通じて戻ります。セラーは再び測定ベンダーでもあります。
- セラーがベンダーのときベンダーアイデンティティは暗黙: BrandRef が
delivery_measurement.vendorsでセラーにアンカー。ベンダースコープのcommitted_metricsエントリーがセラーの測定エージェントケイパビリティを指す。performance_standards.vendor（存在するとき）がセラーを名指す。追加スキーマ不要。 - 結果メトリックは同じ語彙を通じて流れる:
conversion_value+qualifier.attribution_methodology: "deterministic_purchase"+qualifier.attribution_window: { interval: 30, unit: "days" }が、ChatGPT のアトリビューショントークンベースのコンバージョンアトリビューションと Walmart Connect のattributedSalesIn14Daysをクリーンに表現。リテールメディア固有スキーマなし、AI ネイティブ固有スキーマなし。 (metric_id, qualifier)行形状が両方を処理: コントラクト / diff / 配信 / フィードバックが、ベンダーがサードパーティかセラー-as-ベンダーかにかかわらず同じ方法で照合。
3. アトリビューション — 「結果を引き起こしたか?」
配信と結果間のバイヤー側結合: コンバージョン、リフト、マルチタッチアトリビューション、メディアミックスモデリング、インクリメンタリティ。 セラーはコンバージョンイベントを知りません。バイヤー（またはバイヤーの測定パートナー）が結果データを保持しそれを配信に結合します。AdCP の役割は結合を可能にすることです — ログレベルシグナル、アイデンティティフック、クリーンルームへのハンドオフパターンを露出 — モデルを実行することではありません。 AdCP では、アトリビューションは 境界 に現れます:sync_event_sources— バイヤーがコンバージョンイベントソースをセラープラットフォームにプッシュし、プラットフォームが実結果に向けて最適化できるlog_event— バイヤー証明イベント配信- コンバージョントラッキング — 配信を結果に接続するパターン
- Trusted Match — PII をリークせずに結合を可能にするアイデンティティ解決
なぜ分離が重要か
ワーキンググループのほとんどのメジャメント議論は、層が名指しされるとより速く解決します:- SSAI（#3759）は 検証 問題です。どのメトリックがレポートされるかを変えません。どの検証パスが有効か、生き延びるシグナルがどれだけリッチかを変えます。修正は配信レポートではなくケイパビリティ + クリエイティブマニフェストトラッカーに存在します。
- アイデンティティ喪失（クッキーレス、IDFA 非推奨、ウォールドガーデンシグナル崩壊）はメトリックではなく アトリビューション に現れます。セラーは依然としてサーブしインプレッションをカウントします。バイヤーの結果への結合が劣化します。修正は配信ペイロードではなくアトリビューション境界（クリーンルーム、Trusted Match）に属します。
- AI コンテンツプロベナンス は 検証 の関心事（この広告はブランドが承認したものか?）で、アトリビューションの関心事ではありません。他の検証ケイパビリティと並ぶべきで — プロベナンス検証 を参照 — 結果レポートにボルト留めされません。
- 結果ベースの最適化目標（CPA、ROAS、カスタムイベント）は、最適化入力として表示される アトリビューション の関心事です。バイヤーがプラットフォームが何に向けて最適化すべきかを引き渡すイベントソース境界に属します。
実用的経験則
メジャメントフィールドがどこに属するかを評価するとき、誰が真実の源泉か? と尋ねます。- セラー がそれをカウント → メトリック → 配信レポート
- サードパーティ がそれを証明 → 検証 → ケイパビリティ + クリエイティブマニフェスト
- バイヤー が結果を所有 → アトリビューション → イベントソース / ログレベルハンドオフ
原子単位: (metric_id, qualifier)
プロトコルのメジャメントプリミティブは、同じ方法でインデックスされ照合される 1 つのタプルに還元されます:
committed_metrics行:{ scope, metric_id, qualifier, committed_at }— セラーが投入に同意したもの（#3576、出荷済み）missing_metrics行:{ scope, metric_id, qualifier }— 現れなかったもの（#3576、出荷済み）metric_aggregates行:{ metric_id, qualifier, value, …components }— 実際に配信されたもの、qualifier で分割（#3848、提案）
(metric_id, qualifier) の結合に崩れます。各 committed_metrics 行について、一致する metric_aggregates 行を見つける。一致がないものは missing_metrics として表示。カスタムのメトリックごと照合ロジックなし、コントラクトと配信間のトラバーサル非対称なし。
qualifier 語彙は表面によって異なります: コントラクトは閉じている（additionalProperties: false、今日 viewability_standard のみを運ぶ）。配信は意図的な スーパーセット（例: tracker_firing は、バイヤーがコミットしないがセラーが配信後に露出できる透明性開示として存在）。非対称は名指しされ、偶然ではありません — バイヤーは語彙を共有するものにコミットし、セラーは配信されたもののパスレベル透明性を露出します。
将来の qualifier（completion_threshold、標準化するならアテンション方法論）が構造サポートを必要とするとき、既存のスロットに差し込みます。並行 *_by_* フィールドなし、新しい集計表面なし、スキーマ破損なし。
Signals と Governance との境界
メジャメントは AdCP の唯一のサードパーティ証明表面ではありません。Signals と Governance もサードパーティを関与させ、証明されたアーティファクトを生成し、コアメディアバイプリミティブより速く進化します。境界は実際ですが、プロトコルはベンダーとライフサイクルで重なります — Signals 自身の key-concepts ページはシグナルが「ターゲティングまたはメジャメントに」使われると記し、その曖昧性が問題の境界です。 最も明確な分離はライフサイクルモーメントと尋ねられる質問による:
同じベンダーがしばしば複数のレーンでプレイします。例えば DoubleVerify は、事前入札ブランドセーフティ シグナル、配信後 検証 証明、ガバナンス ポリシー強制が消費するコンテンツ分類フィードを販売します。ベンダーは 1 つのエンティティです。プロトコル表面は、タイミング、真実の源泉、消費パターンが異なるため 3 つです。
線が鮮明な場所
- シグナルは予測的、メジャメントは記述的。 事前入札ビューアビリティスコアはシグナル — インプレッションがビューアブルである可能性の推定。配信後ビューアビリティレートはメジャメント。同じ方法論ファミリー、異なる質問。
- ガバナンスは規範的、メジャメントは事実的。 ガバナンスは「これは私たちが設定したルールに準拠したか?」と尋ねます。メジャメントは「客観的に何が起こったか?」と尋ねます。アトリビューションモデルは、任意のポリシーに違反せずにバイヤーの結果目標と不一致になりうる。配信がクリーンに測定されてもブランドセーフティ違反は起こりうる。
- シグナルは入力、メジャメントは出力、ガバナンスは制約。 購入決定はシグナルを消費し、ガバナンスに境界され、メジャメントが記録する事実を生成します。
線がぼやける場所
- 事前入札ブランドセーフティ分類子は シグナル として販売される。同じベンダーの配信後レポートは 検証。同じ入力データ、異なるプロトコルの居場所 — データが いつ 消費されるかで駆動。
- ガバナンス ポリシーが証拠として メジャメント 証明を要求できる（「このキャンペーンは MRC 認定ベンダーで検証しなければならない」）。メジャメントがガバナンス承認の前提条件になる。
- シグナル が アトリビューション モデルを供給 — オーディエンスセグメントとアイデンティティシグナルが結果推定を生成するリフトまたは MMM モデルへの入力。
実例: サードパーティビューアビリティコミットメント
バイヤーが CTV キャンペーンで MRC しきい値の DoubleVerify ビューアビリティを必要とします。SSAI がスコープ内です。バイヤーはどの製品がそれを使うか知らず気にしません。 1. ディスカバリー。 バイヤーが以下でget_products を呼びます:
create_media_buy を呼びます。performance_standards がバイコントラクトに入ります。performance-standard.json に従い、クリエイティブは doubleverify.com からの tracker_script または tracker_pixel アセットを含まなければなりません（MUST）。セラーはコントラクトをスナップショットする committed_metrics（標準とベンダーエントリーの両方を運ぶ統一された配列、各が committed_at 付き）を返します — バイの寿命の間追加のみ。ビューアビリティコミットメントは qualifier.viewability_standard: "mrc" を運び、MRC と GroupM が互いに対して決して照合しないようにします。
3. 実行。 クリエイティブマニフェストが DV のトラッカーアセットを運びます。それらが発火します — クライアント側、サーバー側、OMID、SIVA、セラーがコミットメントを尊重するため選んだどのパスでも。バイヤーはパスを見ません。
4. レポート。 バイごとの totals が標準 viewability ブロック（卒業した Tier 1 表面 — measurable_impressions、viewable_impressions、viewable_rate、standard）を投入します。バイ横断の aggregated_totals が metric_aggregates 経由で qualifier で分割（#3848、提案） — コントラクトと同じ原子単位、(metric_id, qualifier) で結合。セラーが任意のコミットされたメトリックを配信できない場合、それは missing_metrics に現れます — アカウンタビリティ違反、プロトコル内で表示。
この例が示すもの。 バイヤーは決して 「これは SSAI か?」 と尋ねません。彼らが実際に持つ質問 — 「選んだ検証ベンダーはこの在庫で信頼できるビューアビリティを生成できるか?」 — は、製品がフィルターを通過するかどうかで構造的に答えられます。セラーの配管は、彼らが作成時に署名したコントラクトに束縛された私的な実装詳細です。SSAI、CSAI、アプリ内、ウェブ、DOOH がすべて同じ表面を通じて流れます。どれも特別なスキーマを得ません。
これは、層が機能するはずの方法で機能する検証です: バイヤーが 必要とする結果（ベンダー + 標準 + しきい値）を指定し、セラーがコミットするか自身を除外し、アカウンタビリティはナラティブではなく構造的です。
オープンな質問
分類は何が別個かを明確にしますが、2 つの質問が境界に位置します。メジャメントは専用のプロトコル表面を得るべきか?
測定エージェントは既にファーストクラスです: ベンダーはbrand.json agents[type='measurement']（BrandRef アンカー）として発見可能で、get_adcp_capabilities.measurement.metrics[] 経由でメトリックカタログを公開し、performance-standard.vendor、vendor_metrics、committed_metrics（ベンダースコープエントリー）から BrandRef で参照され、delivery-metrics.viewability（卒業した標準）と vendor_metric_values（非卒業ベンダーメトリック）を通じて証明された値を発行します。パターンは 「複数のプロトコル全体で消費される発見可能なエージェントアイデンティティ」 で、「プロトコルの居場所なし」 ではありません。
オープンな質問は、その分散パターンが正しいか、メジャメントが Signals と Governance と並ぶ ピアプロトコル に値するか — 自身のタスク表面（例: register_measurement、attest_outcome、dispute_measurement）と自身の仕様ページとともに。今日、測定エージェントコントラクトは暗黙で、BrandRef が消費される場所の union によって定義されます。
現状（分散）のケース。 測定ベンダーは既に OMID、MRC 認定、ベンダー SDK 経由で運用します。プロトコルの仕事はそれらをバイヤー/セラーフローから呼び出し可能にすることで、それをしています。専用プロトコルは既に機能するものを複製するリスクを負います。
ピアプロトコルのケース。 紛争解決、再カウント、（配信行のベンダーフィールドではなく）主要アーティファクトとしての署名付き測定証明は、共通プリミティブから利益を得るかもしれません。測定エージェントケイパビリティが 「値をレポート」 を超えて — 飛行中のシグナル生存レポート、予測測定可能性、独立ガバナンス監査へ — 拡大すると、分散パターンが緊張します。
この質問は抽象的な答えを必要としません。現在のパターンに合わない測定ベンダーケイパビリティが表面化するとすぐに解決します。
事前入札測定シグナルはどこに存在するか?
事前入札ビューアビリティスコア（インプレッションがビューアブルになる予測可能性）は、配信後ビューアビリティ測定を生成する同じベンダーによって販売されます。今日、予測は シグナル（決定前に消費）。測定は 検証（配信後に消費）。同じベンダー、同じ方法論ファミリー、2 つのプロトコルの居場所。これは 消費パターン が異なるから機能します — が、特に予測測定と配信後測定がリアルタイムビディングコンテキストで収束するにつれ、重複コストが層化利益を上回るか監視する価値があります。会話コンテキストターゲティングはどこに合うか?
AI ネイティブチャネル（ChatGPT と類似のエージェンティック会話表面）は、会話トピックをシグナルとして広告をターゲットします — クッキーなし、フィンガープリンティングなし、オーディエンスグラフなし。同じアカウントが異なるチャット主題で異なるアドバタイザーを得ます。プロンプト自体がリアルタイムでターゲティングシグナルを運びます。 これは構造的に シグナル 層パターン（予測的、決定前）ですが、従来のコンテキストシグナル（ページ URL またはページコンテンツをターゲット）より細かい粒度です。従来のコンテキスト広告よりウォールドガーデンエンゲージメントシグナルターゲティング（Facebook News Feed）に近い — 在庫がフィード投稿ではなく会話テキストであることを除いて。 AdCP のシグナル分類は今日会話コンテキストターゲティングを直接モデル化しません。それが新しいシグナルタイプに値するか既存のContextual signals カテゴリー内に合うかはオープンな質問です — 在庫形状（会話対ページベース）とシグナルライフサイクル（プロンプトごと対ページビューごと）は異なりますが、消費パターン（決定前ターゲティング入力）は同じです。