コンバージョン計測の設定とトラブル解決｜計測できない・二重計測・GA4と広告の数値が合わない原因を徹底解説【2026年版】

1-1. 計測が崩れると全KPIが嘘になる

なぜここまで計測を強調するのか。それは、計測の誤差が「掛け算」で全KPIに伝播するからです。たとえばCVが実際の2倍に水増しされていると、CPAは半額に見え、ROASは2倍に見え、CVRも2倍に見えます。これを信じて「この媒体は効率が良い」と予算を寄せれば、実際には採算の合わない出稿を増やしてしまう——という最悪の連鎖が起きます。逆にCVを取りこぼしていれば、本来は優秀な施策を「効果が薄い」と誤判定して止めてしまいます。

このように、計測のズレは「数字の誤差」では済まず、意思決定の方向そのものを反転させます。広告のパフォーマンスを語る前に、まず「この数字は信じてよいのか？」を疑うこと。それが計測トラブル解決の出発点です。

1-2. 最初に「CVの定義」を決める

実装に入る前に、必ず「何をコンバージョンと呼ぶか」を言語化して決めること。これが設計フェーズの核心です。CVの定義が曖昧なまま進むと、「フォーム送信の完了」なのか「確認画面の表示」なのか、「電話タップ」も含むのか、といった点が人によってバラバラになり、後で数字が合わない原因になります。

• 主要CV（最終成果）を1つ決める：購入完了／問い合わせ送信完了／会員登録完了など、事業の売上に直結する行動
• カウント方法を決める：1ユーザー1回まで数えるのか、購入のたびに数えるのか（ECは後者、問い合わせは前者が一般的）
• CV値（金額）を持たせるか決める：注文金額を動的に送るのか、固定値か（コンバージョン値の設定ガイドを参照）
• マイクロCV（補助指標）を決める：カート追加・フォーム開始・電話タップなど、後述の機械学習用に観測したい中間行動

この「設計」を最初に紙やシートに書き出しておくと、実装担当・運用担当・発注者の認識が揃い、トラブルの大半は事前に潰せます。逆に言えば、設計を飛ばした実装は、ほぼ必ずどこかで破綻します。

2-1. 計測の仕組み＝サイト側イベント→媒体へ送信

コンバージョン計測の正体は、ごくシンプルに言えば「サイト側で“成果が起きた”という合図（イベント）を発生させ、それを広告媒体や解析ツールへ送る」という仕組みです。登場人物は次の3つです。

流れを図式化すると、「ユーザーが成果行動を取る → トリガー条件を満たす → タグが発火しイベントが生成される → 媒体・GA4へ送信される → 管理画面にCVとして記録される」という一連のバケツリレーです。このどこか1か所でも詰まると、CVは記録されません。トラブル①「計測できない」は、まさにこのリレーのどこかが切れている状態だと考えると見通しが良くなります。

タグの設置方法には、HTMLに直接書く「ベタ書き」と、タグマネージャー（GTMなど）で管理する方法があります。考え方を擬似コードで表すと、媒体タグは「成果ページで一度だけ発火し、必要な情報を送る」だけのものです。

// 【考え方】コンバージョンイベント送信の擬似コード
// 購入完了ページが表示されたら、1回だけCVを送る
if (現在のページ === "/thanks" && まだ送信していない) {
    send_conversion({
        event:  "purchase",      // イベント名
        value:  order.amount,    // CV値（注文金額。動的に渡す）
        txn_id: order.id         // 注文番号（重複排除のキー）
    });
    送信済みフラグ = true;        // ← 二重送信を防ぐ
}

※ 実際のタグの記述・呼称・パラメータ名は媒体やツールにより異なります。上記はあくまで「何が起きているか」を理解するための概念図です。

2-2. サンクスページ型とイベント型の違い

CVを「いつ・どうやって」検知するかには、大きく2つの方式があります。これを混同すると計測トラブルの温床になるため、違いを押さえましょう。

最もシンプルで安定するのは「独立した完了ページの表示をCVとする」サンクスページ型です。ただし、完了ページを持たないサイト（フォーム送信後に同じURLのまま「送信しました」と表示する、決済が外部サービスに飛ぶ、電話やLINEがCVなど）では使えません。その場合はイベント型で「動作」を捕捉する必要があります。完了ページがないサイトでのCV計測の具体策はサンクスページなしのコンバージョン計測ガイドで詳しく解説しています。

3-1. 「計測できない」の主な原因

