GA4でスクロール率を確認する方法｜標準計測とGTMでの追加設定を分けて解説

GA4で「どこまで読まれたか」を調べたいとき、最初に確認するのはスクロールイベントの条件です。

標準のスクロール計測は、ページの90％付近に到達したことを捉える仕組みです。

25％、50％、75％の到達を、最初からすべて記録しているわけではありません。

また、「スクロール済みの割合」と「そこまで到達した人の割合」は、意味が異なります。

この記事では、GA4の標準設定を確認し、ページ別に数値を取り出し、必要な場合だけGTMで途中の到達を追加する順番を解説します。

最後には、そのまま社内の設定依頼に使える「スクロールイベントの設計・確認表」を載せています。

GA4のスクロール計測を確認する

設定を変える前に、何を数えているのかをそろえます。

標準イベントの条件を調べる

GA4の拡張計測機能では、ページの垂直方向で90％の位置まで表示されたときに、標準の scroll イベントを記録します（参考：Googleの拡張計測機能）。

同じページを少し上下するたびに、移動量を連続して送っている仕組みではありません。

途中で読むのをやめた位置を、標準の scroll だけから細かく復元することもできません。

たとえば、記事の前半で離れた場合も、90％の直前で離れた場合も、このイベントが記録されない場合があります。

イベントがないという結果だけでは、両者を区別できません。

「スクロール済みの割合」は、到達したページ内の深さを表すディメンションです。

その値に90と表示されても、訪問者の90％が到達したという意味ではありません（参考：Googleのスクロール関連ディメンション）。

知りたいこと	確認する情報	その情報だけでは分からないこと
ページの終盤まで到達したか	標準のscroll	途中のどこで止まったか
前半・中盤まで到達したか	追加した到達地点のイベント	文章を理解したか
重要な説明が画面に出たか	特定要素の表示イベント	注意して読んだか
到達した人の割合はどれくらいか	条件をそろえた分子と分母	到達が成果を生んだか

まず、このうちどの問いに答えたいのかを1つ選んでください。

率の分母を決める

ここでは、社内で使う補助指標として「対象ページを見たユーザーのうち、90％に到達したユーザーの割合」を定義します。

計算式は次のとおりです。

90％到達ユーザー率
＝ 対象ページでscrollがあった合計ユーザー数
÷ 対象ページでpage_viewがあった合計ユーザー数 × 100

分子と分母は、同じURL、期間、端末、対象ストリームで集計します。

例として、対象ページを見た200ユーザーのうち、80ユーザーで scroll が記録されたなら40％です。

この数値は説明用の架空例です。

80件のイベントを200ユーザーで割る計算とは、区別してください。

GA4の合計ユーザー数は、対象期間にイベントを発生させたユニークユーザーの数です（参考：Googleのユーザー指標）。

同じ人がページを何度も開く可能性があるため、イベント件数とユーザー数は一致するとは限りません。

分母を表示回数にする場合は、ユーザー単位の到達率とは別の名前で管理します。

分母が0の場合は0％と埋めず、算出対象外とします。

この定義をレポートの冒頭に残すだけでも、担当者ごとに違う率を報告する混乱を防げます。

GA4の拡張計測機能を点検する

GA4に基本のページ計測が入っていることを前提に、対象サイトの設定を確認します。

対象データストリームを確認する

最初に、GA4のプロパティ名、ウェブストリーム名、サイトURL、測定IDを控えます。

代理店や複数サイトの担当者は、別のクライアントの設定を開いていないか確認してください。

操作は、管理画面の「データの収集と修正」から「データストリーム」を開くところから始めます。

対象のウェブストリームを選び、「拡張計測機能」の設定を開きます。

個別の計測項目で、スクロールが有効になっているかを確認します。

設定変更には編集者以上の権限が必要です（参考：拡張計測機能の設定手順）。

ここで、他の計測項目までまとめて変更する必要はありません。

