Push通知許諾率向上へのアプローチ日本経済新聞社 郷治 雅1
View Slide
自己紹介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.3811
通知許諾率の変化● OS「全ての通知」● 2週間で集計● 端末のOSを12以下からアップデートしたユーザーは許諾が一時的に引き継がれる全ての通知許諾率(%) 速報通知許諾率(%)Android12以下 79.1 74.1%Android13以上 69.16 65.4612
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
②権限ダイアログの再表示● ビジネス的にアプリインストール直後・課金直後の利用率が課金継続に寄与○ 課金後７日以内など不安要素● 許諾を自分で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はFirebaseRemote Configから受け取る● 1度しか出さない動画なのでアプリ内に持たせない判断52
ダッシュボード設計● KPI (全ての通知の許諾率)● ABテストの確認項目○ 割り振り人数/エンゲージメント○ どの画面でダイアログが表示されたか○ どの画面のダイアログから設定されやすいか○ etc…53
実装● DialogFragmentにComposeViewを配置● VideoViewを使ってミニマムに実装54
仕様の決定④計測● 最終的な集計を意識して計測値を決定○ ダイアログのview/confirm/cancel○ 通知許諾のON/OFFイベント○ ABテストのパターン○ 開封率・PVなど収益に貢献する数値55
ダイアログA ダイアログB56
結果目標: ダイアログを見た課金ユーザーの5%に通知許諾をONにしてもらう結果:割合(%)ダイアログA 6.57ダイアログB 5.9457
許諾の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 5959
画面ごとの成績● 速報通知画面にくる人自体は少ないが通知に関心がある人が多い● 速報セクションにも出すことである程度人数を増やせたダイアログview 設定するボタン押下 割合速報通知画面 200 48 24%速報セクション 9048 341 3.7%60
施策のまとめ● 通知をONにする機会を提供できた● ユーザー行動を根拠にダイアログを出す画面を絞ることでユーザーにとって過剰なコミュニケーションになることを避けられた● ダイアログは簡潔な情報を見せるのが良さそう● 定期的にユーザーに見せるのも良さそうだが頻度や場所は要検討61
通知をONにしてもらうための工夫まとめ● 通知許諾をONにしてもらうために○ 初回起動時○ 権限ダイアログでの再許諾○ 任意のタイミング■ ユーザー行動から■ 通知が送られると予測できる時62
全体のまとめ● 通知許諾はOFFにされてしまう前提でOFFにされない工夫とONにしてもらう工夫の両方をやっていく必要がある● 切り方をわかりづらくするのではなく明確に示した上で切られない工夫をする● ONにしてもらうための過剰なコミュニケーションは避けるための事前分析や予測が大切63
Appendix64
● iOS日経電子版での通知許諾改善施策○ ABテストが上手く行かなかった話65
miyabigouji
skanehira
miciek
chimame
manfredsteyer
ivanova1991
ivargrimstad
okuramasafumi
palkan
codehex
zakky21
inoichan
akakou
nonsquared
paulrobertlloyd
lemiorhan
revolveconf
lauravandoore
deanohume
mraible
rasmusluckow
tmm1
tanoku
hatefulcrawdad
mojombo