GA4の離脱率はどこで見る？離脱数・直帰率との違いと調べ方

GA4で「離脱率」を探しても、見たい表が見つからない。

直帰率を代わりに見ればよいのか、迷うこともあると思います。

まず確認するのは、探索で見られる「離脱数」と、そのページの役割です。

申込みが終わったページから離れることと、入力途中で進めずに離れることは、改善上の意味が違います。

この記事では、離脱数をページ別に表示する手順、割合を自分で計算するときの注意点、経路と録画で原因を調べる流れを解説します。

最後に「離脱の定義と対象ページの調査表」へまとめ、次に調べるページを決めます。

操作名と定義は2026年10月5日に確認したGoogleなどの公式資料に基づき、本文の数値は説明用の架空例です。

GA4の離脱率を調べる前に

離脱の分析では、件数、割合、訪問の質を表す指標を分けます。

名前が似ていても、分母や数え方が違う指標を置き換えないことが大切です。

離脱数と割合を分ける

GA4の離脱数は、セッション内の最後のイベントが、そのページや画面で発生した回数です（参考：GA4の閲覧開始数と離脱数）。

ブラウザの閉じるボタンを押した回数を、そのまま集計しているわけではありません。

Googleの公式手順では、この離脱数を探索で確認します。

「離脱率」という列が見つからないときは、まず離脱数と表示回数を取り出してください。

社内で割合も使う場合は、たとえば次のように計算式を明記します。

表示回数に対する離脱数の比率 ＝ 離脱数 ÷ 表示回数 × 100

表示回数が500回、離脱数が100回なら、この計算では20％です。

これは、ここで定義した補助的な集計であり、GA4の直帰率ではありません。

また「訪問者の20％が離れた」とは言えません。

表示回数には同じページの繰り返し表示も含まれるからです（参考：GA4の表示回数）。

同じセッションでページを何度も開けば、分母は増えます。

比率を小さくするためにページの再読み込みを増やしても、利用者が目的を達成しやすくなるわけではありません。

比較するときは、計算式と分母を表の見出しに残してください。

直帰率との違いを確認する

GA4の直帰率は、エンゲージメントのなかったセッションの割合です。

エンゲージメントの判定には、継続時間、キーイベント、ページや画面の表示回数が関係します（参考：GA4の直帰率の定義）。

「最後に記録されたページはどこか」という離脱数とは、見ている対象が違います。

たとえば、商品ページからカート、注文完了へ進んだセッションを考えます。

この場合も最後に離脱する場所はありますが、単に離脱したから直帰になるわけではありません。

調べたいこと	主に使う情報
セッションの最後がどのページか	離脱数
表示に対して離脱がどの程度あるか	定義を明記した独自の比率
エンゲージメントのない訪問がどれだけあるか	直帰率
手順の途中から次へ進まない人がいるか	ファネルや経路の確認

直帰率の数字を離脱率という名前で報告すると、改善したい問題が伝わりにくくなります。

直帰率の詳しい表示方法は、GA4の直帰率を調べる手順で整理しています。

GA4で離脱したページを確認する

最初の表は、ページと離脱数だけの簡単な形で作ります。

表示できることを確認してから、表示回数や端末などを追加します。

現行の指標と探索を確認する

GA4で対象のプロパティを選び、左側の「探索」から自由形式を作成します。

以下の順に設定すると、ページ別の一覧を作れます。

1. 分析する開始日と終了日を指定する
2. ディメンションに「ページタイトルとスクリーン クラス」を追加する
3. 指標に「離脱数」と「表示回数」を追加する
4. 設定の「行」にページのディメンションを入れる
5. 「値」に2つの指標を入れ、表で表示する
6. 離脱数の多い順に並べ、対象ページを確認する

Googleは離脱数の確認例として、自由形式とページタイトルの組み合わせを案内しています（参考：離脱数を探索で確認する）。

自由形式では、行、列、値、フィルターを組み替えて集計できます（参考：自由形式の設定）。

表が空の場合は、期間、適用したフィルター、指標とディメンションの組み合わせを確認します。

まず余分な条件を外し、単純な表が出るか確かめてください。

標準レポートには古いデータがあるのに探索では出ない場合は、データ保持期間も確認します。

Googleの保持設定は探索へ影響するため、標準の集計レポートと同じ期間を見られるとは限りません（参考：GA4のデータ保持）。

後から期間を長くしても、すでに削除されたデータが戻るわけではありません。

URLの集約条件を決める

同じページタイトルを複数のURLで使っている場合、タイトルだけでは対象を区別しにくくなります。

URLで分析したいときは、ページパスなどのディメンションへ切り替えます。

GA4には、ページパス、ページタイトル、ホスト名など、異なる切り口があります（参考：ページのディメンション）。

同じプロパティで複数のドメインを計測しているなら、ホスト名も確認してください。

