Meta広告のコンバージョンAPIの二重計上は、購入イベントをストアの注文数と照らして見つける

【結論】二重計上は、購入イベントの数をストアの注文数と月ごとに照らして見つける

ピクセルとコンバージョンAPIの重複除外が機能しているかは、設定画面ではなく、届いた数で確認します。イベントマネージャに届いた購入イベントをストアの注文数で割った倍率を月ごとに並べ、ふだんの水準から跳ねた月を探します。

1. イベントマネージャで購入イベントの数を月ごとに出し、同じ月のストアの注文数で割った倍率を並べる。
2. 改修前など問題のない期間の倍率を「ふだんの水準」とし、そこから跳ねて戻らない月があれば、その月から二重に数えている疑いがある。
3. 疑いのある月を日別に分けて境目の日を特定し、その日に行ったサイトやタグの変更を確認する。

設定画面に重複除外の設定があることと、実際に重複が除かれていることは別の事柄です。設定したあとの改修で、片方の値だけが変わることがあるためです。Metaのヘルプも、重複除外の問題のトラブルシューティングとして、イベント数の予期せぬ急増や減少がないかを確認するよう案内しています。

Meta広告のコンバージョンAPIとピクセルを併用すると、なぜ購入が二重になるのか

同じ購入をピクセルからもコンバージョンAPIからも送ると、Metaはその購入を2回受け取ります。2つが同じ購入だとMetaが識別するための値（イベントIDとイベント名など）がそろっていなければ、2件として数えられます。

ピクセルは、Webサイトでの購入などの行動を、ブラウザからMetaへ送る仕組みです。コンバージョンAPIは、ブラウザを通さず、広告主側のサーバーがMetaにイベントを送る仕組みです。Metaのヘルプによると、ピクセルはブラウザの設定や接続の問題でイベントが失われることがあり、サーバーから送るコンバージョンAPIは、ブラウザ側の制限や広告ブロッカーに左右されにくいとされています。開発者ドキュメントでも、広告の成果のために、ピクセルとコンバージョンAPIを併せて導入することが推奨されています。

併用すると、同じ購入がブラウザとサーバーの両方から届きます。そこで必要になるのが重複除外です。重複除外とは、ブラウザ経由とサーバー経由で届いた同じイベントを、レポート上で1回として数える処理のことで、重複排除とも呼ばれます。ヘルプは、重複除外が行われない場合、コンバージョン数が不自然に多くなり、最適化や予算配分の判断を誤るおそれがあるとしています。

重複除外の方法は2つ：イベントIDとイベント名、またはfbp・external_id

Metaが2つのイベントを同じ購入と判断する方法は2つあります。1つは、イベントIDとイベント名を一致させる方法です。ピクセルの eventID とコンバージョンAPIの event_id に同じ値を入れ、ピクセルの event とコンバージョンAPIの event_name を同じ名前（購入なら Purchase）にそろえます。開発者ドキュメントはこちらを推奨しています。もう1つは、イベント名と fbp、または external_id で照らす方法です。開発者ドキュメントによると、この方法は原則として、ブラウザのイベントが先に届き、サーバーのイベントが後から届く場合にだけ機能します。

同じ event_id のイベントが重複として除かれるのは、最初のイベントを受け取ってから48時間以内に届いたものだけです。また日本語のヘルプでは、重複除外の対象として、ピクセルとサーバーの間の重複に加えて、同じ送り元から複数回送られた重複（ピクセルならイベント名とeventID、サーバーならevent_nameとevent_idが同一のもの）も挙げています。つまり二重計上の原因になるのは、event_id が欠けている、送り元ごとに違う値になっている、イベント名がそろっていない、といった場合です。

二重になりやすい場面：サイトの改修、カートの入れ替え、タグの追加

Metaの公式の資料に「この場面で二重になる」という一覧はありません。ただ、仕組みから考えると、次の変更のあとは確認する価値があります。

• サイトの改修で、ピクセルの購入イベントに eventID を渡すコードが消えた
• カートシステムの入れ替えで、サーバー側の event_id の作り方が変わった（注文番号から別の番号へ、など）
• イベント名が、ブラウザとサーバーで別の名前になった
• eventID を持たない購入のタグが、既存のタグとは別に追加された

ヘルプも、よくある問題として、event_id の不一致または欠落、パラメーター名や値の誤りを挙げています。

イベントマネージャの購入イベントを、ストアの注文数と照らす手順