とくに見落とされがちなのが、下3つです。同意管理（CMP）を導入していると、ユーザーがCookieを拒否した場合に計測タグが発火せず、その分のCVが丸ごと欠落します。SPA（シングルページアプリケーション）では、画面は切り替わっても通常の「ページ読み込み」が発生しないため、サンクスページ型のタグが反応しないことがあります。外部決済では、購入完了が外部サービス側で起き、自社の完了ページに戻ってこない設計だとCVを取り逃します。

3-2. 「計測できない」ときの確認手順

原因を効率よく特定するには、上流から順にチェックします。次の手順を上から潰していけば、ほとんどのケースで原因にたどり着けます。

• ① 完了ページのURLを確定する：実際にCVを発生させ、最終的に表示されるURL（パラメータ含む）を正確に控える
• ② タグが入っているか確認：そのページのソース／タグマネージャーに、対象媒体の計測タグが存在するか
• ③ 発火しているか確認：プレビューモードやタグアシスタント系ツールで、実際にイベントが発火するか見る
• ④ トリガー条件を突き合わせる：条件のURLと①で控えたURLが完全一致しているか（http/https・末尾スラッシュ・パラメータ差に注意）
• ⑤ 同意管理の挙動を確認：Cookie拒否時にタグが止まる設定になっていないか、同意取得の順序は適切か
• ⑥ SPA・外部決済を確認：ページ遷移を伴わないCVを、別の方法（履歴変化やイベント）で捕捉できているか
• ⑦ リアルタイムで届くか確認：テストCVを発生させ、GA4のリアルタイムや媒体の計測状況に届くか見る

4-1. 二重計測の主な原因

4-2. 二重計測を防ぐ考え方

二重計測対策の本質は、「同じ1件の成果を、絶対に2回数えない」仕組みを作ることです。最も確実なのは、注文番号やリードIDのような“1件ごとにユニークな鍵”を使った重複排除です。媒体やツールでは「重複の削除」「トランザクションID」「イベントID」などの呼称で提供されており、呼び方は媒体により異なりますが、考え方は共通です。

// 【考え方】重複排除（デデュープ）の擬似コード
// 同じ注文IDが既に記録済みなら、二度とCVに数えない
受信したCV = { txn_id: "ORDER-12345", value: 8000 };

if (記録済みID一覧.includes(受信したCV.txn_id)) {
    skip();                       // ← 重複として破棄
} else {
    記録済みID一覧.add(受信したCV.txn_id);
    count_conversion(受信したCV);  // 初回だけ計上
}

• 送信は「1注文＝1イベント」に制限：完了ページに送信済みフラグを持たせ、リロードでは再送しない
• タグの設置を1本化：GTMかベタ書きのどちらかに統一し、同一CVの二重送信を物理的になくす
• 注文ID等で重複排除：媒体・GA4・サーバー側のいずれでも、ユニークキーで重複を除く
• 社内アクセスを除外：社員のテスト・確認操作がCVに混ざらないよう、IP除外やテスト環境を分ける
• 定期的に実数と突合：計測CVと、実際の受注・問い合わせ件数を月次で照合して乖離を監視する

5-1. なぜズレるのか──6つの主因

GA4と広告媒体、あるいは媒体同士でCV数がズレる理由は、おおむね次の6つに集約されます。これらは“不具合”ではなく、各ツールの「設計思想の違い」から生じる構造的なズレです。

たとえば、Google広告は「クリックから〇日以内のCVを、データ駆動で各クリックに配分し、ビュースルーやモデリング推計も含む」一方、GA4は「ラストクリックに近い別のモデルで、チャネル横断で1回として数える」——というように、見ている“宇宙”が違います。これでは数が一致しないのは当然です。さらに、媒体は広告がクリックされた時刻を基準にCVを遡って計上する（コンバージョン時刻ではなくクリック時刻に紐づける）ことがあり、これも日次の数字がズレて見える一因になります。

5-2. 「どちらが正しい」ではなく用途で使い分ける

では実務でどう扱えばよいか。原則は「同じものさしで比べる」ことと「目的別に使い分ける」ことです。

最も信頼できる“最終の真実”は、実は計測ツールのどれでもなく、自社の受注・売上データ（CRMや基幹システム）です。広告媒体やGA4の数字は、あくまでそれぞれの目的のための「近似値」。だからこそ、月次では計測CVと実受注を突合し、乖離の傾向を把握しておくことが、計測を“信じられる状態”に保つ鍵になります。なお、近年はCookie規制の影響で計測できない分が増え、各媒体がモデリング推計でそれを補うようになっているため、実数との差はむしろ拡大傾向にあります。背景はCookie規制とファーストパーティデータ活用の記事で詳しく解説しています。

