持続的なサービス提供のための計測と分析

Transcript

1. 持続的なサービス提供のための計測と分析
   DroidKaigi 2021, 2021/10/21 11:20~
   

   View Slide

2. 自己紹介
   名前: Miyabi Gouji
   所属: 日本経済新聞社
   - 2020年からAndroid開発
   - アプリ利用ユーザーの分析
   名前: Ryo Yamazaki
   所属: 日本経済新聞社
   - 2016年からAndroid開発
   2
   

   View Slide

3. はじめに
   弊社には計測データ基盤の整備を行うチームは存在しますが、効果検証や計
   測・分析を包括的に管理するチームが存在しません。
   本セッションでは開発チームがどのように効果検証をして意思決定をしている
   のかを共有していきます。
   参考: https://hack.nikkei.com/blog/atlas_opensource_project/
   3
   

   View Slide

4. 本セッションの目的
   ● 本セッションを聞いて欲しい人
   ○ サービスの施策検討者
   ○ データドリブンな開発をされたい方
   ● 話すこと
   ○ 開発者が効果検証を行うプロセス
   ● 話さないこと
   ○ データを収集ツールや分析、実装の手法
   ○ KPIツリー・財務シミュレーション
   4
   

   View Slide

5. 開発中の課題
   ● 目的がはっきりしない施策が降ってくる
   ● 既にリリースされている機能を消す判断材料がない
   ● 出してみたが適切に評価されず一度も改善されていない機能がある
   その施策は本当に効果がありますか？
   5
   

   View Slide

6. 効果検証とはなにか
   ● ある施策を実施した際に実際に目的の指標に対して施策の効果があった
   のかを検証する一連の評価サイクル
   ○ 検証の計画を立てる
   ○ 検証をする
   ○ 評価する
   ○ 改善する
   6
   

   View Slide

7. なぜ効果検証をするのか
   ● 施策のビジネス的な価値を正しく評価して意思決定するため
   ○ 施策が何のために行われているのかを明確にするため
   ○ ユーザー体験を損なわないため
   ● 継続的な改善をするため
   ● 機能を消すという強い判断を可能にするため
   ○ 画面の奪い合い
   ○ 機能過多
   7
   

   View Slide

8. 計画の重要性
   実装前に検証計画に必要な項目を全て洗い出す
   1. 意思決定のための指標を結果によって変えないため
   2. すでに取られている計測値を確認して実装コストを下げるため
   3. リリース後に計測値の欠損に気づくようなミスを防ぐため
   4. 上手くいかなかった場合にどの指標を見て次にどのような改善・行動がで
   きるか列挙することですぐに次の改善を実行するため
   8
   

   View Slide

9. 検証計画を誰でも書けるようにする
   ● 検証計画を誰が立てるか
   ○ 実際に仮説を立てて施策を立案したチームが分析の計画までたてて
   検証を持ってくる方が解像度の高い計画が立てられる
   ○ 検証計画のフォーマットを全てのチームで同じように記述できるように
   すると記述や管理のコストが下がる
   ● どうやって始めるか
   ○ 弊社と同じように分析・検証を管理するチームがない状況ではまず開
   発者から始めていき徐々に周知していく方法がある
   9
   

   View Slide

10. 実際に行った事例を通して
    効果検証の流れを説明していきます
    10
    

    View Slide

11. 検証計画
    1. 施策の経緯
    2. 何をどう変えるか
    3. どのユーザーに対して
    4. どの指標を良くしたいか
    11
    

    View Slide

12. 検証計画
    5. ネガティブチェックが必要か・どの指標を見るべきか
    6. 目標値と指標の優先度
    7. 必要な計測値は何か・取得可能であるか
    12
    

    View Slide

13. 検証計画
    8. どう検証するか
    9. うまくいかない場合にどのような理由が考えられるか
    10. 9の分析のために必要な数値は何か
    13
    

    View Slide

14. 前提
    タップ スワイプ
    14
    

    View Slide

15. 施策の経緯
    15
    ● ビジネス課題: 定期購入の継続率を上げる
    ● 訪問回数・記事閲覧本数を指標とする
    ● 記事閲覧本数を改善する施策を立案した
    発表資料: メディアにおける顧客体験とエンゲージメントの最適化
    https://www.domo.com/assets/downloads/jp-city-tours/B-3_Bre
    akout_The%20Nikkei.pdf
    

    View Slide

16. 施策の経緯
    一部の記事ではネイティブビューで表現
    せずにChrome Custom Tabsに遷移
    して表示を行います
    本記事への表示時には、必ず遷移の確
    認を行うダイアログが表示されスムーズ
    な記事閲覧を妨げているように感じられ
    ました
    16
    

    View Slide

17. 何をどう変えるか
    ダイアログを表示しない
    変更前 変更後
    17
    

    View Slide

18. 施策の経緯
    1. ダイアログが表示されなくなることにより、スワイプ時に体験がブロックさ
    れなくなる
    2. その結果としてよりアプリの閲覧体験が向上するはず！！！！
    a. アプリ滞在時間は減っているか？
    b. スワイプ経由でなく、記事一覧から閲覧する方が多いか？
    18
    

    View Slide

19. どのユーザーに対して
    Android 日経電子版の全ての有料会員
    19
    

    View Slide

20. 指標とネガティブチェック
    指標
    ● アプリ内での一人当たりの記事閲覧本数を0.3本あげる
    ● アプリ内の総記事PVを1%向上させる
    ネガティブチェック
    ● Chrome Custom Tabsに遷移させる記事への遷移数と遷移率
    20
    

    View Slide

