GA4のディメンションとは？指標・スコープと使い方
2026年6月22日
著者: 与謝秀作
GA4のディメンションは、データを「何別に見るか」を決める属性です。指標は、その切り口で数や量、率を測るための値です。文字か数字かだけでは見分けられません。この記事では2026年10月11日確認の公式資料を基に、分析の問いから項目を選び、スコープや合計の読み違いを避ける方法を具体例で説明します。
ディメンションと指標は見た目ではなく役割で分ける
GA4のディメンションと指標の公式説明に沿い、ディメンションを分類の軸、指標を測定する値として考えます。ページ名はディメンション、表示回数は指標です。ただし、時刻の「時間」や番号で表されたカテゴリのように、数字に見えても分類に使うディメンションがあります。
項目例 | 役割 | 読むときの注意 |
|---|---|---|
ページタイトル | ディメンション | 同じタイトルのページが複数ないか確認 |
時間（例：09、10） | ディメンション | 足すための数ではなく時間帯の分類 |
セッションの参照元 | ディメンション | 訪問の流入元というセッションの切り口 |
セッション数 | 指標 | ユーザー数やイベント数とは異なる |
イベント数 | 指標 | 送信されたイベントの回数。人数ではない |
エンゲージメント率 | 指標 | 分子と分母を確認して集計する |
「ディメンションは全部文字」「使える項目は固定で何個」と覚えるより、分析したい単位に合う項目を公式の定義で確認する方が実務的です。表示名が似た項目でも、集計する対象やタイミングが違うことがあります。
分析したい問いからディメンションと指標を選ぶ
先に「どこから来た訪問が多いか」「どの入口が使われたか」のような問いを一文にします。次に分類の軸、測る指標、期間、対象ホストとページ、流入条件を決めます。表へ項目を足す前に、何を答えるための表かを明らかにしてください。
分析の問い | 軸の候補 | 指標と条件の例 |
|---|---|---|
どこから来た訪問が多いか | セッションの参照元/メディア | セッション数。自然検索のみか全経路かを明示 |
どのページから訪問が始まったか | ランディングページ | セッション数。本番ホストと対象パスを固定 |
どのイベントが何回届いたか | イベント名 | イベント数。対象イベントと成功条件を別途確認 |
最初に利用者を獲得した経路は何か | ユーザーの最初の参照元/メディア | 新規ユーザー等、問いに合う指標を確認 |
たとえば記事の自然検索入口を調べるなら、全流入のセッション数を代用しません。全ページの閲覧数も入口セッションとは違います。記事別の表とサイト全体の表は、対象範囲が違うものとして保存します。
ユーザー・セッション・イベントのスコープをそろえる
GA4のスコープには、ユーザー、セッション、イベントなどがあります。最初の参照元は初回獲得、セッションの参照元は訪問単位、イベントに関係する流入情報はイベントの分析に使います。同じsourceという語があるだけで、同じ問いに答えるわけではありません。
スコープが異なる項目を一律に使用禁止にするのではなく、組み合わせの意味と利用可能性を確認します。UIやAPIで組み合わせられることと、業務の問いに答えていることも別です。二つのレポートを比べるなら、項目名、指標の定義、期間、フィルタ、識別の条件までそろえます。
レポート用識別子の設定によって利用者のまとめ方も変わります。ユーザー指標を検証済みの実人数と無条件に扱わず、端末をまたぐ同一人物の扱いなど、分からない範囲を残してください。
標準レポートと探索で同じ条件の表を作る
- 対象プロパティを選び、日付と対象ホスト・パスを固定する。
- 標準レポートで問いに合う主ディメンションと指標を選ぶ。
- 必要なら副ディメンションや比較を加え、その条件を記録する。
- 探索で同じ問いを調べる場合は、ディメンション・指標を選び、行や値、フィルタへ配置する。
- 数字が異なる場合は、指標やスコープ、フィルタ、表示の制約から順に照合する。
表を細かく分けるほど意味が明確になるとは限りません。少数データに多数の軸を重ねると、各行が小さくなり判断しにくくなります。まず必要な一つの軸で状況をつかみ、疑問を絞って次の軸を足すと、比較の目的を保ちやすくなります。
カスタムディメンションの収集と定義を設計する
既存の標準項目で答えられるなら、それを優先します。追加の属性が必要な場合は、何を送るかという収集設計と、レポートで使えるようにする定義を分けて進めます。カスタム定義の公式案内に従い、用途に合うスコープを選んでください。
確認項目 | 設計例・判断 |
|---|---|
問いと値 | 記事の編集分類を比較するなら、分類名の候補を決める |
適切なスコープ | イベント、ユーザー、商品など、属性が属する単位を選ぶ |
実装と登録 | 対象パラメータ等の送信を確認し、対応するカスタム定義を登録 |
確認時期 | 収集と登録後、通常24〜48時間を目安にレポートでの利用を確認 |
値の管理 | 無制限のIDやURLで細分化せず、必要なカテゴリを維持する |
プライバシー | 氏名やメールアドレス等を分類値として送らない |
登録しただけで過去の全データが新しい属性で読み直せるとは限りません。収集開始日、登録日、値の変更履歴を残して比較します。個人情報送信防止の指針も確認し、ユーザーIDやセッションIDを単に表へ出す目的でカスタム分類を増やす運用は避けましょう。
ユーザー重複・率の平均・未設定を読み誤らない
架空の集計例として、分類Aに説明用の利用者1・2・3、分類Bに3・4が含まれるとします。Aは3、Bは2でも、両方を合わせた重複除外は4であり、3＋2＝5ではありません。この番号は説明用の記号で、GA4へ個人の識別値を送る推奨ではありません。
率も単純平均しません。架空の訪問でAが100セッション中40のエンゲージメント、Bが20中10なら、率は40%と50%です。全体は（40＋10）÷（100＋20）＝約41.7%で、二つの率の平均45%ではありません。分母の違いを踏まえて計算します。
年齢の区分が18〜24歳や25〜34歳なら、その表だけで正確な「20代」の人数へ組み替えられません。Googleシグナル等の条件や取得範囲を確認し、未知の値やプライバシー上の制約を全利用者の属性と混同しないでください。未設定の行も、不要と即断せず取得・定義・適用条件を調べます。事業成果を扱う場合は、イベント件数と成功人数を分け、検証できた範囲を報告します。
次に確認する内容
