Meta ピクセルと CAPI の二重計上を検証する 6 手順 — event_id・発火順序・ゲートウェイの落とし穴と 5 つの例外

二重計上はどこで起きているのか

経営側が押さえる点は 3 つに絞れる。管理画面の設定確認だけでは重複排除が効いているかは分からないこと、判定は広告側の受信件数と自社側の実件数の突合でしか下せないこと、未確認の項目を明記していない件数は暫定値として扱うこと。実装の詳細は担当者向けに手順 2〜5 に置いた。

重複排除（同じ行動を 1 件にまとめる処理）の成立条件は公式仕様で明示されている。方式は 2 つあり、推奨は event_id とイベント名を両経路でそろえる方式である。ピクセル側の eventID とサーバー側の event_id、ピクセル側の event とサーバー側の event_name が一致し、同一のピクセル ID に対して 48 時間以内に届いたとき、後から来たイベントが破棄される。もう 1 つの方式は fbp または外部 ID とイベント名の組み合わせで照合する^[1]が、ブラウザ → サーバーの順で届いたときにしか働かない。本稿で「3 条件」と書くときは推奨方式の条件を指す。公式ドキュメントは、この重複排除がブラウザとサーバーという異なる経路の間で働くものであり、単一の経路（ブラウザのみ、サーバーのみ）では働かないと記している。

実装側の観察は、リード獲得型サイト 1 件の検証にもとづく。出典は匿名化した支援案件の実装ログで、観測主体は当社、観測範囲は当該サイトのタグ管理ツールの公開バージョンとブラウザの通信ログ、観測期間は数週間。案件が特定されないよう、業種・規模・時期・件数の実額は抽象化している。以下では、公式仕様で言えることと当該サイトでの観察を文中で区別して書く。観察は一般則ではない。

手順 1 — どのイベントがどの経路から何本出ているかを先に数える

最初にやるのは推論ではなく棚卸しである。ブラウザ側は開発者ツールの通信タブで計測リクエストを絞り込み、1 ページの読み込みで何本出ているかを実測する。サーバー側は Events Manager のイベント一覧で、同名イベントの受信件数とサーバー表示の有無を見る。

このとき、ページ上で初期化されているピクセルの数を必ず数える。1 つのドメインに複数の出稿主のタグが同居しているサイトでは、1 ページで複数のピクセルが初期化され、そのすべてに同じイベントが配られていることがある。複数の出稿主のタグが同居する構成では、初期化されるピクセルのすべてが自社の管理下にあるとは限らない。

手順 2 — テストイベントで event_id とイベント名の一致を確認する

Events Manager のテストイベント機能を使うと、両経路のイベントを 1 画面に並べられる。確認するのは 3 点である。同じ行動から両経路のイベントが出ているか、イベント名が文字列として同一か、event_id が同一の値か。

event_id はピクセル側では fbq 呼び出しの引数として渡す。頻出する事故が引数の位置ずれで、カスタムパラメータを省略すると、ID の指定がカスタムパラメータとして解釈され値が届かない。

// 誤り: eventID がカスタムパラメータとして解釈される
fbq("trackSingle", "PIXEL_ID", "Lead", { eventID: "abc123" });
 
// 正しい: カスタムパラメータが空でも {} で埋める
fbq("trackSingle", "PIXEL_ID", "Lead", {}, { eventID: "abc123" });

ブラウザ側とサーバー側でそれぞれ ID を生成する構成は、いずれずれる。受け付けたリードや注文といった業務イベントごとに安定した識別子を 1 つ発行し（再送や二重クリックでも同じ値を使い回す）、両経路がその値を読む形にしておけば、以後の検証は「同じ値が両方に載っているか」の確認だけで済む。

手順 3 — 発火順序を疑う：初期化前のイベントが消えていないか

検証したサイトの通信ログでは、初期化前に呼ばれたイベントは送信されず、エラーも警告も出なかった（タグ管理ツールで初期化とイベント送信を別タグに分けた構成での観察。公式ピクセルの読み込み方法やタグの種類によって挙動は変わりうるため、公開仕様として保証された動作ではない）。タグ管理ツールにはページ読み込み開始時点で発火するトリガーと HTML の解析完了時点で発火するトリガーがあり、前者が先に動く。初期化タグを後者に、イベントタグを前者に置いた構成は、タグの順序付けを設定していなければ通常はイベントが先行する^[2]。

