Quantcast
Channel: blog - ブログ - 株式会社JADE
Viewing all articles
Browse latest Browse all 109

GA4の「セッション」とは? session_start、閲覧開始数、ランディングページについても徹底解説 【#現場で役立つGA4】

$
0
0

こんにちは、JADEのコンサルタントの郡山です。今回はGA4の「セッション」について解説します。

 

セッションとは、「ユーザーがウェブサイトを訪問した回数」をカウントする基本的な指標の一つです。

一方で、適切に説明・活用するために仕組みや関連情報も理解しておく必要があります。

この記事では、GA4で計測されるセッション指標に関する「知っておいたほうがいいこと」に触れつつ、基本的な仕組みから解説していきます。

 

目次をご覧になっていただければ分かる通り、長いです。なので、

一気に全部読む(理解する)必要はありません。

記事内で知りたい部分だけ参考にしてもらえれば幸いです。

何度でも、読み返しに来てください。この記事が誰かの役に立てば嬉しいです。

もしわかりづらい点や間違っている点、追加してほしい点があればお気軽にお声がけください。

セッションについて一緒に学んでみましょう。

 

GA4の「セッション」指標とは

筆者がGA4初心者向けにユーザー・セッション・ページビューについて説明する時に利用している図解

GA4のセッションを「訪問回数をカウントする指標」と覚えるのは、GA4初学者の誰もが通る道ではないかと思います。

もう少し具体的に説明すると、

「ユーザーがウェブサイトに訪問してから、30分以上GA4で何も計測することが無くなったタイミングを離脱と見なして区切りをつけた訪問回数」です。

 

GA4の各種イベントデータを計測するためにウェブサイトに実装されたGoogle タグは、セッション指標を下記のように計測します。

  • ウェブサイトのページ閲覧や何かしらの行動をGoogle タグが計測するとセッション開始
  • セッション開始時に自動的に session_startイベントを記録
  • セッション ID(ga_session_id)とセッション番号(ga_session_number)が生成される
  • 30分操作がなければセッションはタイムアウト(終了)する

基本的にはこのような仕様になっています。

  • セッションID=セッションごとのユニークなID
  • セッション番号=ユーザーごとにセッションが記録された回数(通算訪問回数)

という情報がセッションごとに記録されるため、GA4ではユニークなセッションIDの数を集計することで「セッション」指標をカウントしています。


参考:[GA4] アナリティクスのセッションについて - アナリティクス ヘルプ

 

セッションが計測されるタイミング

初心者の方は「ユーザーがウェブサイトを訪問しページを表示すると記録される」という点を押さえておけば十分ですが、厳密には下記のタイミングでセッションがGA4に記録されます。

  1. 初めてウェブサイトのページを表示した時
  2. 過去のセッションがタイムアウトしてから、ウェブサイトのページで何かしらのイベントをGA4で計測した時

この2パターンです。

2の例ですが、「初回訪問セッションで閲覧していたページが表示されているブラウザのタブ」を放置して、後日に同じタブの開きっぱなしのページをスクロールするケースがわかりやすいかと思います。

ページを表示するためにURLの読み込みが発生していないため、ページを下までスクロールした際に「scroll」イベント等を記録したタイミングで再訪問セッションが開始されるケースもあるということですね。

ページの閲覧に限らず、何かしらのイベント(サイト上の行動)を計測したタイミングでセッションは開始されます。

 

セッションが終了するタイミング

「30分操作がなくタイムアウトしたときにセッションは終了する」という仕様です。

例えば「ユーザーAが4月1日の23:59にサイトを訪問し、4月2日の0:30に離脱」というユーザー行動を計測する場合、セッションは1回しか計測されません。

日付が変わったタイミングで新しいセッションがカウントされるという仕様ではないためです。

 

GA4の「session_start」イベントとは

「session_start」とは、サイト訪問時に1ページ目で計測される「イベント」です。

セッション指標との違いや注意点を理解するために、少しだけGA4の基本的な仕組みに触れてから説明します。

 

GA4がサイト上のユーザー行動を計測する仕組み

ウェブサイトに実装されたGoogle タグがユーザーのサイト上の行動を「イベント」データとして計測し、サーバーに送信される(記録される)というのがGA4の基本的な仕組みですね。

