Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
持続的なサービス提供のための計測と分析
Search
MiyabiGouji
March 24, 2022
Marketing & SEO
0
250
持続的なサービス提供のための計測と分析
MiyabiGouji
March 24, 2022
Tweet
Share
More Decks by MiyabiGouji
See All by MiyabiGouji
Analytics-Backed App Widget Development - Served with Jetpack Glance
miyabigouji
0
820
Push通知許諾率向上へのアプローチ
miyabigouji
1
3.6k
Suitable Notification Channel for each users
miyabigouji
0
570
Other Decks in Marketing & SEO
See All in Marketing & SEO
どの種は何の花を咲かす?DevRelのターゲットオーディエンスを知ることの意味
taijihagino
PRO
2
190
How to Overcome SEO Challenges in Website Migrations - Brighton SEO 2024
nikkihalliwell
1
570
How to validate your site speed optimization efforts
aymenloukil
0
320
Salford SEO - From Audit to Action: Maximising Results from Technical SEO
nikkihalliwell
0
180
Your biggest SEO threat is not AI Overviews (or other Google updates) - Eduard Blacquière - SEO Benelux Conference 2024
edwords
2
250
Build RELEVANT content by researching your audience on all organic channels
raysaddiq
0
180
Turing Fest 2023: The Rise of AI
peakace
PRO
0
420
MIXI における技術広報とその役割
mixi_engineers
PRO
2
190
Building effective SEO roadmaps #brightonSEO
lucialecesne
0
130
RでPSM分析
bob3bob3
0
170
Advancing your SEO Career - 15 Tips from my own SEO Journey #WTSFest
aleyda
6
1.4k
¿Por qué pensar en SEO?: Creando el once ideal en una redacción
clarasoteras
0
180
Featured
See All Featured
CSS Pre-Processors: Stylus, Less & Sass
bermonpainter
355
29k
10 Git Anti Patterns You Should be Aware of
lemiorhan
654
59k
Why Our Code Smells
bkeepers
PRO
334
57k
How GitHub (no longer) Works
holman
311
140k
The Myth of the Modular Monolith - Day 2 Keynote - Rails World 2024
eileencodes
14
1.9k
Rebuilding a faster, lazier Slack
samanthasiow
79
8.6k
Building an army of robots
kneath
302
42k
Agile that works and the tools we love
rasmusluckow
327
21k
Java REST API Framework Comparison - PWX 2021
mraible
PRO
28
7.9k
[Rails World 2023 - Day 1 Closing Keynote] - The Magic of Rails
eileencodes
32
1.8k
Visualization
eitanlees
144
15k
RailsConf 2023
tenderlove
29
880
Transcript
持続的なサービス提供のための計測と分析 DroidKaigi 2021, 2021/10/21 11:20~
自己紹介 名前: Miyabi Gouji 所属: 日本経済新聞社 - 2020年からAndroid開発 - アプリ利用ユーザーの分析
名前: Ryo Yamazaki 所属: 日本経済新聞社 - 2016年からAndroid開発 2
はじめに 弊社には計測データ基盤の整備を行うチームは存在しますが、効果検証や計 測・分析を包括的に管理するチームが存在しません。 本セッションでは開発チームがどのように効果検証をして意思決定をしている のかを共有していきます。 参考: https://hack.nikkei.com/blog/atlas_opensource_project/ 3
本セッションの目的 • 本セッションを聞いて欲しい人 ◦ サービスの施策検討者 ◦ データドリブンな開発をされたい方 • 話すこと ◦
開発者が効果検証を行うプロセス • 話さないこと ◦ データを収集ツールや分析、実装の手法 ◦ KPIツリー・財務シミュレーション 4
開発中の課題 • 目的がはっきりしない施策が降ってくる • 既にリリースされている機能を消す判断材料がない • 出してみたが適切に評価されず一度も改善されていない機能がある その施策は本当に効果がありますか? 5
効果検証とはなにか • ある施策を実施した際に実際に目的の指標に対して施策の効果があった のかを検証する一連の評価サイクル ◦ 検証の計画を立てる ◦ 検証をする ◦ 評価する
◦ 改善する 6
なぜ効果検証をするのか • 施策のビジネス的な価値を正しく評価して意思決定するため ◦ 施策が何のために行われているのかを明確にするため ◦ ユーザー体験を損なわないため • 継続的な改善をするため •
機能を消すという強い判断を可能にするため ◦ 画面の奪い合い ◦ 機能過多 7
計画の重要性 実装前に検証計画に必要な項目を全て洗い出す 1. 意思決定のための指標を結果によって変えないため 2. すでに取られている計測値を確認して実装コストを下げるため 3. リリース後に計測値の欠損に気づくようなミスを防ぐため 4. 上手くいかなかった場合にどの指標を見て次にどのような改善・行動がで
きるか列挙することですぐに次の改善を実行するため 8
検証計画を誰でも書けるようにする • 検証計画を誰が立てるか ◦ 実際に仮説を立てて施策を立案したチームが分析の計画までたてて 検証を持ってくる方が解像度の高い計画が立てられる ◦ 検証計画のフォーマットを全てのチームで同じように記述できるように すると記述や管理のコストが下がる •
どうやって始めるか ◦ 弊社と同じように分析・検証を管理するチームがない状況ではまず開 発者から始めていき徐々に周知していく方法がある 9
実際に行った事例を通して 効果検証の流れを説明していきます 10
検証計画 1. 施策の経緯 2. 何をどう変えるか 3. どのユーザーに対して 4. どの指標を良くしたいか 11
検証計画 5. ネガティブチェックが必要か・どの指標を見るべきか 6. 目標値と指標の優先度 7. 必要な計測値は何か・取得可能であるか 12
検証計画 8. どう検証するか 9. うまくいかない場合にどのような理由が考えられるか 10. 9の分析のために必要な数値は何か 13
前提 タップ スワイプ 14
施策の経緯 15 • ビジネス課題: 定期購入の継続率を上げる • 訪問回数・記事閲覧本数を指標とする • 記事閲覧本数を改善する施策を立案した 発表資料:
メディアにおける顧客体験とエンゲージメントの最適化 https://www.domo.com/assets/downloads/jp-city-tours/B-3_Bre akout_The%20Nikkei.pdf
施策の経緯 一部の記事ではネイティブビューで表現 せずにChrome Custom Tabsに遷移 して表示を行います 本記事への表示時には、必ず遷移の確 認を行うダイアログが表示されスムーズ な記事閲覧を妨げているように感じられ ました
16
何をどう変えるか ダイアログを表示しない 変更前 変更後 17
施策の経緯 1. ダイアログが表示されなくなることにより、スワイプ時に体験がブロックさ れなくなる 2. その結果としてよりアプリの閲覧体験が向上するはず!!!! a. アプリ滞在時間は減っているか? b. スワイプ経由でなく、記事一覧から閲覧する方が多いか?
18
どのユーザーに対して Android 日経電子版の全ての有料会員 19
指標とネガティブチェック 指標 • アプリ内での一人当たりの記事閲覧本数を0.3本あげる • アプリ内の総記事PVを1%向上させる ネガティブチェック • Chrome Custom
Tabsに遷移させる記事への遷移数と遷移率 20
どう検証するか 検証方法: 2パターンのABテスト(Firebase Remote Config) 対象ユーザー: Androidで対象バージョンの日経電子版を利用している全て の有料会員に対して均等に50%ずつ振り分けた 例: ユーザー(ランダム
%) <= 50% 期間: 2週間 21
必要な計測値は何か・取得可能であるか 計測値 収集可能性 アプリの実装状態 記事PV ◦ ◦ ダイアログのボタンtap ◦ ✕
=> 実装が必要 遷移先PV △ ◦ ... ... ... 22
計測管理シート: 通称魔法のスプレッドシート • 計測はスプレッドシートで一元管理しています • もっと良い方法を教えてください 23
データを収集する方法を決める • Firebase A/B Testing • Google Analytics • 自社計測基盤
欲しいデータを計測・集計できればツールはなんでもOK 24
ダッシュボードとツール Redash / Kibanaを用いて見たい値をそれぞれ可視化しておきます。 弊社では継続的に追っていく値はRedash(BigQuery)、リアルタイムで計測が 送られているかのチェックにKibana(Elasticsearch)を利用しています。 25
実験が開始されたらチェックする項目 1. データが正しく飛んでいるのか 2. 割り振られた人数 3. ユーザーが本当にランダムに割り振られているのか a. エンゲージメントの割合 4.
記事閲覧本数の分布 26
記事閲覧本数(Redash) 27
記事総PV(Redash) 28
遷移率(Redash) 29
遷移数(Redash) 30
検証結果と次のアクション • 検証結果 ◦ 記事消費本数は0.16本増加 (p値: 3.71*e-10) ◦ 記事PVは0.1%増加(p値: 9.2*e-18)
◦ 該当記事への遷移率が著しく減ってしまった • アクション ◦ 記事内のリンクを目立たせて再検証する 31
何をどう変えるか 前回(ダイアログを非表示) 改善案 32
(再掲) 指標とネガティブチェック 指標 • アプリ内での一人当たりの記事閲覧本数を0.3本あげる • アプリ内の総記事PVを1%向上させる ネガティブチェック • Chrome
Custom Tabsに遷移させる記事への遷移数と遷移率 33
どう検証するか 検証方法: 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
必要な計測値は何か・取得可能であるか 計測値 収集可能性 アプリの実装状態 記事PV ◦ ◦ 記事内のボタンtap ◦ ✕
=> 実装が必要 遷移先のPV ✕ ◦ ... ... ... 35
パターン コントロール群: 赤 介入群: 青 介入群: 緑 36
記事閲覧本数(Redash) 37
記事総PV(Redash) 38
遷移率(Redash) 39
遷移数(Redash) 40
結果 • 一人当たりの記事閲覧本数は「ダイアログなし・前文あり」が一番高く、 0.29本増加 (p値: 1.92*e-16) • PVも3%増加 (p-value: ほぼ0)
• ネガティブチェックとして懸念していた遷移率・遷移数の減少を抑えること ができ、PVの増加に対して無視して良い数値になったといえそう 41
• 計画時に意思決定するための指標をチームで合意する ◦ 必要な計測値・クエリを記述しておく ◦ 実験開始後には実際の結果を検証するだけ ◦ 指標を定める過程を通じて次のアクションも検討できる まとめと実際 42
中長期的にデータを見るための取り組み • チームの定例でアプリの重要指標の昨対比や細分化したダッシュボード を分析する当番を回す • 定期的にチームでダッシュボードを見て雑談 ◦ 過去に行った施策の経過 ◦ PUSH通知の見出し・画像と開封率
◦ 課金継続率 43
44
セッションの振り返り 1. 効果検証とは何か 2. 検証計画の重要性 3. 検証計画をどうたてるのか 4. データに基づいて意思決定し、改善のサイクルを回す方法 45
おわりに 本セッションでお話した効果検証のサイクル自体も改善していく必要があると 思っています。うちはこんな効果検証をしているよ!!!というご意見・ご感想 お待ちしております! 今後も効果検証を行い継続的なアプリの改善に努めていきます。 ▪参考文献 安井翔太(2020)『効果検証入門』技術評論社 46
付録:検証計画 1. 施策の経緯 2. 何をどう変えるか 3. どのユーザーに対して 4. どの指標を良くしたいか 47
付録:検証計画 5. ネガティブチェックが必要か・どの指標を見るべきか 6. 目標値と指標の優先度 7. 必要な計測値は何か・取得可能であるか 48
付録:検証計画 8. どう検証するか 9. うまくいかない場合にどのような理由が考えられるか 10. 9の分析のために必要な数値は何か 49