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
Push通知許諾率向上へのアプローチ
Search
MiyabiGouji
September 14, 2023
Programming
1
3.5k
Push通知許諾率向上へのアプローチ
MiyabiGouji
September 14, 2023
Tweet
Share
More Decks by MiyabiGouji
See All by MiyabiGouji
Analytics-Backed App Widget Development - Served with Jetpack Glance
miyabigouji
0
740
Suitable Notification Channel for each users
miyabigouji
0
560
持続的なサービス提供のための計測と分析
miyabigouji
0
250
Other Decks in Programming
See All in Programming
Memory API: Patterns, Use Cases, and Performance
josepaumard
1
150
Re:PandasAI:生成AIがデータ分析業務にもたらすパラダイムシフト【増補改訂版】
negi111111
1
900
CSC509 Lecture 02
javiergs
PRO
0
160
RemixとCloudflare Stack におけるFile Upload
ossamoon
1
130
モジュラモノリス、その前に / Modular monolith, before that
euglena1215
6
680
Vue :: Better Testing 2024
up1
1
400
文化が生産性を作る
jimpei
3
560
ECS向けのドリフト検知機構を実装してみた
tkikuc
0
280
Cloud Adoption Framework にみる組織とクラウド導入戦略
tomokusaba
2
450
Taking LLMs out of the black box: A practical guide to human-in-the-loop distillation
inesmontani
PRO
3
1.2k
게임 개발하던 학생이이 세계에선 안드로이드 개발자?
pangmoo
0
100
推しの夫に恋のGPS「ときメーター」#M5Stack #IoT #M5JPTour2024
riyu
0
230
Featured
See All Featured
In The Pink: A Labor of Love
frogandcode
139
22k
Teambox: Starting and Learning
jrom
131
8.7k
Evolution of real-time – Irina Nazarova, EuRuKo, 2024
irinanazarova
3
230
How GitHub (no longer) Works
holman
311
140k
The Cult of Friendly URLs
andyhume
77
6k
Agile that works and the tools we love
rasmusluckow
327
21k
Practical Orchestrator
shlominoach
186
10k
Embracing the Ebb and Flow
colly
84
4.4k
RailsConf 2023
tenderlove
28
840
The MySQL Ecosystem @ GitHub 2015
samlambert
250
12k
[Rails World 2023 - Day 1 Closing Keynote] - The Magic of Rails
eileencodes
29
1.7k
The Myth of the Modular Monolith - Day 2 Keynote - Rails World 2024
eileencodes
8
520
Transcript
Push通知許諾率向上へのア プローチ 日本経済新聞社 郷治 雅 1
自己紹介 Miyabi Gouji • 日本経済新聞社 ◦ 2020年からAndroidアプリ開発 ◦ アプリ利用ユーザーの分析 ◦
アプリ開発案件企画 2
We are Hiring :) https://hack.nikkei.com/jobs/android/ 3
本セッションの目的 • 本セッションを聞いて欲しい人 ◦ 通知許諾率をあげたいと思っている人 ◦ 通知関連の施策を実施したい人 • 話すこと ◦
通知許諾率に関する知見 ◦ 施策の進め方 • 話さないこと ◦ 詳しい実装 4
はじめに Push通知はアプリの外でユーザーとコミュニケーションができる重要な機能で す。弊社のようなニュース配信アプリでは重要度の高いニュースをより多くの ユーザーにリアルタイムに周知するために通知は欠かせない機能です。 しかし、ユーザーに通知を受け取ってもらうハードルは年々高くなっています通 知はアプリの外でユーザーとコミュニケーションができる重要な機能です。しかし、ユーザーに通知を受け 取ってもらうハードルは年々高くなっています 5
通知許諾率向上へのアプローチ • OFFにされないための工夫 ◦ 最低限のOFFに留めてもらう • ONにしてもらうための工夫 ◦ OFFにするとONにするきっかけはほぼない ◦
ONにしてもらうためのコミュニケーションをする 両方やっていく必要がある 6
ここから話すこと • 通知をOFFにされないための工夫 ◦ OFFにされてしまう要因 ◦ 解決策 • 通知をONにしてもらうための工夫 ◦
実際の施策紹介 7
ここから話すこと • 通知をOFFにされないための工夫 ◦ OFFにされてしまう要因 ◦ 解決策 • 通知をONにしてもらうための工夫 ◦
実際の施策紹介 8
OFFにされてしまう要因 全ての通知を切られてしまう原因 • Android13から許諾がデフォルトOFFに • 通知の本数が多すぎる・コンテンツが合わず煩わしいと感じる ◦ チャンネルが分かれていないので全ての通知を切ってしまう ◦ 通知にどの許諾が当てはまるのかがわかりづらい
9
Android13からの通知許諾 • 13未満: デフォルトでON • 13以降: デフォルトでOFF ◦ 通知の権限を取得する必要がある •
OSアップデートで許諾の設定は引き継がれる ◦ 12以下で明示的に「無効」としていなけれ ば一時的に通知権限が付与される 10
ダイアログでの許諾率 • 2週間で集計 • 初回の画面でキャンセルすると再度ホーム画面でも許諾を聞く仕様 View(回) View(人) 許諾率(%) 非許諾率(%) キャンセル率(%)
9,550 8,152 51.48 34.51 18.38 11
通知許諾率の変化 • OS「全ての通知」 • 2週間で集計 • 端末のOSを12以下からアップデートしたユーザーは許諾が一時的に引き継がれる 全ての通知許諾率(%) 速報通知許諾率(%) Android12以下
79.1 74.1% Android13以上 69.16 65.46 12
Android13以上利用ユーザーの割合 • アプリ全体のアクティブユーザー におけるAndroid12以下/13以上 の割合 ◦ 13以上が半数近くまで伸びて きている ◦ 段々と許諾率が落ちていくの
は自明 UU(%) Android12以下 57.4% Android13以上 42.6% 13
通知の本数と許諾OFFの関係 • 通知の本数と許諾の切られやすさの関係はすでにわかっていて切られや すい本数も統計的に把握している • 全てのチャンネルを許可している場合、通知が数本増えたら切られる可能 性が高まる 14
実際の通知の数と許諾オプトアウト数 実際の通知の数 許諾オプトアウト数 15
通知の本数を減らす必要はあるか • ニュースアプリにとって「速報」通知は重要コンテンツ ◦ 1日に複数件の重大ニュースがある時に通知の数が増えるのは仕方 ない • 朝刊・おすすめ記事など定時の通知もうまく届けたい 送る本数を減らすのは簡単ではない •
本数を減らせたとしてもミスマッチは起こりうる 16
朝刊の通知を届かな いようにしたい 日経電子版 一般的な通知 日経電子版 17
どちらを切っても全ての通 知が届かなくなる アプリ内に設定が別れている パターンも多い 18
チャンネルの最適化 日経電子版 日経電子版 19
通知チャンネル • Andriod8(Oreo)から導入された通知を細かく管理する機能 • ユーザーが個別の通知を受け取るかどうか、どのように受け取るかを詳 細に設定できる 2022年DroidKaigiの発表: 通知チャンネルに対応する 20
チャンネル毎の重要度 • 速報通知・災害速報: IMPORTANCE_HIGH ◦ アプリ使用中にポップアップが表示される • 注目記事・朝刊・その他の記事: IMPORTANCE_DEFAULT ◦
ポップアップなしで通知ドロワーに表示される ◦ 通知音あり 21
許諾率の変化 • 全体の許諾率は下がっている(P12で記載済み) 22
許諾オプトアウト数の変化 • 2022年9月にチャンネル対応 • 通知オプトアウト数は段々と減ってきている 23
開封率の変化 (朝刊) • 重要度を下げたことで開封率は顕著に低下がみられる • 2021年から2022年で大きな差がなくチャンネル対応をした2022年9月ご ろから下がっている 24
開封率の変化 (速報通知) • 重要度維持した速報通知の開封率は向上している • 相対的に目立つようになった 25
チャンネル最適化まとめ • 通知のチャンネルを分ける ◦ 「全ての通知」が切られづらくなった • 通知の重要度の調整 ◦ (良い) 重要度の高い通知の開封率が上がった
◦ (悪い) 重要度を下げた通知の開封率が下がった 26
重要度が下がった通知を押してもらう工夫 • 通知ドロワー内での表示の最適化 ◦ グループ化 ◦ 通知タイトルの工夫 • 画像を入れ替えてみる ◦
朝刊通知には画像を入れているが自動で1面トップの画像を取って いるので工夫の余地がある 27
OFFにされないための取り組みまとめ • チャンネル最適化 • 通知数 ◦ チャンネルの重要度の調整でも少なく感じさせることは可能 • 通知の表現の工夫 ◦
どのチャンネルの通知かを明確にして届ける ◦ 通知ドロワー内で最適な表示方法を模索する 28
ここからの流れ • 通知をOFFにされないための工夫 ◦ OFFにされてしまう要因 ◦ 解決策 • 通知をONにしてもらうための工夫 ◦
実際の施策紹介 29
施策未実施時 許諾をONにしてくれるユーザー数(全ての通知) • OFFにするユーザー数はONにするユーザー数の3倍程度 30
通知許諾をONにしてもらうタイミング • Android12以下 ◦ アプリインストール時(デフォルトON) ◦ 任意のタイミング ▪ ONにしてもらうようなサジェスト・誘導 31
通知許諾をONにしてもらうタイミング • Android13以上 ◦ アプリ初回起動時(権限ダイアログ) ▪ 初回でなくても良い ◦ 権限ダイアログの再表示 ◦
任意のタイミング ▪ ONにしてもらうようなサジェスト・誘導 32
① 初回起動時(Android13以上) • 現状、既存のウェルカム画面上にダイアログが出 る • 初回の通知許諾が50%程度になっており改善の 余地あり 通知許諾をONにするメリットを伝えるような画面で訴求 する案を実装中
33
過去の施策紹介 • iOS日経電子版で2018年に初回起動時の許諾について施策を行ってい るがダイアログを出すだけの時よりも許諾率が下がってしまった ◦ 離脱ポイントを作ってしまったこと ◦ 通知のメリットを伝えきれなかった というような反省点が上がっていた 34
④ ② ① ③ 35
許諾を保留にし ている場合 36
②権限ダイアログの再表示 • ビジネス的にアプリインストール直後・課金直後の利用率が課金継続に寄 与 ◦ 課金後7日以内など 不安要素 • 許諾を自分でOFFにしているので煩わしいと感じる可能性も高い •
2回「許可しない」を押されてしまうと後がなくなる 37
ONにしてもらえそうな任意のタイミング • ONにしてもらいやすそうなタイミングにOSの通知設定に誘導 ◦ ユーザーの行動分析から許可してくれそうなタイミングにダイアログ や画面などを出す ◦ 選挙のようにONにしておくと良いかも、と思わせるタイミングで誘導 施策を立案・実施 38
施策を進めるにあたって 2021年の発表: 持続的なサービス提供のための計測と分析 • 事前準備で大事なこと: ◦ 正しく効果検証できるように仮説を構築しKPIを決める ◦ 継続的に改善できるようにすること ◦
結果を受けてどうするか、という合意を先に取る 39
課題感とアプローチ • 通知をONにしてほしいが現状ONにするきっかけがない ◦ 通知許諾画面に遷移するUIにて訴求 • 全てのユーザーに対して通知許諾を促すのは過剰 ◦ ONにしてくれるユーザーの行動を分析してより確率を高める 40
ONにしてくれる人の行動分析① • 通知許諾をONにしてくれる人の前後の行動を集計 ◦ 前後の行動を見るとほとんどが無意味なON ▪ 元々許諾ONの状態で通知許諾画面にて OFF => ONを繰り返
している ◦ 「速報通知」画面を閲覧後に通知許諾をONにしているユーザーが一 定数いた 41
速報通知画面 過去に速報チャンネルに送られた記事の一覧 • 通知をONにしてくれるポテンシャルが高そう • この画面で通知の許諾案内が出ることに対して納 得感がありそう 42
どのチャンネルの許諾をONにしてもらうか • 行動分析から ◦ 速報通知一覧からの誘導なので「速報」の許諾をONにしてもらうの が納得できそう ◦ 全ての通知+速報通知をONにしてもらう • 通知開封率の高さから
◦ 速報通知の平均的な開封率が30%と他の通知より圧倒的に高い 43
どの画面を対象にするか • 速報通知に来てる人: 4376人 • そのうち全体許諾がOFFの人: 740人 • 全ての通知がONで速報がOFFの人: 293人
対象者が少ない 対象画面を増やして対象ユーザーを増やす できるだけ納得感が出るように「速報セクション」に出す 44
仮説 速報通知がOFFになっているユーザーが ◦ 「速報通知」を閲覧した時 ◦ 「速報セクション」をスクロールした時 通知をONにするサジェストをすることで速報通知の許諾をONにしてくれる 45
事業貢献度① • アプリのアクティブ率は課金継続率に効果的な数値の一つ • 速報通知の開封率は20-30%程度 ◦ 5本に1本は開封してもらえる ◦ 起動する回数が増えて一定数の解約防止に寄与する可能性 46
目標値 • KPI: 速報通知の許諾をONにする課金ユーザー数 • KPIの目標値 ◦ ダイアログを見た課金ユーザーの5%程度 47
ABテスト • ダイアログがない場合と比較することで真の効果を知りたい • ダイアログありに多めにユーザーを割り振ってクリエイティブのテストをし て良い方を残したい ダイアログなし vs ダイアログA vs
ダイアログB • 全ユーザーを対象 • 期間は1ヶ月 48
仕様の決定①デザイン 必須要素 • 訴求メッセージ • 設定方法の動画 • なぜこのタイミングで表示されたのかの説明 文言は短めを意識 許諾の状態に応じ
て動画を変える 49
仕様の決定②UX • アプリ内の通知設定画面に遷移 ◦ 初めてアプリ内から通知を設定するユーザーも次 回以降アプリ内から設定できるように 50
仕様の決定②UX • どちらかの画面で一度ダイアログを出たら次からは出さない • 通知を許可せずに画面に戻った時にのみダイアログを 消さずに設定方法の動画を複数回みられるように ◦ OSの通知許諾を複数回操作するとアプリのプロセスが終了するので 戻ってきた時にもダイアログの表示ができるようにしておく 51
仕様の決定③リソースの配置 • 文言・動画などを差し替えて繰り返し ABテストをしてブラッシュアップしていく ために文言や動画URLはFirebase Remote Configから受け取る • 1度しか出さない動画なのでアプリ内に 持たせない判断
52
ダッシュボード設計 • KPI (全ての通知の許諾率) • ABテストの確認項目 ◦ 割り振り人数/エンゲージメント ◦ どの画面でダイアログが表示された
か ◦ どの画面のダイアログから設定され やすいか ◦ etc… 53
実装 • DialogFragmentにComposeViewを配置 • VideoViewを使ってミニマムに実装 54
仕様の決定④計測 • 最終的な集計を意識して計測値を決定 ◦ ダイアログのview/confirm/cancel ◦ 通知許諾のON/OFFイベント ◦ ABテストのパターン ◦
開封率・PVなど収益に貢献する数値 55
ダイアログA ダイアログB 56
結果 目標: ダイアログを見た課金ユーザーの 5%に通知許諾をONにしてもらう 結果: 割合(%) ダイアログA 6.57 ダイアログB 5.94
57
許諾のON数/率 • ダイアログを見た人の許諾ON数はダイアログなしに比べて2倍程度に増加 • ダイアログを見た人のうち5%以上が許諾をONに ダイアログView ONにした人数 割合(%) ※正規化した割合 ダイアログA
4,369 287 6.57 3.6% ダイアログB 4,375 260 5.94 3.0% 58
速報通知の許諾ON数 • 個別の許諾をONにしてくれる人は少ないが効果があった 全ての通知 速報通知 ダイアログA 251 56 ダイアログB 220
59 59
画面ごとの成績 • 速報通知画面にくる人自体は少ないが通知に関心がある人が多い • 速報セクションにも出すことである程度人数を増やせた ダイアログview 設定するボタン押下 割合 速報通知画面 200
48 24% 速報セクション 9048 341 3.7% 60
施策のまとめ • 通知をONにする機会を提供できた • ユーザー行動を根拠にダイアログを出す画面を絞ることでユーザーにとっ て過剰なコミュニケーションになることを避けられた • ダイアログは簡潔な情報を見せるのが良さそう • 定期的にユーザーに見せるのも良さそうだが頻度や場所は要検討
61
通知をONにしてもらうための工夫まとめ • 通知許諾をONにしてもらうために ◦ 初回起動時 ◦ 権限ダイアログでの再許諾 ◦ 任意のタイミング ▪
ユーザー行動から ▪ 通知が送られると予測できる時 62
全体のまとめ • 通知許諾はOFFにされてしまう前提でOFFにされない工夫とONにしても らう工夫の両方をやっていく必要がある • 切り方をわかりづらくするのではなく明確に示した上で切られない工夫を する • ONにしてもらうための過剰なコミュニケーションは避けるための事前分析 や予測が大切
63
Appendix 64
• iOS日経電子版での通知許諾改善施策 ◦ ABテストが上手く行かなかった話 65