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

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

重複除外が機能しているかは、設定画面ではなく、Metaに届いた購入イベントの数で確認します。購入イベントの数をストアの注文数で割った倍率を月ごとに算出し、問題のない期間の倍率（この記事では「通常の水準」と呼びます）から上昇したまま戻らない月を探します。その月を日別に分け、倍率が切り替わった日に行ったサイトやタグの変更を確認します。

コンバージョンAPIの二重計上と重複除外とは：導入後に広告マネージャの購入の数だけが増える理由

同じ購入がピクセルとコンバージョンAPIの両方から届き、2つのイベントが同じ購入であることを示す値（購入ごとの識別値とイベント名）がそろっていないため、Metaが2件として数えています。

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

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

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

開発者ドキュメントが推奨するのは、購入ごとの識別値（イベントID）とイベント名を、ピクセルとコンバージョンAPIで一致させる方法です。運用担当者が確認するのは、両方に同じ値が入っているかという1点です。値を入れる項目の名前は、ピクセルとコンバージョンAPIで異なります。同じ識別値（event_id）のイベントが重複として除かれるのは、最初のイベントを受け取ってから48時間以内に届いたものだけです。

識別値には、注文番号など購入ごとに一意の値を、ピクセルとコンバージョンAPIの両方に同じ値で入れます。イベント名は、購入の場合は両方とも Purchase にします。

• 識別値：ピクセルでは eventID、コンバージョンAPIでは event_id という項目に入れる
• イベント名：ピクセルでは event、コンバージョンAPIでは event_name という項目に入れる

もう1つは、イベント名と fbp、または external_id で照合する方法です。この方法は、原則として、ブラウザのイベントが先に届き、サーバーのイベントが後から届く場合にだけ機能します。

二重計上が起きやすい場面：サイトの改修、カートシステムの入れ替え、タグの追加

二重計上の原因になるのは、識別値が欠けている場合、ピクセルとコンバージョンAPIで識別値が異なる場合、イベント名がそろっていない場合です。Metaの公式の資料に二重計上が起きる場面の一覧はありませんが、仕組みから考えると、次の変更のあとは確認が必要です。ヘルプも、よくある問題として、event_id の不一致または欠落、パラメーター名や値の誤りを挙げています。

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

購入イベントの倍率とは：重複除外を設定済みでも、購入の数を注文数と照合する理由

イベントマネージャの購入イベントの数を、ストアの注文数で割った倍率で確認します。重複除外を導入したあとにサイトを改修すると、ピクセルとコンバージョンAPIの片方の値だけが変わることがあり、画面上で重複除外が有効になっていることと、実際に重複が除かれていることは一致しないためです。

倍率は、注文1件に対して購入イベントがいくつ届いているかを示します。重複除外が機能していれば1倍に近い値になります。ストアの注文の中に、Metaに送っていない注文（電話注文や手入力の注文など）や、ブラウザとサーバーのどちらからも送信できなかった注文がある分だけ、やや下回ることが多くなります。明らかに超えた状態が続く場合は、同じ購入が2回届いている疑いがあります。月単位で比べるのは、1日単位ではセールや配送の都合で値が変動しやすく、1年単位では変化の時期が分からないためです。Metaのヘルプも、重複除外の問題のトラブルシューティングとして、イベント数の予期しない急増や減少がないかを確認するよう案内しています。

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

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

送り元（ブラウザ／サーバー）ごとに分けて、どちらから増えたかを確認する

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

二重計上はいつ始まったか：ある月から購入の数が増えたまま戻らない理由

倍率が通常の水準から上昇したまま戻らない月の途中に、二重計上が始まった日があります。その月を日別に分けて倍率が切り替わった日を特定し、その日に行った変更と照合します。

通常の水準は、改修前など問題がないと分かっている期間の倍率の幅で決めます。倍率が上昇した月があっても翌月に戻る場合は、二重計上よりも、セール月のキャンセルの多さや、月末の注文が翌月に数えられたことなどを先に疑います。二重計上は設定が変わらない限り続くため、2か月以上同じ水準が続くかを判断の目安にします。

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

