Recommended
More Related Content
What's hot
What's hot (20)
Similar to 持続的なサービス提供のための計測と分析
Similar to 持続的なサービス提供のための計測と分析 (20)
持続的なサービス提供のための計測と分析
- 2. 自己紹介 名前: Miyabi Gouji 所属: 日本経済新聞社 - 2020年からAndroid開発 - アプリ利用ユーザーの分析 名前: Ryo Yamazaki 所属: 日本経済新聞社 - 2016年からAndroid開発 2
- 4. 本セッションの目的 ● 本セッションを聞いて欲しい人 ○ サービスの施策検討者 ○ データドリブンな開発をされたい方 ● 話すこと ○ 開発者が効果検証を行うプロセス ● 話さないこと ○ データを収集ツールや分析、実装の手法 ○ KPIツリー・財務シミュレーション 4
- 5. 開発中の課題 ● 目的がはっきりしない施策が降ってくる ● 既にリリースされている機能を消す判断材料がない ● 出してみたが適切に評価されず一度も改善されていない機能がある その施策は本当に効果がありますか？ 5
- 6. 効果検証とはなにか ● ある施策を実施した際に実際に目的の指標に対して施策の効果があった のかを検証する一連の評価サイクル ○ 検証の計画を立てる ○ 検証をする ○ 評価する ○ 改善する 6
- 7. なぜ効果検証をするのか ● 施策のビジネス的な価値を正しく評価して意思決定するため ○ 施策が何のために行われているのかを明確にするため ○ ユーザー体験を損なわないため ● 継続的な改善をするため ● 機能を消すという強い判断を可能にするため ○ 画面の奪い合い ○ 機能過多 7
- 8. 計画の重要性 実装前に検証計画に必要な項目を全て洗い出す 1. 意思決定のための指標を結果によって変えないため 2. すでに取られている計測値を確認して実装コストを下げるため 3. リリース後に計測値の欠損に気づくようなミスを防ぐため 4. 上手くいかなかった場合にどの指標を見て次にどのような改善・行動がで きるか列挙することですぐに次の改善を実行するため 8
- 9. 検証計画を誰でも書けるようにする ● 検証計画を誰が立てるか ○ 実際に仮説を立てて施策を立案したチームが分析の計画までたてて 検証を持ってくる方が解像度の高い計画が立てられる ○ 検証計画のフォーマットを全てのチームで同じように記述できるように すると記述や管理のコストが下がる ● どうやって始めるか ○ 弊社と同じように分析・検証を管理するチームがない状況ではまず開 発者から始めていき徐々に周知していく方法がある 9
- 11. 検証計画 1. 施策の経緯 2. 何をどう変えるか 3. どのユーザーに対して 4. どの指標を良くしたいか 11
- 12. 検証計画 5. ネガティブチェックが必要か・どの指標を見るべきか 6. 目標値と指標の優先度 7. 必要な計測値は何か・取得可能であるか 12
- 13. 検証計画 8. どう検証するか 9. うまくいかない場合にどのような理由が考えられるか 10. 9の分析のために必要な数値は何か 13
- 14. 前提 タップ スワイプ 14
- 15. 施策の経緯 15 ● ビジネス課題: 定期購入の継続率を上げる ● 訪問回数・記事閲覧本数を指標とする ● 記事閲覧本数を改善する施策を立案した 発表資料: メディアにおける顧客体験とエンゲージメントの最適化 https://www.domo.com/assets/downloads/jp-city-tours/B-3_Bre akout_The%20Nikkei.pdf
- 18. 施策の経緯 1. ダイアログが表示されなくなることにより、スワイプ時に体験がブロックさ れなくなる 2. その結果としてよりアプリの閲覧体験が向上するはず！！！！ a. アプリ滞在時間は減っているか？ b. スワイプ経由でなく、記事一覧から閲覧する方が多いか？ 18
- 20. 指標とネガティブチェック 指標 ● アプリ内での一人当たりの記事閲覧本数を0.3本あげる ● アプリ内の総記事PVを1%向上させる ネガティブチェック ● Chrome Custom Tabsに遷移させる記事への遷移数と遷移率 20
- 21. どう検証するか 検証方法: 2パターンのABテスト(Firebase Remote Config) 対象ユーザー: Androidで対象バージョンの日経電子版を利用している全て の有料会員に対して均等に50%ずつ振り分けた 例: ユーザー(ランダム %) <= 50% 期間: 2週間 21
- 22. 必要な計測値は何か・取得可能であるか 計測値 収集可能性 アプリの実装状態 記事PV ○ ○ ダイアログのボタンtap ○ ✕ => 実装が必要 遷移先PV △ ○ ... ... ... 22
- 23. 計測管理シート: 通称魔法のスプレッドシート ● 計測はスプレッドシートで一元管理しています ● もっと良い方法を教えてください 23
- 24. データを収集する方法を決める ● Firebase A/B Testing ● Google Analytics ● 自社計測基盤 欲しいデータを計測・集計できればツールはなんでもOK 24
- 26. 実験が開始されたらチェックする項目 1. データが正しく飛んでいるのか 2. 割り振られた人数 3. ユーザーが本当にランダムに割り振られているのか a. エンゲージメントの割合 4. 記事閲覧本数の分布 26
- 28. 記事総PV(Redash) 28
- 29. 遷移率(Redash) 29
- 30. 遷移数(Redash) 30
- 31. 検証結果と次のアクション ● 検証結果 ○ 記事消費本数は0.16本増加 (p値: 3.71*e-10) ○ 記事PVは0.1%増加(p値: 9.2*e-18) ○ 該当記事への遷移率が著しく減ってしまった ● アクション ○ 記事内のリンクを目立たせて再検証する 31
- 33. (再掲) 指標とネガティブチェック 指標 ● アプリ内での一人当たりの記事閲覧本数を0.3本あげる ● アプリ内の総記事PVを1%向上させる ネガティブチェック ● Chrome Custom Tabsに遷移させる記事への遷移数と遷移率 33
- 34. どう検証するか 検証方法: 3パターンの中でABテスト 対象ユーザー: Androidで対象バージョンの日経電子版を利用している全て の有料会員に対して33.3%ずつに割り当てる 期間: 2週間 (Remote Configの設定例) button_in_article_with_lead(random_key: test_dialog): ~33.3% => 1 button_in_article(random_key: test_dialog): 33.3~66.6% => 2 デフォルト値 => 0 34
- 35. 必要な計測値は何か・取得可能であるか 計測値 収集可能性 アプリの実装状態 記事PV ○ ○ 記事内のボタンtap ○ ✕ => 実装が必要 遷移先のPV ✕ ○ ... ... ... 35
- 36. パターン コントロール群: 赤 介入群: 青 介入群: 緑 36
- 38. 記事総PV(Redash) 38
- 39. 遷移率(Redash) 39
- 40. 遷移数(Redash) 40
- 41. 結果 ● 一人当たりの記事閲覧本数は「ダイアログなし・前文あり」が一番高く、 0.29本増加 (p値: 1.92*e-16) ● PVも3%増加 (p-value: ほぼ0) ● ネガティブチェックとして懸念していた遷移率・遷移数の減少を抑えること ができ、PVの増加に対して無視して良い数値になったといえそう 41
- 42. ● 計画時に意思決定するための指標をチームで合意する ○ 必要な計測値・クエリを記述しておく ○ 実験開始後には実際の結果を検証するだけ ○ 指標を定める過程を通じて次のアクションも検討できる まとめと実際 42
- 43. 中長期的にデータを見るための取り組み ● チームの定例でアプリの重要指標の昨対比や細分化したダッシュボード を分析する当番を回す ● 定期的にチームでダッシュボードを見て雑談 ○ 過去に行った施策の経過 ○ PUSH通知の見出し・画像と開封率 ○ 課金継続率 43
- 44. 44
- 45. セッションの振り返り 1. 効果検証とは何か 2. 検証計画の重要性 3. 検証計画をどうたてるのか 4. データに基づいて意思決定し、改善のサイクルを回す方法 45
- 47. 付録：検証計画 1. 施策の経緯 2. 何をどう変えるか 3. どのユーザーに対して 4. どの指標を良くしたいか 47
- 48. 付録：検証計画 5. ネガティブチェックが必要か・どの指標を見るべきか 6. 目標値と指標の優先度 7. 必要な計測値は何か・取得可能であるか 48
- 49. 付録：検証計画 8. どう検証するか 9. うまくいかない場合にどのような理由が考えられるか 10. 9の分析のために必要な数値は何か 49