← 記事一覧へ

ブログ

コンバージョンが二重に計測される原因と確認方法【重複カウントの直し方】

公開 2026-06-30

コンバージョン 二重計測コンバージョン 重複 カウントコンバージョン 2回 計測されるコンバージョンタグ 重複 原因

「1件の申し込みなのに、コンバージョンが2件・3件とカウントされる」——これも広告運用でよくあるトラブルです。数が多く出ると一見うれしく見えますが、実態より水増しされた数字で入札やレポートを判断すると、費用対効果を見誤り、最適化が狂います。「計測されない」と同じくらい、「二重に計測される」も危険なのです。

こんな症状に心当たりはありませんか？

  • 実際の件数より、コンバージョンが明らかに多い
  • フォーム送信は1回なのに、レポート上は2件ついている
  • ページを更新したり「戻る」を押すたびに件数が増える
  • 売上（value）の合計が、実売上より膨らんでいる

この記事では、コンバージョンが二重に計測される原因と、開発者ツールでの確認方法、そして重複を直す具体策を、実務目線で整理します。

確認の前に：「二重」は発火の段階で起きている

二重計測の切り分けでつまずく原因は、「記録の問題」だと思い込むことです。実際には、ほとんどの重複は②発火の段階で同じイベントが複数回送られていることから起きます。まず「1回の操作で、リクエストが何回飛んでいるか」を見るのが出発点です。

レベル 二重計測の起き方
① 設置 タグが2か所（gtag直貼り＋GTMなど）に入っている
② 発火 1回の操作で同じイベントが複数回送信される（リロード・再訪・SPA遷移など）
③ 記録 カウント設定が「すべて」で、1クリックの複数成立を全部数える

このうち①②は「送りすぎ」、③は「数え方」の問題です。原因の階層が違うと直し方も変わるので、まずどこで増えているかを特定します。

二重計測の「よくある原因」トップ5

1. タグを2か所で読み込んでいる

最も多い原因です。gtag直貼りとGTMの両方で同じGA4／Google広告タグを入れている、テーマやプラグインが自動でタグを挿入しているのに気づかず手動でも入れている——といったケース。1回の操作で、同じリクエストが2回飛びます。

2. イベントスニペットを全ページ共通に置いてしまった

Google広告のコンバージョンのイベントスニペットは、成立するページ（サンクス／完了ページ）だけに置くのが原則です。これを全ページ共通のヘッダーに入れてしまうと、ページを見るたびに発火し、水増しされます。

3. リロード・「戻る」でサンクスページが再訪される

完了ページでユーザーがF5やブラウザバックをすると、コンバージョンのイベントがもう一度発火します。1人が2〜3回リロードすれば、その分だけ重複します。

4. リダイレクト・SPA遷移での再発火

完了後にリダイレクトが挟まる構成や、SPA（シングルページアプリ）で擬似的なページ遷移をする構成では、同じイベントが意図せず複数回送られることがあります。

5. カウント設定が「すべて」になっている

Google広告のコンバージョンアクションで、カウント設定が**「すべて」**だと、1クリックから複数回成立したコンバージョンを全部数えます。問い合わせなど「1人1件」で数えたいものが「すべて」になっていると、多めに出ます（これは設定上の正常動作で、意図と合っているかの確認が必要）。

もう一つのよくある原因：コンバージョン「アクション」の重複（ネイティブタグ＋GA4インポート）

ページ上のタグ重複とは別に、Google広告のアカウント内で起きるもう一つの二重計測があります。同じ目標（たとえば購入）を、Google広告のネイティブコンバージョンタグ（GTMやgtag経由） と GA4からインポートしたキーイベント の両方で計測していて、どちらも**「メイン」**に設定されている場合、「コンバージョン」列で二重にカウントされます。

ページ自体は正常に動いている（1操作＝1発火）ため、見落としやすいのが特徴です。重複はコンバージョンアクションの一覧の中にあります。

確認方法： Google広告 > 目標 > コンバージョン > 概要 を開きます。同じ目標に対して2つのアクション（例：Google広告タグの「購入」とGA4インポートの「purchase」）があり、両方が「メイン」になっていれば、重複しています。

