GA4のセッション数の仕様｜session_start・推計・UAとの違い

GA4の「セッション」は、session_startイベントの件数と常に一致する指標ではありません。GA4はセッションを識別する情報からセッション数を推計します。イベント件数との比較やBigQueryでの再集計では、識別子、期間、収集条件、集計方法をそろえて差を調べる必要があります。

セッションが始まる条件と識別子

進行中のセッションがない状態で、Webページやアプリ画面を表示する、またはアプリをフォアグラウンドで開くと、セッションが始まります。通常、session_startが自動収集され、セッションIDのga_session_idと、何回目のセッションかを示すga_session_numberが生成されます。詳細はGA4のセッションの公式説明を参照してください。

既定では30分間操作がないとタイムアウトします。この値は設定で変更できます。操作が続くセッションに、30分という総時間の上限があるわけではありません。タブを閉じる、別のサイトを見る、日付が変わるという事実だけから、毎回新しいセッションが始まったと判断するのも適切ではありません。基本的な訪問の数え方はPV・ユーザーと比較した時系列例で確認できます。

セッション数・開始イベント数・BigQueryの数を区別する

GA4はHyperLogLog++による推計を使用するため、観測データを独自に厳密集計した結果と小さな差が生じ得ます。ただし、「推計だから必ず少なくなる」とは言えません。差の方向を決めつけず、実装と集計条件の違いも確認します。

BigQueryの値も、実際に起きたすべての訪問を完全に表すとは限りません。エクスポートされた範囲、同意や識別子の欠損、遅れて届くイベントなどの影響があります。独自集計が厳密であることと、観測できなかった行動まで完全に含むことは別です。

ga_session_idだけを一意キーにしない

ga_session_idはセッション開始時刻を秒単位で表す値です。異なるユーザーが同じ秒に開始すると、同じ値を持つ可能性があります。独自集計ではuser_pseudo_idなどの適切なユーザー識別子と組み合わせ、採用したキーを記録します。

架空例で、ユーザーAとBのga_session_idがどちらも1234567890でも、A＋1234567890、B＋1234567890という組み合わせは2種類です。IDだけの重複排除なら1と誤集計します。識別子がない行をすべて1つにまとめる、あるいは説明なく除外する処理も避け、件数と扱いを明示してください。

Measurement Protocolやデータインポートで送るイベントには、通常の自動収集と同じようにセッション情報が自動付与されるとは限りません。公式仕様と用途に応じて必要な情報を設計します。数字を合わせるためにすべてのイベントへ固定のセッションIDを付ける方法は、別の訪問を混ぜる原因になります。

GA4とUAの訪問の区切りは同じではない

過去のUAとの比較では、GA4とUAの指標比較とUAのセッション定義を分けて参照します。UAの歴史的な仕様を、現在のGA4の操作説明に混ぜないことが大切です。

架空例として、同じ識別ユーザーが23時55分にAページ、翌0時5分にBページを表示したとします。途中にタイムアウトがなく、計測が正常ならGA4では同じセッションです。UAでは日付境界で区切られます。UAより少ない値になる理由の一つですが、差がすべて仕様通りと判断できるわけではありません。

UAは現在の新規計測先ではありません。標準UAは2023年7月、対象UA 360は2024年7月に新規データ処理が終了しています。保存済みデータとの比較条件は公式のUA終了案内も確認します。

日別の足し算と期間全体の集計を無条件に同じとしない

日別の行、参照元別の行、期間全体の合計では、重複排除や推計を行う集計範囲が異なります。各行を足した値が、別の条件で取得した合計と必ず一致するとは限りません。特に独自集計では「期間内に開始したセッション」か「期間内にイベントがあるセッション」かも定義します。

日付をまたぐセッションを独自集計するとき、初日の開始イベントだけを数えるのか、翌日のイベントからも識別するのかで結果が変わります。比較対象の定義に合わせて抽出し、GA4の差を説明する際に異なる定義の数字を並べないでください。ページ表示の集計方法はGA4のPV確認手順でも確認できます。

エンゲージメントのあったセッションは成果人数ではない

既定では、10秒を超える、キーイベントが発生する、2回以上のページまたはスクリーン表示がある、のいずれかを満たすセッションがエンゲージメントの対象です。時間条件は設定で変更できます。first_visit、first_open、session_startは、キーイベントとして扱ってもこの判定のキーイベント条件には使われません。根拠はエンゲージメント率と直帰率の公式説明です。

これは活動条件であり、登録成功や満足を保証しません。セッション時間と、画面が前面で利用されていたエンゲージメント時間も別の概念です。成果は成功条件を確認したイベントと適切な分母で評価します。

数値が合わないときの調査順

1. 同じプロパティ・期間・タイムゾーン・Web／アプリ・ホストで比較する。
2. 比較している値がセッション指標か、イベント数か、独自集計かを確認する。
3. フィルタ、比較、ディメンションの集約範囲をそろえる。
4. 欠損ID、同意状態、手動送信、重複・送信失敗を確認する。
5. 処理状況を確認し、完了した期間で再比較する。常に72時間以内に確定するとは断定しない。
6. 残る差を、推計・収集・期間境界のどれで説明できるか記録する。

推計値とイベント件数の違いを理解すれば、単なる一致を目標にせず、原因ごとに調査できます。数え方と抽出条件を残すことが、継続比較に使えるセッション分析につながります。