はじめに
こんにちは。askenでプロダクトマネージャーを担当している伊藤です。
主に「あすけん」のロードマップや機能企画を考えたりする仕事をしていますが、本日はプロダクト利用状況の分析に関して書かせていただきます。
これにあたり、先日開催したPdM勉強会の内容を一部抜粋し、同じく習慣化をテーマにアプリ運営をする他社様の事例も交えてご紹介いたします。
当社の事例に関しては、実際のSQLクエリやアウトプットも交えてご紹介しますので、ぜひ最後までご覧ください。
抜粋元のイベントについて
イベント詳細および登壇者のプロフィール詳細はこちらをご覧ください。
- 戸田 大介 氏(bondavi株式会社)
- 飯田 諒氏 (株式会社mikan)
- 伊藤 拓哉 (株式会社asken)
各社が見ている重点指標は?
習慣化促進アプリ「継続する技術」の場合
見ている指標: 30日の目標達成率
元々データサイエンティストをされていた戸田さんは、KGI/KPIへの意識を特に強く持たれているとのことです。そのため、ユーザーにとって重要な瞬間では必ずデータ取得ができるよう、留意して設計されています。
「継続する技術」では、ユーザーが決めた任意の習慣を「30日間継続して達成する」ことがゴールとなるため、これをプロダクトのKGIとしても定義し、このKGIが増加すればするだけ、ユーザーに対しても価値を提供できていると見なすことができるようになっています。また、プロダクトに施す変更は、全てこの「30日の目標達成率」に寄与するか?という観点でレビューを行い、テストを実施しているとのことです。
英語学習アプリ「mikan」の場合
見ている指標: 利用開始翌日と7日後の継続率
英語学習アプリ「mikan」では、各個別施策のKPIは別途設定しつつ、KGIとして特に初期の継続率を重視しています。具体的には、利用開始翌日と7日後の継続率です。
このKGIを上げるために、例えば「プッシュ通知の許諾率」といったKPIを設け、
- ユーザー自身に目標を宣言させる
- 「宣言した目標達成を支援するために」という理由を明確にした上で、通知許諾を取る
といったような体験設計をしているとのことです。
食事管理アプリ「あすけん」の場合
見ている指標: ロイヤリティ別でのDAU推移
現状のあすけんは「なるべく毎日食事を入力し、意識し続けることで成果が出る」という特性があります。
そういった意味で言うと、もちろん売上やMAU等の基本的な数字は日々見ていますが、私はプロダクトマネージャーとして「毎日使いたくなるプロダクトになっているか?」を最も気にしています。
単にアクティブユーザー数を見ることもできますが、こうした指標は一時的に増加することもあり得ます。(例: テレビ番組で紹介された / インセンティブキャンペーンを実施した / 大規模な広告施策を展開した など)
こういったイレギュラーを考慮しながら、結果的に「毎日使いたくなるプロダクトになっているか?」を測るために、ロイヤリティ別のDAU推移をウォッチしています。
ロイヤリティ別のDAUとは?
ある1日のアクティブユーザー(DAU)の内訳を細分化すると、その日初めてアプリを開いた、1年ぶりにアプリを開いた、という人もいれば、昨日も一昨日も毎日開いている、という人もいます。
このようなログイン頻度での内訳を日次ベースで可視化することで、「連続してログインしてくれている人」がちゃんと増えているか?を見ることができます。
数字はダミーとなります。
ロイヤリティ別のDAUを積み上げ棒グラフで表現すると、地層のごとく可視化することができます。サービスのグロースやマーケティングを考えていく上で、下層のオレンジ色と赤色の層を厚くしながら、アクティブユーザー数の規模を拡大していくことが重要です。
数字はダミーとなります。
どうやって出す?
BigQuery上で下記のようなSQLクエリを実行し、ロイヤリティ別のDAUを計算しています。
with #ユーザーごとのログイン日付と、集計開始日から起算した日数を抽出します。 login_logs as ( select user_id, login_date, date_diff(login_date, date(2017, 1, 1)) as day_num from analytics.logins where login_date >= "2017-01-01" group by user_id, login_date, day_num ) # 上記で算出したday_numとrange ~ preceding句を使って、各login_dateから30日前までの期間でのログイン日数を算出します。 login_counts as ( select user_id, login_date, count(login_date) over (partition by user_id order by day_num asc range 29 preceding) as cnt_login from login_logs ) # ログイン日数ごとにセグメントを分け、人数をカウントします。 aggregation as ( select login_date , countif(cnt_login = 1) as cnt_once , countif(cnt_login between 2 and 9) as cnt_super_light , countif(cnt_login between 10 and 19) as cnt_light , countif(cnt_login between 20 and 29) as cnt_loyal , countif(cnt_login = 30) as cnt_super_loyal from login_counts group by login_date ) select * from aggregation order by login_date asc
テーブル名やカラム名は全てダミーとなります。
おわりに
事業のフェーズやプロダクトの特性によって、見るべき指標が様々であることは言うまでもありません。これをお読みいただいている方々にとって、指標選びの参考になれば嬉しいです。最後までご覧いただきありがとうございました!