直し方： 1つの目標につき1つのソースに統一します。入札に使いたい方を「メイン」のまま残し、もう片方を**「サブ」**に変更する（または一時停止／削除する）。「サブ」に設定したアクションはデータ収集は続きますが、「コンバージョン」列やスマート自動入札には反映されません。

確認方法：開発者ツールで「1操作あたりの回数」を数える

二重計測の確認は、ブラウザの開発者ツール（Network）で、1回の操作につきリクエストが何回飛ぶかを数えるのが最も確実です。

  1. コンバージョンが成立するページを開き、開発者ツールの「Network」タブを開く
  2. フィルタを入れる：
    • GA4 … collect
    • Google広告 … conversion または googleadservices
    • Meta … facebook.com/tr または tr?
  3. コンバージョンの操作（送信・購入）を1回だけ行う
  4. 同じイベントのリクエストが1回だけか、2回以上飛んでいないかを数える

つまずきやすい例： リロードや「戻る」で増えるかも、その場で試して確認しましょう。完了ページを再読み込みして件数が増えるなら、再訪での二重発火が起きています。

GTMプレビューモードとTag Assistantでクロスチェック

開発者ツールのNetworkで生のリクエスト数を数えるのが最も確実ですが、GTMを使っているなら、GTM内蔵のプレビューモードで「どのタグが、なぜ発火したか」を俯瞰できます。

  1. GTMの右上にある**「プレビュー」**をクリック — デバッグパネルがサイトと並んで開きます
  2. コンバージョンのフロー（送信・購入）を実行する
  3. デバッグパネルの**「Tags」タブで、該当イベントの「Tags Fired」にコンバージョンタグが1回だけ**表示されていることを確認する
  4. 同じタグが複数のイベント（例：「DOM Ready」と「Window Loaded」の両方）で表示されている場合、トリガーの条件が広すぎます — 条件を絞るか、ブロッキングトリガーを追加してください

GTMの外でも、Tag Assistant Chrome拡張機能でセッションを記録・再生し、想定以上にタグが発火していないかを確認できます。CMSプラグインやテーマが自分で設定していないタグを自動挿入している疑いがある場合に特に有効です。

ヒント： プレビューモードと開発者ツールのNetworkは補完関係です。プレビューモードは「どのGTMタグが、どのトリガーで発火したか」を、Networkは「実際にネットワークへ飛んだリクエスト」を示します。原因が明確でないときは両方を使いましょう。

二重計測の直し方

原因の階層ごとに、対処が変わります。

「送りすぎ（①②）」を直す

  • タグの重複設置を解消する：gtag直貼りとGTMのどちらか一方に統一する。プラグイン／テーマが自動挿入していないか確認する
  • イベントスニペットの設置場所を見直す：コンバージョンスニペットは成立ページだけに置く
  • リロード・再訪での再発火を防ぐ：完了後にURLパラメータやフラグを除去する、サーバー側で「処理済み」を管理する、などで同一完了の再カウントを防ぐ
  • 重複排除（デデュープ）の仕組みを使う：
    • GA4／eコマースは**トランザクションID（transaction_id）**を付与すると、同一取引の重複が排除されます
    • Metaはevent_idによるデデュープが標準です。ブラウザのピクセルとサーバーのコンバージョンAPI（CAPI）を併用する場合、イベント名＋event_idの両方を一致させて初めて重複排除が効きます（Metaピクセルの確認）

拡張コンバージョン・サーバーサイドタグでの重複に注意

最近の計測環境では、複数のコンバージョン経路を重ねて使うケースが増えています。GTMのブラウザタグ、拡張コンバージョン（ハッシュ化したメールアドレス等のファーストパーティデータを送信）、場合によってはサーバーサイドGTMコンテナやGA4インポートなどです。それぞれの経路が独立して同じコンバージョンをGoogle広告に報告する可能性があります。

Googleがこれらの経路を重複排除するのは、すべての経路で同じ transaction_id が送られている場合だけです。1つの経路でも異なるIDが送られていたり、IDが空だったりすると、別のコンバージョンとして扱われます。