異なるサイトの「/contact」を同じものとして集めると、どのフォームを直すべきか分からなくなります。

確認すること	混ざると起きる問題
ホスト名	別サイトの同じパスが混ざる
ページパス	似た名前の別ページを取り違える
クエリの扱い	同じ内容が複数行に分かれる
ページの版	変更前後の見た目が混ざる
アプリのデータ	Webページ以外の画面が含まれる

割合を計算する場合は、離脱数と表示回数を同じ表、同じ期間、同じ条件から取り出します。

A表の離脱数を、条件の違うB表の表示回数で割らないでください。

離脱数があるのに表示回数が0など、想定外の行は計算を保留します。

イベントに正しいページ情報が付いているか、ページビューの送信が抜けていないかを先に調べます。

表示回数が0なら、表計算でも0％と決めず「算出対象外」と残す方が誤解を防げます。

離脱が多いページを分類する

離脱数が多い順に並べた表は、調査候補の一覧です。

そのまま「悪いページのランキング」として使わないでください。

完了画面を分ける

注文完了や問い合わせ受付完了の画面は、目的を終えた人が離れる場所です。

離脱が多いことだけを理由に、不要なページへ回遊させる必要はありません。

先に、その画面で利用者が知るべき内容を確認します。

画面の役割	完了後に必要な情報
問い合わせ受付	受付済みであることと返信の目安
注文完了	注文内容と配送確認の方法
資料の取得	ファイルを開く方法と再取得の案内
予約完了	日時と変更・取消の連絡方法

必要な案内を見たうえで離れているなら、自然な終了である可能性があります。

一方、完了画面が出ていても、実際の処理が成功したとは限らない実装もあります。

受付や注文の成功イベント、必要に応じて管理側の記録と照合してください。

「完了ページを表示した回数」と「有効な注文の件数」は、同じとは限りません。

ページの再読み込みで成功が二重に数えられていないかも点検します。

途中のページを選ぶ

優先して調べるのは、利用者が次へ進むことを期待している途中のページです。

たとえば、商品詳細、料金説明、入力フォーム、配送条件の確認画面などです。

ページごとに、次の行動を1つ書きます。

商品詳細なら「条件を確認してカートへ」、入力フォームなら「必要事項を入力して受付完了へ」といった形です。

次に、離脱数だけでなく、対象の規模と成果への近さを見ます。

表示回数が非常に多ければ、問題がなくても離脱の件数は多くなり得ます。

逆に、10回の表示で8回離脱したページは、比率が高くても情報が少ない状態です。

次の表は、優先順位を考えるための架空例です。

ページ	表示回数	離脱数	最初の判断
注文完了	600	500	成功後の案内を点検
入力フォーム	400	180	入力と送信の状態を調査
新しい比較記事	10	8	少数のため追加観察

同じ比率でも、ページの目的によって次の作業は変わります。

まず1ページに絞り、離脱前後の流れを詳しく見ていきます。

GA4で離脱までの経路を見る

ページの集計だけでは、そこに来る前に何を見たかが分かりません。

経路と流入の条件を加えると、調査する操作を絞れます。

直前の操作を確認する

探索から「経路データ探索」を開き、「最初からやり直す」を選びます。

対象ページへ来る前を見たい場合は、終点にページパスなどを指定します。

その前のノードを展開して、よく通るページやイベントを確認します（参考：GA4の経路データ探索）。

ただし、対象ページを終点にしただけでは、そのページで離脱した人だけの経路にはなりません。

そのページへ到達するまでを見ているのであり、到達後に購入へ進んだ人も含まれ得ます。

ここを混同すると、成功した人の操作を離脱理由として報告してしまいます。

また、経路は複数のセッションをまたぐ場合があるため、すべてを1回の訪問と読まないでください（参考：経路とセッションの関係）。

申込みの途中で進まなくなる段階を調べたいなら、ファネルの方が問いに合うことがあります。

入力開始、確認、受付完了など、確認済みのイベントで段階を定義します。

ファネルは順序や開始位置の条件によって対象が変わるため、途中から入った人を含めるかも決めます（参考：GA4のファネルデータ探索）。

ファネルで次に進まなかった人と、サイトから離脱した人も、同じ意味ではありません。

別ページへ移動したり、期間外に完了したりした可能性を残しておきます。

流入と端末を分ける

同じフォームでも、スマホだけ入力しづらい場合があります。

また、広告で案内した内容と、検索から来た人が期待した内容が違う場合もあります。

探索のセグメントや内訳を使い、端末と流入の違いを確認します。

最初はモバイルとデスクトップを分け、次に同じ端末内で広告と検索を比べると整理しやすくなります。

セッションの流入を調べたいなら、初回ユーザーの獲得元と混ぜず、セッションに対応する参照元などを使います。

同じ「Googleから来た人」でも、初めて来たときと今回の訪問では入口が異なる可能性があるためです。