Google タグが埋め込まれているウェブサイト上のユーザー行動を「イベント」という形式のデータでGA4のサーバーに送信する仕組み

 

GA4のイベント・パラメータ・値の基本的な構造の例

 

「session_start」イベントの特徴

「session_start」イベントはウェブサイト訪問時の1ページ目でGoogle タグが計測するイベントで、セッション番号(ga_session_number)とセッション ID(ga_session_id)が生成されパラメータにセットされます。

  • 1回のセッションで「session_start」が記録されるのは最初の1ページ目のみ
  • セッション中に記録されるイベントすべてに同じセッション番号(ga_session_number)とセッション ID(ga_session_id)がパラメータとして紐づく

 

 

「session_start」イベントと「セッション」指標が一致しない理由

「session_startイベントのイベント数の実績」と「セッション指標の実績」は、どちらもユーザーがサイトを訪問した際に計測するものですが実績は一致しないことがあります。

どのようなケースがあるのか解説します。

  • 1回のセッションで「session_start」が記録されるのは最初の1ページ目のみ
  • セッション中に記録されるイベントすべてに同じセッション番号(ga_session_number)とセッション ID(ga_session_id)がパラメータとして紐づく

という仕組みを理解していれば、違和感に気付けるはずです。

 

ケース 1:「ページ」ごとに「セッション」を集計

ページごとに「外部サイトから自サイトへ訪問した数」をカウントしたい場合は

  • 「ランディングページ」ごとの「セッション」指標
  • 「ページ」ごとの「閲覧開始数」指標

という組み合わせの集計が適切です。

「ランディングページ」とは、セッションで最初に閲覧されたページです。

これはセッション単位で記録される「セッションスコープのディメンション」なので、セッション指標と組み合わせて集計することができます。

※閲覧開始数の説明は後述。

一方、誤った集計の組み合わせの例としては、

  • 「ページ」ごとの「セッション」指標

というものがあります。

「ページパスとスクリーン クラス」など、ページ(URL)ごとに記録されるディメンションはイベント単位(イベントスコープ)のデータです。

1回のセッションで複数のページを閲覧した場合、「ページごとにユニークなセッションIDをカウント」という集計結果になってしまいます。

 

セッションIDはsession_startに限らずセッション中の各イベントに紐づくため「ページごとのセッションIDのユニーク数」となってしまいます。

 

「ランディングページ×セッション」の集計結果と「ページパスとスクリーン クラス×セッション」の集計結果

 

つまり、セッションが開始された数ではなく「セッション中に閲覧されたユニークビュー数」のような集計結果になります。(旧バージョンのGA=ユニバーサルアナリティクスで利用できた「ページ別訪問数」のような集計)

このような理由から、「ページ」と「ランディングページ」のセッション実績は一致しません。

 

ケース 2:「日付」ごとに「session_start」を集計

前段では、

「セッションが終了するタイミングは30分操作しないでタイムアウトした時」

「日付をまたいでもセッションは途切れず1回のセッションとして計測される」

「session_startイベントはセッションの最初のページでのみ計測される」

とご説明しました。

この仕様では、日付ごとの訪問数を評価するための集計をする際にsession_startイベントとセッション指標に差が出ることがあります。

理由は2つあります。

まず、ユーザーが訪問してから離脱するまでに日付をまたぐケースです。

 

  • 2025/04/01 の深夜にセッションを開始してから翌日2025/04/02にサイトを離脱
  • 2025/04/03 に再訪問

という2回の訪問をしたユーザーがいたとします。

2025/04/01 ~ 2025/04/03 の集計期間で日付ごとにsession_start とセッションを集計すると、2024/04/02はsession_startが記録されません。前日にアクセスした際の1ページ目でsession_startイベントを記録したセッションであるためですね。

一方、セッション指標は30分操作されなくなりタイムアウトするまで1回のセッションとして計測されます。

このような理由から、日付ごとのsession_startイベントとセッション指標は一致しません。

また、日付ごとのセッション指標の実績の合計は「集計期間中に記録されたセッション」とは一致しないことも覚えておきましょう。

