GA4の仕様に関する無料で受けられる全40問のテスト(30分の時間制限)を見つけたので受けてみました。この記事では、テストの振り返りを通じて学んだ、実装者が知っておくべきGA4の「集計ロジック（処理の思想）」について整理します。
悲惨な結果で撃沈
普段、クライアントワークでGTMやGA4実装を行っている身としてある程度は正解できるかな、なんて思いながら気軽に受けてみると 40問中19問正解という目も当てられない結果になって少し落ち込みました。
解説を読み込んでいくと、「データを送ること（実装）」と「データが処理されること（集計）」の間にはギャップがあり「集計ロジック（処理の思想）」を十分に理解していないと、意図しないデータを計測してしまうリスクがあることが分かりました。
そして私は今回のクイズで、「送られたデータがGA4の中でどう処理されるか」という部分で多くの不正解を出してしまいました。
実装と集計のギャップ：「送信」＝「計測」ではない
特に混同しやすいのが「スコープ（集計範囲）」の概念です。 例えば、レポート作成時に「ソース（Source）」と「セッションのソース（Session Source）」のどちらを選ぶべきか。
実装者としては「どちらも流入元のパラメータ（utm_source等）が入っているのだから同じだろう」と考えがちですが、GA4の仕様では明確に異なります。
- ソース（Source）： 「イベントスコープ」です。コンバージョン（キーイベント）が発生した時のみ機能します。
- セッションのソース（Session Source）： 「セッションスコープ」です。セッション全体の流入元を示します。
もしクライアントが「総ユーザー数」と「ソース」を組み合わせてレポートを作ると、キーイベントが発生していないセッションが除外され、数値が激減して見えます。 「実装は正しいのに、BigQueryやLooker Studioで出す数字がおかしい」といった問い合わせの原因は、こうした集計ロジック（スコープ）の理解不足にあることが多いです。
直感を裏切る「参照元」の仕様
「参照元（Referrer）」の扱いについても、単純なラストクリックではない複雑な仕様があり、これが「実装ミスではないか？」という誤解を生むことがあります。
「Direct」は過去の情報を引き継ぐ
「昨日Google検索で来たユーザーが、今日ブックマーク（Direct）で再訪した」場合、今日のセッションの参照元はどうなるでしょうか。 実装的には「リファラーなし（Direct）」ですが、GA4のレポート上では、過去（最大90日）に遡って最後の参照元（Google）が適用されます。
「タグで正しく計測しているはずなのにDirectが少ない（あるいはOrganicが多すぎる）」という現象は、このルックバック仕様によるものです。
除外設定の挙動
特定のドメイン（例: 決済ゲートウェイ example.com）を「除外する参照元（Unwanted Referrals）」に設定しても、そのドメインからのアクセスが消えるわけではありません。参照元が「Direct」に書き換わるだけです。
さらに前述のルックバック仕様と組み合わさることで、「除外設定をしたのに、過去の履歴が残っているため、しばらくはそのドメインがレポートに残り続ける（または別の過去の参照元に書き換わる）」という現象が起きます。 クライアントから「除外設定したのに消えていない」と指摘された際、この仕様を知らないと設定ミスを疑ってしまいますが、これはGA4の仕様通りの挙動なのです。
実装時のチェックリスト
クイズの解説から、技術的な設定ミスを防ぐためのチェックリストを整理しました。
User ID設定のバリデーション
ログインしていないユーザーに対して、変数のデフォルト値などで文字列の "none" をUser IDとして送信していませんか？ GA4はそれを「”none” というIDを持つ一人のユーザー」として名寄せしてしまい、ユーザー数が激減します。
ポイント: 未ログイン時はID自体を送信しない（undefinedにする）処理が入っているか。
探索フィルタの正規表現
GA4の探索レポートでフィルタをかける際、正規表現は「部分一致」ではなく「完全一致」として扱われます。
ポイント: フィルタ設定時、含む条件なら .*admin.* のように記述しているか。
クロスドメイン設定
異なるドメイン間で同じ測定IDを使っても、管理画面でのクロスドメイン設定を行わない限りCookieは共有されず、別々のユーザーとしてカウントされます。
ポイント: 測定IDの一致だけでなく、管理画面でドメイン設定を行っているか。
備忘録としてのまとめ
GA4やGoogle広告のタグは「ユーザーのすべての行動を計測の対象とする」思想ですが、その集計ロジックまで把握していないと、意図しないデータを計測してしまうリスクがあります。
私たち実装者も、タグの発火確認、データ受信の確認だけでなく、その後の「アトリビューション」や「スコープ」といった仕様を理解しておくことで、より手戻りの少ない実装が可能になると感じました。今回の気付きを今後の実装ガイドラインに役立てていきたいと思います。
