こんにちは。バナナデスクです。
ブログから外部の申込ページへ移動した読者が、その先で申し込んだかを知りたい。ところが、別サイトの数字では「そのブログから来た人」とうまくつながらない。そんなときに検討するのが、GA4のクロスドメイン測定です。
最初に見るのは、設定欄のドメイン名よりも、申込先へ自分のタグを設置できるかです。記事側にGA4があるだけでは、相手のサイトの受付結果まで自動で見えるわけではありません。管理できる2サイトの場合と、外部サービスへリンクするだけの場合を分けて進めましょう。
クロスドメイン測定は、移動前後をつなぐ設定
クロスドメイン測定は、異なるドメインへ移動する行動を同じユーザーの行動として扱うための仕組みです。同意がある条件で、リンクやフォームの移動時に_glというURLパラメータなどを使い、測定に必要な情報を渡します。対象ページには、同じウェブデータストリームの同じG-で始まるタグIDが必要です。Googleの公式設定ガイドに条件と確認方法があります。
この設定が扱うのは測定上のつながりです。フォームが正常に受け付けたか、同じ申込を二重に数えていないかは、別に確認します。クロスドメインが正しくても、クリックを受付完了として送っていれば、その数字の意味は変わりません。
申込先をどこまで管理できるか確認する
| 申込先の条件 | 先に行うこと | 確認できる範囲 |
|---|---|---|
| 自社管理の別ドメインでタグを設置できる | 両方の測定先、同意設定、リンク経路を確認 | 移動と受付をそれぞれ検証できる |
| 外部サービスにGA4連携欄がある | 対応プラン、入力するID、計測対象ページを公式資料で確認 | サービスが対応する範囲。任意のタグを置けるとは限らない |
| タグを設置できず、連携機能もない | 記事側の外部リンククリックと、申込先の受付集計を分けて持つ | クリックは確認できても、同一ユーザーの完了をGA4でつなげられるとは限らない |
外部サービスへ渡す相談文なら、「GA4は使えますか」だけでは答えが足りません。「同じG-IDを、入力ページと受付完了ページへ設置できるか」「途中の転送で_glなどのパラメータが残るか」「同意設定は誰が管理するか」まで確認します。iframe内で表示する申込フォームは、通常のページ移動と同じ確認をしただけでは足りません。埋め込みの提供元の方式を調べます。
両方のタグを確認してから対象ドメインを設定する
2026年10月1日の公式説明では、管理画面で対象のウェブデータストリームを開き、「タグ設定を行う」から「ドメインの設定」へ進みます。対象のドメインを条件として追加し、保存する流れです。操作には編集権限が必要です。
教材用の例として、記事サイトをexample.com、申込サイトをexample.netとします。両方の対象ページで同じ測定先を使うことを先に確認し、必要なドメインの条件を追加します。別のG-IDを持つサイトを一覧へ書き足すだけで、測定先が統一されるわけではありません。
名前に一部の文字が含まれるという広い条件を選ぶと、意図しないドメインが入ることがあります。実際のホスト名とマッチタイプを照らし合わせ、必要な範囲だけを指定します。wwwの有無や、決済途中の別ホストも、実際の移動で確かめてください。
すでに対象が登録されている場合は、保存済みの内容を先に記録し、同じものを重複して追加しないようにします。画面へ入力した事実と、対象ページでその設定が使われることは別に確認します。
正常・途中で欠落・同意条件の違いを分けて試す
以下は2つの管理可能なドメインを用意したときに使う、架空の検証計画です。実際のGoogleタグでこの3条件を測った結果ではありません。確認すべき場所を先に決めるための記入例です。
| 条件 | 移動で確認すること | 計測側で確認すること |
|---|---|---|
| 両サイトの同意条件をそろえて通常リンクを押す | 移動先が開き、付与された_glが受け渡されるか | 同じ測定先、受信イベント、実行時刻に対応する移動の連続性 |
| 検証用の転送でパラメータを落とす条件を作る | 最初の移動URLと各転送先で、どこで消えたか | 正常条件との違い。最終URLだけで原因を決めない |
| 同意の選択を変えて同じリンクを押す | バナーの選択、実際の同意状態、タグの動作 | 保存・送信の違いを記録し、同条件の結果と比較 |
_glが付いたことは、情報を渡す入口を確認する材料です。移動先で正しく受け取り、想定した測定先へ送ったことまで、その文字列だけで分かるわけではありません。反対に、アドレス欄で見えなかった場合も、瞬間的な転送で消えた可能性があります。
Googleは、転送やクエリパラメータの取り扱いによる欠落を、ブラウザーのネットワーク記録で調べる方法を説明しています。リンク元から記録を開始して移動し、各応答と次のURLを見ます。最終ページのスクリーンショット1枚だけでは、途中で何が起きたかを追えません。
同意条件もそろえて記録します。Googleの同意モードのリファレンスでは、analytics_storageが分析用の保存に関わる設定として説明されています。計測をそろえる目的で、利用者の同意を勝手に上書きする方法は取りません。二つのサイトで、実際に選ばれた状態と実装がどう対応しているかを確認します。
_glが付かないときは、リンクの動きまで見る
対象ドメインの設定と実際の移動先が一致するかを最初に見ます。次に、移動が通常のリンクやフォームによるものか、JavaScriptが独自に画面を切り替えているかを確認します。Googleは、クリックイベントの伝播が別のスクリプトで止められる場合なども問題として挙げています。
タグをもう一つ追加して試す前に、現在のタグ、移動を処理するスクリプト、転送先を一つずつ追います。変更前の記録を残し、一か所直して同じ操作を繰り返せるようにすると、原因に近づきやすくなります。ルールが効かない原因を、ドメイン名だけに決めつけないことが大切です。
担当者へ渡す確認票の書き方
| 項目 | 架空の記入例 |
|---|---|
| 記事側／申込側 | example.com／example.net。どちらも自社管理という想定 |
| 測定先 | 同じウェブストリームを使う。実IDは管理表にだけ記録 |
| 移動 | 記事の申込リンク→申込フォーム→受付完了 |
| 変える条件 | 通常移動、検証用転送での欠落、同意条件の変更 |
| 記録 | 実行時刻・ブラウザー・同意状態・途中のURL・受信イベント |
| 受付の定義 | サーバーが新しい問い合わせを正常に受理した時点 |
| この教材の実測欄 | 未実施。設定入力や2ドメイン計測の成功記録ではない |
申込先を管理できない場合は、記事側ではリンククリックを、相手側では受付件数を、条件を付けて報告します。キャンペーン用のパラメータを相手が受け取れるなら集計の助けになる場合がありますが、クリックした一人と受け付けた一人を同一人物として検証したことにはなりません。
知りたいのは、設定欄が埋まったかではなく、記事から申込までどこを観測できるようになったかです。観測できる区間を明確にしておくと、次に改善するのが記事の誘導文なのか、申込フォームなのかを判断しやすくなります。