MetaピクセルとコンバージョンAPI｜重複計測を防ぐ確認手順

Meta コンバージョンAPIの重複計測を防ぐには、同じユーザー行動をMetaピクセルとサーバーの両方から送る際、event_nameとevent_idをそろえます。ブラウザー側だけ、サーバー側だけにIDを付けても重複排除は成立しません。同一イベントの2経路に、同じ名前と同じIDを渡すことが要点です。

設定後はMetaイベントマネージャのテストイベントで、ブラウザーとサーバーのイベントが届き、同一イベントとして処理されているかを確かめます。ただし、テスト画面に両方が表示されただけでは十分ではありません。IDの生成単位や再送時の扱いまで確認できて、初めて本番の重複を防げます。

配信前の計測を含む設定全体はMeta広告の出し方、配信後に計測・権限・予算を見直す順序は広告アカウント診断チェックリストで確認できます。

以下はMetaの公開情報を2026年8月8日時点で確認した内容です。管理画面の名称や表示位置は更新される可能性があるため、実際の表示と公式案内も併せて確認してください。

MetaピクセルとコンバージョンAPIで重複計測が起きる理由

Metaピクセルはブラウザーからイベントを送り、コンバージョンAPI（CAPI）はサーバー、ウェブサイト基盤、CRMなどからMetaへマーケティングデータを送ります。Metaは、ウェブイベントについてピクセルとCAPIの併用を案内しています。ブラウザーの読み込みエラーや接続状況などの影響を受けにくい経路を加え、計測の接続性を補うためです。詳しい位置づけはMeta公式のコンバージョンAPIについてで確認できます。

一方、1回の購入や送信完了を両方の経路から送れば、Metaには見かけ上2件のイベントが届きます。併用そのものが重複の原因なのではありません。同じ行動だと判定するための識別情報が一致していないことが問題です。

たとえば、購入完了をブラウザーではPurchase、サーバーでは別名のカスタムイベントとして送ると、同じ注文でもイベント名が一致しません。両方をPurchaseにしても、片方のIDが注文単位、もう片方がページ表示のたびに生成される値なら対応しません。イベント数の差を見てから原因を探すより、送信設計を先に1対1で対応させる必要があります。

event_nameとevent_idで重複排除する設計

Meta公式のピクセルとサーバーイベントの重複排除では、ブラウザーイベントとサーバーイベントを重複排除するためにイベント名とイベントIDを用いる方法が示されています。実装上は表記が異なり、ピクセルではeventID、CAPIではevent_idとして同じ値を渡します。

// ブラウザー側の概念例
fbq("track", "Purchase", purchaseData, {
  eventID: conversionId,
});

{
  "event_name": "Purchase",
  "event_id": "同じconversionId"
}

ここで「同じconversionId」は説明用の表記であり、固定文字列を使うという意味ではありません。満たすべき条件は次のとおりです。

• 1回の実イベントに対し、ブラウザーとサーバーで同じIDを使う
• 別の実イベントには別のIDを発行する
• event_nameの大文字・小文字を含め、両経路で同じ名前を使う
• ページの再読み込みやAPI再送が起きても、同じ実イベントならIDを不用意に変えない

つまり、IDは「送信処理の番号」ではなく「計測対象となる行動の番号」として設計します。購入なら、要件を満たす一意な注文識別子を両経路へ受け渡す設計が考えられます。問い合わせ完了のように既存の識別子がない場合は、完了処理の時点で一意なIDを生成し、ピクセル送信とサーバー送信の双方が参照できるようにします。個人情報をそのままIDへ入れる必要はありません。

IDをブラウザーとサーバーのどちらで作るか

生成場所よりも、同じ行動に同じ値を配れる設計かどうかが判断基準です。フォーム送信時にブラウザーで生成してリクエストに含める方法も、サーバーで確定したIDを完了画面へ返す方法もあり得ます。決済の確定をサーバー通知で受ける構成では、ブラウザー表示と売上確定が同義でない場合もあります。何をPurchaseとみなすかを先に決めなければ、IDだけ一致させても計測対象がずれます。

テストイベントで重複排除を確認する手順

実装コードの確認だけでは、タグ管理ツール、プラグイン、決済完了画面などから別のイベントが追加送信されている可能性を除けません。Metaイベントマネージャで対象のデータセット（またはピクセル）を選び、テストイベントを開いて実際の動作を確認します。

