MetaコンバージョンAPIの重複排除｜event_idでブラウザ・サーバーイベントを一致させる方法
MetaピクセルとコンバージョンAPI（CAPI）を併用すると、同じ購入や問い合わせがブラウザとサーバーから1回ずつ送信されます。これは障害やブラウザ制限に備えるための二重経路ですが、識別子が揃っていないとMeta側では別の成果として扱われ、コンバージョン数や広告評価を読み違える原因になります。
重複排除の基本は、同じ顧客行動についてブラウザ側とサーバー側のevent_nameを一致させ、ブラウザのeventIDとサーバーのevent_idに同じ一意な値を送ることです。IDは送信経路ごとではなく顧客行動ごとに1回だけ発行し、再送でも変えません。別の購入や別のフォーム送信には新しいIDを発行します。
実装で重要なのは、ランダムな文字列を作ること自体ではありません。「どの処理がIDを発行するか」「ブラウザからサーバーへどう引き渡すか」「送信失敗を再試行しても同じIDを取り出せるか」を一つの設計として固定することです。広告計測全体のKPIを整理したい場合は、BtoBマーケティングのKPI設計も併せて確認してください。
本記事のポイント
- 同じ顧客行動では、ブラウザとサーバーのevent_nameを揃え、PixelのeventIDとCAPIのevent_idへ同じ一意な値を送ります。
- event_idは送信経路ごとではなく顧客行動ごとに一度だけ発行し、業務レコードへ保存して再送でも維持します。
- Events Managerの表示だけでなく、自社台帳、ブラウザ送信、CAPI responseを突き合わせ、重複排除とイベント一致品質を分けて確認します。
重複排除の条件とイベント一致品質を分けて理解する
Metaの公式仕様では、ピクセルとCAPIの同じイベントを識別するためにevent_nameとevent_idを使います。ブラウザ側のPixelコードではオプション引数のeventID、サーバーイベントではevent_idという表記ですが、入れる値は同一です。大文字・小文字、接頭辞、空白、文字列化の違いも含め、完全に同じ値を渡します。
| 確認項目 | ブラウザ側 | サーバー側 | 揃え方 |
|---|---|---|---|
| イベント名 | Purchase、Leadなど | event_name | 同じ顧客行動は同じ標準イベント名または同じカスタムイベント名にする |
| イベントID | eventID | event_id | 同じ顧客行動で同じ文字列を使い、再送でも変えない |
| 発生時刻 | ブラウザで行動した時刻 | event_time | API送信時刻ではなく実際の顧客行動時刻を保持する |
| 発生経路 | ページURLやPixelの文脈 | action_source、event_source_url | Web上の行動なら発生したURLとwebsiteの経路を正しく伝える |
| 利用者情報 | Cookieやブラウザ情報など | user_data | 同意とMetaの仕様に従い、照合に使える情報を正規化して送る |
重複排除とイベント一致品質は別の問題です。重複排除は「同じ顧客行動をブラウザとサーバーから二重に数えない」ためのイベント識別です。一方、イベント一致品質は、メールアドレス、電話番号、external_id、fbp、fbcなどの利用者情報を使って、送信したイベントをMeta上のアカウントへどれだけ照合できるかを見る観点です。event_idが正しくても利用者情報が不足すれば一致品質は上がらず、利用者情報が豊富でもevent_idが別なら重複を防げません。
Metaは、WebイベントでCAPIとピクセルを併用する構成を案内しています。ただし、CAPIは同意管理や各地域のプライバシー要件を迂回する仕組みではありません。必要な同意、データ最小化、保持期間、削除手順を先に決め、広告計測のために不要な個人情報をイベントIDへ埋め込まないでください。
event_idは顧客行動の発生点で作り、二つの経路へ配る
良いevent_idには3つの性質があります。第一に、別の顧客行動と衝突しない一意性。第二に、同じ行動のブラウザ送信・サーバー送信・サーバー再送で変わらない安定性。第三に、メールアドレスや氏名などを含まない非識別性です。UUIDのような十分に一意な値、または第三者に意味を推測されにくい内部トランザクションIDを使い、イベント種類や環境のnamespaceを付けると運用しやすくなります。
購入イベントなら、注文を確定するバックエンドでIDを作り、注文レコードに保存したうえでCAPIへ送ります。ブラウザの完了画面でも同じIDを受け取り、Pixelへ渡します。フォーム送信のようにブラウザ操作から始まる場合は、送信前にIDを作り、フォームAPIのrequestとPixelの両方へ渡します。どちらの方式でも、ブラウザとサーバーが別々にcrypto.randomUUID()を呼ぶ構成にはしません。
// 顧客行動ごとに一度だけ作る
const eventId = crypto.randomUUID();
// ブラウザのMetaピクセル
fbq('track', 'Lead', {}, { eventID: eventId });
// 同じrequestで自社サーバーへ引き渡す
await fetch('/api/leads', {
method: 'POST',
headers: { 'Content-Type': 'application/json' },
body: JSON.stringify({ eventId, formData })
});サーバーでは受け取ったeventIdを検証し、リードや注文のレコードへ保存してから、CAPIのevent_idへ設定します。送信に失敗したときは、ジョブを作り直して新しいIDを採番するのではなく、保存済みレコードから同じIDと元のevent_timeを読み出します。送信処理のattempt IDやキューメッセージIDは監視には使えますが、顧客行動を識別するevent_idとは分けます。
| 方式 | 適する場面 | 設計 | 避けること |
|---|---|---|---|
| ブラウザ起点 | 問い合わせ、資料請求、会員登録 | 画面操作時に1回発行し、Pixelと自社APIへ同じ値を渡す | Pixel送信後にサーバーが別IDを作る |
| サーバー起点 | 注文確定、審査完了、契約成立 | 業務レコード確定時に発行・保存し、CAPIと完了画面へ配る | 注文番号が未確定の段階で推測値を使う |
| タグ管理基盤起点 | GTMなどでブラウザ・サーバー計測を統合 | data layerの同じイベントに一つのIDを載せ、両タグが参照する | コンテナごとに自動生成へ任せ、値を突き合わせない |
| 非同期業務起点 | 後日の商談化、オフライン成果、定期更新 | 実際の業務イベントに新IDを発行し、元のWebイベントとは別の行動として扱う | 数日後の別成果へ最初のLead IDを流用する |
event IDをURL queryやdata layerへ載せる場合も、個人情報や秘密情報を含めません。公開画面から見える値であっても単体で顧客を特定できないようにし、ログ保持期間とアクセス権を決めます。サイト上の計測タグを棚卸しする方法は、企業サイトの外部スクリプト管理で確認できます。
7段階で実装し、再送でも同じIDを維持する
実装はPixelコードとCAPI送信処理だけを同時に書き換えるのではなく、イベント定義、IDの正本、保存、テスト、監視まで段階化します。重複排除の成否は、Metaへ送れた件数ではなく、一つの顧客行動に一つのevent_idを発行し、ブラウザとサーバーで同じ値を保てたかで決まります。
- 対象イベントを決める：まずPurchase、Lead、CompleteRegistrationなど、ブラウザとサーバーの両方から送るイベントだけを一覧化します。イベント名、発生条件、金額・通貨、送信責任者を固定します。
- IDの正本を決める：フォームrequest、注文、会員登録、予約など、実際の顧客行動を表すレコードを正本にします。ブラウザ・サーバー・キューごとに別のID生成器を置きません。
- 発生点でIDを一度だけ作る：UUIDなどの一意な値を作り、業務レコードへ保存します。Purchaseでは既存の注文IDを使える場合もありますが、再注文・テスト環境・複数店舗で衝突しないnamespaceを確認します。
- 二つの送信経路へ同じ値を配る：Pixelの
eventIDとCAPIのevent_idへ完全に同じ文字列を渡します。イベント名も同じにし、Leadとleadのような揺れを許しません。 - Test Eventsで受信を確認する：Metaのテストイベント機能を使い、ブラウザとサーバーの両方が同じイベント名・IDで届くかを確認します。テスト用コードやデバッグ設定を本番ジョブへ残しません。
- 本番の低リスクイベントで確認する：テスト機能だけで完了せず、自社台帳の1件、ブラウザ送信、サーバー送信、Meta Events Managerの表示を時刻とIDで突き合わせます。広告管理画面の集計値だけで判定しません。
- 再送と監視を固定する：HTTP timeoutや一時的なAPIエラーでは同じ
event_idと元のevent_timeを使います。新しい顧客行動だけ新しいIDにし、重複・欠損・遅延を継続監視します。
再送時に同じIDを使うには、CAPI送信をその場限りのHTTP処理にしないことが重要です。イベント台帳にevent_id、event_name、event_time、業務レコードID、browser送信状態、server送信状態、attempt回数、最後のresponse、完了状態を保存します。API tokenや利用者の生データは通常ログへ出さず、必要な監査情報だけを残します。
同じevent_idを永続的な利用者IDとして使い回してはいけません。1人の利用者が資料請求を2回行えば、それぞれ別の顧客行動です。逆に、1回の資料請求をCAPIで3回retryしても顧客行動は1回なので、3回とも同じIDです。この区別を台帳とキューの設計に反映します。
Events Managerと自社台帳を照合して不一致を切り分ける
確認は「イベントが見えた」だけで終えません。Meta Events Managerでは対象データセットまたはピクセルを選び、Test Events、Overview、Diagnosticsなどでブラウザ・サーバーの受信、警告、イベント一致品質を確認します。画面名称や配置は更新されることがあるため、表示された接続方法とイベント詳細を基準に見てください。
| 症状 | 考えられる原因 | 最初に確認する値 | 対応 |
|---|---|---|---|
| ブラウザとサーバーが別々に計上される | IDまたはイベント名が不一致 | eventID、event_id、event_nameの生値 | 同じ顧客行動の台帳から両payloadを再現し、文字列を揃える |
| サーバーイベントだけ届かない | token、dataset ID、必須項目、API error | HTTP status、response、action_source、event_time | MetaのAPI応答を保存し、同じIDで安全に再送する |
| ブラウザイベントだけ届かない | Pixel未発火、同意状態、タグ条件、ブラウザ制限 | data layer、Pixel Helper、network、同意状態 | タグ発火条件とID引き渡し順を確認する |
| 重複は減ったが一致品質が低い | 利用者情報の不足・正規化不備 | user_data、fbp、fbc、ハッシュ前の正規化 | 同意とMeta仕様の範囲で必要な情報を整える |
| 一部だけIDが空になる | 非同期処理、画面遷移、タグ順序、例外経路 | 顧客行動レコード、request body、キューメッセージ | IDを送信直前ではなく発生点で保存し、必須検証を入れる |
| retry後に件数が増える | 再送ごとに新IDを採番 | attempt IDとevent IDの対応表 | 送信ジョブを業務レコードへ紐付け、保存済みIDを再利用する |
監視では、Metaへ送ったrequest数と広告管理画面の成果数を単純比較しません。ブラウザ送信数、サーバー送信数、両経路が揃った顧客行動数、片側だけの顧客行動数、API error数、再送数、ID欠損数、自社の実成果数を分けます。GA4側のイベント名を同時に変更する場合は、GA4イベント名の変更管理のように旧名・新名・移行期間を記録し、Metaの修正と混ぜない方が原因を特定しやすくなります。
重複排除が成功しても、広告の増分効果まで証明できるわけではありません。計測基盤が整った後は、必要に応じてBtoBマーケティングのホールドアウトテストのような対照設計で、広告がなかった場合との差を評価します。イベント送信の品質と施策の因果効果を分けて判断してください。
実装確認に使うMeta公式資料
- Meta Business Help Center：About Conversions API：CAPIとピクセルの併用、イベント一致品質、プライバシー上の前提を確認できます。
- Meta for Developers：Deduplicate Pixel and Server Events：ブラウザ・サーバーイベントで
event_nameとevent_idを揃える条件を確認できます。 - Meta for Developers：Server Event Parameters：
event_name、event_time、event_id、action_source、user_dataの仕様を確認できます。 - Meta for Developers：Using the API：CAPI requestとTest Eventsの手順を確認できます。
- Meta Help Center：Set up and install the Meta pixel：Events Managerでデータセット、ピクセル、CAPIを設定する現在の導線を確認できます。
よくある質問
MetaピクセルとCAPIは何を条件に重複排除されますか？
同じ顧客行動について、ブラウザとサーバーのevent_nameを一致させ、ブラウザのeventIDとサーバーのevent_idへ同じ一意な値を送ります。イベント名またはIDが異なれば、二つの経路は同じ行動として結びつきません。
event_idはどこで生成しますか？
注文、フォーム送信、会員登録など、顧客行動が確定する発生点で一度だけ生成します。ブラウザ起点ならPixelと自社APIへ同じ値を渡し、サーバー起点なら業務レコードへ保存してCAPIと完了画面へ配ります。
注文番号をevent_idに使えますか？
一つの注文を一意に識別し、ブラウザとサーバーの両方で同じ値を参照できるなら候補になります。ただし、環境、店舗、再注文、注文番号の再利用で衝突しないようnamespaceを確認し、個人情報や推測しやすい機密情報は含めません。
サーバー送信をretryするときevent_idは変えますか？
変えません。同じ顧客行動の送信再試行では、保存済みのevent_idと元のevent_timeを再利用します。attempt IDは別に採番し、送信回数と顧客行動の識別を分離します。
イベント一致品質が高ければ重複排除も成功していますか？
別の指標です。イベント一致品質は利用者情報による照合のしやすさ、重複排除は同一行動のイベント名とIDの一致を扱います。両方を個別に確認してください。
Events Managerでは何を確認しますか？
Test Eventsでブラウザ・サーバーの両経路、イベント名、IDを確認し、OverviewやDiagnosticsで受信状況と警告を見ます。自社台帳の顧客行動ID、送信時刻、API responseとも照合し、画面上の総件数だけで判断しません。
まとめ
MetaピクセルとCAPIの重複排除では、同じ顧客行動のevent_nameとevent_idを二つの経路で揃えます。IDは送信処理ではなく顧客行動の発生点で一度だけ作り、業務レコードへ保存し、PixelのeventIDとCAPIのevent_idへ配ります。
再送では同じIDと発生時刻を維持し、新しい顧客行動だけ新しいIDにします。Test Events、Events Manager、自社台帳、API responseを突き合わせ、重複排除とイベント一致品質を別々に確認してください。件数が合ったかではなく、一つの行動を二つの送信経路で同じ識別子へ結び付けられたかを運用の完了条件にすることが重要です。