各日付ごとに区切ってセッションをカウントすると、日付をまたいでいるセッションがそれぞれの日付ごとに1回ずつ記録されるので、すべて合計すると集計期間中のセッションより多くなります。

 

  1. 期間中のセッションを集計したレポートの合計行(ユニークなセッションIDをカウント)
  2. 期間中の日付別セッションを集計したレポートの合計行(ユニークなセッションIDをカウント)
  3. 各日付ごとのセッション実績の合計(日付×ユニークなセッションIDをカウントして合算)

 

GA4の「閲覧開始数」指標とは

「閲覧開始数」とは、「セッションの最初のイベントがページで発生した回数」です。


参考:[GA4] 閲覧開始数と離脱数 - アナリティクス ヘルプ


最初に計測されるpage_viewイベントには entrances = 1 というパラメータ・値が紐づくので、その数をカウントしています。

探索レポートでイベント名ごとの閲覧開始数を確認すると、page_viewイベントで記録されていることがわかる

この「最初に計測される」という点が少し厄介で、Google タグが配信される順番が非常に重要です。

 

config コマンドパラメータのGoogle タグを最初に配信する必要がある

ウェブサイトに実装されたGoogle タグがページ閲覧時に読み込まれることで、「自動収集イベント(session_start等)」や「拡張計測機能イベント(page_viewやscroll等)」が計測されます。

それだけではなく、Google タグは測定の基礎となるデータを構成する役割があります。

「最初に計測するpage_viewイベントには entrances = 1 というフラグを付与する」という仕様もその一つです。

よって、GA4の基本的なユーザー行動を計測するためのGoogle タグはページ閲覧時に最初に動作することが推奨されています。

GTMでタグを実装する場合も同様で、Google タグの配信トリガーは「初期化トリガー(Initialization - All Pages)」にすることが推奨されます。

 

※詳細は公式ヘルプを確認することをおすすめします。


参考:Google タグについて - タグ マネージャー ヘルプ

参考:タグ マネージャーと Google タグ(gtag.js) - タグ マネージャー ヘルプ

参考:タグ マネージャーで Google アナリティクスを設定する - タグ マネージャー ヘルプ

参考:Google タグとタグ マネージャー | Google Analytics | Google for Developers

参考:Google タグ API リファレンス | Google tag (gtag.js) | Google for Developers

参考:Google サービスを設定してイベントデータを送信する | Google tag (gtag.js) | Google for Developers

参考:[GA4] イベントについて - アナリティクス ヘルプ

参考:[GA4] 自動収集イベント - アナリティクス ヘルプ

参考:[GA4] 拡張計測機能イベント - アナリティクス ヘルプ

 

event コマンドパラメータのイベント計測タグはGoogle タグより後に配信する必要がある

 

注意すべき点として覚えておきたいのが「Google タグ配信より前に、その他のイベントを計測するタグが配信される実装は避けるべき」という点です。

 

例えば、カスタムイベントなどを計測する場合はGoogle タグの後にタグ配信するのが基本です。

セッションが開始された際や、新しいページ(URL)を閲覧する際にはまず最初にGoogle タグが配信され、それより後にカスタムイベントを計測するという順序が大前提です。

もし、config コマンドパラメータのGoogle タグ配信前に別のイベントを計測してしまうと、最初に=1回目に配信されたGoogle タグが「何かしらイベントを計測した後に配信された」とみなされ、本来の挙動とは異なるセッションの計測をしてしまうことが懸念されます。

 

このような場合「最初に計測するpage_viewイベントに entrances = 1 というフラグが付与されない」という計測の仕方になるため、閲覧開始数をカウントできないケースがあります。


参考:ページビューの測定 | Google Analytics | Google for Developers

参考:シングルページ アプリケーションを測定する | Google Analytics | Google for Developers

 

「閲覧開始数」と「セッション」が一致しない理由

  • 「閲覧開始数」とは、「セッションの最初のpage_viewイベントの回数」である
  • 「セッション」とは、「ユーザーがウェブサイトに訪問してから、30分以上GA4で何も計測することが無くなったタイミングを離脱と見なして区切りをつけた訪問回数」である

という説明を並べると、閲覧開始数とセッションの実績は同一であると思いますが、一致しないケースがあります。

 

