課金権威

​

概要

1. 誰の数値が権威的か? 異なるディールは異なる当事者を名指します — セラーの広告サーバー、バイヤーのサードパーティ広告サーバー、または Nielsen や IAS のような名指しされた測定ベンダー。
2. その数値は動くのを止めたか? テレメトリーは数時間、数日、数週間で落ち着きます（放送 C3 → C7 DVR 蓄積、デジタル IVT 後スクラブ、ポッドキャスト 30 日ダウンロード、コンバージョン dedup）。最終数値は請求可能。暫定数値はそうでない。

​

権威の名指し

​

数値を最終としてマーク

​

get_media_buy_delivery 上

• is_final: boolean — 行レベルの最終性、行のすべてのパッケージが同じウィンドウについて最終であることと同等。
• finalized_at: string (date-time) — is_final: true のとき、かつそのときのみ存在。billing_measurement.finalization_deadline_hours で宣言された任意のデッドラインをアンカー。
• パッケージごと: by_package[*].is_final、by_package[*].finalized_at、by_package[*].measurement_window、by_package[*].supersedes_window。

​

report_usage 上

• final: boolean — 不在は不明を意味する。 レポーターが実際に数値を落ち着けたとき（例: post-SIVT 月末クローズ）のみ true を設定。予備レコード（日次ペーシングプッシュ、期間内進捗）には false を設定。measurement_terms.billing_measurement がこのレポーターを権威的と名指すとき、受信者は final: false または不在で請求してはならない（MUST NOT） — まず最終レコードを要求。billing_measurement なしの 3.0 スタイル使用と非メディアバイバリアント（signals、governance、creative、brand — 暫定状態概念のないドメイン）には、受信者は不在を最終として扱い既存動作を保持してもよい（MAY）。
• finalized_at: string (date-time) — final: true のとき、かつそのときのみ存在。
• measurement_window: string — バイの billing_measurement.measurement_window が設定されているとき設定すべき（SHOULD）、受信者が正しい段階に対して照合するように。

​

Webhook 最終性を行最終性から区別する

​

セラーが請求書をどう生成するか

​

セラー証明（デフォルト）

billing_measurement absent, or vendor names seller's own ad server

​

バイヤー証明（3PAS）

