こんにちは、JADEのコンサルタントの郡山です。今回はGA4の「ランディングページの基本的な使い方」について解説します。
ランディングページとは「セッションで最初に閲覧されたページ」を記録するディメンションです。
「広告やソーシャル経由でサイトを訪問したセッションは、どのページにランディングしているのか?」といったセッションベースの分析をする際に利用するデータですね。
利用する機会が多いディメンションですが、間違った使い方をしているケースもよく目にするので基本的な使い方を改めて解説してみたいと思います。
※ランディングページというディメンションの仕様について詳細を知りたい方は、こちらをどうぞ。
【もくじ】
- ランディングページと組み合わせて集計できないディメンションがある
- ランディングページの次に閲覧されたページはわからない
- ランディングページのコンテンツグループはない
- BigQueryにエクスポートしたデータならランディングページの情報をすべて利用できる
- AmethystならSQLなしでBigQueryにエクスポートしたデータを使い倒せる
ランディングページと組み合わせて集計できないディメンションがある
ランディングページは、セッションで表示された1ページのURLのパス部分を記録するディメンションです。
アクセスしたURL | GA4の「ランディングページ」ディメンションで記録する値 |
---|---|
https://blog.ja.dev/entry/blog/2025/02/26/ga4-sessions-explained | /entry/blog/2025/02/26/ga4-sessions-explained |
この情報を見て、
「ページのホスト名(ドメイン)を表示させたい」
「ページのタイトル名を表示させたい」
と考え、探索レポートやLooker Studioで組み合わせてみたくなったことはありませんか?
実はランディングページのタイトルやホスト名は、GA4の標準のレポート機能では表示することができないのです。
ページ(URL)ごとのホスト名やタイトル名を表示させるだけなのだから、「ランディングページ」ディメンションと組み合わせても問題ないように思うかもしれません。しかし、そのような集計をすると誤った集計結果になってしまいます。
本来、1ページにつきURLとタイトルは1つずつGA4で対応するディメンションに記録されます。
(※例外として、URL末尾のパラメータ情報の有無や、アクセスしたブラウザの言語設定などによってはGA4で複数パターンの値が記録されるケースもあります)
しかし、集計するディメンションや指標の組み合わせを間違えると誤った集計結果になってしまうので注意が必要です。
探索レポートやLooker Studioでそのような集計をすると下記のようになります。
- ランディングページ × ホスト名
- ランディングページ × ページの完全なURL
- ランディングページ × ページタイトル
このような組み合わせはすべて間違いです。
ランディングページが「セッションごとに記録されるデータ」であるのに対して、ホスト名やタイトルは「イベントごとに記録されるデータ」であるためこのような集計結果になります。
イベントスコープのデータとは
GA4で記録されるデータは「スコープ」という粒度が定義されています。
「イベントスコープ」と「セッションスコープ」について理解できると、前述の集計結果が何を示しているのか読み取ることができます。
1回のセッションで複数のページを閲覧したケースを例に説明します。
このセッションでは「URLとページタイトルの組み合わせで表示回数をカウントする」といった集計は問題なくできます。
ページパス | ページタイトル | 表示回数 |
---|---|---|
/blog/aaa/ | ページA | 2 |
/blog/bbb/ | ページB | 2 |
/blog/ccc/ | ページC | 1 |
表示回数をカウントするpage_viewイベントは、どのページで計測されたのかといった情報を含め記録するため、各ページごとのURL、タイトル情報の組み合わせで表示回数を集計できます。
このような「イベントごとに記録する情報」をイベントスコープという単位でGA4は処理します。
- ページのタイトルやURLは「イベントスコープのディメンション」
- 表示回数は「イベントスコープの指標」
として記録されます。
セッションスコープのデータ
では同じように「ランディングページ」のスコープを確認してみましょう。
ランディングページ | 表示回数 |
---|---|
/blog/aaa/ | 5 |
ランディングページは「セッションごとに記録する情報」です。
セッション単位で記録されるため、セッション内で複数のページで発生した表示回数(page_viewのイベント数)を集計してもランディングページはすべて同じになります。
「ランディングページ×セッション」ならどちらもセッション単位のデータなので集計しても問題ないですが、「ランディングページ×表示回数」だと、ちょっとよくわからない集計結果になってしまいますね。
では、この組み合わせにページのタイトルを追加するとどうなるでしょうか。
ランディングページ | ページタイトル | 表示回数 |
---|---|---|
/blog/aaa/ | ページA | 2 |
/blog/aaa/ | ページB | 2 |
/blog/aaa/ | ページC | 1 |
ちょっと意味がわからないですね。
ランディングページのタイトルが複数あるような集計結果になってしまいます。
「このランディングページが記録されたセッション内で閲覧されたページのタイトルごとの表示回数」を集計したことになります。ややこしい。
誤った集計例として挙げた3つの集計パターンを改めて確認すると
- ランディングページ × ホスト名
- ランディングページ × ページの完全なURL
- ランディングページ × ページタイトル
ランディングページと組み合わせたディメンションは、セッション単位ではなくイベント単位で記録されるものばかりですね。
「ランディングページのタイトル」といったセッション単位のディメンションがGA4にはないため、正確な集計ができないのです。
ランディングページの次に閲覧されたページはわからない
ランディングページの誤った使い方としてもう一つ覚えておきたいのが「次に閲覧されたページ」の捉え方です。
GA4では「ページの参照元URL」というディメンションに【ユーザーが対象のページにアクセスする前にアクセスしていた URL】が記録されます。
このディメンションを利用することで、特定のページの次に閲覧されたページの表示回数を集計することができます。
ページの参照元URLはページが閲覧される度に記録される「イベントスコープ」のディメンションです。
よって、直前に閲覧していたページがランディングページかどうかに関係なく記録されます。
では、ランディングページのディメンションとページの参照元URLを組み合わせるとどうなるでしょうか。
指定したランディングページ×ページの参照元URL
「特定のランディングページごとのページの参照元URLごとの表示回数」を集計すると、【特定のランディングページから始まったセッション内で閲覧されたページごとの直前の閲覧ページごとの表示回数】がわかるんですね。ちょっとよくわからないですね。
ランディングページ×指定したページの参照元URL
「特定の直前の閲覧ページごとのランディングページごとの表示回数」を集計すると、【指定したページが直前に閲覧されたページを記録したセッションのランディングページごとの表示回数】がわかるんですね。ちょっとよくわからないですね。
このように、GA4の標準のディメンションの組み合わせではランディングページの次の閲覧ページ=セッションの2ページ目がわからないのです。
ランディングページ×セッションの参照元/メディア
ランディングページはセッション単位のディメンションなので、そのセッションがどのウェブサイトからアクセスされたのか確認する際は「セッションの参照元/メディア」など【セッションの~】という接頭辞がついたディメンションを組み合わせるのが基本です。
GA4がセッション単位で流入経路を判定・処理しているためセッションごとの実績を確認するならばやはりセッションスコープで集計するのがわかりやすいですね。
ランディングページのコンテンツグループはない
GA4では「コンテンツグループ」という、任意のルールでページを分類するディメンションが利用できます。
URLのディレクトリごとに分類できる他、dataLayerなどを利用すれば様々なルールでページを整理することができる便利なディメンションです。
旧バージョンのGA=ユニバーサルアナリティクスでは「ランディングページのコンテンツグループ」や、「前のページのコンテンツグループ」「次のページのコンテンツグループ」といったディメンションがありましたが、2025年3月時点では残念ながらGA4にそのようなディメンションが実装されていません。
GA4で現在使えるコンテンツグループはイベントスコープで集計される「ページ単位のグループ」に限られます。
ランディングページごとのグルーピングをしたい場合は、Looker Studioの計算フィールドやBigQueryにエクスポートしたデータを処理する必要があります。
BigQueryにエクスポートしたデータならランディングページの情報をすべて利用できる
- ランディングページのホスト名、タイトル名
- ランディングページの次に閲覧されたページ
- ランディングページをグループ化したディメンション
いずれも、GA4やLooker Studioで利用できる標準の機能では集計ができません。
今回ご紹介したようなケースは「BigQueryへデータをエクスポートして加工する」ことが解決策となります。
個人的には、GA4で「セッションスコープ」の標準のディメンションや機能が充実していってほしいと1,000回くらい祈っています。
SQLを使わず、わかりやすいUIでそのような分析がすぐにできると嬉しいですよね。
AmethystならSQLなしでBigQueryにエクスポートしたデータを使い倒せる
SQLを使わず、わかりやすいUIでセッションデータの分析がすぐにできるツールがあると嬉しいですよね。というわけでそのようなツールをJADEでは提供しています。Amethystといいます。
Amethystでは、GA4で記録されたユーザーのデータを「セッションごとに」データ抽出したりモニタリングする機能が充実しているのです。最後にちょっとだけご紹介しますね。
ランディングページとセッションの2ページ目のタイトル、URL
ランディングページのURLフルパスとタイトル情報を取得できるので、ランディングページごとのタイトルでフィルタをしたデータ抽出がすぐにできます。
また、ランディングページの次に閲覧されたページもフィルタできます。
ランディングページとセッションの2ページ目のグルーピング
SQLやGTMの変数を使わず、Amethyst管理画面上で「完全一致」や「含む」条件でURLを分類するルールを定義できます。
1つの分類ルールを決めてしまえば「ランディングページ」と「セッションの2ページ目」のグループどちらも作成されるので楽ですね。しかもBigQueryにエクスポートされた過去のデータすべてを分類できるので過去の実績もグループごとに集計できるのが嬉しいです。
ランディングページとセッションの2ページ目のモニタリング
Amethystなら特定のランディングページの次の閲覧ページごとにセッションを集計できるので、サイト内の回遊傾向を確認することもすぐにできます。
僕がLooker Studioでやりたかったのはこれです。GA4標準の機能でもいつかできるようになるといいのですが、Amethystならすぐにできるのでおすすめです。
まとめ
GA4のランディングページの使い方と、間違った集計例、そして解決策について解説させていただきました。
BigQueryを使わない環境でも工夫すれば「ランディングページのURLグループ」は計算フィールドで実現可能ですが、ランディングページのタイトルなどは表示できません。
最後にご紹介したAmethystは、SQLを使わなくてもGA4のローデータを活用することができるマーケティングツールです。
GA4探索レポートの「ユーザーエクスプローラー」のように、セッションの個票分析ができる点が特徴ではありますが、「セッションデータの抽出・モニタリング」でもとっても便利なのでおすすめです。
GA4のお困りごとがある方や、Amethystにご興味がある方はお気軽にお声掛けくださいませ。
私はAmethystユーザーのカスタマーサポートを担当していますので、皆様のGA4データ活用のお役に立てる機会を楽しみにしています!
ここまで読んでくださりありがとうございます!
それではまた来月の #現場で役立つGA4 でお会いしましょう~。