21. どう検証するか
    検証方法: 2パターンのABテスト(Firebase Remote Config)
    対象ユーザー: Androidで対象バージョンの日経電子版を利用している全て
    の有料会員に対して均等に50%ずつ振り分けた
    例: ユーザー(ランダム %) <= 50%
    期間: 2週間
    21
    

    View Slide

22. 必要な計測値は何か・取得可能であるか
    計測値 収集可能性 アプリの実装状態
    記事PV ○ ○
    ダイアログのボタンtap ○ ✕ => 実装が必要
    遷移先PV △ ○
    ... ... ...
    22
    

    View Slide

23. 計測管理シート: 通称魔法のスプレッドシート
    ● 計測はスプレッドシートで一元管理しています
    ● もっと良い方法を教えてください
    23
    

    View Slide

24. データを収集する方法を決める
    ● Firebase A/B Testing
    ● Google Analytics
    ● 自社計測基盤
    欲しいデータを計測・集計できればツールはなんでもOK
    24
    

    View Slide

25. ダッシュボードとツール
    Redash / Kibanaを用いて見たい値をそれぞれ可視化しておきます。
    弊社では継続的に追っていく値はRedash(BigQuery)、リアルタイムで計測が
    送られているかのチェックにKibana(Elasticsearch)を利用しています。
    25
    

    View Slide

26. 実験が開始されたらチェックする項目
    1. データが正しく飛んでいるのか
    2. 割り振られた人数
    3. ユーザーが本当にランダムに割り振られているのか
    a. エンゲージメントの割合
    4. 記事閲覧本数の分布
    26
    

    View Slide

27. 記事閲覧本数(Redash)
    27
    

    View Slide

28. 記事総PV(Redash)
    28
    

    View Slide

29. 遷移率(Redash)
    29
    

    View Slide

30. 遷移数(Redash)
    30
    

    View Slide

31. 検証結果と次のアクション
    ● 検証結果
    ○ 記事消費本数は0.16本増加 (p値: 3.71*e-10)
    ○ 記事PVは0.1%増加(p値: 9.2*e-18)
    ○ 該当記事への遷移率が著しく減ってしまった
    ● アクション
    ○ 記事内のリンクを目立たせて再検証する
    31
    

    View Slide

32. 何をどう変えるか
    前回（ダイアログを非表示） 改善案
    32
    

    View Slide

33. (再掲) 指標とネガティブチェック
    指標
    ● アプリ内での一人当たりの記事閲覧本数を0.3本あげる
    ● アプリ内の総記事PVを1%向上させる
    ネガティブチェック
    ● Chrome Custom Tabsに遷移させる記事への遷移数と遷移率
    33
    

    View Slide

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
    

    View Slide

35. 必要な計測値は何か・取得可能であるか
    計測値 収集可能性 アプリの実装状態
    記事PV ○ ○
    記事内のボタンtap ○ ✕ => 実装が必要
    遷移先のPV ✕ ○
    ... ... ...
    35
    

    View Slide

36. パターン
    コントロール群: 赤 介入群: 青
    介入群: 緑
    36
    

    View Slide

37. 記事閲覧本数(Redash)
    37
    

    View Slide

38. 記事総PV(Redash)
    38
    

    View Slide

39. 遷移率(Redash)
    39
    

    View Slide

40. 遷移数(Redash)
    40
    

    View Slide

41. 結果
    ● 一人当たりの記事閲覧本数は「ダイアログなし・前文あり」が一番高く、
    0.29本増加 (p値: 1.92*e-16)
    ● PVも3%増加 (p-value: ほぼ0)
    ● ネガティブチェックとして懸念していた遷移率・遷移数の減少を抑えること
    ができ、PVの増加に対して無視して良い数値になったといえそう
    41
    

    View Slide

42. ● 計画時に意思決定するための指標をチームで合意する
    ○ 必要な計測値・クエリを記述しておく
    ○ 実験開始後には実際の結果を検証するだけ
    ○ 指標を定める過程を通じて次のアクションも検討できる
    まとめと実際
    42
    

    View Slide

43. 中長期的にデータを見るための取り組み
    ● チームの定例でアプリの重要指標の昨対比や細分化したダッシュボード
    を分析する当番を回す
    ● 定期的にチームでダッシュボードを見て雑談
    ○ 過去に行った施策の経過
    ○ PUSH通知の見出し・画像と開封率
    ○ 課金継続率
    43
    

    View Slide

44. View Slide

45. セッションの振り返り
    1. 効果検証とは何か
    2. 検証計画の重要性
    3. 検証計画をどうたてるのか
    4. データに基づいて意思決定し、改善のサイクルを回す方法
    45
    

    View Slide

46. おわりに
    本セッションでお話した効果検証のサイクル自体も改善していく必要があると
    思っています。うちはこんな効果検証をしているよ！！！というご意見・ご感想
    お待ちしております！
    今後も効果検証を行い継続的なアプリの改善に努めていきます。
    ■参考文献
    安井翔太(2020)『効果検証入門』技術評論社
    46
    

    View Slide

47. 付録：検証計画
    1. 施策の経緯
    2. 何をどう変えるか
    3. どのユーザーに対して
    4. どの指標を良くしたいか
    47
    

    View Slide

48. 付録：検証計画
    5. ネガティブチェックが必要か・どの指標を見るべきか
    6. 目標値と指標の優先度
    7. 必要な計測値は何か・取得可能であるか
    48
    

    View Slide

49. 付録：検証計画
    8. どう検証するか
    9. うまくいかない場合にどのような理由が考えられるか
    10. 9の分析のために必要な数値は何か
    49
    

    View Slide