検証したサイトではこの順序のまま運用されているイベントが実在し、該当イベントはブラウザ側でもサーバー側でも受信件数がゼロだった。検証した Web イベント連携型のゲートウェイ構成では、サーバー送信はブラウザの発火をもとに生成されるため、ブラウザで出ていないものはサーバーにも現れなかった（構成やバージョンが違えば挙動は変わりうる）。「サーバー計測を入れれば取りこぼしが埋まる」という期待が成立しない種類の欠落である。

順序を直すときは注意が要る。順序だけを修正すると、それまで消えていたイベントが初期化済みの全ピクセルに配られるようになり、今度は宛先の広がりが問題になる。順序の修正は、宛先を 1 つに限定する送信方式への変更か、発火条件の限定とセットで入れる。

手順 4 — ブロードキャストと単一ピクセル送信の混在を数える

Meta ピクセルには、ページ上の全ピクセルへ配る送信方式と、指定した 1 つのピクセルにだけ送る方式（trackSingle）がある。ここに温床がある。検証時の実装で観測された挙動として、ページビューは同一ピクセルへの重複が抑止されていたが、それ以外のイベントには同様の抑止が見られず、単一ピクセル送信はこの抑止の対象外だった。いずれも公式仕様として保証された動作ではなく、ライブラリの版が変われば変わりうる。

検証したサイトでは「一部のタグだけを単一ピクセル送信に書き換える」改修案が出ていた。通信ログを確認した結果、当該サイトの構成では減少数を説明できず、発火順序によっては件数が増える側に倒れると判断して採用しなかった。他の構成では未検証である。送信本数を数える手順を挟んでいなければ、良かれと思った変更で件数が増える側に倒れていた。

手順 5 — ゲートウェイ経由とサーバーサイドタグ経由で何が変わるか

サーバー送信の実装は大きく 2 通りある。ブラウザの発火を写し取って同時に送るゲートウェイ方式と、ブラウザからサーバー側のコンテナへ送りそこから API を呼ぶサーバーサイドタグ方式である。確認すべき点が異なる。以下は本稿で検証した Web イベント連携型の構成での観察で、ゲートウェイの構成・バージョン・イベントソースが違えば確認事項は変わる。

見落としやすいのは、ゲートウェイの接続はピクセル単位であり、必ずしも自社が接続したものとは限らないという点である。検証では、観測されたパラメータからサイト側の共通設定が原因だと推定したが、設定を実測するとその経路は存在せず、ピクセルの所有者側の接続だったため推定を撤回した。観測されたパラメータからサイト側の構成を推論すると、この種の誤りが起きる。

移行期に両方式を並行させる場合は、event_id の生成元が移行の前後で同一であることを先に確認する。生成元が変わると同じ行動に別の ID が付き、重複排除の条件から外れる。

手順 6 — 受信件数と実件数を突き合わせる

最後は件数の突合である。広告側の受信件数（Events Manager に届いたイベント数。広告管理画面のアトリビューション済みコンバージョンではない）と、自社側の実件数（フォーム送信の記録や顧客管理システムの登録数）を、同じ期間・同じ定義で並べる。タイムゾーン、テスト送信、同意拒否、再送、無効リードは調整項目として先に列挙しておく。ここで初めて多いのか少ないのかが判定できる。

倍数にならない差が出たときは、イベント名ごとに分けて同じ表を作る。全体では説明できなくても、イベント単位では「片方の経路にしか ID が載っていない」といった単純な原因に行き着くことが多い。

重複排除が効かない 5 つの例外

手順を通しても残るのが、仕様上そもそも排除の対象にならないケースである。

次に読む診断チェック — 二重計上を報告する前に 7 項目を確認する

広告側の件数に違和感を持ったとき、次の 7 項目を上から確認すると、切り分けの大半は着手当日に終わる。