マルチパス構成でのチェックポイント：

  • すべての経路（ブラウザタグ、拡張コンバージョン、サーバーコンテナ、GA4インポート）で、同じイベントに対して同じ transaction_id を送っているか
  • サーバーサイドGTMを使う場合、サーバーコンテナ側でIDが再生成されていないか — サーバーコンテナのプレビューモードで送信リクエストを確認する
  • 拡張コンバージョンを有効にしている場合、既存タグを補完する形か、別のコンバージョンアクションを作ってしまっていないかを確認する

「数え方（③）」を直す

  • Google広告のコンバージョンアクションで、**カウント設定（すべて／1回）**を目的に合わせる。問い合わせ・申し込みは通常「1回」、購入は「すべて」が基本

確実に確認するためのチェックリスト

  • 1回の操作で、同じリクエストが1回だけ飛んでいるか（開発者ツールで実測）
  • gtag直貼りとGTMで、タグを二重に設置していないか
  • コンバージョンのイベントスニペットを成立ページだけに置いているか
  • **リロード・「戻る」**で件数が増えないか
  • リダイレクト・SPA遷移で再発火していないか
  • GA4／eコマースでtransaction_idによる重複排除をしているか
  • Metaでevent_idのデデュープが（イベント名＋event_idで）効いているか
  • 同じ目標に対してコンバージョンアクションが重複していないか（ネイティブタグ＋GA4インポートの両方がメインになっていないか）
  • マルチパス構成（拡張コンバージョン・サーバーサイド）で**transaction_idが全経路で一致**しているか
  • Consent Modeのモデリングが水増しの原因ではないか（タグ重複ではなく推定値の上乗せの可能性）
  • Google広告のカウント設定が目的（1回／すべて）に合っているか

よくある質問（FAQ）

Q. 二重計測と「正常なズレ」はどう違う？ A. 二重計測は、1回の出来事を同じものさしで2回数えている水増しです。一方、Google広告とGA4で数字が違うのは別のものさしで数えているためで、別問題です（数が合わない理由）。まず開発者ツールで「1操作＝1回」かを確認すれば、二重計測かどうかは切り分けられます。

Q. transaction_idを入れれば必ず重複は消える？ A. 同一の transaction_id が付いた重複は排除されますが、毎回違うIDが振られていたり、空だったりすると効きません。実際に同じ取引で同じIDが渡っているかを確認してください。

Q. Metaのデデュープが効かないのはなぜ？ A. ピクセルとCAPIでイベント名が一致していない、event_id が片方にしか付いていない、IDの生成ルールがずれている、などが典型です。両方で同じイベント名＋同じevent_idが必要です。

Q. 同意モード（Consent Mode）のモデリングで数字が膨らんでいる可能性は？ A. あります。Consent Mode v2を使っている場合、トラッキングの同意を拒否したユーザーのコンバージョンをGoogleがモデリング（推定）で補完します。このモデリング分がレポートに加算されるため、開発者ツールで確認できる実発火数より合計が多く見えることがあります。これは発火の二重計測ではなく、推定値の上乗せです。「コンバージョン（時間別）」列で「モデリング」の注記を確認するか、サーバー側の実績と比較してください。モデリングを除外したデータで水増しが消えるなら、原因はタグの重複ではなくConsent Modeのモデリングです。

Q. 手元では1回なのに、レポートでは多い場合は？ A. 自分の操作（1パターン）では再現しない経路で増えている可能性があります。特定ブラウザ・特定流入・特定デバイスでの再発火は、手元の確認だけでは見つけきれません。本番の実ユーザー条件での検証が必要です。

まとめ：「足りない」だけでなく「多すぎ」も計測の故障

二重計測は、数字が増えるぶん見落とされがちですが、水増しされた成果で判断すると費用対効果を見誤る立派な計測の故障です。まずは開発者ツールで「1操作＝1リクエスト」かを実測し、送りすぎ（設置・再発火）と数え方（カウント設定）のどちらが原因かを切り分けましょう。

ただし、手元での1回の確認では、実ユーザーの経路でだけ起きる重複は見つけきれません。ConversionOKは、外部の独立した実ブラウザであなたの本番ページにアクセスし、実際に送信されるコンバージョンのリクエストを傍受して、発火の回数や中身まで検証します。自分の広告をクリックする必要も、社内環境の影響を受けることもありません。まずは無料の静的チェックで、計測の入口を確認してみてください。