すでにGTMや別のスクリプトでスクロールを計測している場合は、担当者にイベント名と発火条件を確認します。

標準の scroll と同名のイベントを独自に送っていると、画面上の名前だけでは送信元を見分けにくくなります。

変更前の設定と確認日を記録し、追加が必要か判断してください。

実際のイベント受信を確かめる

スイッチがオンになっていても、対象ページから正しく送信されているかは別に確認します。

自分の端末をTag Assistant、またはGTMのプレビューモードに接続します。

GA4では「管理」から「データの表示」に進み、DebugViewを開きます。

自分のデバッグ端末を選び、対象ページを開いてから終盤までスクロールします。

表示された scroll を選び、対象ページのURLとイベントのパラメータを確認します（参考：GoogleのDebugView）。

確認するのは「何かイベントが来たか」ではなく、「今操作したページのイベントが来たか」です。

別タブで開いたページや、他の担当者のテストを混ぜないようにします。

同意の状態によっては、DebugViewにイベントが表示されない場合があります。

その場合は、同意を無視して計測を強制するのではなく、想定した同意状態とタグの動作を照合してください。

通常の集計レポートにすぐ出ないことだけで、設定失敗とは判断しません。

まず送信の確認と、集計画面への反映待ちを分けます。

GA4でページ別のスクロールを確認する

全サイトの合計ではなく、改善したい記事やLPに対象を絞ります。

URLと期間を絞る

自由形式の探索を使うと、ページとイベントを並べて確認できます（参考：Googleの自由形式のデータ探索）。

初めて作る場合は、次の形から始めてください。

1. GA4の「探索」から自由形式を開く。
2. ディメンションに「ページの場所」「イベント名」「デバイスカテゴリ」を追加する。
3. 指標に「イベント数」と「合計ユーザー数」を追加する。
4. 行に「イベント名」を置き、値に2つの指標を置く。
5. フィルタで「ページの場所」を対象URLに絞る。
6. イベント名を page_view または scroll に絞る。
7. 調べたい期間を指定し、2行の数値を確認する。

イベント名のフィルタを正規表現で指定する場合は、次を使えます。

^(page_view|scroll)$

この表から、対象ページの scroll 行と page_view 行の合計ユーザー数を取り出します。

先ほど定義した到達ユーザー率は、この2つの数で計算します。

フィルタで scroll だけを残したまま、表全体のユーザー数を分母にしないでください。

それでは、到達した人だけを母集団にしてしまいます。

URLに広告用パラメータが付く場合、完全一致では一部の閲覧だけを抽出する可能性があります。

ページのパスで集約するか、対象のパラメータ付きURLも含めるかを決めます。

複数ドメインに同じパスがあるサイトでは、ホスト名も合わせて固定してください。

毎月使う表には、対象URLの条件と集約方法を名前やメモに残します。

端末ごとの差を分ける

次に、同じ探索をPCとスマートフォンに分けます。

同じ記事でも、画面の高さ、文字の折り返し、画像の並び方が異なるためです。

PCでは1画面で見える説明が、スマートフォンでは数画面先に移ることがあります。

ページ全体の50％という位置も、同じ見出しを指すとは限りません。

「スマートフォンの到達率が低い」と分かったら、実際のスマートフォン表示を開いて位置を照合します。

最初に、比較する期間とページの版をそろえてください。

片方は改修前、もう片方は改修後のデータでは、端末差を切り分けにくくなります。

広告流入の増加やキャンペーンの切り替えも、あわせて記録します。

集計条件をそろえてから、重要な説明やCTAの位置を調べると、次の確認先を決めやすくなります。

GTMで追加のスクロール計測を設計する

90％到達だけでは改善箇所を絞れない場合に、途中の地点を追加します。

必要な到達地点を決める

追加設定の例として、ページの25％、50％、75％を計測します。

これは推奨値がすべてのサイトで同じという意味ではなく、前半・中盤・後半を区切るための設計例です。

GTMでは、次の手順でトリガーを用意します。