比較表には、選んだディメンション名をそのまま記録してください。

条件を細かくしすぎて数件になった場合は、結論を急がず、不要な条件を減らします。

たとえば「スマホで料金確認後に入力へ進む場面」を調べたいなら、最初から地域や曜日まで細分化する必要はありません。

データの量と、次に確認する操作が釣り合う範囲へ絞ることが大切です。

録画で離脱前の状態を調べる

GA4で調査候補を選んだら、録画で具体的な操作を確認します。

録画は、GA4の集計をそのまま映像化したものではないため、対象条件を合わせて補助的に使います。

エラーや行き止まりを確認する

Clarityなどのセッションリプレイで、対象URL、期間、端末を指定します。

最後のページが対象URLになった記録を見る場合は、ClarityのExit URLも使えます（参考：ClarityのURLフィルター）。

ただし、GA4とClarityでは記録条件や同意の状況などが異なり、件数の完全一致は前提にしません。

確認するのは、最後の一瞬だけではなく、その前の操作です。

入力エラーの後に同じ欄へ戻る、ボタンを押しても進まない、メニューが本文を隠す、といった場面を探します。

観察した操作	実ページで確認すること
送信を繰り返し押す	エラー表示と受付結果
入力欄を行き来する	必須条件や書式の説明
同じ画面を上下する	次の操作の場所と固定表示
外部サイトへ移動する	予定した予約・決済への遷移か

外部の予約サイトへ進んだ場合は、自社サイトの離脱が利用者の失敗とは限りません。

GA4の拡張計測にある離脱クリックは外部リンクのクリックであり、セッションの離脱数とは別の情報です（参考：拡張計測の離脱クリック）。

リンクのクリックと、移動先での予約完了も分けて確認してください。

理由は仮説として残す

録画で操作が止まっていても、理由まで直接分かるとは限りません。

必要な情報を得た、別の用事が入った、あとで申し込もうとしたなど、画面に出ない事情もあります。

Clarityの録画自体も、画面を動画撮影したものではなく、HTMLと操作をもとに再構成した表示です（参考：Clarityの記録方式）。

再生で見えた崩れが、実際のページにもあるかを確認します。

報告では、観察、解釈、確認方法を分けてください。

「入力エラーの表示後に操作が止まった」は観察です。

「エラーの直し方が分からなかった可能性」は仮説です。

「スマホで同じ入力を行い、修正箇所が分かるか確かめる」が次の確認です。

成功した記録も見ると、失敗した記録だけに共通点を探す偏りを減らせます。

必要ならユーザビリティテストや問い合わせ内容と照合し、操作記録だけでは分からない部分を補います。

離脱分析を改善へつなげる

最後に、直す対象と確認方法を調査表へまとめます。

離脱の数字を下げることだけを、施策の目的にしないでください。

次の行動の案内を点検する

途中のページでは、必要な情報を確認した後に、次の操作へ進めるかを見ます。

ボタンの数を増やす前に、文言、位置、対象条件との距離を点検します。

「次へ」だけでは内容が分かりにくい場合は、進んだ先で何をするかが伝わる案内を検討します。

フォームなら、送信前に料金や連絡の流れを確認できることも大切です。

ここまでの調査を、次の表に書き出してください。

調査項目	記入する内容
対象ページ	URLとホスト名、ページの版
役割	完了画面か、途中の画面か
定義	離脱数と、使う場合は比率の計算式
集計条件	期間、端末、流入、除外条件
観察	GA4での件数と録画で見た操作
仮説	進めない原因の候補
変更案	文言、表示、操作の具体的な修正
確認方法	実操作、成果指標、再集計の日程

1回の調査で複数の問題が見つかったら、操作を妨げる不具合から優先して対応します。

見た目の調整と、受付ができない問題を同じ優先度で扱わないようにします。

同じ条件で再評価する

修正後は、実ページで意図した操作ができるかを先に確かめます。

計測も変えた場合は、Tag Assistantなどでデバッグを有効にし、GA4のDebugViewでイベントとパラメータを確認します（参考：DebugViewでの確認方法）。

その後、変更前と同じ定義、同じ対象条件で数字を比較します。

表示回数が減った結果として離脱数も減っただけなら、改善の効果とは判断できません。

申込完了や購入など、ページの目的に対応する成果も一緒に見てください。

広告の配信内容や季節が変わった場合は、その影響も記録します。

前後の差だけで変更の因果効果を断定せず、必要に応じてA/Bテストなどで確かめます。

フォームの改善項目を整理したい場合は、EFOの進め方と計測設計も参考になります。

まずは離脱数の多いページを1つ選び、完了画面か途中の画面かを分類してください。

GA4で調査対象を絞り、実際の操作を確かめ、目的の行動へ進めるように直すことが、離脱分析の使いどころです。