Skip to main content
アトリビューションと最適化のためにコンバージョンまたはマーケティングイベントを送信します。バッチ送信、テストイベント、および部分的な失敗レポートをサポートしています。 レスポンス時間: 約1秒(イベントは処理キューに追加されます) リクエストスキーマ: /schemas/v3/media-buy/log-event-request.json レスポンススキーマ: /schemas/v3/media-buy/log-event-response.json

クイックスタート

購入イベントをログに記録する:

リクエストパラメータ

Event オブジェクト

User Match オブジェクト

uidshashed_emailhashed_phoneclick_id、または client_ip + client_user_agent のうち少なくとも1つが必須: ハッシュ化: ハッシュ化された識別子は SHA-256 の16進数文字列(64文字、小文字)でなければなりません。ハッシュ化前に正規化すること: メールアドレスは小文字かつ前後の空白をトリミング、電話番号は E.164 形式(例:+12065551234)にします。

Custom Data オブジェクト

レスポンス

成功レスポンス:
  • events_received - 受信したイベント数
  • events_processed - 正常にキューに追加されたイベント数
  • partial_failures - バリデーションに失敗したイベント(event_id、コード、メッセージを含む)
  • warnings - 非致命的な問題(マッチ品質が低い、フィールドが欠落しているなど)
  • match_quality - 全体的なマッチ品質スコア(0.0 〜 1.0)
エラーレスポンス:
  • errors - オペレーションレベルのエラーの配列(無効なイベントソース、認証失敗など)
注意: レスポンスは判別共用体(discriminated union)を使用しており、成功フィールドまたは errors のどちらか一方のみが返されます。部分的な失敗は、成功レスポンス内にイベントごとに報告されます。

よくあるシナリオ

クリエイターエンゲージメントイベント

クリエイターまたはコンテンツのエンゲージメントイベントを、設定済みの自社プロパティのソースに対してログします。プロパティを識別するには surface を使い、視聴のしきい値は custom_data.progress_percent または custom_data.progress_seconds に入れます。
test=false
無料で継続的なオプトインには event_type: "follow" を使います。event_type: "subscribe" は有料の購読または有料のメンバーシップに限定します。

バッチイベント

複数のイベントを1つのリクエストで送信します:

テストイベント

本番データに影響を与えずにイベント連携を検証する:
テストイベントはセラーのテストイベント UI に表示されるが、本番のアトリビューションやレポートには影響しません。

店舗内コンバージョン

CRM データを使用してオフラインコンバージョンを報告する:

イベントの重複排除

イベントは event_id + event_type + event_source_id の組み合わせで重複排除されます。同じイベントを複数回送信しても安全で、重複は無視されます。 リトライをまたいで安定した event_id の値を選ぶこと:
  • トランザクション ID: "order_98765"
  • 複合キー: "purchase_user123_20260115"
  • UUID: "550e8400-e29b-41d4-a716-446655440000"

エラーハンドリング

ベストプラクティス

  1. 先にソースを設定する — イベントを送信する前に必ず sync_event_sources を実行します。設定されていないソースへのイベントは拒否されます。
  2. user_match を含める — ユーザー識別子のないイベントはアトリビューションできません。利用可能な最も強力な識別子を提供すること: ハッシュ化されたメール・電話番号 > UID > クリック ID > IP/UA。マッチ率を最大化するために、複数の識別子タイプを可能な限り送信します。
  3. 最初はテストイベントを使用する — 連携の検証時は test_event_code を設定し、本番データに影響を与えずにイベントが正しく表示されることを確認します。
  4. 可能な限りバッチ処理する — API 呼び出し回数を減らすために、1リクエストあたり最大10,000件のイベントを送信します。バッチ内のイベントはそれぞれ独立して処理されます。
  5. value と currency を含める — 購入イベントでは、ROAS レポートと最適化を有効にするために常に custom_data.valuecustom_data.currency を含めます。
  6. 安定したイベント ID を使用する — ランダムな UUID ではなく、決定論的なイベント ID(注文番号、トランザクション ID)を使用します。これにより重複カウントなしに安全なリトライが可能になります。
  7. イベントを迅速に送信する — できる限りリアルタイムに近いタイミングでイベントをログに記録します。セラーのアトリビューションウィンドウを超えたイベントはマッチングされない場合があります。

次のステップ