モーダルを出すだけで登録後のコンバージョン率が30%改善した話

こんにちは！Wantedly ユーザーグロースチームの竹野です。普段は Web エンジニアとしてモバイルウェブやアプリ API の開発をしています。

さて、Wantedly では、エンジニア自身が施策を考え、実装から評価まで行います。これを実現するために、さまざまな仕組みやプロセスがあることをこの Wantedly Feed で紹介してきました。

今日は、僕が過去に行った実際の施策「モーダルを出すだけで登録後のコンバージョン率が30%改善した話」を取り上げることで、実際にどうやってグロースをしているかをできるだけリアルにお伝えできればいいなと思っています。

サービスの基本機能とチームの目標

まず背景としてちょっとだけ Wantedly の会社に遊びに行くサービスについて説明します。

Wantedly には「募集」と呼ばれる会社が作成したコンテンツがあります。ユーザーはこの募集を見て、興味のある会社があれば「話を聞きに行きたい」ボタンを押すことで会社に興味を伝えることができます。その後、会社の人がプロフィール等を見て会ってみたいと思ったら Wantedly 経由で連絡が来ます。

この話を聞きに行くボタンを押すアクションを「応募」と呼んでいて、Wantedly におけるコンバージョンになります。

また、画面左下にある応援ボタンを押してSNS等にシェアするアクションを「応援」と呼んでいて、これも一つのコンバージョンになります。こちらは主に募集をしている会社の社員やその友達が利用します。

他の多くのサービスと同じく、Wantedly でもこれらのボタンは未ログイン時にも表示されており、これが押されるとユーザーに登録・ログインを促します。

そして、この施策を行ったとき、ユーザーグロースチームの目標は月間の応募ユーザー数を1.3倍にすることでした。

施策アイデアと仮説立て

様々なデバイスから使われるサービスでは、必ずユーザーがログインしてサービスを利用しているということは期待できません。

例えば、Wantedly の募集は Facebook にシェアされることが多いですが、Facebook アプリから募集を閲覧する場合でも約半数のユーザーはログインしていません（こういった事実はデータウェアハウスである TreasureData にクエリを投げることで確認できます）。

自分たちで開発しているサービスは普段ログインしているので、あえてログアウトした状態にして、SNS に流した募集に応募してみました。するとログインしている時に比べてちょっと使いにくい。

具体的には、応募ボタンを押してログインすると、元の募集ページにリダイレクトされ戻ってくるのです。これは普通に Rails で実装したらまあそうなるよねという挙動なのですが、元のページに戻ってきてもう一回応募ボタンを押すのは微妙に面倒です。なら募集ページに戻ってきたら勝手に応募のモーダルが出すのが良いかも？というアイデアが出ました。

図にすると、こんな感じです。

さて、ここまでがアイデアです。

この後いきなり実装に取り掛かりたくなりますが、このアイデアが実装された時に実装されて良かったと判断するにはどのポイントを明らかにすべきか？を言葉にしておきます。つまり仮説ですね。

今回の仮説は次のようになります：

ログイン後にログインのトリガーとなったアクションを促すモーダルを出すことで、
そのアクションを行わずに離脱するユーザーが減る

仮説を検証する

仮説を検証するための非常に強力なメソッドが、ランダムに振り分けたユーザーに異なる挙動を出し、結果を比較する A/B テストです。

今回は、50%のユーザーはログイン後にモーダルが出るようにして、50%のユーザーは元の挙動になるようしました。仮説が一般性のあるものなので、モーダルは応募と応援のどちらでも出るようにします。

このテストを一定期間走らせた結果がこれです。応募について出しました。

説明すると、施策のあり／なしのグループそれぞれに対して、1) 応募ボタンを押してログインした人数、2) その直後に実際に応募した人数、3) 1と2の割合 となっています。

ログイン後にモーダルを出したグループの方が応募ユーザーの割合が29%多いことが分かります。良くなってそうですね！

統計的に有意な差？

これで仮説が検証できた！…と言いたいところですが、次のような疑問が残ります。

・良くなっているという結果が偶然であるということはないか？

・この結果はどのくらいの幅でぶれるのか？

これは R の prop.test 関数を使うことで確認できます。Execute R Online で次のコードを打ち込んでみましょう。

> prop.test(c(52, 31), c(69, 67), conf.level=0.85, alternative="greater") 

  2-sample test for equality of proportions with continuity correction