比べるのは、イベントマネージャに届いた購入イベントの数と、ストアの管理画面の注文数です。月ごとに倍率を出し、送り元（ブラウザ／サーバー）ごとの内訳も並べます。

1. イベントマネージャでデータセット（ピクセル）を開き、［概要］で購入イベントの数を月ごとに出す。
2. ストアの管理画面から、同じ月の注文数を出す。キャンセルやテスト注文を含めるかどうかは、Meta側の送り方とそろえる。
3. 購入イベント÷注文数を、月ごとに並べる。
4. 送り元（ブラウザ／サーバー）ごとの購入イベントの数も並べ、どちらから増えたかを見る。

開発者ドキュメントによると、［概要］では、重複除外の前に受け取ったイベントの数と、処理されたイベントの数が分かれて表示され、イベントがどの経路で送られたか（Connection Method）も確認できます。比べるのは処理されたあとの数です。日本語の画面での項目名は、管理画面で確認してください。送ったイベントは送信から20分ほどで確認できるとされているため、テスト注文での確認にも使えます。

比べるのはイベントマネージャの購入イベントで、広告マネージャの購入ではない

広告マネージャの「購入」とイベントマネージャの購入イベントは、もともと数が一致しません。Metaのヘルプによると、イベントマネージャは受け取ったほとんどのイベントを表示するのに対し、広告マネージャは広告の結果としてアトリビューションされたものだけを表示するため、広告マネージャの数のほうが少なくなります。広告と関係なく起きた購入も含めて数えているのはイベントマネージャなので、ストアの注文数と比べる相手はイベントマネージャの数です。何を成果として数えているかを先にそろえる考え方は、Google広告の主要・副次の設定と同じです（関連：コンバージョンの主要と副次）。

倍率＝購入イベント÷ストアの注文数を、月ごとに並べる

倍率は、注文1件に対して購入イベントがいくつ届いているかを示します。重複除外が機能していれば1倍に近く、ブラウザで届かない購入がある分だけ、1倍をやや下回ることが多くなります。前述のとおり、ピクセルはブラウザの設定や接続の問題でイベントが失われることがあるためです。1倍をはっきり超え、その状態が続くなら、同じ購入が2回届いている疑いがあります。月ごとに並べるのは、1日単位ではセールや配送の都合で値が揺れやすく、1年単位では変化の時期が見えないためです。

接続方法（ブラウザ／サーバー）ごとに分けて、どちらから増えたかを見る

倍率が上がったときは、ブラウザから届いた数とサーバーから届いた数を分けて見ます。ある月から片方の数が上乗せされる形で増え、もう片方の数は変わっていなければ、両方から届いた同じ購入が重複として除かれていない可能性が高くなります。どちらの経路で増えたかが分かれば、修正するコードの場所も絞り込めます。

倍率が跳ねた月から、いつ二重になったかを特定する

問題のない期間の倍率の幅を「ふだんの水準」と決め、そこから跳ねて戻らない月を探します。見つけた月は日別に分け、倍率が切り替わった日と、その日に行った変更を照らします。

ふだんの水準は、改修前など問題がないと分かっている期間の倍率を並べ、その幅で決めます。そこから跳ねた月があっても、翌月に戻るなら、次の章で挙げる別の理由を先に疑います。跳ねたまま戻らない月を見つけたら、その月の購入イベントと注文数を日別に分け、倍率が切り替わった日を特定します。特定した日は、サイトの改修、カートシステムの変更、タグの追加の記録と照らします。イベントマネージャの［履歴］では、ピクセルやコンバージョンAPIに加えられた変更の内容、変更日時、変更した人を確認できます。

開発者ドキュメントによると、イベントマネージャには、送り元ごとに重複除外されたイベントの割合や、重複除外に使う値（キー）を含むイベントの割合を示す画面もあり、割合が低いと警告が表示されます。日本語の画面での項目名は、管理画面で確認してください。

F社の例：5月12日の改修から、0.94倍が1.48倍に

診断サンプルの架空の会社（F社）の例です。表は2025年10月〜2026年9月の12か月の、ストアの注文数と、Metaに届いた購入イベントの数です。

改修前の7か月の倍率は0.93〜0.95倍で、合計では注文12,734件に対して購入イベント11,955件（0.94倍）でした。改修のあった5月は1.29倍、6〜9月は1.46〜1.50倍です。原因は、ブラウザとサーバーの購入で event_id がそろわなくなったことでした。

