こんにちは。株式会社ペライチの執行役員開発部長の佐藤です。
さっそくですが、日々開発している機能が本当に使われているか?気になりますよね。
弊社では私(エンジニア)や PdM,PO,マーケといったメンバーでサービスの指標をウォッチを行っています。
データエンジニア、データサイエンティストという専業メンバーがいるわけではなく、エンジニア側でデータ分析の基盤となるデータを整理して、PdM,PO,マーケがデータ分析(軽微な SQL 作成等データの抽出も)を行っているような形です。
そのような状況の中でサービスグロースの指標が見えてくるようになった時の話を今回は書きたいと思います。
お断り
今回はデータエンジニアがいないような組織で、RDS にあるようなデータからちょっと SQL で覗いてみようくらいから始めるときにこんな考え方をしたという話です。
専門家、専門ツールのほうが有力であると思いますし、より本質的な洞察が得られると思いますが、まぁまだそこまでのサイズ感でもないしな。。。といったケースに少しでも役立てば幸いです。
そして何よりも自分たちでまず試行錯誤しないことには、データ分析のプロセスにどのような課題があってどのように解決するべきかも設定できないので、第一歩を踏み出そうというモチベーションのお話と理解いただければと思います。
課題感
弊社は SaaS サービスを提供しており、当時は毎月の売上、新規契約数、解約数等は契約データから把握できており、MRR や課金率、チャーンレート等の把握はできていたが、特にチャーンレートの改善にどのような指標改善が有効かがわかっていない状態でした。
やったこと
まずデータ抽出、分析の糸口としてペライチで提供している機能をユーザーさんに使いこなしていただくほどチャーンにはつながりにくいのでは?と仮説を立てました。
ペライチはホームページを作れるサービスとしての認識されていることが多いですが、決済、予約、メルマガ、フォームなどネットビジネスのコンバージョンを取るために必要な複数の機能を提供しているサービスです。
なので絶対的な機能利用の指標があるという訳ではなく、機能ごとに「機能を利用した状態」を定義しました。
ex.
- 計測日にページを公開していれば、ページ編集機能を使っている。
- 計測期間内に決済機能で売上が立っていれば、決済機能を使っている。
そのうえでユーザーごと機能利用状況と契約状況をかけ合わせて抽出することで、
- 機能利用したユーザーとそうでないユーザーごとにグループ分けした時のチャーンレート
- 機能ごとのチャーンレート
- ユーザーが使っているの機能利用数ごとのチャーンレート
を抽出しました。
わかったこと
データを抽出した結果、おおむね仮説通りの傾向で、
- 機能を使っていただいているユーザーグループのチャーンレートは機能ごとに差がある。
- 機能を使っていただいているユーザーグループほどチャーンレートは低い。
- 複数の機能を使っていただいているユーザーグループほどチャーンレートは低い。
ということがわかりました。
参考イメージ
※数値はマスキングしてかつ、ダミーの数値になっております。
ここからいえることとして、以下があると考えました。
-
機能を使っていただいているユーザーグループのチャーンレートは機能ごとに差がある。
- チャーンレートが低い機能ほど、プロダクトがユーザーの課題を解決できている(から使い続けていただけている)ととらえられる。
- ユーザーの課題を解決できている = 機能として充足して来ていると考え、マーケティングでの訴求を強めて拡大すべきフェーズの機能になりつつある。
- 逆にチャーンレートが高い機能は、まだ機能として不足している。(ユーザーの課題を解決できていない)のでプロダクトを磨くフェーズ。
- (もしくはユーザーの課題を解決できない、不要な機能という判断もあるかもしれません。)
ということが読み取れるのではと考えました。
-
機能を使っていただいているユーザーグループほどチャーンレートは低い。
- シンプルな発見ですが、プロダクト開発をする際に、機能利用数を上げる開発か?という基準で開発優先順位を決めれる重要な発見でした。
- チャーンレートに何が効いたかはわかりづらいですが、機能利用数であれば一体どの開発が効いたのかの判断もしやすいかなと考えています。
-
複数の機能を使っていただいているユーザーグループほどチャーンレートは低い。
- ペライチとして複数の機能を一括で提供することを目指す意義の大きな根拠のひとつになりました。
- 今後機能間の連携機能の強化等でより一層ペライチの価値を高めることができそうな示唆を得ました。
- 1機能使っているユーザーへ別の機能の利用お試しいただく施作など検討しても良いと思いました。
次のステップ
エンジニアとして仮説と SQL の工夫で一定今後のプロダクト開発に役立つ情報を整理できたと思っています。
今後はより詳細なファネルを定義して、機能利用までにいたっておらずとも、どこまでならお使いただけたのか。どこで離脱してしまっていたのか。
という情報も DB の中の情報から取れる情報はまだたくさんあるのでさらなる情報整理を進めていきたいです。
狙いとしては、プロダクト、機能ごと 0→1 のフェーズ。1→100 のフェーズがあると思っています。
その中の 1→100 のフェーズ(機能を使っていただいているユーザーのチャーンレートが低減して来た時)にプロダクトが育った時に、機能を使わず離脱していった方のポイントはどこだったのか。といった細かいグロースの開発案件のインプットに役立てると考えています。
採用情報
現在エンジニア募集しています！データを元にしたプロダクトグロースの開発も 0→1 のフェーズの開発もいろいろやりたいことがまだまだあります！
少しでも気になった方はぜひ以下の見ていただけると幸いです！
▼ 選考をご希望の方はこちら（募集職種一覧）
▼ まずはカジュアル面談をご希望の方はこちら
募集中の職種についてご興味がある方は、お気軽にお申し込みください（CTO がお会いします）
Discussion