6-1. なぜマイクロCVが必要か

現在の運用型広告は、自動入札（機械学習）がCVデータを“教師データ”として学習し、CVしやすいユーザーへ配信を寄せていきます。ところが主要CVの件数が少ない（目安として月に数十件未満）と、学習データが足りず、機械学習が安定して回りません。結果、配信が最適化されず、CPAが下がらない・成果が安定しない、という悪循環に陥ります。

6-2. 主要CVとマイクロCVの役割分担

ただし、マイクロCVを主要CVと“同じ重み”で入札最適化に使うと、「フォームを開いただけ・スクロールしただけ」で成約しないユーザーばかり集まる危険があります。そこで、両者は明確に役割を分けて設計します。

媒体によっては、CVを「主要」「副次（観測のみ）」のように区分して、入札に使うものと参考値として見るだけのものを分けられます（呼称は媒体により異なります）。マイクロCVは“成約に近いほど価値が高い”ため、フォーム開始＞スクロール＞滞在、のように成約への近さで優先順位をつけると設計しやすくなります。CVが少ない立ち上げ期はマイクロCVで学習を回し、主要CVが貯まってきたら主要CVへ最適化を切り替えていく、という段階設計も有効です。

7-1. アトリビューション──どのクリックにCVを帰属させるか

ユーザーは1回の広告クリックで即購入するとは限らず、複数の広告・チャネルに触れてからCVします。このとき「どの接点にCVの“手柄”を割り当てるか」のルールがアトリビューションです。代表的な考え方を整理します。

近年はデータ駆動アトリビューション（DDA）が主流になりつつあります。これは「実際の経路データから、各接点がどれだけCVに貢献したか」を推定し、1件のCVを複数のクリックに小数で配分する考え方です。そのため管理画面で「CV 2.4件」のような小数が出ることがあり、ラストクリック前提の他ツールと数が合わなくなります。これは不具合ではなく、配分モデルの違いによる当然の結果です。GA4と各媒体でアトリビューションモデルが異なる以上、数字が一致しないのは構造的に避けられません。

7-2. コンバージョンウィンドウ──期間でCPA/ROASが変わる

コンバージョンウィンドウは「クリック（または表示）から何日後までのCVを、その広告の成果として数えるか」の期間設定です。これがCPA・ROASに直接効きます。

つまりウィンドウを長くするほど、同じ広告でもCPAは良く見えます。検討期間の短い商材（衝動買い・低単価）は短め、検討期間の長い商材（高額・BtoB）は長めが目安ですが、絶対的な正解はありません。最も大切なのは次の2点です。

• 比較対象と同じウィンドウに揃える：媒体間・期間比較をするなら、できる限り計測期間の条件を合わせる
• 一度決めたら頻繁に変えない：ウィンドウを途中で変えると、過去との比較ができなくなり、改善の評価が狂う

8-1. 検証の基本手順

• ① テストCVを発生させる：自分で実際に申込み・購入（テスト注文）を行い、完了まで通す
• ② リアルタイムで確認：GA4のリアルタイムや、媒体の計測状況に、そのイベントが届くかを見る
• ③ タグの発火を確認：プレビューモードやタグアシスタント系ツールで、対象タグが「1回だけ」発火するか確認
• ④ 二重発火がないか確認：1回のCVで2件記録されていないか。リロード・戻る操作でも再発火しないか
• ⑤ 値・パラメータの確認：CV値（金額）や注文IDが正しく送られているか。固定値になっていないか
• ⑥ 期間・タイムゾーンの突合：記録された日時が想定どおりか。日付の区切りがズレていないか
• ⑦ 反映の遅延を理解しておく：媒体の管理画面への反映には時間差があるため、即時に出なくても焦らない

8-2. 運用開始後の継続チェック

検証は一度きりではありません。サイトのリニューアル、フォーム改修、決済の変更、タグの追加などのたびに、計測は壊れる可能性があります。次のタイミングでは再検証を習慣化しましょう。

計測は「一度設定したら終わり」ではなく、サイトと一緒に生き続けるものです。だからこそ、誰が・いつ・どの設定で計測しているかを記録し、変更のたびに点検する運用体制が、長期的に数字を信じられる状態を保ちます。