5月の1.29倍は、月の途中から二重になったためです。仮に5月の毎日の注文数が同じだったとすると、1〜11日が0.94倍、12〜31日が1.48倍で、月の倍率は約1.29倍になり、表の値と一致します（日ごとの注文数を同じとした、説明用の計算です）。このように、月の倍率が改修前と改修後の中間の値になっている月は、その月の途中に境目の日があると考えられます。

1か月だけの跳ねは、2か月以上続くかで判断する

倍率が1か月だけ跳ねて翌月に戻った場合は、二重計上よりも、セール月のキャンセルの多さや、月末の注文が翌月に数えられたことなどを先に疑います。二重計上は設定が変わらない限り続くため、2か月以上同じ水準が続くかを判断の目安にします。F社でも、6〜9月の4か月にわたって1.46〜1.50倍が続いていました（診断サンプルの架空の会社（F社）の例です）。

二重計上はROASを高く見せ、実際の悪化を隠す

二重に届いた購入は、購入の件数だけでなく購入の金額にも加わるため、管理画面のROASは実際より高く出ます。F社の例では、改修後にROASが上がって見えた一方、二重分を除くと下がっていました。

F社の例：管理画面のROAS 3.21は、二重分を除くと2.02

診断サンプルの架空の会社（F社）の例です。12か月の購入は、管理画面では9,945件、二重分を除くと8,306件でした。ROASは管理画面の2.79に対して、二重分を除くと2.33です。改修後の期間だけを見ると、管理画面のROASは3.21で、12か月の平均より高く見えていました。ところが二重分を除くと2.02で、12か月の平均（2.33）を下回っています。

同じ期間に、ストアの注文数は4月の1,778件から9月の1,310件へ減っていました（診断サンプルの架空の会社（F社）の例です）。管理画面だけを見ていると成果が上がっているように見える時期に、実際の注文は減っていたことになります。二重計上は数字を少し多めに見せるだけでなく、実際の悪化を逆の向きに見せることがあります。

判断に使う数字は、二重分を除いて引き直してから

損益分岐のROASとの比較も、二重分を除いた数字で行います。F社は粗利率を65%と仮定しており、損益分岐のROASは1÷0.65で約1.54です（診断サンプルの架空の会社（F社）の例です）。キャンペーン別・配置別の比較や、新規顧客と既存顧客の比較も同じです。Advantage+ セールスキャンペーンの既存顧客の割合（関連：Advantage+ セールスキャンペーンの既存顧客は何割か）や、Audience Networkの配置別の成果（関連：Audience Networkは外すべきか）の記事の数字も、二重分を除いた購入で計算しています。

また開発者ドキュメントによると、サーバーのイベントはピクセルのイベントと同様に処理され、計測・レポート・最適化に使われることがあります。二重に届いた購入が配信の最適化にどの程度影響したかは、アカウントの外からは切り分けられません。影響を評価するには、修正後の期間の購入単価とROASを、修正前の引き直した数字と、同じ長さの期間で比べる必要があります。

倍率が上がっても二重計上とは限らない場合

倍率が1倍を超えても、二重計上ではないことがあります。判断する前に、同じ注文が2件届いているかを確認し、届いていなければ次の5つの理由を切り分けます。

1. キャンセル・返品：ストアの注文数からキャンセルや返品を引いている一方、Metaに届いた購入イベントは注文した時点の数のまま。
2. テスト注文：ストアでは除外しているが、Metaには購入として届いている。
3. 定期便などの更新の購入：サーバーから購入として送っているが、ストアの「新規の注文」の数には入っていない。
4. 送るタイミング：コンバージョンAPIの event_time（イベントが起きた時刻）は、送信の7日前まで指定できる。ストアの集計日（注文日・出荷日など）と、Metaに送る event_time の基準がずれていると、月末の注文が別の月に数えられる。
5. 送り元の追加：別のストアやアプリの購入を、同じデータセットに送り始めた。

1〜4は、ストアの数とMetaの数で「何を購入として数えるか」がそろっていないことが原因です。この場合に修正するのは計測の設定ではなく、比べ方です。ストア側の数を、Metaに送っている範囲にそろえてから倍率を出し直します。action_source（イベントが起きた場所）を指定して送っている場合は、ウェブサイト以外の購入が混ざっていないかも確認します。

二重計上を修正する手順と、修正後の確認

修正の中心は、ブラウザとサーバーの購入に同じ event_id とイベント名を入れることです。修正したら、テスト注文で1件として届くかを確認し、翌月に倍率がふだんの水準に戻ったかを確認します。