billing_measurement.vendor.domain = "campaignmanager.google.com" (buyer's CM360)
billing_measurement.max_variance_percent = 10
billing_measurement.measurement_window = "post_sivt"
billing_measurement.finalization_deadline_hours = 240   // 10 days after post_sivt close

1. バイヤーの CM360 が期間について post-SIVT を落ち着ける。
2. バイヤーのオペレーター — 実際には holdco プラットフォーム（例: Choreograph、Annalect、Acxiom）または CM360 エクスポートをラップするインハウスエージェンシーエンジニアリングチーム — がメディアバイレコードで report_usage を呼ぶ: media_buy_id、impressions、vendor_cost、currency、final: true、finalized_at、measurement_window: "post_sivt"。日次ペーシングプッシュ（使われる場合）は final: false を設定。落ち着いたファイルのみが final: true を設定。
3. セラーが get_media_buy_delivery からの自身の post-SIVT 行（is_final: true、同じ measurement_window）と比較。|seller - buyer| / max ≤ max_variance_percent なら、セラーはバイヤーの数値で請求。
4. 分散がしきい値を超えるなら、セラーは makegood_policy.available_remedies から救済を提案。
5. バイヤーが finalization_deadline_hours 内に最終レコードを公開しないなら、セラーは自身のセラー証明数値から請求し遅い最終化を makegood_policy の下の違反として扱ってもよい（MAY）。

今日の現実: 月次 3PAS 照合はほとんど、セラーの AR チームにメールされた CSV/PDF 経由で帯域外で処理されます。このフローはワイヤー形式アップグレードです — 最初のアダプターは、CM360 / Flashtalking / Innovid エクスポートを report_usage でラップするエンジニアリングを持つ holdco オペレーターの可能性が高く、RTB SSP ではなく共感的な直接パブリッシャーと働きます。

​

ベンダー証明（名指しされたサードパーティ）

billing_measurement.vendor.domain = "nielsen.com"
billing_measurement.max_variance_percent = 5
billing_measurement.measurement_window = "c7"
billing_measurement.finalization_deadline_hours = 528   // 22 days after c7 close

• セラーがベンダー関係を保持（一般的な CTV パターン）。 セラーは自身のスケジュールで Nielsen（NPower など）から C7 数値を引き、C7 ウィンドウがクローズプラス内部処理するとき measurement_window: "c7"、is_final: true、finalized_at 設定で get_media_buy_delivery に行として公開。バイヤーからの report_usage プッシュ不要。照合はセラーの行に対して起こる。
• バイヤーがベンダー関係を保持。 バイヤー（またはそのオペレーター）がベンダーの権威数値をフェッチ — 例: エージェンシーの iSpot サブスクリプション、インハウス IAS ダッシュボードエクスポート — し、final: true、finalized_at、measurement_window: "c7" でバイのアカウントに対して report_usage 経由でプッシュ。ベンダー自体は AdCP を呼ばない。

今日の現実: RTB を実行する SSP は当面セラー証明であり続けます — 彼らの課金システムはバイヤー証明の請求基準のため設計されたことがなく、max_variance_percent プラス makegood_policy は彼らがそれをレトロフィットする十分な商業カバーではありません。ここでの最初の実際のアダプターは、Nielsen バックの保証が既に測定ベンダーのカウントで請求する CTV 直接セラー（例: Disney、NBCU、Paramount）です — 彼らにとってこの PR は既存の慣行を構造化された条件で記述するだけです。

​

今日の不一致の解決

• バイの makegood_policy.available_remedies — セラーが事前コミットした救済のメニュー（追加配信、クレジット、請求書調整）。
• 両側の finalized_at タイムスタンプ付き最終レコード — 誰が何が最終と言ったか、いつかの完全な監査証跡。
• create_media_buy で捕捉された元の committed_metrics と measurement_terms — 当事者が同意したもの。

​

実例: バイヤー証明 3PAS 照合

{
  "measurement_terms": {
    "billing_measurement": {
      "vendor": { "domain": "campaignmanager.google.com" },
      "max_variance_percent": 10,
      "measurement_window": "post_sivt",
      "finalization_deadline_hours": 240
    },
    "makegood_policy": {
      "available_remedies": ["additional_delivery", "credit", "invoice_adjustment"]
    }
  }
}

{
  "media_buy_deliveries": [
    {
      "media_buy_id": "mb_q1_2026",
      "is_final": true,
      "finalized_at": "2026-04-08T18:00:00Z",
      "by_package": [
        {
          "package_id": "pkg_001",
          "is_final": true,
          "finalized_at": "2026-04-08T18:00:00Z",
          "measurement_window": "post_sivt",
          "impressions": 5120000,
          "spend": 51200
        }
      ]
    }
  ]
}

{
  "idempotency_key": "f9b3...e2a1",
  "reporting_period": { "start": "2026-03-01T00:00:00Z", "end": "2026-03-31T23:59:59Z" },
  "usage": [
    {
      "account": { "account_id": "acct_acme_seller" },
      "media_buy_id": "mb_q1_2026",
      "currency": "USD",
      "impressions": 5040000,
      "vendor_cost": 50400,
      "final": true,
      "finalized_at": "2026-04-09T14:32:00Z",
      "measurement_window": "post_sivt"
    }
  ]
}

​

関連

• measurement-terms — スキーマ
• get_media_buy_delivery — セラー側最終性フラグ
• report_usage — バイヤー側 / サードパーティ最終性フラグ
• アカウンタビリティ — パフォーマンス標準、メイクグッド救済、キャンセル
• レポートケイパビリティと測定ウィンドウ