ANDPADチャットチームでエンジニアをしている椎野(@taikishiino)です。
前回、5000万件越えのRDS大量データをFirestoreに移行する勘所 という記事を書かせていただきました。
その後、グロースのための施策にも徐々に注力できるようになってきました。 今回は効果的にグロースさせていくための効果検証の仕組み作りの取り組みについて紹介していきます。
効果検証
主な効果検証の目的は以下の2つです。
- リリースした機能のニーズの検証
- ユーザーの操作傾向の把握
機能をリリースして終わりではなく、ユーザーの反応をみて改善していく。既存機能についても操作傾向を把握することにより改善に繋げていく。そんなサイクルを作っていきたいという思いから効果検証の仕組み作りを始めました。
どんな方法で
機能導線のタップ・クリックでFirebaseにログを送りmetabaseのダッシュボード機能を使って可視化する方法をとりました。
こちらのログ基盤は既にデータ基盤チームが構築してくれていたので「プロダクトからどんなログを送るか」に集中することができました。
Firebase Analytics ログイベントについて
- 導入
- Firebase SDKをアプリに導入すると使えるようになります。
- 仕様
- イベント名とパラメータ名は、定義済みの名前と自分で作成する名前の2種類があります。
- 定義済みの名前
- イベント： FirebaseAnalytics.Event
- パラメータ： FirebaseAnalytics.Param
- 定義済みの名前
- イベント名とパラメータ名は、定義済みの名前と自分で作成する名前の2種類があります。
- 制限
- アプリごとに最大500までイベントを使えて、各イベントタイプに最大25の一意のパラメーターを関連付けることができるとのことです。制限に関してはそれなりに余裕がありそうです。
An Event is an important occurrence in your app that you want to measure. You can report up to 500 different types of Events per app and you can associate up to 25 unique parameters with each Event type. https://firebase.google.com/docs/reference/android/com/google/firebase/analytics/FirebaseAnalytics.Event?hl=ja
- アプリごとに最大500までイベントを使えて、各イベントタイプに最大25の一意のパラメーターを関連付けることができるとのことです。制限に関してはそれなりに余裕がありそうです。
どのようにイベント設計したか
各画面の機能導線の「タップ数/UU」を可視化することで対象機能のニーズを検証したいので、ユーザーID・画面・機能導線の3つのパラメータが必要でした。
そのためにFirebase Analyticsの以下2つの機能を利用しました。
- EventSelectContent（FirebaseAnalytics.Event）
このイベントは、アプリ内の人気のあるコンテンツとコンテンツのカテゴリを特定するのに役立ちます。
- イベント名： select_content
- タイミング： ユーザーがアプリ内でコンテンツを選択したとき。
- パラメータ： content_type、item_id
- ユーザーIDの設定（ユーザーIDを設定する）
- （2022/03現在）WebSDKではこの機能が使えないようなので、ユーザープロパティを設定するで行いました。
パラメータルール
各画面の機能導線のタップ数を集計するために以下のようなパラメータルールを定めました。
- content_type: 画面名
- item_id: 機能導線名
- コンテンツの選択：select_
- コンテンツの長押し：press_
- 設定値のON/OFF系：setting_
どのように可視化したか
以下の3つのダッシュボードをmetabaseで可視化しました。
- 画面内の機能導線タップ総数の割合
- 対象画面の各機能導線のタップ数/UU
- 対象機能導線のタップ数/UU
画面内の機能導線タップ総数の割合
画面ごとのタップ総数の割合を把握するためのグラフです。
画面ごとにイベントを仕込む対象導線の数に影響をされやすいグラフなので、「割合が多い＝滞在時間が多い・使われている」と判断してしまうのはあまり好ましくないと思っています。
イベントを仕込んでいる導線を全て把握した上で、あくまで大枠の操作傾向を掴む目的で使うことを想定しています。
対象画面の各機能導線のタップ数/UU
特定画面でイベントを仕込んでいる機能導線のタップ数/UUの変化をリリース前後で比較するためのグラフです。
- Web: 月次比較
- iOS/Android: バージョン別比較
新機能の導線であればリリースしてみてのニーズの検証や他機能へのユースケースの変化などを把握する目的で使うことを想定しています。
対象機能導線のタップ数/UU
特定機能導線のタップ数/UUの変化をリリース前後で比較するためのグラフです。
- Web: 月次比較
- iOS/Android: バージョン別比較
主に特定機能の改善施策を行った際に、期待する数値の変化があらわれたかを検証する目的で使うことを想定しています。
この先の話
ここまで仕組み作りについて紹介してきましたが、個人的には実際にこの仕組みを使ってグロースに繋がる事例を出すところまでやらなければと感じています。そのためにこれから行っていきたいことを書いてこの記事を締めくくろうと思います。
効果的な仮説検証へ
対象機能や施策の内容によって期待する数値は変わってくると思いますので、その都度仮説を定義することが大切だと思っています。
仮説がないとリリース後に単純にタップ・クリック数をみても何が成功か失敗の判断ができないからです。
機能開発の実装に入る前などのタイミングでログの数値など仮説をチームで認識を合わせておく、といったような試行錯誤を繰り返していき、効果的な仮説検証のサイクルを回していけたらと思っています。
施策リリース前段階でのニーズ検証
この記事では、施策リリース後の効果検証を紹介してきましたが、一方で施策リリース前の仮説検証も非常に重要だと思っています。（使ってもらえないものを工数かけて開発するのは辛いので、、）
よくある定性調査にユーザーインタビューなどがあると思いますが、一方で定量調査できる仕組みがあるととても重宝するなと思っています。今回作ったログの仕組みもうまく施策実施前の仮説検証に使っていけたらと思っています。
さいごに
以上のように、ログの仕組みは作ったもののまだ入り口に立った段階で、これからまだまだやることがあるという状態です。
アンドパッドでは、実装以外にもUXを向上させるための分析など、様々な取り組みをエンジニアの発信から進められる環境です。
エンジニア向けのオンラインイベントやカジュアル面談なども積極的に開催・募集中ですので、興味を持った方はぜひご応募ください！