1. 購入1件ごとに一意の値（注文番号など）を決め、ブラウザからは eventID、サーバーからは event_id として、両方に同じ値を送る。
2. イベント名も両方で一致させる。購入の場合は、ブラウザ側もサーバー側も Purchase で送る。
3. fbp・external_id の方法を使っている場合は、ブラウザのイベントが先に届く構成になっているかを確認する。
4. テスト注文を送り、イベントマネージャの［イベントのテスト］で、購入の受信と重複除外の状況を確認する。
5. 翌月、倍率がふだんの水準に戻ったかを確認する。
6. 修正前の期間の購入とROASは、倍率から二重分を除いた推計に引き直して記録しておく。

Shopify や WooCommerce のようなパートナー連携を使っている場合、ヘルプによると、多くのプラットフォームで重複除外のパラメーターが自動的に処理されます。ただし、サイトの改修で連携とは別に購入のタグを追加した場合は二重になりうるため、倍率の確認は省かないようにします。

ブラウザとサーバーの両方に、同じ注文番号を識別値として渡す

開発者ドキュメントでは、fbq('track', 'Purchase', {…}, {eventID: …}) のように、ピクセルの購入イベントに eventID を渡す書き方が示されています。サーバー側では、同じ購入のイベントの event_id に同じ値を入れます。値は一意である必要があります。注文番号は、ブラウザの購入完了ページでも、サーバーの注文データでも同じ値を参照しやすいため、候補になります。

修正前の期間の数字は、倍率から推計して引き直す

修正前の期間の数字は、二重分を除いた推計に引き直してから判断に使います。二重になっていた期間の購入イベントを、その期間の倍率とふだんの水準の比で割り戻すのが基本の考え方です。F社の改修後の期間なら、1.48÷0.94で、購入イベントが約1.57倍に膨らんでいたと推計できます（診断サンプルの架空の会社（F社）の例です）。引き直した数字は、修正前と修正後を比べるときの基準になります。どの期間を、どの倍率で割り戻したかも一緒に記録しておくと、あとから数字の出どころを説明できます。

TAMKOのMeta広告アカウント診断で確認すること

この記事で挙げた、ストアの注文に対するMetaに届いた購入イベントの倍率、いつから二重になったか、二重分を除いたROASは、TAMKOのMeta広告アカウント診断で最初に確認している項目です。

診断の確認項目には「Metaピクセルとコンバージョン APIの重複排除と、購入の数の正しさ」が含まれます。「判断はすべて、重複を除いた購入の数で行います。重複の解消方法（event_id のそろえ方）もお渡しします。」料金は「診断・報告書・説明会まで無料（毎月2社まで）」です。「エグゼクティブサマリー・調査報告書・分析の明細（Excel）・オンラインの説明会1回をお渡しします。」詳しくは診断ページをご覧ください。

よくある質問（FAQ）

購入の数はストアの注文と照らしてから使う｜まとめ

ピクセルとコンバージョンAPIを併用するときは、重複除外の設定が必要です。購入1件ごとの識別値（eventID・event_id）とイベント名がブラウザとサーバーで一致していなければ、同じ購入が2件として数えられます。設定が機能しているかは、イベントマネージャの購入イベントをストアの注文数で割った倍率を月ごとに並べて確認し、ふだんの水準から跳ねて戻らない月を見つけたら、日別に分けて境目の日とその日の変更を特定します。二重計上は管理画面のROASを高く見せ、実際の悪化を隠すことがあるため、判断は二重分を除いた数字で行います。倍率が上がったときは、キャンセル・テスト注文・定期便の更新・月またぎ・送り元の追加という別の理由を先に切り分けます。修正したあとは、テスト注文と翌月の倍率で確認し、修正前の期間の数字を引き直してから判断に使ってください。

この記事のポイント

• ピクセルとコンバージョンAPIを併用するときは、ピクセルの eventID とコンバージョンAPIの event_id、イベント名をそろえて重複除外を設定する（重複として除かれるのは48時間以内に届いたものだけ）。
• 重複除外が機能しているかは、イベントマネージャの購入イベントの数をストアの注文数で割った倍率を、月ごとに並べて確認する。
• 倍率がふだんの水準から跳ねて2か月以上戻らなければ、日別に分けて境目の日を特定し、その日の改修やタグの変更を確認する。
• 二重計上は管理画面のROASを高く見せ、実際の悪化を隠すことがある（診断サンプルの架空の会社F社では、3.21に見えたROASが二重分を除くと2.02）。
• キャンセル・テスト注文・定期便の更新・月をまたいだ送信でも倍率は上がるので、同じ注文が2件届いているかを確認してから判断する。