セッションは「新規訪問または過去のセッションのタイムアウト後にイベントを記録したタイミング」で開始するため、下記のケースでは【セッションは記録するが閲覧開始数は記録しない】という結果になります。

 

ケース 1:「page_view」イベントが計測されなかったセッション

ウェブサイトに実装されたGoogle タグがページ閲覧時に読み込まれると session_start や page_view イベントは自動的に記録されます。

しかし、「Google タグが読み込まれず page_view イベント記録されないセッション」では閲覧開始がカウントされません。

 

探索レポートでpage_viewイベントが記録されたセッションと記録されなかったセッションのセグメントごとに比較した集計結果

 

閲覧開始数は「セッションの最初のpage_view イベント」をカウントするものなので、表示回数が0のセッションでは閲覧開始数も0になります。

探索レポートで「表示回数 = 0」というフィルタを適用して閲覧開始とセッションを集計した結果

 

例えば、初回訪問した記事ページを閲覧したブラウザのタブを開きっぱなしで放置してセッションがタイムアウトしたケースです。

タイムアウトしたことで初回訪問セッションは終了します。その後、開きっぱなしのタブで閲覧を再開し、記事ページの最下部までスクロールして、読了後にタブを閉じたとしましょう。

「scroll」イベントを計測したタイミングで再訪問セッションが開始されますが、この時「page_view」イベントは計測されません。

すでにページが表示されている開きっぱなしのタブから閲覧を再開したので、ページ(URL)の読み込みをしない=ソースコードに埋め込んだGoogle タグが配信されないという状況です。

セッションはpage_viewイベントではなく「ユニークなセッションIDをカウントする指標」なので、このようなケースではセッションは記録されますが閲覧開始数は0となります。

 

ケース 2:「page_view」イベントより先にカスタムイベントが計測されたセッション

ケース 1で提示した例では「page_viewを記録しない再訪問セッション」でしたが、

「page_view以外の別イベントを記録し、その後page_viewイベントを記録したセッション」はどうでしょうか。

click やscroll、またはカスタムイベントやオーディエンストリガーのイベントなど「ページ閲覧ではないユーザー行動を計測するイベント」の後にpage_viewを記録するケースですね。

探索レポートでpage_viewイベントを記録したセッションのセグメントを適用し、閲覧開始数とセッションの実績を比較してみます。

 

探索レポートでpage_viewイベントを記録したセッションのセグメントを適用し、閲覧開始数とセッションの実績を比較した集計結果。

 

page_viewイベントが記録されているセッションを対象としているため、「セッション開始時に配信したGoogle タグで記録されるpage_view」には entrancesパラメータに 1 という値がセットされるので閲覧開始数をカウントします。

しかし、探索レポートの集計結果を見ると「page_viewイベントの閲覧開始数よりもセッションが多い」ケースが確認できました。

これは、「entrancesパラメータに 1 という値がセットされたpage_viewの数よりも、ユニークなセッションIDの数が多い」と言い換えられます。

「page_view以外の別イベントを記録し、その後page_viewイベントを記録したセッション」では上記のような集計結果になることがあります。

 

Google タグの配信よりも先に別のイベントが記録されるセッションでは

  1. 「Google タグ配信時に記録するpage_view以外のイベント」を計測するタグが最初に配信される
  2. 次にGoogle タグが配信されてpage_viewイベントが計測される

という順序でタグ配信・イベント計測をします。

このケースでは 2. のタイミングで記録されるpage_viewイベントに entrancesパラメータに 1 という値がセットされません。

「後から配信したGoogle タグ」で記録されるpage_viewイベントには entrancesパラメータに 1 という値がセットされなくなるためです。

結果、page_viewイベントを記録したセッションにも関わらず閲覧開始数は 0 となります。

オーディエンストリガーの計測時や、開きっぱなしのタブから閲覧を再開した再訪問セッションなどが該当します。

 

GA4の「ランディングページ」ディメンションとは

「ランディング ページ」とは、「セッションの最初に閲覧されたページ」です。

ランディングページはsession_startイベントの page_location パラメータに記録されたURLではありません。

page_view イベントに紐づく entrances パラメータの値が 1と記録されたページが対象となります。

(セッションの最初のpage_viewのみ 1 という値がセットされます。)