data:  c(52, 31) out of c(69, 67)
X-squared = 10.905, df = 1, p-value = 0.0004794
alternative hypothesis: greater
85 percent confidence interval:
 0.1933031 1.0000000
sample estimates:
   prop 1    prop 2 
0.7536232 0.4626866 

この出力結果を先ほどの疑問に答える形で書くと、こうなります。

・良くなっているという結果が偶然であるということはないか？

　→ 偶然である確率は 0.04%

・この結果はどのくらいの幅ぶれるのか？

　→ （悪い方にぶれても）+19.3%

確実に良くなっていて、かつその幅も20%以上と大きいことが分かりました。

そして、応援に関しても同じような改善が見られたことから、最初に立てた仮説、

ログイン後にログインのトリガーとなったアクションを促すモーダルを出すことで、 そのアクションを行わずに離脱するユーザーが減る

は正しいと結論付け、全ユーザーにこの挙動を開放しました。

検証できた仮説を展開する

ここまででもモバイルウェブの応募は目に見えて良くなったのですが、実はまだやることは半分残っています。

それは、検証できた仮説の展開、別の言い方をすると上手く行ったパターンを広げることです。

Note: 今回の施策は、純粋にUXを良くするためにやるということも可能でしたが、きちんと仮説を立てて結論を出すことで自信を持って他に広げられるものになりました。この展開性を持たせられる部分がデータを見ることのメリットだと思ってます。

PCウェブへの展開

PCウェブの募集ページもモバイルウェブの募集ページと同ような仕様になっていたので、同様にログイン後にモーダルを出すようにしました（念のため A/B テストを行った結果、数値的にも良い結果が得られました）。

メールへの展開

Wantedly では友達が募集を始めると応援を勧めるメールを配信しています。このメールには「応援」ボタンがあるのですが、このボタンは募集ページに飛ぶだけでした。これは、ユーザーが二度同じボタンを押す必要があるという点で、ログインの時と同じ問題を抱えていました。

そこで、メールの応援ボタンを押すと募集ページが開いた上で応援モーダルが出るようにしました。

成功パターンを広げるための仕組み化

ここまであまりエンジニアリングの話が出てきませんでしたが、このパターンを広げる部分では適切な仕組みを作ることが重要だと思っています。

改善すると言っても色々な箇所で ad-hoc な実装をしていてはコードの保守性が落ちますし、何よりインターフェースを良くしておくことで実装が簡単になり広まりやすくなります。

今回の例では、結局ユーザーがページを開いた後に何かをさせたいということだったので、URLパラメータとしてページを開いたあとにすべきタスク名を渡せるようにしました。 そしてクライアントサイドではそれぞれのタスクが渡ってきた時に何をするかを登録できるようにしました。

まとめ

この記事では僕が過去に行った施策を例に、施策のアイデア出しから仮説立て、仮説の検証、そしてその結果分かったことを他に展開していくところまでを一通り説明しました。

施策アイデア 様々なデバイスからユーザーがサービスを使うことから、未ログイン時のUXが良くないことを発見し、ログイン済みの時のフローに合わせてモーダルを出すことを考えました

仮説立て 施策アイデアが良いと言えるかどうかを判断するためのポイントを明確にするために、ログイン後にログインのトリガーとなったアクションを促すモーダルを出すことで、 そのアクションを行わずに離脱するユーザーが減るという仮説を立てました。

仮説の検証 応募と応援のそれぞれについてモーダルを出す A/B テストを行い、ログイン・登録後の応募が30%改善することを確認しました。併せて統計的な有意性を確認し、偶然の要素がどの程度入るかを把握しました。

検証できた仮説の展開 プラットフォームを変えても有効だという見込みの元、PCウェブにも同様の施策を入れました。また少し観点を変えて「同じボタンを二度押させることを避ける」という視点から、メールにも似た施策を入れました

今回は説明のためにシンプルな施策を取り上げましたが、実際にはグロースのために機能開発や選択的な受信など事前の仕込みが必要なことも多いです。ただその場合でも、このように自分なりの仮説を立ててユーザーとサービスに対して理解を深めていくというプロセスは有効なのではないかと思います。

参考資料

1. Wantedly ではサービスの現状を定量的に把握するために、基本的なセグメントや指標について継続的な可視化を行っています。

2. 途中で紹介した R の prop.test などの使い方が詳しく紹介されています。