1. 「トリガー」から「新規」を選ぶ。
2. 「トリガーの設定」で「スクロール距離」を選ぶ。
3. 縦方向のスクロール距離を選び、単位を割合にする。
4. しきい値に 25,50,75 を入力する。
5. 有効化のタイミングは、まず既定のウィンドウの読み取りで確認する。
6. 対象を必要なページに限定し、分かる名前で保存する。

公式仕様では、指定した地点ごとに初めて到達したときに発火し、ページの再読み込みなどで再び発火可能になります（参考：GTMのスクロール距離トリガー）。

75％まで進むと、25％、50％、75％のそれぞれでイベントを送る設計です。

3件のイベントがあるからといって、3人が到達したわけではありません。

特定の「料金表が見えたか」を知りたい場合は、割合より要素の表示を計測する方が目的に合うことがあります。

要素の表示トリガーでは、対象をIDやCSSセレクタで指定し、表示割合や表示時間の条件を設定できます（参考：GTMの要素の表示トリガー）。

ページ内のすべての要素を監視するのではなく、判断に必要な見出しやCTAだけを対象にします。

標準イベントと区別する

この例では、追加イベントを scroll_depth と名付け、標準の scroll と分けます。

これは本記事の設計例であり、GA4が自動作成する標準イベント名ではありません。

GTMの組み込み変数で、Scroll Depth Thresholdを有効にします。

この変数には、発火したしきい値の数値が入ります（参考：GTMの組み込み変数）。

「タグ」から新規作成し、GoogleアナリティクスのGA4イベントタグを選びます。

対象ストリームの測定ID、イベント名、イベントパラメータを設定します（参考：GTMでGA4イベントを設定する手順）。

設定欄	この例で入力する内容
イベント名	scroll_depth
パラメータ名	percent_scrolled
パラメータ値	{{Scroll Depth Threshold}}
トリガー	先ほど作った25・50・75％のトリガー
測定ID	対象サイトの実際の測定ID

基本のGoogleタグがすでに設定されている場合は、同じ目的のタグを重ねて追加しないよう管理者に確認します。

標準の90％計測は残し、追加した3地点とは別に集計します。

探索ではイベント名を scroll_depth に絞り、「スクロール済みの割合」で25、50、75の行を分けます。

percent_scrolled は既存ディメンションに対応するパラメータなので、最初から同じ内容のカスタム定義を増やす必要はありません。

独自の分類を追加する場合も、事前定義されたディメンションがないかを先に確認してください（参考：Googleのカスタムディメンション作成前の確認事項）。

送信条件、名前、集計方法を1組として残しておくと、後から別の担当者が意味を確認できます。

GTMとGA4で重複を検証する

保存した設定をすぐ全体へ公開せず、手元の操作で期待したイベントを確かめます。

プレビューで発火を確認する

GTMのワークスペースで「プレビュー」を選び、対象サイトのURLへ接続します。

Tag Assistantでは、発生したイベントと、配信されたタグを確認できます（参考：GTMのプレビューとデバッグ）。

長いテストページを開き、ゆっくり25％、50％、75％まで進めます。

それぞれの地点でGA4イベントタグが発火し、パラメータに異なるしきい値が入るかを確認します。

同じページで上下しても、同じ地点のイベントが何度も増えないかを見ます。

次に、GA4のDebugViewでも scroll_depth と percent_scrolled を確認します。

GTMでタグが発火したことと、GA4が正しい内容を受信したことを、両方確かめてください。

テスト操作	この設計で期待する結果	想定外なら調べる点
長いページを75％まで進む	25・50・75の3地点が記録される	しきい値とトリガー条件
同じ地点を上下する	同一ページで同じしきい値を繰り返し送らない	重複タグ、独自スクリプト
標準の90％地点まで進む	標準scrollと追加イベントを区別できる	イベント名の混在
対象外のページを開く	追加イベントを送らない	URLの限定条件