参考:[GA4] ランディング ページ - アナリティクス ヘルプ

参考:[GA4] ランディング ページ レポート - Android - アナリティクス ヘルプ

参考:ランディングページがディメンションに追加 – Google Analytics 4 ガイド

 

ランディングページが (not set) になるケース

GA4で「ランディング ページ」ディメンションを利用した集計を行うと (not set) の行が表示されることがあります。

(not set) とは、何らかの理由でディメンションに記録する情報を取得できなかった際に格納される値です。


参考:[GA4] レポートに表示される「(not set)」という値の意味 - アナリティクス ヘルプ

 

ケース 1:「page_view」イベントが計測されなかったセッション

page_viewイベントを記録しないセッションではランディングページが (not set) と記録されます。

「entrances パラメータの値が 1と記録されたpage_view イベント」が存在しないためですね。

同じ理由で閲覧開始も0になります。

セッションがタイムアウトした後、開きっぱなしのタブから閲覧を再開したセッションなどが該当します。

 

ケース 2:「page_view」イベントより先にカスタムイベントが計測されたセッション

サイトに実装されたGoogle タグの配信よりも先に、オーディエンストリガーやカスタムイベント等のタグが配信されるケースもランディングページが (not set) と記録されます。

閲覧開始数が0となるセッションでも同様の解説をしましたが、「セッション中、何かしらのイベント計測をした後に配信されるGoogle タグで計測される page_view イベントには entrances パラメータに 1 という値がセットされない」という仕様のためです。

 

ケース 3:セッション終了後にブラウザを閉じる、又はタブを閉じる

GA4では「ユーザーエンゲージメント」という指標があり、「ウェブページがフォーカス状態にあった時間、またはアプリの画面がフォアグラウンド表示されていた時間の長さを指す」と公式ヘルプページで説明されています。

  • ページを表示していたタブを閉じる、ブラウザを閉じるといったタイミングで user_engagementイベントを記録する
  • user_engagementイベントに紐づくengagement_time_msec というパラメータにエンゲージメント時間を記録する

[GA4] ユーザー エンゲージメント - アナリティクス ヘルプ

セッション中に何かしらイベントを計測したタイミングと、user_engagementイベントを記録したタイミングを測ることで、エンゲージメント時間が算出されるという仕組みですね。

では、「ページを閲覧していたブラウザのタブを放置してセッションがタイムアウトした後、ブラウザ又はタブを閉じる」といったユーザー行動がGA4で計測されると、ランディングページはどのような計測結果になるでしょうか。

ブラウザを閉じた際の user_engagementイベント計測時に記録された再訪問セッションなので、ランディングページは (not set) となります。

このような検証を株式会社プリンシプル 取締役フェローの木田 和廣氏が個人ブログでわかりやすく共有してくださっていますので、ご興味がある方はぜひご覧ください。


参考:[GA4] ユーザー エンゲージメント - アナリティクス ヘルプ

参考:[GA4] 自動収集イベント - アナリティクス ヘルプ

参考:GA4のユーザーエンゲージメント(時間)を検証してみた – kazkida.com

 

GA4で集計する際に注意が必要な仕様

最後に、セッションに限らずGA4で集計をする際に集計精度に影響のある仕様に触れていきます。

「集計した指標の数値がブレる理由」として理解しておきたいところですね。

 

データ サンプリング

サンプリングとは、集計するデータ量が多い場合などで適用される仕様です。

集計するデータ量が1,000万イベントを超えるような複雑・長期間のレポート集計時に、レポートの上に警告するようなラベルが表示されます。

この状態の標準・探索レポートにはサンプリングが適用されています。

サンプリングが適用されると、すべてのデータを集計するのではなく一部のデータをサンプルとして集計し、全体の実績を予測(推測)した値を表示します。

 

参考:[GA4] データ サンプリングについて - アナリティクス ヘルプ

参考:GA4レポートの落とし穴 ”サンプリング”に要注意!| イー・エージェンシー

 

しきい値

しきい値とは、ユーザーの年齢や性別、インタレストカテゴリなどの「ユーザー属性データ」等のユーザー関連の情報を集計する際に適用される仕様です。

