ファネル分析とは、ユーザーがコンバージョンに至るまでの行動を段階に分けて、どこで離脱が起きているかを特定する分析手法です。全体CVRだけを見ていても、流入・訴求・CTA・フォームなどのコンバージョンに至る流れのどこに課題があるのかまでは分かりません。
流入はあるのに成果が出ない。CVRは低いのに、どこを直すべきか説明できない。改善案は思いつくのに、それを優先してよい根拠が持てない。そんなときに必要なのが、ユーザー行動を段階で切って見る視点です。ファネル分析を使うと、課題を「なんとなく悪い」で終わらせず、「どの段階で落ちているか」という形で捉えやすくなります。
この記事では、ファネル分析とは何か、全体CVRとの違い、ファネルの設計方法、GA4での見方、ボトルネックを見つけた後に次に見るべき分析までを整理して解説します。まずは、ファネル分析が何のための手法なのかから押さえていきましょう。
【1】ファネル分析とは?課題位置を見つける方法
ファネル分析という言葉は知っていても、「CVRを改善するためのGA4の機能」というイメージで止まっている人は少なくありません。ここでは、ファネル分析とは何か、使えるサイトの種類、分かることと分からないことの線引きをしていきます。使い始める前に「何のための分析か」を押さえておくことで、どこで使えば良いのかがはっきりとします。
ファネル分析は課題位置を特定する手法
ファネル分析とは、Webサイト上でユーザーが最終的なコンバージョンに至るまでの行動を分解して、どの箇所でCVRが落ちているかを特定する分析手法です。
「ファネル(funnel)」とは漏斗(ロート)のことで、多くのユーザーが流入しても段階を経るごとに数が減っていく様子が、その形状に似ていることに由来しています。この構造を可視化することで、課題がどこにあるかを場所として把握できます。
ファネル分析の役割は、改善案を出すことではなく、疑う場所を見つけ出すことです。ページを直すべきか、CTAを見るべきか、フォームを疑うべきか。その順番を決めるために使います。
【関連記事|A01】Web課題を“構造で理解する”ための分析フレームワーク入門
全体CVRだけでは課題を見誤る理由
全体CVRとは、サイト全体の訪問者数に対してコンバージョンに至った割合のことです。たとえば「月間1万セッションで50件の問い合わせ、CVR0.5%」という数字がこれにあたります。
この数字が低いとき、原因として考えられる箇所は複数あります。流入してくるユーザーの質が変わったのか、ページの訴求が刺さっていないのか、CTAまで到達していないのか、フォームで離脱しているのか——全体CVRはこれらをひとまとめにした値なので、どこが問題かを切り分ける情報を持っていません。
段階ごとに落ち方を見たときの当たりのつけ方は、シンプルです。流入からCTAへの遷移率が低いなら、ページの訴求か流入の質を疑います。CTAからフォームへの遷移率が低いなら、導線かCTAの設計を疑います。フォームから完了への遷移率が低いなら、入力負荷や心理的な障壁を疑います。全体CVRだけでは、この「どこを先に疑うか」の判断が立ちません。具体的な数字例と読み方は、2章と4章で詳しく説明しています。
3つのファネルモデルの違いを押さえる
ファネルには複数のモデルがあり、自分のビジネスの成果地点をどこに置くかで、選ぶべきモデルが変わります。モデル名を覚えることよりも、「購入で終わりなのか、継続利用や推奨行動まで含めるのか」を先に決めてから始める必要があります。
| モデル名 | 概要 | 向いている用途 |
|---|---|---|
| パーチェスファネル | 認知→興味→比較→購入という購買プロセスを段階化したモデル。AIDMA・AISASなどが代表例 | ECサイト、購買導線のある商材、新規顧客獲得の可視化 |
| インフルエンスファネル | SNSや口コミなど、ユーザーが外部に影響を与えるプロセスも含めたモデル | ブランド認知・UGC(ユーザー生成コンテンツ)が重要なBtoC商材 |
| ダブルファネル | 新規獲得(上部ファネル)とリピート・ロイヤルティ形成(下部ファネル)を一体化したモデル | サブスクリプション・継続利用型サービス、LTV重視のビジネス |
よく使われるのはパーチェスファネルですが、「ユーザーを獲得してからが本番」のSaaSやアプリでは、ダブルファネルの発想が実態に近くなります。どのモデルを選ぶにしても、基準になるのは「自社のビジネスの成果をどこまでと定義するか」です。その定義さえ決まれば、どのファネルを使うのかもおのずと決まります。
ファネル分析が使えるサイトの種類
ファネル分析はECサイトや広告運用の文脈で語られることが多いですが、ユーザーが複数の段階を経てゴールに至る構造があれば、サイトの種類を問わず使える考え方です。ただし、導線が短すぎるサイト(広告LPなど)や各段階のデータが安定して傾向を読める量に達していないサイトでは、段階を細かく切っても判断しにくくなります。
主な適用例としては、次のものがあります。
①問い合わせ・リード獲得サイトは、流入→ページ閲覧→CTA到達→フォーム入力→送信完了という導線を分解します。
②ECサイトは、流入→商品一覧→商品詳細→カート→決済→購入完了を段階化します。
③メディア・記事サイトは、流入→記事閲覧→CTA到達→メルマガ登録や資料ダウンロードというコンテンツ導線に適用します。
④SaaS・アプリは、流入→会員登録→初期設定→利用定着→継続課金という段階を設計します。
サイト種別ごとの具体的な設計例は、3章でまとめて紹介します。
ファネル分析で分かること・分からないこと
ファネル分析で見えるのは、ユーザーが離脱している場所です。逆に見えないのは、その理由です。
たとえばフォームの前で落ちていても、入力項目が多すぎるのか、個人情報への不安が強いのか、そもそも導線が分かりにくいのかまでは、数字だけでは決まりません。ボトルネックの「場所」は特定できますが、「なぜそこで落ちているか」は別の分析が必要です。
分かることを整理すると、どの段階でユーザーが最も多く離脱しているか、段階ごとの遷移率の比較、改善を優先すべき箇所の絞り込みの3つです。原因の特定には、ヒートマップや行動ログ、定性調査などの補完分析が別途必要になります。
ファネル分析の役割は「落ちている箇所の特定」です。その限界を理解したうえで使うことが、分析を実務判断につなげる前提になります。
ファネル分析が向く場面と向かない場面
ファネル分析がいちばん役に立つのは、CVRが悪いことは分かっているのに「どこが悪いか」がわからないときです。GA4で表示回数やCV数といった全体指標の数字しか見ていない状態から分析を深めたいとき、複数の改善案が出ていてどこに工数をかけるかを整理したいときも、使いどころが合っています。
逆に、すでにフォームが原因だと分かっているなら、ここでやるべきなのはファネル分析ではなく、フォームの中を見る作業です。課題の場所が特定済みであれば、次の分析に進めなければいけません。
もう一点、注意が必要なのは母数です。流入が極端に少ないサイトでは、各段階の数字が少数の変動で大きく動いてしまいます。数字がノイズに左右されやすい状況では、ファネルより定性的な観察を優先するほうが実務上は有効なことがあります。分析として使えるかどうかの判断は、まずデータ量の確認から始めるのが基本です。
【2】全体CVRだけでは課題が見えない理由
全体CVRが低いことは分かっている。でも、どこを直せばいいのかがわかっていない。そういう状況は、数字をよく見る習慣がある人ほど陥りやすいものです。この章では、全体CVRという指標がなぜ課題の特定に使えないのかをその仕組みから整理し、ファネル分析が必要になる理由を具体的に解説します。あわせて、数字の解釈以前に確認すべき計測のそもそもの前提についても触れます。
全体CVRでは課題箇所を切り分けられない
全体CVRは、サイト全体の訪問者数に対してコンバージョンが発生した割合を示す数字です。この数字が低下したとき、原因として考えられる箇所は複数あります。流入してくるユーザーの質が変わったのか、ランディングページの訴求が刺さっていないのか、CTAまで到達していないのか、フォームで離脱しているのか——全体CVRはこれらをひとまとめにした結果値なので、どこが問題かを切り分ける情報を持っていません。
たとえば、全体CVRが先月の1.2%から今月0.8%に落ちたとします。この事実だけでは、「ページの訴求を改善する」のが正しいのか、「フォームを短くする」のが正しいのか、判断できません。改善の方向性を決めるには、どの段階で数字が落ちているかを先に特定する必要があります。
段階ごとのCVRでボトルネックが見える
同じサイトの数字を、段階ごとに分解して見ると状況が変わります。以下のようなコンバージョンまでの推移の流れで考えてみます。
| 段階 | ユーザー数 | 遷移率 |
|---|---|---|
| 流入(セッション) | 10,000 | ― |
| LP閲覧(スクロール50%以上) | 6,000 | 60% |
| CTA到達 | 4,800 | 80% |
| フォーム開始 | 960 | 20% |
| 送信完了 | 720 | 75% |
この例では、CTA到達からフォーム開始への遷移率が20%と突出して低い。全体CVRを計算すると720÷10,000=7.2%ですが、この数字だけを眺めていてはCTAとフォームの間に大きな落ち込みがあることに気づけません。先に疑うべきなのはCTAそのものではなく、CTAの先の導線です。
ボトルネックとは、段階ごとの遷移率を並べたときに特定の箇所で数字が急落している場所のことです。ファネル分析はこのボトルネックの位置を特定するための手法であり、「どこを疑うべきか」の初手を与えてくれます。
離脱率だけでは原因の場所を読み違える
アクセス解析ツールでは、ページごとの離脱率を確認できます。ただし、離脱率が高いページがボトルネックとは限りません。
離脱率が高くても、そのページ自体に問題があるのではなく、流入してくるユーザーの質や流入経路の問題である場合があります。逆に、離脱率が低く見えていても、次のページへ進んだユーザーがその先で大量に離脱しているケースもあります。
ページ単体の離脱率は「どのページで多く抜けているか」は教えてくれますが、「流入から最終ゴールまでの道のりでどこが詰まっているか」は教えてくれません。ファネル分析は導線全体を通した遷移率の連鎖を見るため、ページ単体の指標では見えてこない構造上の問題を浮かび上がらせることができます。
GA4を見ても判断できないときに効く
GA4で詰まりやすいのは、機能がないことではなく、段階の切り方です。デフォルトのレポートはセッション数・ユーザー数・CV数・全体CVRといったサイト全体的な集計値が中心で、状況の把握には役立つものの「なぜCVが取れていないのか」を判断する材料にはなりにくい構造になっています。
探索でファネルは作れますが、どのステップを置くかで見える景色がかなり変わります。またオープンファネルとクローズドファネルのどちらを選ぶかによっても数字の意味が変わるため、設定の前提を意識しながら使う必要があります。※GA4の具体的な設定と読み方は4章で解説します。
「GA4を見ているのに何も分からない」という状態は、多くの場合この段階の切り出しが行われていないことが原因です。デフォルトの集計値を眺めるだけでなく、ファネルの視点で主要な通過箇所を設計して数字を切り出す一手間が、課題箇所の特定につながります。
計測前提のズレが分析を狂わせる落とし穴
ファネル分析を始める前に確認しておきたいのが、そもそもの計測の数値が正しく行われているかどうかです。数字の解釈以前に、計測そのものにズレがあると、ファネルを設計しても誤った判断になってしまいます。
計測のズレでまず多いのは、CVの取り忘れと重複カウントです。フォーム送信完了ページへのタグが設置されておらずCVが正しくカウントされていないケース、同一ユーザーの複数回の送信が別々のCVとして計上されているケースがこれにあたります。
特に注意したいのは、必要なイベントを後から設定した場合です。
デフォルトで取得するデータであればよいのですが、追加でイベントクリックなどをとる必要がある場合、設定をした後のデータしか取れません。設定後、ある一定期間データが貯まるまで待つタイムラグが発生してしまいます。
そのうえで、イベントの発火条件が意図とずれていたり(クリックイベントが「到達」ではなく「表示」で発火しているなど)、社内IPや開発環境のアクセスが除外されていなかったりすると、ファネルの数字そのものが信用しにくくなります。
これらは数字を見ても気づきにくいため、ファネル分析に入る前に計測設定を一度確認しておくのが実務上の基本です。現状取得している数字がずれた状態でファネルを組んでも、出てくる数字は実態を反映していません。
【3】ファネル分析のやり方と設計の基本
ファネル分析を「やってみよう」と思ったとき、最初に迷うのは「どこからどこまでを段階として切るか」という切り方の部分です。テンプレートを探して当てはめようとしても、自分のサイトの導線と微妙にズレてしまう。そういう経験がある人は少なくないはずです。この章では、ファネルの設計手順を基本から整理し、サイトの種類ごとの具体的な設計例までを解説します。設計に正解の型はありませんが、考え方の基礎を押さえておくと判断がしやすくなります。
最終コンバージョンを先に決める
ファネルの設計は、最終コンバージョンを先に定義することから始めます。最終コンバージョンとは、そのサイトにおいてビジネス上の成果として計測するゴールのことです。
問い合わせフォームの送信完了なのか、商品の購入完了なのか、会員登録なのか、資料のダウンロードなのか。
この定義が曖昧なままファネルを組むと、どの段階を見るべきかが定まってきません。
終点が決まれば、そこに至るまでの行動を逆算して段階に分解できます。出発点(流入)から考え始めるよりも、ゴールから逆算する順番のほうが、設計がぶれにくくなります。
行動導線に沿って段階を分解する
最終コンバージョンが決まったら、ユーザーがゴールに至るまでに実際に踏む行動を順番に並べ、段階として切り出します。
このとき大事なのは、「理想の導線」ではなく「実際の行動導線」に沿って設計することです。サイト設計者が意図した順番でユーザーが動くとは限らないため、GA4のユーザー行動レポートや実際の遷移データを参照しながら、現実に近い導線を確認するのが有効です。
段階の粒度は、細かければ細かいほど良いわけではありません。段階をわけすぎると各段階の離脱率にあまり変化がなくどこがボトルネックなのか判断しにくくなります。逆に粗すぎても、どこで落ちているかが見えなくなります。「判断が変わるレベルで数字を分けられるか」を基準に、3〜6段階程度で分けるが実務上の目安です。
【関連記事|A01-02】課題分解を最短で行うための実践フレームワーク大全
マイクロCVの置き方で精度が変わる
最終コンバージョンに至るまでの途中段階に設定する中間指標を、マイクロCV(マイクロコンバージョン)と呼びます。どこに置くかで、ファネルの分析精度が変わります。
たとえば「フォームページへの到達」だけを見ていると、フォームを開いたもののすぐ閉じたユーザーと、最後まで入力して送信直前で止まったユーザーが同じ扱いになってしまいます。「フォーム入力開始(最初のフィールドへの入力)」をマイクロCVとして設定することで、フォームページへの到達とフォーム入力開始の間で落ちているのか、入力開始後に止まっているのかを区別できます。
マイクロCVを設定するときの判断基準は、「そこで数字が変わるなら、対処も変わるか」です。対処が変わらない段階は無理に細かく切らず、判断の分岐点になる行動に絞るのが実用的です。
なお、2章でも触れましたが、イベント計測は設定後のデータしか取れません。マイクロCVに使うイベントが未設定の場合は、早めに設定してデータを貯め始めることが先決です。
問い合わせサイトのファネル設計例
BtoBのリード獲得や問い合わせを最終CVとするサイトでは、「流入→サービスページ閲覧→CTA到達→フォームページ到達→フォーム入力開始→送信完了」の流れが基本的な設計です。
| 段階 | 計測ポイントの例 |
|---|---|
| 流入 | セッション数・新規ユーザー数 |
| LP・サービスページ閲覧 | ページビュー数、スクロール深度 |
| CTA到達 | CTAボタンの表示・クリック |
| フォームページ到達 | フォームページのページビュー |
| フォーム入力開始 | 最初のフィールドへの入力イベント |
| 送信完了 | サンクスページ到達・送信完了イベント |
このタイプのサイトでよく起きるのは、CTAのクリック率は高いのにフォームでの離脱が多いというパターンです。段階を分解することで初めて、「CTAは機能しているがフォームに問題がある」という判断が持てるようになります。問題はCTAより後——フォームの入力項目数、入力の煩雑さ、確認画面の有無あたりを先に疑うことになります。
ECサイトのファネル設計例
ECサイトでは、商品の閲覧から購入完了までの購買導線を段階として設計します。
| 段階 | 計測ポイントの例 |
|---|---|
| 流入 | セッション数(表示回数) |
| 商品一覧ページ閲覧 | カテゴリ・一覧ページのPV |
| 商品詳細ページ閲覧 | 商品詳細ページのPV |
| カート追加 | カートへの追加イベント |
| 決済開始 | チェックアウト開始イベント |
| 購入完了 | 購入完了イベント・サンクスページ |
ECは、どこで落ちているかによって見る場所がかなり変わります。商品詳細からカート追加で止まるのか、カート以降で止まるのか——前者は訴求や商品の魅力に関わる問題であり、後者は送料・支払い方法・入力の手間といった購入プロセスの障壁です。この差は大きいです。
記事サイトのファネル設計例
メディアや記事サイトでは、最終CVがメルマガ登録・資料ダウンロード・会員登録などになることが多く、購買導線型とは異なる設計が必要です。
| 段階 | 計測ポイントの例 |
|---|---|
| 流入 | セッション数・検索流入数 |
| 記事閲覧 | 表示回数・平均セッション継続時間・50%スクロール率 |
| 記事内CTA到達 | CTAバナー・テキストリンクの表示 |
| CTAクリック | クリックイベント |
| LP・登録ページ到達 | ページビュー |
| 登録完了 | 登録完了イベント |
記事サイトでは、流入数が多くても記事の途中で離脱するユーザーが大半を占めます。記事の読了率やスクロール深度をマイクロCVに設定しておくと、「記事は読まれているがCTAに到達していない」のか、「CTAまでは到達しているがクリックされていない」のかを区別できます。どちらかで課題の性質はかなり変わります。
SaaSはAARRRモデルで設計する
SaaSやサブスクリプション型のサービスでは、購入・登録がゴールではなく、その後の継続利用や課金転換までを含めてビジネスの成否が決まります。このような構造には、AARRRモデルに基づいたファネル設計が実態に合います。
AARRRとは、Acquisition(獲得)・Activation(活性化)・Retention(継続)・Revenue(収益化)・Referral(紹介)の頭文字を取ったフレームワークで、ユーザーライフサイクル全体をファネルとして捉える考え方です。
| 段階 | 内容 | 計測例 |
|---|---|---|
| Acquisition | 流入・会員登録 | セッション数・登録完了数 |
| Activation | 初期利用・価値体験 | 初回ログイン率・主要機能の利用率 |
| Retention | 継続利用 | 7日・30日のリテンション率 |
| Revenue | 収益化 | 有料転換率・MRR |
| Referral | 紹介・口コミ | 紹介経由の新規登録数 |
ファネルを「登録完了まで」で切ってしまうと、登録後に誰も使っていないという状態を見逃します。「登録は増えているのに継続されていない」「有料転換の手前で止まっている」——こうした課題はAARRRの視点でファネルを設計することで、初めて見えてきます。
テンプレより実際の導線を優先する
ここまで挙げた設計例はあくまで参考であり、どのサイトにもそのまま当てはまるわけではありません。自分のサイトのファネルを設計するときは、テンプレートを当てはめることよりも、実際のユーザーがどう動いているかを先に確認することをとにかく優先してください。
たとえば、問い合わせサイトでも「LP→フォーム」の一段階で完結するシンプルな導線のサイトもあれば、複数のサービスページを回遊してから問い合わせに至る導線のサイトもあります。ECサイトでも、ユーザーが一覧ページを経由せず検索から直接詳細ページに到達するケースが大半であれば、一覧ページの段階は設計上の優先度が下がります。
設計したファネルと実際のユーザー行動が合っていなければ、数字を見ても実態は見えません。GA4のユーザー探索レポートや経路データ探索を使って実際の行動の流れを確認してからファネルの段階を決めると、分析の精度が上がります。
【4】数字例とGA4でボトルネックを読む
ファネルを設計しても、数字の読み方が分からなければ「眺めて終わった」になってしまいます。この章では、GA4のファネルデータ探索の設定上の注意点から、各段階の遷移率をどう解釈してボトルネックを特定するかまでを、具体的な数字例とともに解説します。ツールの操作手順というより、「どこを見て、何を疑うか」という判断の流れを中心に説明します。
GA4のファネル探索は設定の差が重要
GA4でファネル分析を行うには、「探索」メニューの中にある「ファネルデータ探索」を使います。任意のステップを設定することで、段階ごとの遷移率と離脱数を可視化できます。
ファネルデータ探索には「オープンファネル」と「クローズドファネル」という2つのモードがあり、どちらを選ぶかで数字の意味が変わります。
| 設定 | 内容 | 向いている用途 |
|---|---|---|
| クローズドファネル | ステップ1から順番に通過したユーザーだけを計測する | 特定の導線を通ったユーザーの行動を厳密に追いたいとき |
| オープンファネル | どのステップからでも途中参加できるため、各ステップの実数を広く計測する | 流入経路が複数あり、途中から導線に入るユーザーも含めて把握したいとき |
クローズドファネルで設定すると、ステップ1を通過していないユーザーは集計から除外されます。特定のランディングページからの導線を分析したい場合はクローズドが適していますが、複数の流入経路があるサイトではオープンのほうが実態に近い数字になります。設定を変えるだけで遷移率が大きく変わることがあるため、どちらのモードで見ているかは常に意識しておく必要があります。
特定の広告からの遷移を見るといったことがなければ、一般的にはオープンファネルを使うことが多いです。
また、ファネル探索ではステップ間の経過時間を設定できます。「その日のうちに完了したセッション」に絞るといった条件を加えることで、分析の精度を上げられます。この設定の有無も、数字の解釈に影響します。
【関連記事|B01】GA4で“何を見るべきか”を構造から理解する分析フレーム
経過時間と次の行動で離脱の質を見る
ファネルの数字で「離脱」として計上されているユーザーには、いくつかの異なる行動パターンが混在しています。
| 離脱のパターン | 内容 | 疑うべき原因 |
|---|---|---|
| 即時離脱 | ページに到達してすぐ離脱している | 流入の質のミスマッチ、ページの初期表示速度、ファーストビューの訴求 |
| 途中離脱 | ある程度スクロール・閲覧した後に離脱している | ページ内容の訴求力、情報の過不足、CTAの位置・視認性 |
| 入力途中の離脱 | フォームを開いたが入力を途中でやめている | 入力項目の多さ、入力形式の煩雑さ、不安要素(プライバシーポリシーの見えにくさなど) |
GA4のファネルデータ探索では、各ステップの経過時間の分布を参照することで、すぐ離脱しているのか時間をかけた末に離脱しているのかを大まかに判断できます。即時離脱が多ければ流入の質や初期表示を先に疑い、時間をかけた末の離脱であれば、ページ内容の問題か意思決定の障壁を疑う方向になります。
同じ遷移率でも、離脱の質によって対処の方向性は変わります。数字の大きさだけでなく、どのタイミングで離脱しているかをあわせて確認することで、疑うべき原因が絞り込みやすくなります。
各段階の遷移率を順番に確認する
ファネルの数字を読むときは、流入から順番に各段階の遷移率を並べて確認します。以下は2章でも出しましたが、問い合わせサイトを想定した数字例です。
| 段階 | ユーザー数 | 遷移率(前段階比) |
|---|---|---|
| 流入(セッション) | 8,000 | ― |
| サービスページ閲覧 | 5,600 | 70% |
| CTA到達 | 4,480 | 80% |
| フォームページ到達 | 896 | 20% |
| フォーム入力開始 | 717 | 80% |
| 送信完了 | 573 | 80% |
この例では、CTA到達からフォームページ到達への遷移率が20%と、他の段階と比べて突出して低い。全体CVRを計算すると573÷8,000≒7.2%ですが、このCVRの数字だけを見ていてはCTAとフォームの間に問題があることは分かりません。先に疑うべきなのはCTAそのものではなく、CTA周辺での訴求や導線です。
遷移率を並べて見ることで、「どこで急落しているか」が判断できるようになります。落差が大きい段階の原因については、次の各節で段階ごとに整理します。
流入からCTA低下は訴求不足を疑う
流入数に対してCTAへの到達率が低い場合、まず疑うのはページの訴求力です。
ユーザーはページに流入した時点でゴールを決めているわけではなく、「自分に関係があるか」「信頼できるか」「次のアクションを取る価値があるか」を判断しながら読んでいます。その過程で離れているとすれば、コンテンツの訴求・情報の整理・ターゲットへの刺さり方に問題があると考えられます。
ただ、原因がページ側にあるのか流入側にあるのかは、この数字だけでは決まりません。検索キーワードや広告のターゲティングとページの内容がズレていれば、ページ自体に問題がなくてもCTA到達率は低くなります。流入経路ごとにファネルを分けてセグメント別に確認するのが、切り分けの手順です。
CTAからフォーム低下は導線を疑う
CTAまで来ているのにフォームへ進まないなら、まず導線を疑います。テキストが弱いのか、遷移先が想像と違うのか、単純にリンク先へ飛べていないのか。ここは実際に画面を開いて自分で辿ると早いです。
具体的に確認するポイントとしては、CTAボタンのテキストがユーザーの期待と次のページの内容を正しく伝えているか、フォームページの冒頭で「思っていたものと違う」と感じさせる要素がないか、フォームの入力量が多く開いた瞬間に離脱を引き起こしていないかなどが挙げられます。
CTAのクリック数とフォームページのセッション数が大きく乖離している場合は、技術的な問題(遷移の失敗や計測漏れ)も候補に入ります。落差が極端に大きいときは、原因の仮説より先に動作確認から始めるのが現場での基本的な判断です。
【関連記事|E01】導線改善の全体像:ユーザー行動が分かる“導線構造”の読み解き方
完了率低下はフォーム負荷を疑う
フォームページへの到達数は確保できているのに送信完了率が低い場合、フォーム自体の使いやすさや心理的な障壁が原因として考えられます。
よく見るのは、入力項目が必要以上に多い、全角・半角の制限や電話番号のハイフン有無などの形式が煩雑、エラーメッセージがどこの何が間違いなのか分かりにくい、プライバシーポリシーへのリンクが見えにくくて不安が残る、といったパターンです。確認画面でそのまま離脱するケースも少なくありません。
「入力が面倒」のひとことで片付けられがちですが、GA4のイベント計測でフォームの各フィールドへの入力開始・完了イベントを設定しておくと、どの項目で手が止まっているかがより詳細に見えてきます。(このあたりはEFOの領域です)なお、3章でも触れたとおり、イベント計測は設定後のデータしか取れないため、未設定の場合は早めに対応しておくといいです。
セグメント別に見ると課題が変わる
ファネル全体の遷移率を平均として見るだけでは、特定のユーザー群に偏った課題を見落とすことがあります。分けると有効なセグメントの例としては、次のものが挙げられます。
流入経路別(オーガニック検索・広告・SNS・直接流入で遷移率を比較する)、デバイス別(スマートフォンとPCで遷移率を比較する)、新規・リピート別(初めて訪問したユーザーと再訪問ユーザーで比較する)、地域・時間帯別(特定の地域や時間帯でCVが偏っていないかを確認する)です。
たとえば、全体の遷移率は問題なく見えていても、スマートフォンユーザーだけを抽出するとフォームの完了率が極端に低い、というケースがあります。この場合、フォームのモバイル表示やタップ操作のしやすさに問題がある可能性が高く、PC向けの改善とは異なる対処が必要です。セグメントを変えて見ることは、課題の範囲と性質を絞り込むための有効な手段です。
落差が大きい段階から優先して見る
ファネルの数字を眺めていると、複数の段階でそれぞれ遷移率が低く見えることがあります。どこから手をつければいいか迷うときは、落差が大きい段階から確認するのが基本です。
落差が大きい段階は、そこで失われているユーザー数が多い段階でもあります。改善によって遷移率が回復したときの影響が最も大きいのも、この段階です。逆に、もともと遷移率が低くて当然の段階(ユーザーが最終意思決定をする場面など)は、多少の離脱は許容範囲として解釈することも必要です。
ただし、落差が大きくても母数が小さい場合は数字が安定しない可能性があります。「落差が大きい段階」を優先しながらも、「その段階の母数が十分にあるか」を数値がある程度溜まってから判断をしましょう。一般的なBtoCサイトであればセッション数が最低2000は貯めてからの判断になります。
【5】ファネル分析の限界と次に見る分析
ファネル分析でボトルネックの位置が分かった。でも、「なぜそこで落ちているのか」が説明できない。
これはファネル分析を正しく使えているからこそ直面する壁です。ファネル分析は課題の場所を特定する手法であり、原因を確定する手法ではありません。この章では、ファネル分析が持つ構造的な限界を整理したうえで、課題の種類ごとに次にどの分析へ進むべきかを紹介します。
ファネル分析だけでは離脱理由は分からない
ファネル分析で分かるのは、「どの段階で何人が離脱したか」という事実です。「なぜ離脱したか」という理由は、ファネルの数字には含まれていません。
たとえば、CTAからフォームへの遷移率が低いという事実が分かったとします。しかしその理由が、CTAのテキストへの不信感なのか、フォームの入力量への抵抗感なのか、そもそも流入ユーザーの検索意図とのズレなのかは、ファネルを見るだけでは判断できません。
ファネルの結果だけをもとに「フォームを短くすれば解決する」と即断してしまうと、実際の原因が別の場所にある場合に改善効果が出ません。ファネル分析は「次に何を調べるか」の方向性を決めるための課題抽出の中間手段であり、改善策を直接導き出すものではありません。
直線的に見ると行動の揺れを見落とす
ファネル分析は、ユーザーが段階を順番に通過するという前提で設計します。しかし実際のユーザー行動は、必ずしも一直線ではありません。
複数回のセッションにまたがって検討するユーザー、サービスページを行き来してから問い合わせに至るユーザー、一度離脱してから広告を経由して戻ってくるユーザー——こうした「行動の揺れ」は、直線的なファネルの構造では捉えられません。
GA4のクローズドファネルでは、ステップを順番に通過しないユーザーは集計から除外されます。そのため、迂回した導線を経てコンバージョンしたユーザーがファネルの計測の外側に出てしまい、実際より遷移率が低く見える場合があります。ファネルの数字が実態を正確に反映しているかどうかは、設定の前提を確認しながら解釈する必要があります。
複雑導線や少母数では精度が落ちる
ファネル分析の精度は、導線がシンプルであることと、各段階に安定して判断できる量のデータがあることに依存します。どちらかが欠けると、数字の信頼性が落ちます。
複数の流入経路・複数のランディングページ・複数のコンバージョン経路が混在するサイトでは、単一のファネルで全体を表現しようとすると実態と乖離しやすくなります。この場合は、流入経路別や導線別にファネルを分けて設計するほうが実態に近い数字を得られます。
また、各段階の母数が少ない場合は数字が安定せず、偶発的な変動がボトルネックとして見えてしまうリスクがあります。4章でも触れましたが、判断に入るのはある程度データが溜まってからです。月間の流入が少ないサイトでは、ファネルの数字より定性的な観察を優先するほうが実務上は有効な場合があります。
訴求課題は検索意図分析で深掘る
流入からCTAで落ちるなら、次は検索意図を見ます。ページの訴求が弱いのか、そもそも入ってきている人がズレているのかは、ここを見ないと分かりません。
検索意図分析とは、そのページに流入しているユーザーが何を知りたくて検索したのかを整理し、ページの内容・構成・メッセージがその意図に合っているかを確認する作業です。GA4とGoogle Search Consoleを連携して流入キーワードを確認したり、検索結果で上位表示されているコンテンツの構成を参照したりすることで、「ユーザーが求めている情報とページが提供している情報のズレ」を把握できます。
訴求が刺さっていない原因がターゲットのズレにある場合と、訴求の切り口が合っていない場合では、改善の方向性が変わります。どちらの問題かを見極めるための材料として、検索意図の分析は有効です。
導線課題は行動ログで深掘る
「CTAからフォームへの遷移率が低い」「フォームの完了率が低い」という課題が見えた場合、次に確認するのはページ内でのユーザーの具体的な行動です。ヒートマップや行動ログの分析が有効です。
ヒートマップツール(Microsoft ClarityやHotjarなど)を使うと、ユーザーがページのどこをクリックしているか、どこまでスクロールしているか、どこで止まっているかを視覚的に確認できます。セッションの録画機能を持つツールでは、実際のユーザーの操作をそのまま再生して確認することも可能です。
ファネルの数字が「フォームで落ちている」と示していても、行動ログを見ると「特定の項目でエラーが繰り返し発生している」ことが分かる場合があります。数字では見えなかった具体的な詰まりを、行動ログは教えてくれます。
数字課題はKPI分解で深掘る
ファネルの特定の段階でCVRが低いが、原因がページの問題なのか流入の問題なのか判断しにくい場合、KPIを分解して整理すると仮説が立てやすくなります。
たとえば、月間問い合わせ数=流入数×CVRという構造で見たとき、CVRが変わらず流入数が減っているのであれば集客側の課題であり、流入数は変わらずCVRが下がっているのであればサイト内の課題です。KPI分解はファネル分析の前提として行うこともありますが、ファネルでボトルネックを特定した後に「その段階の数字がなぜ変動したのか」を整理するためにも活用できます。
【関連記事|A01-07】KPIを構造的に分解するための設定フレームワーク
商談や継続率はCRMやSFAで見る
BtoBサービスやSaaSでは、Webサイト上のコンバージョン(問い合わせや登録)がゴールではなく、その後の商談化・受注・継続利用までを含めてビジネスの成否が決まります。Webのファネルだけを見ていると、本当の課題が見えないことがあります。
たとえば、Webのファネル上では問い合わせ数が増えているのに売上が伸びていない場合、問い合わせの質が下がっている可能性があります。この「質」はWebのファネル分析では計測できず、CRM(顧客関係管理)やSFA(営業支援システム)に蓄積された商談データを参照する必要があります。
問い合わせから商談化率・受注率・継続率の流れを、WebファネルとCRM・SFAのデータを組み合わせて見ることで、「Webで課題があるのか、営業プロセスで課題があるのか」を切り分けられるようになります。
離脱理由は定性調査で確かめる
定性調査は数ではなく、理由の見当をつけるために使います。
定性調査の方法としては、ユーザーインタビュー・アンケート・オンサイトのポップアップ調査などがあります。たとえば、フォームページに「送信をためらった理由を教えてください」というアンケートを設置するだけでも、数字からは見えなかった「個人情報を入力することへの不安」「どんな連絡が来るか分からない」という理由が浮かび上がることがあります。
ファネルで場所を見て、行動ログで詰まり方を見て、最後に理由を確かめる。順番としてはそのくらいで捉えておけば十分です。
ファネル分析で見えた課題と、次に使う分析の対応関係を整理すると以下のようになります。
| ファネルで見えた課題 | 次に使う分析手法 |
|---|---|
| 流入からCTA遷移率が低い | 検索意図分析・流入経路別セグメント分析 |
| CTAからフォーム遷移率が低い | ヒートマップ・行動ログ・CTAのA/Bテスト |
| フォーム完了率が低い | 行動ログ・フォーム項目ごとのイベント計測・定性調査 |
| 登録後の利用定着率が低い | CRM・SFAデータ・ユーザーインタビュー |
| 課題の場所は分かるが原因が不明 | 定性調査・ユーザーインタビュー・アンケート |
【6】ファネル分析を改善判断につなげる
ここまでで、ファネル分析の定義・設計・数字の読み方・限界と次の分析手法を順に見てきました。手順を頭に入れても、実際に動き始める場面では「どこから手をつければいいか」で迷うことがあります。そうしたときに立ち戻れる軸を、ここでまとめます。
課題発見までの実務手順を整理する
実務では、まず最終CVを決めます。次に計測が信用できるかを確認します。そこまで済んだら、ようやくファネルを切ります。段階を並べて落差を見るのは最後です。
手順を整理すると、次のような流れになります。
最初にやるのは最終コンバージョンの定義です。問い合わせ送信完了なのか、購入完了なのか、会員登録なのか——ここが曖昧なままだと、ファネルの設計全体がずれます。
次に計測の前提確認です。GA4のタグが正しく設置されているか、コンバージョンイベントが重複なく計測されているか、社内IPが除外されているかを確認します。数字が実態を反映していなければ、どれだけ丁寧にファネルを設計しても判断を誤ります。
そこまで整ったら、実際の導線に沿ってファネルを設計します。GA4の経路データ探索や実際のサイト導線を参照しながら段階を切り出します。テンプレートの当てはめではなく、実際の行動の流れを優先するのが基本です。
あとはGA4のファネルデータ探索で遷移率を確認し、落差が大きい段階を起点に次の分析へ進みます。訴求の問題なら検索意図分析、導線の問題なら行動ログ、理由の確認が必要なら定性調査へ。ファネル分析の役割はここで終わりで、次の分析への引き渡しが改善判断の起点になります。
この流れは一度で完結するものではなく、施策を打った後に再びファネルの数字を確認し、変化があったかを検証するサイクルとして繰り返します。
【関連記事|C01】Web課題を“迷わず抽出”できる構造と判断基準の全体ガイド
迷ったら段階ごとの落ち方に戻る
施策の話に入る前に、いったん遷移率を並べたほうが早いです。どこでいちばん落ちているか、そこで何人失っているか。この2つが見えるだけでも、優先順位はかなり決めやすくなります。
実務では、複数の施策案が出てきたり、会議でさまざまな意見が交錯したりして、「結局どこを直せばいいのか」が見えにくくなる場面があります。そうしたとき、感覚や経験則だけで施策の優先順位を決めるより、ファネルの数字という共通の基準があれば、チーム内での認識合わせもしやすくなります。「この施策を先にやる理由」をファネルの数字で説明できる状態が、分析が実務判断につながっているひとつの形です。
まとめ
覚えておきたいのは2つです。
全体CVRだけでは、直す場所は決まりません。もうひとつは、ファネル分析で分かるのは「場所」までだということです。
段階ごとの遷移率を並べることで、初めてボトルネックの位置が見えます。そこから先「なぜ落ちているのか、何を変えれば改善するのか」は、行動ログや検索意図分析、定性調査といった別の分析に進みます。ファネル分析の役割は、その入口を決めることです。
設計はゴールから逆算する。計測の前提を先に確認する。落差が大きい段階を起点に次へ進む。この3つが基本的な流れです。
「全体CVRが低い」という事実から「どこを直すか」の判断へ。その橋渡しをするのが、ファネル分析の役割です。
編集後記
分析の仕事をしていると、「数字を見ている人」と「数字を読んでいる人」の差が気になることがあります。
ファネル分析自体は難しくありません。ただ、全体CVRという一つの数字に慣れきってしまうと、段階を分けて見るという発想がそもそも出てこなくなる。そういう状態に、わりと多くの人が気づかないままいる気がしています。
「どこが悪いか分からない」という詰まり方は、能力の問題ではなく、見る角度の問題です。この記事がその気づきになれたなと思います。
参照・参考サイト
Google アナリティクス ヘルプ・[GA4] Funnel exploration
https://support.google.com/analytics/answer/9327974?hl=en
Google アナリティクス ヘルプ・コンバージョン: 定義
https://support.google.com/analytics/answer/9356034?hl=ja
Google アナリティクス ヘルプ・[GA4] セッション
https://support.google.com/analytics/answer/12798876?hl=ja
アドビ・ファネル分析とは?種類や活用の注意点、成功事例を紹介〖図解付〗
https://business.adobe.com/jp/blog/basics/funnel-analytics
Web担当者Forum・ダブルファネルマーケティングの理論と実践/『ダブルファネルマーケティング』特別公開#2-1
https://webtan.impress.co.jp/e/2013/06/25/14885
Amplitude・AARRR: Come Aboard the Pirate Metrics Framework
https://amplitude.com/blog/pirate-metrics-framework


コメント