次のグラフはF社の2025年10月〜2026年9月の月別の倍率、表は同じ12か月のストアの注文数・購入イベントの数・倍率です（診断サンプルの架空の会社F社の例）。

改修前の7か月は、注文12,734件に対して購入イベントが11,955件で、倍率は0.94倍です。改修のあった5月は1.29倍で、6〜9月の4か月は1.46〜1.50倍が続いています。原因は、ブラウザとサーバーから送る購入イベントの識別値が一致しなくなったことです。

5月の倍率が1.29倍になったのは、月の途中から二重計上が始まったためです。仮に5月の毎日の注文数が同じだったとすると、1〜11日が0.94倍、12〜31日が1.48倍で、月の倍率は約1.29倍になり、表の値と一致します（日ごとの注文数を同じとした、説明用の計算です）。月の倍率が改修前と改修後の中間の値になっている場合は、その月の途中に境目の日があると考えられます。特定した日は、サイトの改修、カートシステムの変更、タグの追加の記録と照合します。

二重計上はROASを実際より高く表示させ、成果の悪化を見落とす原因になる

二重に届いた購入は、購入の件数だけでなく金額にも加算されるため、広告マネージャのROASは実際より高く表示されます。F社の例では、改修後の広告マネージャのROASは上昇していますが、二重分を除くと低下しています。

F社の例：広告マネージャのROAS 3.21は、二重分を除くと2.02

診断サンプルの架空の会社（F社）の例です。12か月の購入は、広告マネージャ（広告にアトリビューションされた購入）では9,945件、二重分を除くと8,306件です。12か月を通したROASは、広告マネージャの2.79に対して、二重分を除くと2.33です。改修後（5月12日以降）の広告マネージャのROASは3.21で、12か月を通したROASより高く表示されますが、二重分を除くと2.02で、12か月を通したROAS（2.33）を下回ります。二重分を除いたROASは、二重に届いた購入の件数と金額を除いて計算した値です。

改修前の4月から改修後の9月にかけて、ストアの注文数は1,778件から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に送っている範囲にそろえてから倍率を出し直します。5は、比べるストアの注文数に、追加したストアやアプリの注文を含めるか、データセットを分けるかを決めます。action_source（イベントが発生した場所）を指定して送っている場合は、ウェブサイト以外の購入が混ざっていないかも確認します。

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

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

1. 購入1件ごとに一意の値（注文番号など）を決め、ピクセルの eventID とコンバージョンAPIの 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が実際より高く表示され、成果の悪化を見落とすおそれがあるため、判断は二重分を除いた数字で行います。倍率が上昇した場合は、まず同じ注文が2件届いているかを確認し、届いていなければ、キャンセル・テスト注文・定期便の更新・月またぎ・別のストアやアプリの追加という別の理由を切り分けます。修正したあとは、テスト注文と翌月の倍率で確認し、修正前の期間の数字を算出し直してから判断に使ってください。

この記事のポイント

• ピクセルとコンバージョンAPIを併用する場合は、ピクセルの eventID とコンバージョンAPIの event_id に同じ値を入れ、イベント名もそろえて重複除外を設定する（重複として除かれるのは48時間以内に届いたものだけ）。
• 重複除外が機能しているかは、イベントマネージャの購入イベントの数をストアの注文数で割った倍率を月ごとに算出し、推移を確認する。
• 倍率が通常の水準から上昇し、2か月以上戻らない場合は、日別に分けて境目の日を特定し、その日のサイトの改修やタグの変更を確認する。
• 二重計上があると、広告マネージャのROASが実際より高く表示され、成果の悪化を見落とすことがある（診断サンプルの架空の会社F社では、改修後に3.21と表示されたROASが、二重分を除くと2.02）。
• キャンセル・テスト注文・定期便の更新・月またぎ（送るタイミングのずれ）・別のストアやアプリの追加でも倍率は上昇するため、同じ注文が2件届いているかを確認してから判断する。