Webプッシュ通知はどう機能しますか？
流れは3つの部分からなります。まず、ページが通知の許可を求めます。ユーザーが受け入れると、ブラウザーはPush APIを通じてプッシュ購読を作成し、ブラウザーベンダー（Google、Mozilla、Apple）が運営するプッシュサービス上のエンドポイントを返します。次に、サーバーがVAPIDキーで署名したペイロードをそのエンドポイントに送ります。するとブラウザーがService Worker（タブを開いていなくても動くスクリプト）を起動し、Service Workerが通知を表示します。ユーザーがオプトインするまで何も送信されず、許可はいつでもブラウザー側で取り消せます。
WebプッシュはiOSやSafariで使えますか？
使えます。ただし、多くのチームがつまずく条件があります。Safari 16.4（2023年3月）以降、iOSとiPadOSは、ユーザーがホーム画面に追加したWebアプリにしかWebプッシュを届けません。通常のSafariのタブでは購読できません。また、許可のリクエストは、ボタンのタップのようなユーザー操作のあとに行う必要があります。macOSでは、Safariはバージョン16.1から通常のブラウザーでWebプッシュに対応しています。実務上の結論として、iPhoneでのWebプッシュは、広く届けるチャネルではなく、最も熱心なユーザー向けのチャネルです。
小さなチームはいつWebプッシュを使うべきですか？
Webプッシュが真価を発揮するのは、メールアドレスなしでサイトの外にいるユーザーに届けたいときです。トライアル終了のひと押し、セットアップのリマインダー、ユーザーがフォローを選んだイベントのアラートなど。アプリ内メッセージとも自然に組み合わさります。アプリ内メッセージはプロダクトの中にいるユーザーに語りかけ、Webプッシュはいないユーザーを呼び戻します。2つのチャネルを1つの施策にまとめる方法は、Webプッシュとアプリ内メッセージのガイドをご覧ください。OneSignalやNovuのようなツールは、主に購読と配信の管理を代行するために存在します。
Webプッシュの限界は？
- 許可は壊れやすい：早すぎるタイミングで求めるとユーザーは拒否を押し、それはほぼ取り消せません。多くのチームは、まず自社のUIで意向を確かめてから、ブラウザーのプロンプトを出しています。
- 配信は保証されない：通知はブラウザーベンダーのプッシュサービスを経由し、到達できない端末では、制限、集約、破棄されることがあります。
- 受信トレイがない：閉じた通知は消えます。残しておくべき内容は、メールやアプリ内メッセージにも載せます。
- 到達範囲にむらがある：デスクトップのChromeとAndroidではよく機能しますが、iPhoneではインストールしたWebアプリだけが対象です。