データ起点でのプロダクト改善の取り組み: 8月

こんにちは。普段はClearと呼ばれる教育系アプリに対して、Ruby on Railsでの開発やインフラの整備、Androidのレビューを行っています。趣味でアクセスログ解析を行っていました。

2018年8月からプロダクトの開発方針を変更し、データの観点からもアプリの各種KPI向上を目指すことになりました。 そこでの取り組みについて、まだまだ手探りですが誰かの役に立つかもしれないので備忘録を兼ねて記しておきます。

前提

  • 世界で200万DLくらいのC to C学習アプリ
  • アプリからのアクセスログはAWS Redshiftにたまっている
  • データ観点での施策は既存機能にまつわる課題の解決に留める。より大きな目線での課題解決はデザイナーが担当

なぜやるのか

これまでの開発方針ではMAUなどの主要KPIの増加を狙うため施策を行っていましたが、個人的に以下の問題があると感じていました

  • 施策に効果があったか評価をしない
  • 施策に効果があるかどうかわからないまま結構な工数を消費しがち

またこれまでユーザーへのインタビューなど行い、ペルソナなどもつくっていましたが、うまくそれをプロダクト開発に活用できていないのも気になっていました。仮説に対する学びを得る、無駄な工数を減らす、ユーザーから得られた情報を活かすという想いから開発方針の変更に至りました。

こんな人におすすめ(だと思う)

  • リーンスタートアップやInspiredをよんだが何したらいいのかいまいちわからない人
    • 僕もよくわからないので試行錯誤してる最中です
  • プロダクトチーム5人以下の小さな会社
    • おそらく大きな会社だとグロースチームや分析チームなどいろいろな役職の人がいるので、より効率的なやり方があると思います。

方針

まずこれからの開発方針を考えました。これまでの施策の粒度には統一感がありませんでしたが、これからはできるだけ「一番インパクトのある課題を解決する」という観点を重視しました。

具体的には以下のような方針で開発をすすめています。

一番改善後の効果が高いパイの多いセグメントをさがし施策を考える

例えばすでに利用頻度の高いヘビーユーザーの利用頻度をさらに上げるよりも、より多くいる通常ユーザーの利用頻度上げたほうがトータルでの利用頻度が上がります。 多くの人がつまづいている部分を見つけ出すことで改善の効果をあげようと考えました。

ヘビーユーザーがよく使用するアクションをとりやすくしたり、より良くする

ヘビーユーザーが価値を感じてよく使ってくれる機能にアプリの価値があると考えました。ただし、新規ユーザーにとっては意図が伝わっていない事があるかと思います。 事実一部機能の使い方がわからないと頻繁に問い合わせをいただいたり、アンケートをとってみると多くの人が存在に気づいていない(!?)機能がありました。

これまでは新機能追加や機能改善などリリースして振り返りもされず放置されることが多かったため、改めてすべての機能の利用実態を調査する必要性を感じていました。新規ユーザーにはアプリの良い部分を理解しやすくし、既存ユーザーにはより良いものを提供しようと考えました。

各ペルソナが抱える致命的な課題を解決する

今回対象のアプリはCGMであり、パイの多いコンテンツ消費者だけでなくパイの少ないコンテンツ作成者のための施策も必須だと考えています。 アプリ内で各ペルソナを定義してるのに、なぜかこれまでの開発の流れだと特定ペルソナへの改善しかできていませんでした。

速度重視

以前からリリースされっぱなしの状況が好きじゃなく空き時間で施策の分析をやっていましたが、今回から業務時間を使うことが可能になりました。

これまでの経験上、分析に時間がかかりすぎることがありました。分析業務以外にも開発業務や採用活動などやることはいろいろあります。 検証精度はさほど高く無いところをまずは目指し、回っていなかった施策のPDCAサイクルを高速で回すことを重視するようにしました。

参考:

medium.com

具体的な取り組み

1. アクセスログ分析

上記方針に乗っ取り、以下の観点で分析します

  1. 課題を解決すると伸びそうなセグメントを調べる
  2. 多くの人がつかっているアクションはなにかを調べる
  3. KPI的に理想の人がどんな使い方しているのかを調べる
  4. a.、b.、c.から伸びそうなセグメントに使って欲しいアクションを定め、現状を調べる
    • もしそのアクションに対して過去に影響を及ぼしたであろう施策があれば数値の変化を調べる。施策に効果があったかどうかざっくり見えるかもしれないため。
  5. 上記のデータから、ユーザの特定のストーリーに対する課題の仮説を立てる
    • 大体ここまでいくともはやデータでは把握できないとこまで調べてるはず。これ以上わからないことがあればユーザーに直接課題感を聞くことに