1. 対象サイトの通常の操作経路で、検証対象の行動を1回だけ実行する
2. 同じevent_nameのブラウザーイベントとサーバーイベントが届くかを見る
3. 両イベントに設定されたイベントIDが一致するかを見る
4. イベントが重複排除されたことを画面上の処理状況で確認する
5. 別の行動をもう1回実行し、今度は前回とは異なるIDになっているかを見る
6. 再読み込み、二重クリック、サーバー再送など、実環境で起こり得る動作も試す

最初の1回だけ成功しても、固定IDを使い回していれば別のコンバージョンまで同一扱いになるおそれがあります。逆に、再送のたびにIDを作り直せば同じ行動が別イベントとして扱われかねません。「同じ行動では同じ、別の行動では別」という両方向の確認が必要です。

CAPIのテストでは、イベントマネージャに表示されるテストイベントコードをCAPIリクエストのtest_event_codeへ設定する方法があります。テストが終わったら本番送信からテスト用の値を外し、通常イベントの診断も確認します。管理画面上で名称や導線が変わっている場合は、表示中の案内を優先してください。

重複が残るときの切り分け

テストで期待どおりにならない場合は、件数だけでなく受信元とパラメーターを並べます。

• ブラウザーだけ届く：CAPIの送信処理、アクセストークン、送信先ID、API応答を確認する
• サーバーだけ届く：ピクセルの発火条件、同意管理、ブラウザー上のエラーを確認する
• 両方届くが重複排除されない：event_nameとイベントIDの値を両経路で比較する
• 1回の操作で同じ受信元から複数届く：タグ、プラグイン、サイト埋め込みなど発火元の重複を調べる
• 別の操作が同じIDになる：IDの固定値、キャッシュ、生成・保存単位を見直す

この順番なら、通信不達、重複排除の不成立、そもそもの二重発火を混同しません。CAPIリクエストが成功したという応答だけでは、ピクセルとの対応関係までは証明できない点にも注意が必要です。

イベントマッチ品質は重複排除と分けて確認する

イベントマッチ品質は、サーバーイベントに含まれる顧客情報のパラメーターが、Meta上のアカウントとの照合にどの程度役立っているかを確認するための指標です。Meta公式も、CAPIで追加の顧客情報パラメーターを含めることが、マッチしたイベントやイベントマッチ品質の向上に役立つと説明しています。

しかし、イベントマッチ品質が良好でも、ピクセルとCAPIのevent_idが一致しているとは限りません。反対に、重複排除が成立していても、照合に使える顧客情報が不足していることはあります。

• 重複排除：ブラウザーとサーバーから届いたものが同じ実イベントかを判定する
• イベントマッチ品質：サーバーイベントをMeta上のアカウントへ照合する情報の品質を見る

目的が異なるため、一方の表示をもう一方の合格判定には使えません。イベントマネージャでは、イベントごとの品質表示と推奨される顧客情報パラメーターを確認し、利用目的、同意、プライバシー方針に沿って送信項目を判断します。CAPIはプライバシー規制やMetaのポリシーを回避する仕組みではないことも、Meta公式ヘルプに明記されています。

本番公開前後の確認項目

テストイベントが通ったら、実装担当者と広告運用担当者で、少なくとも次を共有しておくと判断がぶれません。

• 各コンバージョンの定義とevent_name
• event_idを生成する場所、保存期間、両経路への受け渡し方法
• ピクセルとCAPIそれぞれの発火条件
• タグ管理ツール、EC基盤、プラグインなどイベントを送る全経路
• 再送、取消、返金、ページ再読み込み時の扱い
• テスト日時、操作、確認したイベントIDと受信元

これらが記録されていれば、数値に差が出たときに仕様変更と障害を切り分けやすくなります。Meta広告の管理画面、受注システム、アクセス解析では集計条件や計上時点が同一とは限らないため、件数が完全一致しないことだけを重複計測の証拠にはできません。

重複計測を防ぐ最終判断

MetaピクセルとコンバージョンAPIの併用で重複計測を防ぐ条件は明確です。同じ行動について、両経路のevent_nameを一致させ、ピクセルのeventIDとCAPIのevent_idへ同じ値を渡します。そのうえで、テストイベントにブラウザーとサーバーの両方が届くこと、重複排除されること、別の行動では別IDになることまで確認します。

成否を分けるのは、IDの生成単位と再送時の扱いです。固定IDの使い回しも、同じ行動へのID再発行も避け、「同じ行動では同じ、別の行動では別」を実装とテストの両方で確かめてください。イベントマッチ品質は、照合情報の品質を見る別の軸です。CAPIが届いているか、重複排除が成立しているか、照合情報が十分かを分ければ、重複計測の有無を取り違えずに判断できます。