1. イベント名ごとに、ブラウザ側とサーバー側の送信有無と本数を表にしたか。
2. 1 ページで初期化されているピクセル数を数え、自社管理外のピクセルを把握したか。
3. テストイベントで、両経路の event_id とイベント名が同一の値だと目視で確認したか。
4. event_id の生成元が 1 か所に固定され、両経路が同じ値を読む構成になっているか。
5. 初期化タグとイベントタグの発火タイミングが逆転していないか（件数ゼロのイベントはないか）。
6. 全ピクセルへ配る送信と単一ピクセル送信が、同一ページで混在していないか。
7. 広告側の受信件数と自社側の実件数を、同じ期間・同じ定義で並べたか。

7 項目のうち 1 つでも「確認できない」が残るなら、その数値は暫定として扱い、報告に未確認項目を明記する。mixednuts では、こうした計測設計の検証と実装の是正を マーケティング支援 として提供している。

FAQ

Q. Meta の重複排除はどの条件で成立するのか？ A. 推奨方式では、ピクセル側の eventID とコンバージョン API 側の event_id が一致し、イベント名も一致し、同一のピクセル ID に対して最初の受信から 48 時間以内に届いたときに、後続のイベントが破棄される。もう 1 つの方式は fbp または外部 ID とイベント名で照合するが、ブラウザが先行した場合にしか働かない。

Q. ブラウザから同じイベントを 2 回送った場合は重複排除されるか？ A. ピクセルと API の間の重複排除には依存できない。公式ドキュメントも、単一の経路だけの構成では重複排除が働かないとしている。同じページで複数のタグが同じイベントを撃っているなら、発火条件を限定して送信本数そのものを減らす必要がある。

Q. サーバー計測を追加すれば、ブラウザで取りこぼしていた件数は埋まるか？ A. 実装方式による。ブラウザの発火を写し取るゲートウェイ方式では、ブラウザ側で送信が発生していないイベントはサーバー側にも現れないため埋まらない。まず発火順序と発火条件を直すのが先で、サーバー計測はその後の話になる。

Q. event_id はどこで生成するのがよいか？ A. 1 か所に固定し、ブラウザ側とサーバー側の両方がその値を読む形にする。フォーム送信のタイミングで一意の識別子を発行して両経路に渡しておけば、検証は同じ値が両方に載っているかの確認だけで済む。両経路でそれぞれ生成する構成はいずれずれる。

Q. 一部のタグだけを単一ピクセル送信に書き換えれば重複は減るか？ A. 減るとは限らない。検証したサイトでは、ページビューの重複が抑止されていた一方で単一ピクセル送信はその対象外だったため、部分的な書き換えでは減少数を説明できず、発火順序によっては 2 回送信になる側に倒れた。この挙動は公式仕様として保証されたものではないので、方式はページ単位でそろえ、変更後は必ず送信本数を数え直す。

Q. 移行期にサーバー送信を二重に走らせても問題ないか？ A. 並行送信は原則避ける。公開仕様が保証しているのはピクセルとサーバーの間の重複排除で、サーバー同士の重複排除は立証されていない。やむを得ず並行させる場合は event_id の生成元を移行の前後で同一にし、テストイベントと受信ログで排除された件数を実測で確認しながら、切り戻し手順を先に決めておく。

参考文献 / Sources

重複排除の仕様:

• Meta for Developers^[1]: 重複したピクセルイベントとコンバージョン API イベントの処理 — 2 つの重複排除方式、48 時間の時間窓、eventID の渡し方
• Meta for Developers: コンバージョン API の概要 — 冗長構成（ピクセル + サーバー）の位置づけ
• Meta for Developers: コンバージョン API のパラメーター — event_id / event_name / 顧客情報パラメータの定義

ピクセル実装とゲートウェイ:

• Meta for Developers: Meta ピクセル リファレンス — track / trackSingle の引数仕様
• Meta for Developers: コンバージョン API ゲートウェイの概要 — ゲートウェイ方式の動作とピクセル単位の接続

タグの発火順序とサーバーサイド:

• Google タグマネージャー ヘルプ^[2]: ページビュー トリガー — ページ読み込み開始時点と DOM 解析完了時点の違い
• Google タグマネージャー ヘルプ: タグの順序付け — 発火順を明示的に固定する方法
• Google: サーバーサイド タグ設定の概要 — サーバー側コンテナの構成

関連記事:

• サイトリニューアルの前後比較で誤判定を避ける方法 — like-for-like 比較の設計と 5 つの落とし穴
• 予算ペーシングは「変更履歴」で監査する — 消化率の段差を原因候補に絞る 4 手順