sync_event_sources はイベントの収集元を設定し、log_event はイベント自体を送信します。
イベントデータは配信レポート（コンバージョン数、ROAS、獲得単価）にフィードされ、メディアバイパッケージの最適化ゴールを有効にします。
フロー
これは推奨される順序を示しています。実際には、イベントが流れる前にメディアバイを作成することもできます。セラーは十分なイベント履歴が蓄積されてから最適化を開始します。イベントソース
イベントソースは、コンバージョンイベントを収集するチャネルを表します。ウェブサイトピクセル、モバイル SDK、サーバー間連携、CRM インポートなどがあります。sync_event_sources でイベントソースを設定します。event_source_id、任意の name、event_types、allowed_domains を指定します。レスポンスには各ソースの追加フィールドが含まれます。
バイヤー管理 vs セラー管理
バイヤー管理ソースはsync_event_sources を通じて自分が設定するものです。イベントタイプ、ドメイン、ライフサイクルを自分で管理します。
セラー管理ソースは常時オンで、レスポンスに managed_by: "seller" として現れる。これはコマースメディアでよく見られ、リテーラーが組み込みアトリビューション（例：自社プラットフォームでの購入トラッキング）を提供する場合に使われます。conversion_tracking.platform_managed: true を持つプロダクトは、セラーがこれらのソースを提供することを示しています。
アカウント上のすべてのソース（セラー管理のものを含む）を検出するには、event_sources 配列を指定せずに sync_event_sources を呼び出す。
イベント
イベントは、購入、リード送信、ページビュー、アプリインストール、その他の標準イベントタイプといったユーザーアクションを表します。log_event でイベントを送信します。
イベントは
event_id + event_type + event_source_id で重複排除されます。同じイベントを複数回送信しても安全です。
ユーザーマッチ
ユーザー識別子により、セラーはコンバージョンを広告インプレッションにアトリビュートできます。利用可能な最も強力な識別子を提供すること。識別子が多いほどマッチ率が高くなります。
ハッシュ化: ハッシュ前に正規化すること。メールアドレスは小文字にして空白をトリムし、電話番号は E.164 形式（例:
+12065551234）にします。SHA-256 でハッシュ化し、64文字の小文字16進数として出力します。
利用可能な場合は複数の識別子タイプを送信すること。セラーは最善のマッチを使用します。
カスタムデータ
アトリビューションとレポートのためのイベント固有データ。購入イベントでは、ROAS レポートを有効にするために常にvalue と currency を含めること。
イベントタイプ
IAB ECAPI に準拠した標準マーケティングイベントタイプ:アクションソース
コンバージョンイベントの発生元:イベントサーフェス
action_source は互換性のため意図的にフラットなままです。最適化に関連するソースがより多くの構造を必要とする場合——特に自社プラットフォームのプロパティにおけるクリエイターやコンテンツのエンゲージメント——には surface を使います。
owned_property では property_type と namespace の両方を設定し、プラットフォームが安定したプロパティ識別子を公開している場合は常に property_id を含めてください。
surface.category が action_source の値と一致する場合、プロデューサーは action_source を同じ値に設定すべきです。owned_property では、古いコンシューマーのために最も近い互換のフラット値を保ちます——プラットフォームネイティブなイベントでは一般に system_generated、より近い値がない場合は other。生のコンバージョン起点のようなプラットフォームネイティブの詳細は引き続き ext に載せられますが、共有される最適化の意味は event_type、action_source、surface に属します。
イベントソースの健全性
イベントソースの品質を評価するセラーは、sync_event_sources のレスポンスで各ソースに health オブジェクトを含めます。これは、Snap の Event Quality Score（EQS）や Meta の Event Match Quality（EMQ）のようなプラットフォーム固有の品質スコアの AdCP における等価物です。
status フィールドが AdCP 標準のスコアです——すべてのセラー間で比較可能です:
バイヤーエージェントは、
detail ではなく status に基づいて判断すべきです。任意の detail オブジェクトは、人間向けダッシュボードや高度な診断のためにセラー固有のスコアリング（例: Snap の 0〜10 の EQS、Meta の 0〜10 の EMQ）を含みますが、スケールはセラーによって異なり、プラットフォーム間で比較できません。
健全性はアカウント単位ではなく、イベントソース単位で報告されます。健全なウェブサイトピクセルと壊れたアプリ SDK を持つバイヤーは、それぞれで異なる健全性を見ます。
health が不在の場合、セラーはイベントソースの品質を評価していません。バイヤーエージェントは健全性によるゲーティングなしで進めるべきです——セラーが内部で品質を扱います。不在の健全性を insufficient として扱わないでください。
セラーによる健全性の計算方法
ネイティブな API アクセス可能の品質スコア（Snap EQS、Meta EMQ）を持つセラーは、それらをstatus と detail で直接中継します。ほとんどのセラーはネイティブスコアを持たず、運用メトリクスから status を導出します:
insufficient: タグが非アクティブ、またはevents_received_24hが 0minimum: タグはアクティブだが、低ボリュームまたは高エラー率good: 安定して発火、妥当なボリューム、コアイベントタイプをカバーexcellent: 高ボリューム、低エラー、拡張マッチングが有効
evaluated_at のタイムスタンプが評価の鮮度をバイヤーに伝えます。24 時間より古い評価は、タグ設定やイベントボリュームの最近の変更を反映していない可能性があります。これらのセラーでは detail オブジェクトは不在です——中継すべきネイティブスコアがありません。
スキーマ: /schemas/v3/core/event-source-health.json
計測レディネス
イベントベースの最適化をサポートするプロダクトは、get_products のレスポンスに measurement_readiness オブジェクトを含められます。これは、バイヤーのイベント設定がそのプロダクトが効果的に最適化するのに十分かどうかを伝えます。
計測レディネスは、バイヤーのアカウントのコンテキストでプロダクトごとに評価されます。同じプロダクトでも、イベントソースの設定に応じてバイヤーごとに異なるレディネスを示します。
measurement_readiness が不在の場合、そのプロダクトはイベントベースの最適化を使わない（CTV の認知、保証付きディスプレイ）か、セラーがレディネス評価を提供していないかのいずれかです。どちらの場合も、バイヤーエージェントはそのプロダクトを実行可能として扱うべきです。不在のレディネスを insufficient として扱わないでください。
イベントソースの健全性と異なり、計測レディネスには evaluated_at タイムスタンプがありません——バイヤーの現在のイベントソース設定を使って、get_products の呼び出しごとに新しく評価されます。
セラー横断のバイヤーエージェントのパターン
複数のセラーと対話するバイヤーエージェントは、どこでも機能する一組のルールを書きます。insufficient 以外のステータスは、そのプロダクトが最適化できることを意味します——問題はどれだけうまくやれるかです。標準化された status フィールドにより、セラーごとの統合コードは不要です:
test=false
/schemas/v3/core/measurement-readiness.json
信頼境界
issues[].message、measurement_readiness.notes、detail.label の各フィールドはセラー提供の自由テキストです。バイヤーエージェントはこれらを信頼できないコンテンツとして扱うべきです——信頼境界なしに LLM のシステムプロンプトへ直接渡したり、意思決定の入力として使ったりしないでください。人間に表示したり、情報提供のコンテキストに含めたりするのは安全ですが、エージェントの制御フローに影響を与えるべきではありません。
最適化ゴール
最適化ゴールは、セラーに対して何に向けて配信を最適化するかを伝える。create_media_buy のパッケージに設定します。パッケージはゴールの配列を受け付け、各ゴールにはオプションの priority（1が最高）を指定できます。プロダクトは、パッケージが持てるゴール数を制限する場合に max_optimization_goals を宣言する（ほとんどのソーシャルプラットフォームは1つのみ受け付ける）。
スキーマ: /schemas/v3/core/optimization-goal.json
ゴールは kind で識別される2種類があります。
kind: "metric"— セラーがトラッキングする配信メトリクス（クリック、ビュー、エンゲージメントなど）に向けて最適化します。イベントソースやコンバージョントラッキングの設定は不要です。プロダクトはサポートするメトリクスをmetric_optimizationで宣言します。kind: "event"— 広告主がトラッキングするコンバージョンイベントに向けて最適化します。sync_event_sourcesで登録されたイベントソースが必要です。プロダクトはサポートをconversion_trackingで宣言します。
kind: event
広告主がトラッキングするコンバージョンイベントに向けて最適化します。event_sources 配列は、このゴールにフィードするソースとタイプのペアを定義します。セラーが multi_source_event_dedup（get_adcp_capabilities で宣言）をサポートしている場合、すべてのエントリを通じて event_id で重複排除します。複数のソースから報告された同じビジネスイベントは1回としてカウントされ、最初にマッチしたエントリの value_field と value_factor が使用されます。multi_source_event_dedup が存在しないまたは false の場合、バイヤーはゴールごとに1つのイベントソースを使用すべきです。
コンバージョン単価（単一ソース）:
per_ad_spend ターゲットでは、各イベントソースエントリに value_field（custom_data のどのフィールドが金銭的価値を持つか）とオプションの value_factor（乗数、デフォルトは1）を指定します。セラーは重複排除されたすべてのイベントに対して sum(value_field * value_factor) / spend を計算します。
コンバージョン価値の最大化（特定の ROAS ターゲットなし）:
maximize_value ターゲットは、特定のリターン比率にコミットせずに高価値コンバージョンに向けて支出を誘導します。少なくとも1つのイベントソースエントリに value_field が必要です。
kind: metric
セラーがトラッキングする配信メトリクスに向けて最適化します。イベントソースは不要です。セラーはこれらをネイティブにトラッキングします。プロダクトはサポートするメトリクスをmetric_optimization.supported_metrics で宣言します。
クリック数の最大化（ターゲットなし — セラーが予算内でボリュームを最適化）:
kind: "metric" における attention_seconds / attention_score の列挙値は非推奨です——ベンダーによって実証されるメトリクスは代わりに kind: "vendor_metric" を使い、ゴールを特定の計測ベンダーに結び付けます）:
メトリクス:
kind: vendor_metric
業界で認定された定義を持たない、ベンダーによって実証される計測——アテンション（DoubleVerify、IAS、Adelaide、TVision、Lumen）、パネルベースのブランドリフト（Kantar、Upwave、Cint）、排出量（Scope3、Good-Loop——後述の極性に関する注意を参照）、リテールメディアのパートナーメトリクス——では、ゴールが特定のベンダー +metric_id をエンドツーエンドで結び付けます。セラーの入札スタックはそのベンダーの計測に向けて誘導し、デリバリーは同じ (vendor, metric_id) のキーで vendor_metric_values[] を通じて値をレポートします。
方向の極性（このマイナーバージョンでは上向きの押し上げのみ）。cost_per と threshold_rate は上向きに押し上げるターゲットです——セラーはより高いメトリクス値、または最低しきい値の充足に向けてデリバリーを誘導します。バイヤーが最小化したいメトリクス（排出量、IVT、レイテンシ）は、現時点ではベンダーのメトリクス定義に沿ったセラー側の極性解釈に依存します。ファーストクラスの最小化セマンティクス（ゴール上の direction: "minimize" フィールド、または target.kind: "ceiling_rate"）は WG で議論中です——#4644 を参照してください。
ゴール受理のための三つの前提条件。セラーは、ケイパビリティまたはレポーティング整合性の前提条件を満たさない
vendor_metric ゴールを拒否しなければなりません（MUST）。ディスカバリーの前提条件は検証すべきです（SHOULD）:
- ディスカバリー（このマイナーでは SHOULD、次のマイナーでは MUST）—
metric_idがベンダーの公開するmeasurement.metrics[]カタログに含まれること（ベンダーのbrand.jsonの計測エージェントに問い合わせます）。AdCP 準拠のケイパビリティ公開に対する計測ベンダーの対応が追いつくまでの間 SHOULD に緩和されており、2 社以上のベンダーが準拠エージェントを提供した時点で MUST に強化されます。 - ケイパビリティ —
(vendor, metric_id)のペアがプロダクトのvendor_metric_optimization.supported_metrics[]に含まれ、かつゴールのtarget.kindが該当エントリのsupported_targetsに含まれること。 - レポーティング整合性 — パッケージの
committed_metrics[]に、対応する{ scope: "vendor", vendor, metric_id }エントリが含まれること。コミットされたレポーティングのない最適化は検証不能です——セラーが契約上値を埋める義務を負わないゴールに対して、バイヤーはパフォーマンスを評価できません。この前提条件こそがゴールを意味あるものにします。セラーは、同じパッケージでレポーティングにもコミットされていないメトリクスのゴールを（TERMS_REJECTEDで）拒否しなければなりません（MUST）。
metric 種別との違い。metric 種別は、ベンダーの結び付けが不要なセラーネイティブの計測（clicks、views、completed_views、reach、engagements など）向けです——セラーがそのメトリクスをネイティブに計測します。vendor_metric 種別は、同じメトリクス名がベンダーによって異なる意味を持ち、特定のソースに突き合わせる必要がある、ベンダー実証の計測向けです。metric 種別の列挙にある非推奨の attention_seconds / attention_score の値はこの分割より前のものであり、今後は vendor_metric を経由します。
完全なライフサイクルのリファレンス。標準メトリクスとベンダーメトリクスの両方のフローにまたがる、ケイパビリティ → コミットメント → 最適化 → デリバリーの全体像についてはメトリクスのライフサイクルを参照してください。
ターゲットの種類
三つのゴール種別にまたがるすべてのターゲット種類:戦略の選択
複数ゴールと優先度
パッケージは複数のゴールを持てる。優先度はセラーがどれをメインとして扱うかを制御します。よくあるパターンは、イベントデータが少ない場合にメトリクスゴールをプロキシシグナルとして使用することです。priority: 1 のゴール（SDK と MMP をまたいで重複排除した $10 インストール単価）に注力し、インストールデータが蓄積されるまでクリックをプロキシシグナルとして使用します。
イベントゴールのデフォルト動作
イベントゴールからtarget を省略した場合、セラーは予算内でコンバージョン数を最大化します。これは、イベントソースに value_field があるかどうかに関わらず当てはまります——明示的な価値志向のターゲットを伴わない value_field はレポーティング（デリバリーレポートの conversion_value、ROAS）を有効にしますが、最適化の目的関数は変えません。
ゴールのブレンドとシーケンス
value_factor と priority はどちらも「イベントタイプ A はイベントタイプ B より重要である」を表現しますが、セラーの最適化にとっての意味は異なります:
value_factorは複数のイベントソースを単一の目的関数にブレンドします。単一のゴールのevent_sources配列内のイベントソースエントリごとに設定します。セラーは、複合的な価値シグナルを持つ一つのゴールを見ます。購入とページビューを明示的な相対的重み付けで一緒に最適化すべき場合に使用します。priorityは独立したゴールをシーケンスします。optimization_goals配列内の別々のゴールオブジェクトに設定します。セラーはまずゴール 1 を最適化し、ゴール 2 は二次的な目的であって、ブレンドはされません。ゴールが概念的に別物である場合（例: まず CPA ターゲットを達成し、次に残りの予算でリーチを最大化する）に使用します。
value_factor を、シーケンスするには priority を使用してください。これらを取り違えると、微妙に誤った最適化——シーケンスすべきものがブレンドされたゴール、またはブレンドすべきものがシーケンスされたゴール——が生じ、その影響はデリバリーレポートでは検出しにくいものになります。
イベントタイプの極性
ほとんどのイベントタイプは正のシグナルです——購入、リード、インストールは、バイヤーがより多く欲しいものです。一部のイベントタイプは、単独の最適化ターゲットにすべきでない観測シグナルです:custom イベントはここで分類されません——その極性はバイヤーの定義に依存します。バイヤーエージェントは、カスタムイベントが単独のターゲットとして安全かどうかを選ぶ際に、同じ考え方を適用すべきです。
観測イベントは複合ゴールの内側では有用です——refund に value_factor: -1 を設定すると ROAS が下方に調整され、これはまさに望ましい挙動です。リスクは、refund や remove_from_cart の数に向けて最適化する単独のゴールを作ってしまう、設定を誤ったバイヤーエージェントです。これはバイヤーエージェントの実装上の懸念であり、プロトコルの制約ではありません——プロトコルは意図的に、どのイベントタイプを最適化ターゲットにできるかを制限しません。
value_factor によるボリュームの正規化
異なるボリューム規模のイベントソースを組み合わせる場合（例: page_view は数万、purchase は数百）、明示的な重み付けがなければ sum(value_field * value_factor) / spend における集計値は最もボリュームの大きいタイプに支配されます。バイヤーは、ソース間の相対的な重みを表現するために value_factor を使用すべきです:
page_view は額面価値の 1% しか寄与しないため、purchase より約 100 倍多く発生するにもかかわらず、ROAS の計算を支配することを防ぎます。
自動的な正規化は意図的にスコープ外です——セラーが持っていないかもしれないイベント履歴が必要になり、ROAS の式を不透明にしてしまうためです。イベントタイプをまたいで正規化したいバイヤーエージェントは、value_factor を設定する前に自分たちの側で行うべきです。
価格モデルと最適化ゴール
価格モデル（CPC、CPM、CPA など）はバイヤーが支払う対象を決める。最適化ゴールはセラーがどのようにインプレッションを配分するかを決める。これらは独立しています。パッケージは CPM 価格を使いながら CPA ターゲットに向けて最適化したり、CPA 価格を使いながら ROAS に向けて最適化したりできます。請求の詳細については価格モデルを参照。リーチとフリークエンシー
リーチベースの最適化はmetric: "reach" と2つの追加フィールドを使用します。
reach_unit（必須）: 測定単位 — プロダクトのmetric_optimization.supported_reach_unitsで宣言された値でなければなりません（例:households、individuals）。target_frequency（任意）: 最適化を誘導するフリークエンシーバンド。セラーは未リーチのエンティティへのインプレッションを高価値として、すでに飽和したエンティティへのインプレッションを低価値として扱います。min、max、window（例:"7d"、"campaign"）を含みます。省略した場合、セラーはユニークリーチを最大化します。
frequency_cap を使用します。リーチとフリークエンシーのメトリクスは get_media_buy_delivery の配信レポートで確認できます。
前提条件
メトリクスゴール（kind: "metric"）の場合:
- プロダクトのサポートを確認する — プロダクトは
metric_optimizationで目的のメトリクスをsupported_metricsに宣言していなければなりません。イベントソースやコンバージョントラッキングの設定は不要です。 - ターゲットのサポートを確認する — ターゲットを設定する場合は、ターゲットの種類が
metric_optimization.supported_targetsに記載されていることを確認すること。 - 再生時間を確認する —
view_duration_seconds付きのcompleted_viewsを使用する場合は、その値がmetric_optimization.supported_view_durationsに記載されていることを確認すること。
kind: "event"）の場合:
- イベントソースを設定する —
sync_event_sourcesを呼び出して、event_sourcesで参照するイベントソースをセットアップします。 - プロダクトのサポートを確認する — プロダクトは
conversion_trackingで目的のターゲット種類をsupported_targetsに宣言していなければなりません。 - 重複排除のサポートを確認する — ゴールごとに複数のイベントソースを使用する場合は、セラーが
get_adcp_capabilitiesでmulti_source_event_dedupをサポートしていることを確認すること。サポートされていない場合は、ゴールごとに1つのイベントソースを使用すること。 - イベントを送信する —
log_eventを使用してコンバージョンデータを送信します。セラーが効果的に最適化するにはイベント履歴が必要です。
アトリビューションウィンドウ
アトリビューションウィンドウは、セラーがコンバージョンに広告インプレッションをクレジットするためにどれだけ遡るかを制御します。一般的なオプション:
値はセラーの
conversion_tracking.attribution_windows ケーパビリティのオプションと一致しなければなりません。省略した場合、セラーはデフォルトのウィンドウを適用します。
配信レポートとの連携
イベントソースが設定されてイベントが流れ始めると、get_media_buy_delivery のレスポンスにコンバージョンメトリクスが表示されます。
conversions— キャンペーンにアトリビュートされたポストクリックまたはポストビューのコンバージョンconversion_value— アトリビュートされたコンバージョンの金銭的価値roas— 広告費用対効果（conversion_value / spend）cost_per_acquisition— コンバージョン単価（spend / conversions）
optimization_goals が設定されている場合にパッケージごとにレポートされます。by_action_source ブレークダウンをサポートするセラーは、コンバージョンをソース別（website、app、in_store など）に分けて表示できます。
カタログアイテムのアトリビューション
カタログドリブンのパッケージでは、コンバージョンイベントに関連するカタログアイテムを識別するcontent_ids が含まれます。カタログの content_id_type は期待される識別子タイプ（sku、gtin、job_id など）を宣言します。
アトリビューションは意図的に幅広く設計されています。ユーザーがあるアイテム（求人 A）をクリックして別のアイテム（求人 B に応募）でコンバージョンする場合もあります。イベントはクリックされたアイテムではなく、コンバージョンの実際の content_id で発火します。アイテムごとのクリックからコンバージョンまでのパス分析はプラットフォームの最適化の問題であり、プロトコルの問題ではありません。
get_media_buy_delivery の by_catalog_item ブレークダウンは、アイテムごとのメトリクス（インプレッション、支出、クリック、コンバージョン）を表示します。
関連ドキュメント
sync_event_sources— イベントソースの設定log_event— コンバージョンイベントの送信create_media_buy— パッケージへの最適化ゴールの設定get_media_buy_delivery— コンバージョンメトリクスの監視- 価格モデル — CPA 請求（コンバージョン単価課金）