コンバージョンが計測されない：壊れた計測を診断する（仮想ケース）

状況：3つのカウンター、3つの数字

以下のデータは演習のために作ったもので、実在する企業を描いてはいません。ヒートポンプ設備の施工会社を想像してください。サイト www.hvac-demo.example は、見積もり依頼フォームが中心です。4月の月次レビューで、3つの数字が並べられました。

チームのよくある第一反応は「GA4が壊れている」です。より役に立つ反応は、差を分解すべき仮説として扱うことです。Kohavi、Tang、Xu は『Trustworthy Online Controlled Experiments』の中で、驚くような数字は間違っている可能性が高いというトゥイマンの法則に1章を割いています。最初に疑うべきは現象ではなく、測定器のほうです。ここでは3つのカウンターが食い違っており、どれか1つだけを信じるわけにいかないことが、最初から分かります。

これは学術的な話ではありません。この月の獲得予算は333,000円で、GA4の78件で割ると、1リードあたり4,269円（333,000 ÷ 78 = 4,269.2）。チームが決めた上限4,000円を超えていて、キャンペーンは停止されそうになっています。実際にサイトから来た依頼111件（なぜ120ではなく111なのかは後述）で割ると、同じ予算で1件3,000円です。停止の判断は、欠陥のある測定器に基づいていたことになります。

診断の時系列

1日目：数字を比較できる形にする

バグを探す前に、同じものを比べているかを確かめます。確認は4つ。期間が同じか。タイムゾーンが同じか（データベースがUTC、GA4プロパティが日本時間（JST）だと、日付の境目をまたぐ依頼がずれます）。定義が同じか（「依頼」は受け付けられた送信であり、送信の試行ではない）。そして範囲が同じか。最後の点で、差の一部が解消します。基幹システムには、電話を受けて手入力した依頼が9件あり、サイトを一度も経由していません。比較できる範囲は、120件から、Web経由の111件になります。

2日目：差を発生源ごとに分ける

全体の差は何も語りませんが、セグメントごとの差は犯人を指します。基幹システムには入力元のフォームが記録されていて、92件は問い合わせページのフォーム、19件は年初に代理店が追加したモバイル用ウィジェット「クイック見積もり」からでした。また同意管理ツールの拒否率は15%（仮の値）と表示されています。この前提のもとで、この仮の例の会社は自社方針としてCMPを導入し、拒否した訪問者の計測を止めているとします。この率を当てはめて、発生源ごとにGA4に出るはずの件数を計算します。

計算からは、ページのフォームは整合している（92 × 0.85 = 78.2 に対して実測78）こと、ウィジェットはGA4にまったく痕跡を残していないことが分かります。差の所在が、一回の演算で絞られました。ただしこの計算は、拒否率が一様だという仮定の上にあります。実際には、トラッキングを拒否する人が、そうでない人と同じ頻度で見積もりを送るとは限りません。同意管理ツールが表示する拒否率も、依頼者ではなく訪問者についての数字です。結果は桁感として読んでください。

3日目：プレビューモードとDebugViewで導線を再現する

仮説は、ウィジェットがタグを発火させていない、というものです。導線を再現して確かめます。Googleタグマネージャーのプレビューモードは、操作ごとに、発火したタグと発火しなかったタグを表示します。GA4のDebugViewは、デバッグ中の端末から届いたイベントをほぼリアルタイムで見せます。ページのフォームでは、流れは想定どおりです。送信が受け付けられるとブラウザは /thanks/ にリダイレクトされ、そのページの表示を待ち受けている generate_lead タグが発火します。ウィジェットでは、送信は受け付けられ、ウィジェットの内側に完了メッセージが表示されますが、ページのURLは変わらず、どのトリガーの条件も満たされません。DebugViewにはナビゲーション系のイベントだけが映り、generate_lead は一件もありません。

ブラウザの開発者ツールの「ネットワーク」タブでも、同じ読み取りが裏づけられます。GA4の収集リクエストは一つも送られていません。したがって問題はGA4よりも手前にあります。

4日目：同意の影響と不具合を切り分ける

ウィジェットの19件のうち、トラッキングを拒否した人からのものは約3件。ページのフォームで欠けている14件（92 − 78）とあわせて、同意に起因する依頼は17件です。Googleタグマネージャーのプレビューは、各イベントに渡された同意状態を表示します。トラッキングを拒否して導線をテストしたときに、計測のシグナルが送られない（同意モードの実装によっては制限される）のは想定どおりの動作で、直すべき欠陥ではありません。同意を取得する設計を採っている以上、拒否した訪問者の計測が止まるのは設計どおりの結果で、技術的なインシデントではないのです。Googleが一部のケースで提供するモデル化の仕組みで損失の一部を補える場合もありますが、それは推定であって、数え直しではありません。

なお、日本の法令が分析目的のタグに一律の事前同意を求めているわけではないと整理されるのが一般的で、同意を取るのか、通知・公表とオプトアウトで運用するのかは、事業者の方針と法的整理によって変わります。個人情報保護法上の「個人関連情報」の扱いや、電気通信事業法の外部送信規律に基づく通知・公表を含め、個人情報保護委員会や総務省の公表資料で確認してください。判断は法務担当者や弁護士に相談するのが確実です。

5日目：件数だけでなく、流入元も調べる

