/schemas/v3/media-buy/sync-event-sources-request.json
レスポンススキーマ: /schemas/v3/media-buy/sync-event-sources-response.json
クイックスタート
購入トラッキング用のイベントソースを設定します:リクエストパラメータ
イベントソースオブジェクト
レスポンス
成功レスポンス:event_sources- 同期済みのソースとアカウント上のセラー管理ソースの両方を含む、各イベントソースの結果
errors- 操作レベルのエラーの配列(認証失敗、アカウントが見つからないなど)
- すべてのリクエストフィールド
seller_id- このイベントソースのセラー割り当て識別子action- 実行された操作:created、updated、unchanged、deleted、failedaction_source- イベントソースの種別(ウェブサイトピクセル、アプリ SDK など)surface- フラットなaction_sourceが粗すぎる場合に、このソースが表す構造化されたサーフェスmanaged_by- このソースの管理者:buyerまたはsellersetup- 実装の詳細(スニペット、手順)health- イベントソースの健全性評価(セラーが健全性スコアリングをサポートする場合)errors- ソースごとのエラー(action: "failed"の場合のみ)ext- ソースごとの拡張メタデータ(プラットフォームネイティブのコンバージョン ID、アトリビューションウィンドウのハンドル、生の起点文字列など)
イベントソースの健全性
イベントソースの品質を評価するセラーは、レスポンスの各ソースにhealth オブジェクトを含めます。これは Snap の Event Quality Score や Meta の Event Match Quality に相当します——バイヤーのイベント連携が最適化に十分な程度に機能しているかを伝えます。
test=false
detail.score ではなく status を判断の基準にすべきです。四段階のステータスはすべてのセラー間で比較可能です——バイヤーエージェントは、どこでも機能する一つのルール(「DR プロダクトには good 以上を要求する」)を書きます。detail オブジェクトは人間向けダッシュボードや高度な診断のためのものです。
バイヤーエージェントは健全性データを次のように活用できます:
- イベント品質でプロダクト選択をゲートする(例: DR プロダクトには
good以上を要求) - キャンペーンのローンチ前にセットアップの問題をバイヤーに提示する
- どのイベントソースを最初に修正すべきか優先順位付けする
よくある使用例
ディスカバリーのみ
変更を加えずにアカウント上のすべてのイベントソース(セラー管理ソースを含む)を検出します。セラーが常時オンのアトリビューションを提供するプラットフォーム管理のコンバージョントラッキングに便利:複数のイベントソース
ウェブサイトとアプリ用に個別のソースを設定します:セラー管理ソースの検出
セラーは常時オンのイベントソース(例: Amazon 売上アトリビューション)を提供する場合があります。これらはバイヤー管理ソースと並んでmanaged_by: "seller" としてレスポンスに表示されます:
test=false
conversion_tracking.platform_managed: true を持つプロダクトは、セラーがこれらのソースを提供していることを示しています。
クリエイターおよび自社プロパティのソース
セラー管理のクリエイターまたは自社プロパティのソースは、互換性のためのフラットなaction_source と構造化されたコンテキストのための surface を伴って、同じ event_sources 配列を使います:
test=false
follow を使います。有料の購読または有料のメンバーシップにのみ subscribe を使います。
delete_missing によるクリーン同期
アカウント上のすべてのバイヤー管理イベントソースを置き換える:セットアップ手順
レスポンスには各イベントソースのセットアップ詳細が含まれます。setup オブジェクトはソースのアクティベート方法を示しています:
エラーハンドリング
ベストプラクティス
-
ログ送信前に同期する —
log_eventでイベントを送信する前に、必ずイベントソースを設定しなければなりません。未設定のソースへのイベント送信は拒否されます。 -
わかりやすい ID を使用する — 不明瞭な識別子ではなく、意味のある
event_source_id値(例:web_pixel、app_sdk、crm_import)を選ぶべきです。 - event_types を指定する — より良いバリデーションとデバッグのために、各ソースを関連するイベントタイプに限定すべきです。
-
セラーの機能を確認する — イベントソースを設定する前に、
get_adcp_capabilitiesを使用してサポートされているイベントタイプ、UID タイプ、アクションソースを確認すべきです。 -
セットアップスニペットをインストールする — レスポンスに
setup手順が含まれている場合、イベントをログに記録する前に提供されたスニペットをインストールしなければなりません。サーバーオンリーソース(snippet_type: "server_only")はこの手順をスキップしてよいです。 -
セラー管理ソースを処理する — レスポンスには自分が設定していない
managed_by: "seller"のソースが含まれる場合があります。これらは常時オンであり、追加のアトリビューションデータを提供します。
次のステップ
- コンバージョントラッキング — データモデル、最適化目標、エンドツーエンドのフロー
- log_event — 設定済みイベントソースにマーケティングイベントを送信します
- create_media_buy — イベントソースを参照するパッケージに最適化目標を設定します
- get_media_buy_delivery — デリバリーレポートでコンバージョン指標を監視します