ファネル分析実践入門 〜Web版メルカリの事例で学ぶ〜
こんにちは。メルカリ Analytics チームの @suwachan です。2021年4月にメルカリに入社し、入社当時からWeb版メルカリの分析を行っています。
この記事では、私が実際に行ったWeb版メルカリの分析を例に、ファネル分析の具体的な進め方・考え方について解説いたします。
この記事を通して、ファネル分析の実践のサポートができれば幸いです。
想定する読者の方
・ファネル分析をやってみたいマーケティング担当・アナリスト・PMなどの方
・ファネル分析にかかわらず、分析の基礎について学びたい方
注: この記事に出てくる分析内容・結果は、実際のものとは異なります。
ファネル分析とは
ファネル分析とは、お客さまの購買行動をいくつかのステップに分け、そのステップごとに遷移率 (または離脱率) を算出し、改善点を分析する手法です。
通常、ステップごとに人数が減っていくため、それを図式化すると漏斗 (=ファネル) のようなかたちになることから、「ファネル分析」と呼ばれています。
主にマーケティングの分野で使われるようですが、プロダクトの改善にも使える手法です。メルカリ社内でも、ファネル分析を用いた分析は多く行われています。
ファネル分析を利用するメリットは、ひとことで言うと「優先的に改善すべき箇所を見つけられること」です。
遷移率などの数値の比較・仮説検証を通して、改善インパクトの大きい箇所を見つけることができます。
Web版メルカリとは
ファネル分析の説明に入る前に、今回の分析事例となるWeb版メルカリについてご紹介します。
メルカリと言うと「アプリで使うもの」というイメージが強いかもしれませんが、メルカリはWebブラウザでも使うことができます。
リニューアルオープンした新しいWeb版メルカリ
https://jp.mercari.com/
Web版メルカリでも、アプリと同じように商品の購入・出品が可能で、マイページでは取引の連絡や、過去の取引の確認等もできます。 また、パソコン・スマートフォン両方からアクセスができます。(注: Web版メルカリでは、一部アプリにある機能がないものもあります)
Web版メルカリは、メルカリのアプリと比較すると利用者数の規模が小さいため、社内での注力度合いはアプリよりも低い状況が続いていました。
しかし、コロナ禍における変化として、オンラインショッピングの利用が増えたり、自宅でPCを使う時間が増えたりしたため、Web版メルカリを使ってくださるお客さまが増えてきました。
そのため、もっとWeb版メルカリをあんしん・あんぜんに使いやすくしていきたいという流れが本格的になっていきました。
そこでAnalyticsチームでは、Web版メルカリのどこに課題があり、どこから改善していくべきなのかを分析・提案していくことになりました。
Web版メルカリのファネルを可視化する
今回の分析は、「お客さまのWeb版メルカリの利用の流れにおいて、どこを改善すべきなのか」というざっくりした問いからはじまりました。
まずは見当をつけるところからのスタートです。
ここで登場するのが「ファネル分析」です。Web版メルカリの利用の流れをファネルで可視化すると、以下の図のようになります。
お客さまは、まずメルカリのどこかのページに訪問します (ステップ1) 。
購入したいと思ったお客さまは、登録ページにアクセスし、登録を進めます (ステップ2) 。
無事に登録を完了したお客さまは、買いたい商品の購入手続きを行います (ステップ3) 。
アプリでも使いたいと思ってくださった場合、アプリにもログインします (ステップ4) 。
理想は、訪問してくださったすべてのお客さまがきちんと購入したい商品と出会うことができ、あんしん・あんぜんにお取引ができる状態です。
では、その理想の状態を作っていくために、何がブロッカーとなってしまっているのでしょうか？
それをファネル分析で明らかにしていきます。
今回は、次の3ステップに分けて分析を行いました。
1. 大まかな課題の把握・・・ファネル全体の遷移率の算出
2. 具体的な課題の特定・・・各ステップの内訳や詳細な遷移率の算出
3. 対策優先度の策定・・・・分析結果に基づき何から行うべきか決定
ポイントは、全体 → 細部の順番で進めることです。
「会員登録に課題がありそうだ」という仮説があるとしても、改善のインパクトが大きいかどうかは他と比較してみないと分かりません。
まず全体像をつかみ、ざっくりどこに課題があるのかを把握してから、細部の分析に入っていきます。
分析手順1. ファネル全体の遷移率の算出
1つ目の分析においては、ファネル全体の遷移率を算出し、どのステップに課題がありそうか当たりを付けます。
分析する際には、まず各ファネルのステップにあたるページやイベントを定義します。たとえば会員登録であれば「会員登録ページへの訪問」、購入であれば「購入イベントの完了」などです。
そのページのアクセス数やイベントの発生数をユーザーごとにカウントし、前のステップから次のステップへの遷移率を算出します。
ステップごとの遷移率を相対的に比較することで、どのファネルのステップでお客さまがつまずきやすいのかが明らかになります。
数字をあてはめてみると、以下の図のようになります。
※数字は仮のものです
Web訪問のお客さまが100人いた場合、会員登録が20人であれば遷移率は20%。そのうち15人が購入した場合は遷移率75%、といった感じです。
補足) 時系列で見てみよう
遷移率は、直近の数字だけでなく、時系列で見てみることをおすすめします。たとえば「2年間の月次推移」などです。
時系列で見ることにより、以下のようなことが分かります。
1. 季節トレンドがあるのかどうかが分かる
2. その月だけたまたまその数字だったのか、恒常的に近い数字を取るのかが分かる
3. 遷移率が上がった・下がったタイミングで、何があったかを分析することにより、遷移率に影響のある要因が分かる
分析手順2. 各ステップの内訳や詳細な遷移率の算出
全体観がつかめたら、次はより具体的な分析を行って課題を特定します。
課題を特定するには、「ステップの内訳を見る」と「ファネルをさらに細かくして見る」の2つの方向性があります。
1. ステップの内訳を見る
ステップの内訳とは、ある切り口でお客さまをグループ分けしたときに、遷移率がどうなっているかを見るものです。
例えば、「デバイス」という切り口を使う場合、PCのお客さま・スマートフォンのお客さまでグループ分けし、遷移率をそれぞれ算出します。
先ほどの分析手順1の全体の分析では、会員登録のステップの遷移率が相対的に低そうであるということが分かりました。
メルカリは、会員登録の方法をいくつか用意しており、各会員登録方法によって機能やプロセスに少し違いがあります。
どの会員登録方法でも同じように会員登録率が低いのでしょうか、それとも違いがあるのでしょうか？ それはどの機能差分によるものなのでしょうか？
その問いに答えるために、登録方法別の会員登録率の内訳を見てみたのが以下の図となります。
※数字は仮のものです
登録方法A・Bは会員登録率が比較的高く、C・Dは低くなっており、登録方法ごとに差があることが分かりました。
ここから先の進め方は、場合によりますが、たとえば登録方法A・BとC・Dの間でどの機能やプロセスが異なるのか？ それは改善できるのか？ などを見ていきながら課題と打ち手を探っていきます。
そもそも登録方法C・Dを選ぶ人数が少なければ、改善インパクトが小さいとみなし、対応優先度を低くしてもよいでしょう。ただし、その分析結果と解釈はドキュメントに残しておきます。
このように「ステップの内訳」を見ることで、課題の大きい箇所を特定しやすくなります。
補足) いろいろな切り口で見てみよう
今回の例は登録方法ごとに内訳見てみましたが、他にも以下のような切り口で見る方法があります。
・デバイスごとに見てみる (PC・スマートフォン)
・スマートフォンOSごとに見てみる (iOS・Android)
・ランディングページごとに見てみる (TOP・検索ページ・商品ページ etc.)
すべての切り口で見ることはなかなか難しいので、仮説を立てて見ていくと効率的です。
たとえば、仮説としては「PCでは入力が比較的かんたんだが、スマートフォンはより面倒なのではないか。つまりデバイスによって会員登録率に差があるのではないか？」などが考えられます。
この仮説に対する施策としては、例えばスマートフォンでは入力項目を減らしたり、入力補助を行ったりすることが挙げられます。
2. ファネルをさらに細かくして見る
ファネル全体のステップは、かなりざっくりしています。
実際には「会員登録」と言っても、「会員登録のページを表示する」「会員情報を入力する」などのステップに分かれているはずです。
ステップをさらに細かく分解して分析していきます。
デバイスごとに会員登録率の内訳を見た際、PCのほうが低かったとしましょう。
PCのお客さまは、登録ステップのうちどこでつまづいているのでしょうか？ スマートフォンと比較してみると次のような図となります。
PCは、スマートフォンと比較すると、ステップCで遷移率が低くなってしまっています。
このデータから「PCではステップCになにかハードルがあるのではないか？」という課題が設定できます。その課題に対して調査し、打ち手を議論していきます。
分析手順3. 対策優先度の策定
今回のファネル分析は、毎週プロダクト・マネージャーとミーティングをしながら進め、仮説出し→データの可視化→仮説検証のサイクルを繰り返しました。
そのうちに「具体的に改善すべき画面」や「施策の方向性」が見えてくるので、対策優先度を考えていきます。
改善インパクトの大きさや想定される施策の実現可能性、実装の重さなどを考慮しながら、最終的な優先度をつけていきます。
ファネル分析の注意点
ファネル分析は便利なフレームワークですが、注意点もあります。
注意点1. 数値の差分が必ずしも「解決すべき課題」であるとは限らない
上記の例では、スマートフォン・PCの間であるステップに数値の差があることが分かりました。
しかし、これが必ずしも「解決すべき課題」であるとは限りません。
スマートフォン・PCの特性の違いから、どうしても避けられないものである場合、無理に改善しようとせず、他の改善インパクトの大きいポイントを探しましょう。
注意点2. アクションに結びつかない分析は、なるべく避ける
たとえば「会員登録率の内訳を、流入経路 (チャネル) 別で見てみる」という分析をし、「自然検索流入では会員登録率が比較的低い」という結果が出たとしましょう。
アクションとしてはどうなるでしょうか。「チャネル別に登録方法を出し分ける」という施策は現実的ではなさそうです。
「この分析の結果どんなアクションにつながるのか」を想定し、プロダクト・マネージャーやエンジニアとできる・できないを整理しておくことも重要です。
注意点3. ファネル分析の限界を知っておく
ファネル分析に限りませんが、分析によって「どこを」改善すべきかが分かっても、それがなぜ起こっているのか、「どのように」改善すべきか、が分かるわけではありません。
それを特定するには、実際に自分でプロダクトを使ってみたり、ユーザーインタビューをしたりしてみる必要があります。
ファネル分析の結果得られたこと
ファネル分析を通して、Web版メルカリをどこから改善していくべきか、対策優先度を付けることができました。
現在は施策の具体的なスペックを検討しつつ、それを実現するための開発体制を組んでいるところです。
また、ファネル分析に限らないことですが、Web版メルカリを分析することで、これまで社内に蓄積されてきたアプリの分析結果と比較することができるようになったのも良かったポイントです。
もちろんアプリとWebは使われ方が異なるため一概に比較はできませんが、「この部分はアプリと比較するとWebの強みとなりそう」といったインサイトが得られました。
ファネル分析で用いたツール
今回の分析では、Google Analyticsのデータと、社内で蓄積しているイベントログや取引ログを利用しました。(注: イベントログとは、あるボタンのクリックや会員登録完了などWebサイト上でユーザーが行う行動をイベントと呼び、そのイベントを記録したもの)
Google Analytics と社内ログを併用しているのは、一方にないデータが他方にあるためです。
たとえば Google Analytics は、参照元 (どのページ・サイト・チャネルから来たのか) などが記録されています。
一方社内ログでは、お客さまごとの過去の取引履歴といった情報が格納されています。
これらのデータを統合することで、より多様な分析ができるようになります。 集計はBigQuery上で行いました。
ファネル分析のまとめ
ファネル分析を活用する際の重要なポイントをまとめておきます。
・ファネルを可視化し、まずは分析の全体像を把握すること
・次にファネルの各ステップの内訳や詳細のステップを分析し、改善インパクトの大きい箇所を見つけること
・関係者と密に連携し、仮説の良し悪しや施策の実現可能性を話し合うこと
最後までお読みいただき、ありがとうございました。
▼採用情報サイト・関連記事はこちらから
▼Analytics teamに関する他のオススメ記事
・「他人の目」ではなく「自分のやりたいこと」に集中できる場を求めて メルカリAnalytics新卒メンバーの所感
・アナリスト歴3ヶ月目と3年目のメンバーそれぞれが考える、楽しさの軸とキャリアプラン
・メルカリAnalyticsチームのミッション・ロールモデルを策定した狙い マネージャーが語る“変遷”と“今