Googleアナリティクス（GA4）の登録・設定手順｜計測確認まで
Googleアナリティクス（GA4）の設定は、アカウントの作成、Webストリームの準備、タグの設置、受信確認の順に進めます。登録だけではサイトのデータは届きません。すでに計測しているサイトでは、新しいタグを足す前に既存の管理者と送信先を確認することが出発点です。
設定前に目的・管理者・既存タグを確認する
最初に「どのサイトで、どの行動を、誰が管理するか」を一枚にまとめます。記事の閲覧を知りたいのか、相談フォームの受理まで追いたいのかで、必要なイベントと確認箇所は変わります。担当者個人だけがアクセスできる状態を避け、組織で引き継げるGoogleアカウントと権限管理を用意します。
- 対象となる本番ホスト、テスト環境、アプリや認証への移動先を記録する。
- 既存のGA4プロパティ、CMSの連携機能、ページ内のタグ、GTMコンテナを確認する。
- アカウントとサイトの管理者、公開作業を行う人、検証する人を決める。
- ページ表示と、事業上の成功として扱う行動を分けて定義する。
同じサイトにCMS連携と直接設置とGTMが混在していても、すべてを有効にする必要はありません。まず既存実装の役割を調べ、同じ送信先へ同じイベントを重ねて送っていないかを確認します。
アカウント・プロパティ・ストリーム・タグ・GTMの役割
アカウントは管理の単位、プロパティは計測・設定・レポートの単位です。プロパティにはWebやアプリのデータストリームを含められるため、「プロパティ＝一枚のWebページ」とは限りません。階層はGoogle公式のアカウント構造で確認できます。
要素 | 役割 | 取り違えやすいもの |
|---|---|---|
アカウント | 権限や複数プロパティの管理 | Googleアカウントというログイン手段とは別 |
プロパティ | 計測設定とレポートのまとまり | 数値IDの架空例：123456789 |
Webストリーム | Webサイトから届くデータの入口 | 測定IDの架空例：G-EXAMPLE01 |
Googleタグ | 設定された送信先へデータを送る仕組み | タグIDの架空例：GT-EXAMPLE01 |
GTM | タグ・トリガー等を管理する仕組み | コンテナIDの架空例：GTM-EXAMPLE |
表のIDは説明用です。実際の数値プロパティID、G-で始まるWeb測定ID、GTMコンテナIDは用途が異なります。またGoogleタグは複数のIDや送信先を持てるため、接頭辞だけで判断せず、タグと送信先の対応を見ます。
アカウントとWebストリームを作る：共有・通貨・時刻・拡張計測
- Googleアナリティクスへログインし、既存アカウントに対象サイトのプロパティがないか確認する。必要な場合だけアカウントを作る。
- 適切なアカウント内にプロパティを作成し、名前、レポートのタイムゾーン、通貨を事業の集計条件に合わせる。
- データ共有の各項目を読み、利用目的と組織方針に照らして選択する。既定値を無条件で採用しない。
- Webデータストリームを作り、対象URLとストリーム名を確認する。拡張計測の対象も読み、必要な送信内容を把握する。
- 表示された設置案内から採用する経路を選び、送信先のIDを記録する。
名称や画面配置は変わるため、作業時には公式の導入案内を参照してください。ここで作った設定と、本番サイトに置くタグがつながって初めてデータを受信できます。フォームの自動計測が見えた場合も、それが受理完了を表しているとは限りません。
CMS・直接設置・GTMから一つの設置経路を選ぶ
経路 | 準備・確認 | 重複を防ぐ確認 |
|---|---|---|
CMS連携 | 対応する連携機能、管理権限、接続プロパティを確認 | CMSがタグを出しているか、別設置も動いていないか |
直接Googleタグ | サイトの編集・公開権限と設置対象を確認 | 共通テンプレートと個別ページに重ねて置かない |
GTM | 適切なWebコンテナの編集権限と設置を確認 | コンテナ内の旧設定と別コンテナを棚卸しする |
GTMを使う場合は、現行のGoogleタグを作成してTag IDを指定し、公式手順に沿ってInitializationのトリガーを設定します。旧称の「GA4 Configuration」をそのまま新規作成の名前として探す手順にはしません。プレビューで確認し、変更を公開して本番に反映します。詳細はGTMでのGA4設定手順を参照します。Initializationは同意の取得そのものではなく、同意管理との順序も確認が必要です。
Tag Assistant・DebugView・Realtimeで送信を検証する
確認は一つのテスト端末で、一回のページ表示と一回の操作から始めます。Tag Assistantでタグと送信先を調べ、デバッグモードを有効にしてDebugViewのイベントとパラメータを見ます。DebugViewの公式説明では、プライバシー制御や同意状態でイベントが見えない場合も示されています。表示されないだけでタグの故障と決めつけません。
症状 | 先に確認すること | 記録する証拠 |
|---|---|---|
同じ表示が重なる | CMS・直書き・GTMの重複や手動のページ送信 | 操作回数、受信イベント、動いたタグ |
受信先が違う | プロパティ、ストリーム、タグの送信先 | 選択したIDと受信側の対応 |
受信が見えない | 公開状態、対象ページ、同意状態、デバッグ有効化 | 環境・時刻・状態と検証結果 |
認証後だけ途切れる | ホスト変更、アプリ・別ドメインの測定範囲 | 遷移元と遷移先、成功の確認方法 |
Realtimeで直近の受信を確認した後、通常のレポートは処理を待って再確認します。Googleは処理に24〜48時間かかり値が変わる場合を案内しており、24時間以内という保証ではありません。データの更新頻度と、記録した検証時刻を照合します。
保持・内部トラフィック・同意・成功条件を整えて運用へ進む
保持期間は、必要な分析期間と運用要件から選びます。ユーザー単位・イベント単位の保持設定と、標準の集計レポートは同じ扱いではありません。探索で必要な期間を検討し、後から保持を延ばしても削除済みデータが戻るとは考えないでください。保持設定の適用範囲を確認します。内部トラフィックの除外も、まずTestingで対象を確かめ、恒久的な除外となるActiveへの変更を判断します。内部トラフィックフィルタの手順に沿って進めます。
次は、相談フォームを想定した架空の測定仕様です。イベント名を選ぶ前に、何が起きたら成功なのかを決めます。
行動 | 発火条件の例 | 除外・重複の確認 |
|---|---|---|
ページ表示 | 対象本番ページが表示され、計測が受信される | テスト環境と二重送信を区別 |
フォーム開始 | 入力を始めたことが確認できる | 受理成功とは扱わず、入力値を送らない |
受理成功 | システムが問い合わせを受け付けた結果を確認 | 失敗・再送・再読み込みを区別し、同じ受理を重複計上しない |
未選択・許可・拒否の同意状態をそれぞれ試し、想定した送信制御になっているかを確認します。同意モードは同意の選択をタグへ伝える仕組みで、同意の取得や適用判断を自動で済ませるものではありません。メールアドレスや氏名などがURL、ページタイトル、イベントに混入しないよう、GoogleアナリティクスのPII禁止事項も確認します。
キーイベントの件数は、そのまま登録人数ではありません。成功条件、重複、対象ホスト、認証や別ドメインの遷移まで検証できた範囲を記録します。検証できていない成果は未測定として扱い、計測の完成を確認してから運用レポートへ進みましょう。手順と仕様の確認日は2026年10月11日です。
次の確認に役立つ関連記事：