例：

a. 毎月あえて1日だけアクセスする既存ユーザーさんがかなりの数いる
b. ノートの検索機能をとても良く使う
c. 検索といいねをよくする
d. 毎月1日だけアクセスする既存ユーザーさんは検索してもノートをみるまでに至らないことが多い
e. 検索に問題があるかも？

2. アンケート&インタビュー

1.の分析で完全にわからないこと、例えば課題となるアクションははわかったが具体的にどういう点が一番つらいのかなどをユーザーに直接きいていきます。

アンケートの具体的な送り方は以下一応記しておきます。

  1. GoogleFormでアンケート作る
  2. アプリ内に運営からのお知らせを通知できる場所があるので、そこでアンケート協力のお願いをする

アンケートをする際は対象を厳選することを意識しました。以前全てのユーザーにアンケートを送るとマイノリティであるヘビーユーザーからの回答が多くを占めることがわかり、課題感のある人の意見が汲み取りにくいことがわかっていたからです。

例：

検索に課題がありそうだけど、「検索で欲しいノートがでてこない」「検索結果の画面がわかりにくい」とかいろいろあるので、
毎月1日だけアクセスする既存ユーザーさんにアンケート

3. 1.~2.の繰り返し

具体的な施策に落とし込めるまで繰り返していきます。

例：

「検索で欲しいノートが出てこない」ことに課題感あるのはわかったけど、
「表記ゆれ」への対応に課題感があるのか、「検索の仕方がわからない」ことに課題感があるのかわからないので追加アンケート

4. 実装の前にABテスト

ここまでで具体的にやるべき施策まで落とし込めると思うので、本実装に入る前に事前にABテストをします。 UI修正が必要な部分に対しては審査が無く高速で検証できるAndroidでABテストをし、UI修正が不要な部分に関してはできるだけ既存の機能を使って最短でABテストを実施し、手応えを掴むようにしました。

UI修正が不要な例：

ノートを作成してくれるユーザーは、1.~3.までで「公開しても特にみんなからの反応がなく、役に立っているのかわからない」
という課題感があることがわかった。
ソリューションとして、ユーザーがノートにいいねしたときに通知する「いいね通知機能」を運営からのお知らせ機能をもちいて
最短でABテスト

→評判よかったし、定量的にも効果あった。そもそもなぜいいね通知機能がなかったのか

5. 本実装

4.で効果があったことに関して本実装に進めます。大きな会社だと4.の時点である程度ほぼ本実装と遜色のない正確な検証ができるとおもいますし、できればそちらのほうがいいのかなと思っています。 ただうちはリソースが足らないのでここでサクッと再度よりよい形を考え、提供するようにしています。

発生した問題と対応

アンケートやABテストの集計が終わるまで暇

アンケート調査やABテストのフェーズで待ち時間が発生することが多いです。 この問題に対応するため、Trelloで各ペルソナごとの課題を管理し、待ち時間に着手していない課題について進めるようにしました。

f:id:koyamay:20181002135233p:plain

現時点までの結果、感想

良かったこと

  • 今まで無視されがちだった効果のあるソリューションが提供できた
  • ある程度効果があると自信を持った状態で施策をうてるようになった
  • iOS/Androidエンジニアが本実装する前にある程度高速で仮説が検証できるようになった
  • ABテストの体制ができ、高速で検証ができるようになった

ABテスト、もともと交絡因子が厄介でやりたいと前から思っていました。 やってみると割と大胆な変更もテストでき、変更に対する心理的障壁が下がるので改めて思いますが良いです。

難しいところ

  • 細かい課題までブレークダウンしたあとの施策を考える流れ

これまでの開発方針では実装工数が最短になるようなMVPの観点でデザイン修正を施しています。 問題がある部分だとわかった上での修正なので、ある程度思い切った修正にうつりたいです。 現状まだちょっとうまくいっていないと感じています。 実装工数はあまり気にせず、本実装前のソリューション検証のフェーズをMVPで行っていきたいです。

まとめ

手探りで進めていますが今のところ割といい流れで進めています。今後社内外の人といろいろ相談しながらより改善していければと思います。