プッシュ通知は実行性のあるリテンション対策です。ユーザーにプッシュ通知をオプトインしてもらうために、アプリ開発者はフローを最適化し、あらゆる適切な手段を慎重に取っていることでしょう。
しかし、ユーザーがオプトインしたあとも、私たちアプリ開発者はこの神聖なプッシュ通知というチャネルを使ってユーザーに対し適切なアプローチができているのでしょうか?そうは思えません。実際、私たちはプッシュ通知というチャネルを乱用し、乱用が引き起こした結果を認識していないだけなのかも知れません。現在、私はこんなパターンを目にすることが極めて多いのです。
- ウェブアプリを開発する
- メールを送る
- iOSアプリを開発する
- メールを全員に送っているのと同様に、全員にプッシュ通知を送信する
大抵の場合、このパターンは全く受け入れられません。ユーザーを圧倒し、サービスから去っていくこともあります。例えば、これはPinterestのプッシュ通知設定画面です。
こちらはPinterestのメール設定画面です。
本来、メールとプッシュ通知は根本的に異なります。詳しく説明しましょう。今日では全メールうちの50%から65%がモバイル端末で開封されていますが、メールは未だに非同期型形式のコミュニケーションです。なので、メールは無視されることがあります。一方でプッシュ通知はメールよりも侵略的でスマホで無視することはできません(本来なら皆がFred Wilsonのアドバイスに従い、スマートフォン中毒を控えるべきなのでしょうが。) プッシュ通知には、たいていの一斉メールのフッターにあるような「全て購読停止する」といったオプションがありません。実際、ユーザーがアプリを削除してしまう方が、アプリ内の設定ページを見つけてプッシュ通知を無効にする(または、OSの設定からあなたのアプリへの通知全体を無効にする)ことより簡単なのです。確かにプッシュ通知を多数送信することで、一定数のユーザーの定着が増えているように見えるかもしれません。しかし過剰な量のプッシュ通知を送信していても、多くのユーザーを失うことはないと証明できますか?
あなたが計測していないチャーン(離脱率)こそが、プッシュ通知に関してもっとも重要な指標です。
プッシュ通知を始める前に、適切なものを全てを計測でき、トラッキングできるよう、正しくアプリを実装することが重要です。
1.まず、リピート利用の行動をトラッキングしましょう。Intercomには、リテンションの計測に関する優れた記事があります(Google Analyticsでは、コホート分析機能もテストしているようです。)
2. ユーザーのプッシュトークンが作成された時、ログをとりましょう。
3. プッシュトークンが有効でなくなった時もログをとりましょう。(「ソフト」に削除していることを確かめましょう。詳細はStackoverflowにあります。) ((有効でなくなるタイミングはOSアップデートや端末設定のリセットなどの要因によって一度に起こる場合があります))
4. 各プッシュ通知の貢献度を測りましょう。ユーザーがどのプッシュ通知をスワイプしたか判断するためにプッシュ通知にパラメータを付与しましょう。(これは他のすべての投稿でもそうしましょう。)少なくとも、以下のようなデバイストークンテーブルを持つべきです。
【デバイストークンテーブルの例】
- token
- user_id
- created_at
- deleted_at
さて、上記で実装したトラッキングの手順2と3がここで役立ちます。プッシュトークンのコホートが「チャーンする」時を知らせるクエリーを書くべきです。
【表: プッシュトークンの減少】
ユーザーがアプリを削除、もしくはプッシュ通知を無効にした場合、プッシュトークンはおそらく無効になっているでしょう。どちらにせよ、そのユーザーにはもうプッシュ通知を送信できません。リテンションは一般的に、私たちが最も注目する指標で、コップに半分入っている水のように受け手によって解釈が異なる指標 ((the glass half full metric:コップに水が半分 "も" 入っているか、半分 "しか"入っていないと受け取るかは見た人の解釈によるのと同じように、リテンションも見た人によって解釈が異なる指標だということ )) ですが、そうだとしても送信しているプッシュ通知がユーザーが離脱する原因になっているかどうかを確認することは重要です。表の例では、1日目経過でトークン10個が有効でなくなりました。3日目には全部でトークン20個が有効でなくなりました。つまり、サインアップしてプッシュ通知をオプトインしたユーザーの20%にリーチできなくなってしまったのです。それがリテンションにどう影響すると思いますか?
おせっかいなアドバイス
1. 「取引に関する」プッシュ通知のみにする
確かに、Gilt(ショッピングアプリ)は朝9時にプッシュ通知します。Lumosity(脳トレゲームアプリ)も朝9時に通知します。でも、ユーザーがあなたのアプリのプッシュ通知の受信に同意したからといって、単純なプッシュ通知を送ってよいということにはなりません。例えば、たいていのコマースサイトの運営会社は、大量の売り込みメール(例:「本日のセール」)や、取引に関するメール(例:「あなたの品物が発送されました」)を送信します。ユーザーがオプトインしてしまえば、取引に関するメールと全く同じものだけをユーザーに自動的に送ることはできるでしょう。しかし、毎日の売り込みプッシュ通知をオプトインするよう促すか、ユーザーが売り込みプッシュ通知を自主的に選択させるようにしてください。
2. ボリュームを調節する
ユーザーが大量のプッシュ通知をオプトインした場合、ゆっくり始めましょう。初日から大量に通知してはいけません。一番大事なことですが、ユーザーがしばらくしてもプッシュ通知をスワイプしていないと分かれば、ボリュームを抑えるか、一切止めてしまうことも検討してください。
3.プッシュ通知のA/Bテストをする
プッシュ通知のタイミングや内容をテストできるようにすべきです。大規模展開する前に、ユーザーに何が有効か、テストしましょう。
4.まずハイハイ、それから歩き、それから走る(赤ちゃんがハイハイから始めてそれから歩くようになり、それから走ることができるようになるのと同様、まず基本から始めましょう、という意味)
これは3のアドバイスに反するように聞こえるかもしれませんが、あなたがいろいろ試そうとしている小規模スタートアップなのであれば、世界水準にまで徹底的にパーソナライズされたプッシュ通知を作ろうとしてはいけません。ここにたどり着くまでユーザーはとても複雑なファネルを通過してきたことを忘れないでください。ユーザーは、あなたのアプリを見つけ、AppStoreで「入手」をタップし、パスワードかタッチIDをタイプし、インストールし、起動し、サインアップして、オプトインして、プッシュ通知で見たものを気に入ったのです。ユーザーのエンゲージメントを保ちましょう。しかし極端なことをする必要はないのです。基本的なものから始め、あなたがプッシュしてきた内容がもう十分ではないと決めつける前に、始めたことをどう最適化するか理解しましょう。このことが疑わしいと思ったら、このポール・グレアムの記事を読んでください。「スケールしないことをしよう」
この記事は、Medium上の記事” The Most Important Push Notification Metric を著者の了解を得て日本語に抄訳し掲載するものです。 Repro published the Japanese translation of this original article on Medium in English under the permission from the author.