Facebookの事例から考える、Webアプリにおけるプッシュ通知の許可タイミング

  • このエントリーをはてなブックマークに追加
  • Pocket

fbpush

先日この記事でも紹介しましたが、Webアプリ版のFacebook(Android版Chrome向け)においてもプッシュ通知が始まりました。使ってみるとわかるのですが、トップページでなく、ログインした瞬間にプッシュ通知許可画面が表示されるようになっています。

ネイティブアプリだと、起動直後に許可画面が表示されることが多いです。最近だと、プッシュで何を送ってくるか(お知らせやコンテンツの更新、イベント開催など)を見せてから通知許可するケースも出てきていますが、とにかく利用の初期段階で許可を取るのがスタンダードです。
※実はFacebookのネイティブアプリはそうでないので、上記の比較には適していないのですが・・

この違いは、先日の記事でもすこし触れましたが、Webとネイティブアプリの利用する時点におけるユーザーとのエンゲージメントの度合いが違うということが一因だと考えました。

Webとアプリのエンゲージメントの違い

Webサイトの場合、浅い/深い含めて単純な接触数(訪問数)はネイティブアプリより多くとれる傾向があります。これは検索エンジンやソーシャルメディア、広告により、パーマリンク単位で細切れに接触できるからです。その中には深く意図せずアクセスしたようなトラフィックもあります。それに比べるとネイティブアプリは利用開始時点で何を目的にするかが明らかになっており、であれば利用の初期段階でプッシュ通知許可が出てくるのも文脈的に理解しやすいです。

となるとWebアプリの場合、サイト内の利用動向からプッシュ通知許可を出してもいいエンゲージメント度合いを測る必要があるともいえます。それがFacebookにおいてはログインのタイミングだということなのかもしれません。常識的に考えても違和感はないですし、これは特にソーシャルメディアなどユーザが繰り返し使うサービスにおいては標準的な手法になってきそうです。

ECサイトでのケース

例えばECサイトにおける初回訪問から購入に至る経路として、

検索エンジンの検索結果→商品ページ→カテゴリページ→商品ページ→カート→購入

という流れがあるとします。このケースの場合、最初の接触時はサイトとユーザーの関係は浅く、すぐ離脱してしまう可能性もあるわけですが、最終的には購入に至っており流れの中でエンゲージメントの度合いが大きく変化しています。トラフィックのボリュームで見ると前半に偏重し、逆にネイティブアプリはもう少しなだらかになると思います。だとすると、あまり序盤で通知許可を出してもプッシュのメリットが想起できない(たいして親しくない人から連絡先聞かれるようなイメージ)ですから、そのタイミングをWebサイト側で適切に設定してあげる必要があります。

じゃあ、上記のケースの場合購入の瞬間でいいのかというと、プッシュ通知を許可してくれるユーザーの母数を考えると必ずしも適切でないかもしれません。選別しすぎても結果的に数がとれない。なので、連絡先を聞かれるくらいの親しさを担保しつつも、なるべく多くとれるようバランスをどう取るか?というのが今後ポイントになってきそうですね。

Webプッシュ、今なら無料ではじめられます

Pushnate(プッシュネイト)はAndroidやPC版Chrome 42以上で使える、Webサイトでも無料でプッシュ通知が配信できるサービスです。

プッシュ通知したいWebサイトにJavaScriptを貼り付け、ちょこっと設定するだけ。通知日時を指定したり定期的な通知も可能なので、新商品や新コンテンツ追加時など自由なタイミングでリピート訪問を促進することができます。

今すぐWebプッシュをはじめる(無料)

SNSでもご購読できます。

スポンサーリンク