ほとんどのファネルはユーザーではなく、プロダクトを測定しています
典型的な分析ツールを開くと、ファネルはエンジニアリングチームがたまたま計測したイベントから構築されています: route_loaded, account_created_v2, modal_opened. 技術的には正確ですが、プロダクトの意思決定にはほとんど役立ちません。なぜなら、それらが説明しているのは ソフトウェア したことであって、〜ではなく ユーザー しようとしていたこと。コードベースを測定するファネルは、コンポーネントがいつレンダリングされたかを教えてくれます;意図を測定するファネルは、誰かがどこで諦めたかを教えてくれます。
解決策は、観察された行動からファネルを逆向きに構築することです — そして、1つの数値でも信頼する前に、すべてのステップを実際の録画と照らし合わせて検証することです。次がそのワークフローです。
ユーザーの意図でステップに名前を付ける
最良のファネルはユーザーストーリーのように読めます: 料金ページに到達 → サインアップ開始 → ワークスペース作成 → スニペットをインストール → 最初の録画を確認. 各ステップはユーザーの視点から進捗を表します。次のような内部ラベルは account-created-v2 または dashboard-route-loaded コードには役立ちますが、プロダクトレビューでは意図を隠してしまいます。
ファネルがユーザーの言葉で名付けられていると、誰もがギャップをより速く見つけられます。多くのユーザーがワークスペースを作成するのにスニペットをインストールしないなら、次の疑問は明白です — そして翻訳するアナリストは必要ありません。簡単なテスト:新入社員があなたのファネルのステップを声に出して読み、ユーザーの目標を理解できないなら、そのステップは決定のためではなくエンジニアのために名付けられています。
録画で各ステップを検証する
ファネルを真実として扱う前に、各遷移の前後のセッションを見てください。最も一般的なファネルのバグはチャートにあるのではなく — それに供給するイベント定義にあります:
- 早すぎるタイミングで発動する: そのイベントは、ユーザーが実際にアクションを完了したときではなく、コンポーネントがレンダリングされたりルートが読み込まれたりしたときに発動し — そのステップを水増しし、その下の漏れを隠します。
- 頻繁に発動しすぎる: リトライ、再レンダリング、二重送信は同じユーザーを2回カウントするため、コンバージョンが実際より良く見えてしまいます。
- 誤った理由で発動する: そのイベントは、意図した成功状態ではなく副作用をキャプチャします。
セッション録画 ダッシュボードでは正しく見えるのに文脈では機能しないイベント定義を見つける最速の方法です。遷移ごとに3つのセッションを見てください;イベントがユーザーの明確な意図と一致していれば、そのステップを信頼してください。そうでなければ、データに基づいて行動する前に定義を修正してください。
離脱を読み取り、それから見に行きましょう
ファネルの役割は数値を表示することではなく — その数値を説明する録画へとあなたを導くことです。あるステップで離脱が起きても、勘で再設計しないでください。そのステップに到達して離脱したユーザーで絞り込み、彼らのセッションを5つ見れば、たいていは限られた原因のうちの1つが見つかります：
- 説明のないバリデーションエラーや無効化されたボタン。
- ユーザーが持っておらず、解決もできなかった必須項目または権限。
- 戸惑いの瞬間 — 次のアクションは、彼らが見ていた場所にありませんでした。
- まったく問題なし:彼らは必要なものを得て満足して去りました(「漏れ」ではない「漏れ」)。
その最後のケースが、ファネルだけでは誤解を招く理由です。数値は「離脱」と言い;録画は「成功」と言います。両者の組み合わせだけが真実を語ります。
1つのアクティベーションファネルを神聖に保つ
小規模なチームは、1つの中核となるアクティベーションファネルを維持し、毎週それを見直すべきです。重なり合うファネルを十数個作りたい衝動に抵抗しましょう — それらは注意を断片化し、誰もが自分のプロジェクトを引き立てるチャートを選べるようにしてしまいます。焦点を絞ったファネルは共有された運用リズムを生み出します:今週何が変わったか、コンバージョンはどこで動いたか、そしてどのセッションがその動きを説明するか?
その1つの神聖なファネルを中心に、特定の調査のために短期間の使い捨てファネルを立ち上げ、その後アーカイブできます。重要なのは、ダッシュボードの数を最大化することではなく、チーム全体が信頼して立ち返る単一の数値を持つことです。
よくある質問
ファネルのステップはページビューにすべきですか、それともイベントにすべきですか?
ほとんどの場合、イベントです。ページビューはナビゲーションを表すものであって、達成を表すものではありません — ユーザーは成功せずに「成功」ページを読み込むこともあれば、ナビゲーションなしでシングルページアプリ内で成功することもあります。ステップを、実際のユーザーの意図を表すイベントとして定義してください。
ファネルにはいくつのステップがあるべきですか?
物語を語るのに十分なだけ — 通常は4つから6つ。各ステップは意味のある決定ポイントであるべきです。隣接する2つのステップが常に一緒にコンバージョンするなら、統合してください;その間の差は何も教えてくれません。
なぜ私のファネルのコンバージョンは実際より悪く見えるのですか?
通常、ステップが早すぎるタイミングで発動するか、同じユーザーを複数回カウントしているか、ユーザー単位で重複排除をしていません。各イベントを録画と照らし合わせて検証し、生のイベントではなくユニークユーザーを測定していることを確認しましょう。
ファネルをうまく使うにはセッションリプレイが必要ですか?
それなしでもファネルを実行できますが、原因を推測することになります。各離脱をその背後にある録画と組み合わせることが、ファネルをステータスレポートから修正の源へと変えるのです。次をご覧ください ノイズのないセッションリプレイ.