最後の確認です。GA4の流入元の探索を見ると、78件のイベントのうち29件が forms.tool-demo.example からの「リファラル」として現れています。これは、ページのフォームの入力画面をホストしている外部ツールのドメインです。訪問者は一度サイトを離れ、ツール側で連絡先を入力し、/thanks/ に戻ってきます。クロスドメイン計測がないため、戻った時点でセッションが途切れ、広告や検索から来た依頼なのに、フォームツールが「流入元」として記録されてしまいます。イベントの件数は影響を受けませんが、アトリビューションは影響を受けます。Google 広告が63件のコンバージョンしか見つけられない理由の一部は、これです。GA4のドキュメントには、クロスドメイン計測のドメイン設定と、参照元から除外するドメインのリストが説明されています。外部ドメインをまたぐ導線には、この2つの設定を見込んでおく必要があります。

根本原因と寄与要因

次の表は、42件の差の分解です。

算術の確認：9 + 17 + 16 = 42、120 − 42 = 78。同意の行は推定値の集まりなので、「不具合」の行にもその誤差が入り込みます。数件程度の残差は、追加のシグナルではありません。

根本原因は一文で言えます。generate_lead のトリガーが、状態（「依頼が登録された」）ではなく、経路（「サンクスページの表示」）を記述していたことです。この経路を通らないフォームは、すべて計測から漏れます。ウィジェットは、同じ指標に数字を送っているかを誰も確かめないまま追加されました。

異常が長く続いた理由として、5つの寄与要因があります。

1. タグ設計表がなかった。送信経路の一覧がなく、ウィジェットを追加するときに経路を足す必要も生じなかった（GA4のタグ設計表の書き方を参照）。
2. 変更時の受け入れテストがなかった。代理店は見た目の確認だけでウィジェットを納品し、誰もDebugViewを開かなかった。
3. 定期的な突き合わせがなかった。基幹システムとの最初の照合は、公開から何か月もたってから行われた。
4. サードパーティのドメインが未登録だった。クロスドメイン計測が設定されておらず、アトリビューションが乱れて、問題の大きさが見えにくくなった。
5. 分母の信頼性を確かめずに、リード単価の上限を適用した。4,000円の上限は、誤った数字に当てはめられていた。

重複を生んだ修正

ウィジェットを計測するため、開発者は両フォーム共通のスクリプトに、受け付けた送信ごとにデータレイヤーへ event: 'form_success' を送る処理を追加しました。このイベント名を待ち受けるカスタムイベント型のトリガーを新たに作り、generate_lead タグに関連づけましたが、/thanks/ ページ上の元のトリガーは外しませんでした。その結果、イベントを送ってからリダイレクトするページのフォームでは両方のトリガーが満たされ、タグが2回発火しました。

受け入れテストは、これを本番公開の前に検出します。実行の前に期待する結果を決めておくからです。同意を受け入れた状態で、ページのフォームに10回、ウィジェットに10回、テスト送信を行うので、期待されるイベントは20件。DebugViewには30件が表示されました。ページのフォームが10 × 2、ウィジェットが10 × 1です。修正では、トリガーをデータレイヤーのイベント1つに絞り、サーバーが渡して基幹システムにも保存する lead_id パラメータを追加しました。個人情報を含まない技術的なIDなので、各イベントをデータベースの1行と結びつけられます。再公開後のテストでは、20回の送信に対して20件のイベントが確認されました。

この修正により、4月の範囲ではGA4におよそ94件の依頼が表示されるはずです（111 × 0.85 = 94.35）。78件を大きく上回りますが、111件には届きません。翌月、94前後の数字が出れば計測は健全というサインです。反対に111に近い数字が出たら、同意設定に左右されない計測や重複を疑って警戒すべきです。

受け入れテストのチェックリストと限界

この事例研究の成果物は、サイト、フォーム、同意管理ツール、Googleタグマネージャーのコンテナのいずれかを変更するたびにやり直す受け入れテストです。

もっとも、基幹システムとの差をゼロにすることを目指すのは、方法として誤りです。広告ブロッカーが収集の送信を妨げることがあり、ブラウザによってはストレージを制限し、ボットのトラフィックやテスト送信はどちらかに紛れ込み、GA4はすべての数字をすぐには表示しません。許容範囲（たとえば「見積もった同意の影響を除いて、差が10ポイント未満」）は、判断から出発するKPIの選び方で述べた行動の閾値と同じく、数字を見る前に決めます。

ただし、基幹システムも、世間で思われているほど絶対的な真実ではありません。同じ人が二度送った重複、迷惑な送信、テスト送信も含まれているからです。この仮の例では、手入力を除いたうえで基幹システムを基準にしましたが、その整理をしなければ、バグ探しは幻を追いかけていたでしょう。不完全な2つのデータ源を比べて分かるのは、問題の方向であり、正確な大きさではありません。

最後に、法的側面の限界があります。この記事が説明するのは技術的な診断であり、同意の前に、あるいは同意なしに何を計測してよいかではありません。その判断は、法務担当者や弁護士に相談し、個人情報保護委員会・総務省の資料を基準にしてください。コンバージョンが信頼できるものになったら、流入元の読み方は、範囲が分かっている数字の上で進められます。

計測の診断から分析までを実践的に学ぶ場として、マーケティング分析・AI実践コースを用意しています。