1回の操作で同じ追加イベントが2件ずつ届く場合は、タグをもう1本増やすのではなく、送信元を確認します。

GTM、サイトへの直書き、CMSのプラグインに似た処理がないかを調べます。

確認後は、変更内容と対象ページをバージョンの説明に残して公開します。

通常アクセスでも受信を確認してから、計測開始日を台帳に記録してください。

短いページや画面変更を試す

短いページでは、読み込み直後にしきい値が画面内へ入ることがあります。

GTMのスクロール距離トリガーは、この場合、実際にスクロールしていなくても発火します（参考：スクロール距離の発火条件）。

「操作していないのに記録された」という結果だけで、二重計測と決めないでください。

長いページだけでなく、短いページ、画像が遅れて出るページ、画面の縦横を変えた場合も試します。

無限スクロールなどでページの高さが大きく変わる場合は、割合による計測が目的に合うかを見直します。

再読み込みなしで画面が切り替わるSPAでは、切り替え後のURLとページビューも確認が必要です。

Googleの資料でも、仮想画面ごとの page_view とページ情報の更新を検証する手順が示されています（参考：GoogleのSPA計測）。

画面Aを深くスクロールした後で画面Bへ移動し、Bの到達として正しく記録されるかを試してください。

ページビューが切り替わっただけで、独自のスクロール処理も必ず正しくリセットされるとは決めつけません。

そのまま使えない場合は、画面の識別と到達状態のリセット条件を、実装担当者と設計します。

GA4のスクロール率を改善に使う

正しく計測できたら、数値を上げることより、ページのどこを確かめるかに使います。

読了と到達を分ける

ページの下部に到達しても、その間の文章をすべて読んだとは限りません。

目次で移動した人も、料金だけを探した人も、同じ深さへ到達する可能性があります。

反対に、最初の画面で必要な答えを得た人は、下まで進まない場合があります。

したがって「90％到達率が低いから記事の品質が低い」とは断定できません。

判断するときは、そのページが何を解決するものかを思い出してください。

製品の仕様をすぐ知りたいページと、手順を順番に読むページでは、望ましい行動が異なります。

途中の位置を画面上で確認したい場合は、スクロールヒートマップも役立ちます。

Clarityでは、対象URL・期間・端末を選び、ページ内の各位置へ到達した割合を可視化できます（参考：Microsoftのスクロールマップ）。

GA4とClarityは集計対象が同じとは限らないため、割合の完全一致を確認目的にしないでください。

GA4で調べる対象を絞り、ヒートマップや実ページで、その位置に何があるかを見る流れです。

CTAと成果も確認する

CTAを上へ移動すると、スクロールが浅いまま次へ進む人が増えることがあります。

この場合、到達率が下がっても、問い合わせや申込が増えていれば、目的に合う改善かもしれません。

到達率だけで施策を戻さず、CTAの操作と実際の完了をあわせて確認します。

次の表は、設定を依頼するときに使える架空の記入例です。

項目	スクロールイベントの設計・確認表
対象	サービス紹介LPのスマートフォン表示
知りたいこと	料金説明の前まで進んでいるか
標準計測	scrollによる90％到達
追加計測	scroll_depth、25・50・75％
比較条件	同じURL、端末、期間、ページの版
分母	対象ページのpage_view合計ユーザー数
分子	対象地点に達した合計ユーザー数
検証	Tag AssistantとDebugViewで地点とURLを照合
改善案	料金への案内を、サービス説明の直後にも置く
成果の確認	CTA操作と問い合わせ受付の完了

改修前後では、スクロール地点の定義やタグの設定も変わっていないか確認します。

文章を大幅に短くすると、同じ50％でも別の内容を指すようになります。

重要な見出しの位置も記録しておけば、割合の変化を解釈しやすくなります。

まず1ページで「何を数えるか」「どのイベントで取るか」「どう確かめるか」をそろえてください。

そのうえで、数字が変わった場所にある文章や導線を、実際の表示で確認しましょう。