サンプリングと同様に、GA4管理画面上では警告するようなラベルが表示されます。

しきい値が適用されると、ユーザーのプライバシーに配慮して高精度な集計ができないよう「データが一部除外された集計結果」を表示します。

 

参考:[GA4] データのしきい値について - アナリティクス ヘルプ

 

データの更新速度

Google タグやイベントタグで計測されたデータが管理画面上の各種レポートに反映・表示されるまでにはタイムラグがあります。

当日や前日といった直近の実績を集計する際には、未反映のデータがあることも注意が必要です。

参考:[GA4] データの更新速度とサービスレベル契約の制約 - アナリティクス ヘルプ

 

(other) 行

  • 直近72時間以内に記録されたデータを含む集計
  • ディメンションごとのユニークな値(基数)が50,000行以上となる集計
  • 高基数と呼ばれる、様々な判定結果をするディメンションの集計

このような集計を行うと、行数がまとめられた(other) 行が出現します。

 

 

ランディングページの行数が非常に多い場合などは、(other)行に集約されるケースがよくあります。


参考:[GA4]「(other)」行について - アナリティクス ヘルプ

参考:[GA4]レポートで(other)が表示される理由 | アユダンテ株式会社

 

HyperLogLog++(HLL++)アルゴリズムによる近似値

GA4はアクティブ ユーザーやセッションの数を集計する際、データの集計にかかる負荷を軽減するためにHyperLogLog++(HLL++)というアルゴリズムによって推定値を算出しています。

この仕様により、データすべてを対象に膨大な量のデータを集計したものと比較しても、高精度の集計結果を高いパフォーマンスでレポート画面に出力できます。

よって、GA4管理画面やLooker StudioなどのData API経由の集計はローデータではなく近似値(推定値)で表示されます。これはデフォルトで適用されている仕様であり、詳細を管理画面などから確認することはできません。

ローデータで集計をしたい場合はBigQueryにGA4のデータをエクスポートして集計する必要があります。


参考:Google アナリティクスにおけるユニーク カウントの近似値 | Google Analytics | Google for Developers

参考:Google アナリティクスの UI と BigQuery エクスポートのギャップを埋める | Google Analytics | Google for Developers

参考:スケッチ | BigQuery | Google Cloud

参考:HyperLogLog in Practice

 

オーディエンストリガー

GA4管理画面で設定できるカスタム設定で「オーディエンス」「オーディエンストリガー」という項目があります。

  • オーディエンス:特定の条件を満たしたユーザーをグループとして分類するカスタムディメンション
  • オーディエンストリガー:ユーザーがオーディエンスで定義された条件を満たしてグループに追加された際に計測するカスタムイベント

 

「日本からアクセスしたユーザー」「ページAを閲覧後にページBを閲覧したユーザー」など特定の条件を定義しておくユーザーごとのグループ化機能です。

このオーディエンスの定義に合致したタイミングで計測されるという仕様が厄介で、

  • ランディングページが (not set) になる
  • 閲覧開始数がカウントされない
  • ga_session_numberが (not set) になる ※カスタムディメンションとして登録している場合

といったセッションが記録されることがあります。


参考:[GA4] Google アナリティクスのオーディエンスの概要 - アナリティクス ヘルプ

参考:[GA4] オーディエンス トリガー - アナリティクス ヘルプ

 

「セッション」の解像度は、役割や目的で変わってOK

GA4をWebマーケティングの武器として活用していくなら、セッションについては、「訪問回数をカウントした指標」とだけ理解できていれば十分です。

一方で、データを分析する方やタグ実装や各種設定を管理するような役割を担う方は、今回触れたようなレベルまで理解しておかないと、誤った分析をしてしまう恐れがあります。

解説記事が誰かの、何かのお役に立てば嬉しいです。

困った時に検索・字引きをする辞書のように読んで使ってもらえたらいいなと思っています。

参照元の仕様やイベントのバッチ処理など、今回の記事では触れていない部分はまたいつか記事にしようと思いますので、興味があればぜひそちらもよろしくお願いいたします。

ここまで読んでくださりありがとうございます!それではまた来月の #現場で役立つGA4 でお会いしましょう~。

 

 


Viewing all articles
Browse latest Browse all 109

Trending Articles