GA4クロスドメイン設定と確認方法｜不要な参照元との違い

2026年7月9日

著者: 与謝秀作

サイトと申込画面が別のドメインにある場合、GA4のクロスドメイン計測は、その間の行動をつなぐための設定です。ただし、ドメインの登録だけで認証・決済を含むすべての経路がつながるとは限りません。同じウェブストリームのタグ、識別情報の引き継ぎ、転送や同意の条件を確認し、不要な参照元の設定と目的を分けて検証します。

クロスドメイン計測が必要なケースを判断する

別のルートドメインをまたいで同じ利用者の行動を計測したい場合に、クロスドメインの必要性を検討します。単に別サイトへのリンクがあるだけで必須とは限りません。双方に適切なタグを設置できるか、どの行動をつなぎたいかを先に確認します。

経路	まず調べる設定	目的と限界
異なるルートドメインで双方を計測	クロスドメイン	識別情報を引き継ぐ。タグと遷移の検証が必要
同じルートのサブドメイン	タグとcookie domain	Cookieの共有条件を確認。同じタグだけで断定しない
タグ設置不可の決済サービスから戻る	不要な参照元の必要性	戻りを新しい集客元にしないための扱い。サービス内の行動は計測しない

架空のexample.comからexample.orgの申込画面へ進む経路と、shop.example.comへの遷移では確認箇所が異なります。Googleの前提条件に沿って対象を決めます。

Googleタグ・同一ウェブストリーム・権限を確認する

公式の設定手順では、計測対象の各ドメインで同じウェブデータストリームの同じG-で始まる測定IDを使います。プロパティ名が同じだけでは足りません。直接設置とGTMのどちらでも、実際に読み込まれるGoogleタグと送信先を確認してください。

対象のプロパティとウェブストリーム、設定を変更できる権限を確認する。
A・B双方の本番ページで測定IDとタグの読み込みを確認する。
重複タグやテスト用ストリームへの送信がないか点検する。
リンク、フォーム、認証・決済、転送先を含めたドメイン一覧を作る。

管理画面の設定だけで済むのは、必要なタグと遷移の実装が整っている場合です。設置できないサービスまで計測可能になる機能ではありません。

対象ドメインを条件へ登録する

管理のデータストリームから対象ウェブストリームを開き、Googleタグの設定にある「ドメインの設定（Configure your domains）」で条件を追加します。マッチタイプと対象ドメインを照合し、必要なドメインを含む条件を保存します。画面表記は権限や構成で異なります。

「含む」のように広い条件は、意図しないドメインにも一致しないかを確認します。wwwあり・なし、別の申込用ホストなど、実際に使う遷移を列挙してください。A側だけの作業記録で双方向を確認済みにせず、共通のストリーム設定が双方の実タグに反映されることを、実際のA→BとB→Aで確かめます。

_glで引き継ぐ識別子とUser-IDの違い

対象リンクでは、遷移先URLに_glというリンカーパラメータが付くことがあります。これはCookieの識別情報を受け渡す仕組みであり、ログイン会員のIDを自動で共有する専用User-ID機能と同じではありません。User-IDの別の要件を混同しないでください。

_glが付いていることは重要な途中証拠ですが、受信先が同じストリームへ送信すること、値が受け入れられること、必要な同意やブラウザ条件が満たされることまで単独で証明しません。セッションのタイムアウトや識別が途切れる条件もあるため、「必ず同一ユーザー・同一セッションになる」と保証しないで検証します。

不要な参照元を追加する場合・しない場合

不要な参照元は、指定した参照元を流入元として扱わないための設定です。識別子を接続するクロスドメイン計測の代わりにはなりません。適切なクロスドメインと_glによる遷移は、公式説明では自己参照を自動的に検出する対象です。すべての対象ドメインを重ねて一括登録することを必須手順にはしません。

決済サービスなどから戻った際に、そのサービスを新しい集客元と扱いたくない場合は用途を確認して検討します。一方、実際の集客元である外部ブログまで除外すれば分析を失います。参照元を消して画面を整える前に、タグ・識別・流入処理のどの問題を直すかを明確にしてください。

リンク・フォーム・決済・認証を通しで検証する

以下は実環境で実施するためのテスト表です。この表を作っただけでは検証済みにはなりません。テスト端末、時刻、同意状態、開始ページと終了ページを残し、ケースごとに結果を記入します。

ケース	確認する内容	合否の証拠
A→B・B→A	同じG-ID、遷移先_gl、ページ表示	両方向のURLと送信先
フォーム送信	実際の送信先とリンカー情報	入力後の遷移と送信イベント
転送あり	各段階でのクエリ保持	転送チェーンと最終着地
認証・決済から戻る	同意、識別、成功条件、重複	戻り前後のイベントと業務上の成功

DebugViewでイベント順とパラメータを調べ、必要ならブラウザのCookieや送信情報も使って検証します。DebugViewの標準画面だけで常にclient IDを表示・比較できると決め付けません。識別の接続と、登録成功イベントの正しさも別の合格条件です。

リダイレクト・JavaScript・サブドメインの診断

架空のA→B/checkout→B/login→B/checkoutという経路を考えます。最初のBのURLに_glがあっても、loginへの転送で必要な情報が落ちれば、最終ページだけの確認では原因を見逃します。ブラウザのネットワーク確認で各転送先とクエリの扱いを順に追います。

JavaScriptが通常のリンク操作を置き換える経路、フォーム、iframeは実際の挙動を確認し、どの方式にも自動で適用されると考えません。UTMやクリックIDを含む通常の流入情報まで一律に削除して解決しないでください。サブドメインはCookieの設定範囲とタグの一致を点検し、同じルートだから絶対に問題ないとも断定しません。