1件のデリバリー注文でも、「確認済み」から「配達完了」までの間に5〜7件のプッシュ通知が発生することがあります。週に数回注文すれば、アプリはスパムのように見えてしまいます。スマートフォンユーザーは平均して1日46件のプッシュ通知を受け取っており、週に2〜5件の通知を送るだけで43%がオフにするという実態があります。
ユーザーは、途中で5回割り込まれるのではなく、いつでも現在の状況を把握したいと考えています。エンゲージメントとオプトアウトの違いは、どの瞬間にプッシュ通知が必要で、どの瞬間はただ「見える」状態にしておけばよいかを理解することにあります。
アラート vs. ライブ状態：唯一必要な区別
ほとんどのチームは、リアルタイムのすべてにプッシュ通知をデフォルトのチャネルとして使用しています。注文確認、ドライバー割り当て、ドライバー出発、ドライバー到着間近、配達完了。ユーザーが自ら起こしてすでに待ち望んでいる1つのイベントに対して、5回の割り込みが発生します。
これらの更新はすべて重要ですが、すべてがプッシュ通知である必要はありません。リアルタイムシナリオには、根本的に異なる2つのコミュニケーションの役割があります。
アラートは「何かが起きた！今すぐ見て」と伝えます。割り込んで注意を求めます。フライトのゲートが変更された、支払いが失敗した、ライドが到着したなど、真に決断や行動変容が必要な瞬間に属します。
ライブ状態は「今こういう状況です。見たいときに確認してください」と伝えます。常時表示され、継続的に更新されます。ライブ状態は、ドライバーの位置情報、調理時間、配達の到着予測時間、試合のスコア、ワークアウトの距離など、ユーザーが反応する必要なく追跡したい情報をカバーします。
プッシュ通知はアラートのために作られました。Live Activitiesはライブ状態のために作られました。状態追跡にプッシュを使用するということは、ユーザーが割り込みを求めていないことについて、ユーザーを中断させることを意味します。
3メッセージルール
どのリアルタイムシナリオでも、プッシュ通知は最大3件で十分です。
開始。 プロセスが始まったことを確認します。「ご注文が確認されました。」「支払いを開始しました。」「ドライバーが向かっています。」これにより期待値が設定され、ユーザーに安心感を与え、以降を担うLive Activityが起動します。
例外。 何か問題が発生したか、注意が必要な場合です。「商品が在庫切れです。」「ドライバーが入口を見つけられません。」「支払いが拒否されました。カードを更新してください。」「フライトが2時間遅延しています。」これらは行動が必要なため、真の割り込みです。
終了。 プロセスが完了します。「ご注文が配達されました。」「支払いが完了しました。」「到着しました。」これでループが閉じられ、Live Activityが終了します。
開始と終了の間のすべては、Live Activityとしてロック画面に表示されます。調理時間のカウントダウン、地図上を移動するドライバー、更新されるスコア、再計算される到着予測時間。すべてが自動で更新され、割り込みはゼロです。
実際の例：フードデリバリーの注文
標準的なデリバリーフローを、導入前後で見てみましょう。
導入前（プッシュのみのアプローチ）、約45分間で5件の通知：
- 🔔 「ご注文が確認されました」
- 🔔 「ご注文を準備中です」
- 🔔 「配達員がご注文を受け取りました」
- 🔔 「配達員が近くにいます」
- 🔔 「ご注文が配達されました」
1回のランチ注文で5回の割り込みです。週に2〜3回注文すれば、1つのアプリから10〜15件の通知が届きます。これがユーザーが通知を完全にオフにし始めるしきい値です。
導入後（3プッシュルール + Live Activity）：
- 🔔 プッシュ：「ご注文が確認されました」→ Live Activity開始
- 📱 Live Activityがサイレントで更新：準備中 → 受け取り済み → 配達員の位置情報 → 到着予測カウントダウン
- 🔔 プッシュ（必要な場合のみ）：「配達員がビルに入れません。電話をご確認ください」
- 📱 Live Activity：到着予測カウントダウン継続
- 🔔 プッシュ：「ご注文が配達されました」→ Live Activity終了
ユーザーへの割り込みは5回から2回（問題がある場合は3回）に減少します。ロック画面はすっきりし、リアルタイムの視認性は実際には向上します。5回のバラバラな通知の代わりに、ドライバーの位置情報と到着予測時間を含むライブの継続的なトラッカーが、数秒ごとに更新されます。
結果： オプトアウトの減少、「注文はどこですか」というサポートチケットの減少、そしてアプリは5回点滅して消えるのではなく、ロック画面に30〜45分間継続して表示されます。
アプリに合わせてルールを適応させる
同じルールは、ユーザーがリアルタイムで何かを追跡する場所ならどこでも機能します。
| アプリ | プッシュ：開始 | Live Activity | プッシュ：例外 | プッシュ：終了 |
|---|---|---|---|---|
| ライドシェア（モビリティ） | ドライバー割り当て | 位置情報、到着予測、車両詳細 | ドライバーキャンセル／ルート変更 | 旅程完了＋料金 |
| Eコマース | 注文発送 | 梱包中 → 配送中 → 配達中 → 近くにいます | 遅延または配達失敗 | 配達完了 |
| フィンテック | 取引開始 | 処理状況（国際送金、本人確認） | 支払い失敗／不審な取引 | 取引完了 |
| ゲーム | トーナメント開始／エネルギー満タン | リーダーボード順位、ボスタイマー、進捗 | 対戦相手見つかる／ストリーク危機 | 試合結果 |
| ニュース＆メディア | 速報／ライブイベント | ライブティッカー：スコア、得票数、見出し | 重大な展開 | イベント終了 |
いずれの場合も、プッシュ通知は重要なトランジションを示します。Live Activityはその間の状態を担います。
スタックを再構築せずに始める方法
よくある反論として「Live Activitiesを追加するには大規模なリファクタリングが必要だ」というものがあります。実際には、3ステップのアプローチで1スプリント内に収まります。
-
現在のプッシュフローを監査する
1つのリアルタイムジャーニー（注文追跡、ライド、試合）を選択し、それがトリガーするすべてのプッシュ通知をリストアップします。それぞれにフラグを立てます：ユーザーが何かを実行する必要があるか、新しいことを知る必要があるか、それとも自分で確認できるステータス更新か？通常、5〜7件のプッシュのうち2〜3件がこのフィルターを通過します。
-
抑制して置き換える
ステータス更新のプッシュをオフにします。開始プッシュでLive Activityを起動し、終了プッシュで終了させます。以前にプッシュ通知を送っていたすべての時点で、APIを介してLive Activityを更新します。
-
測定する
2〜4週間にわたって3つのことを追跡します。オプトアウト率が下がるはずです。Live Activitiesによってユーザーが自己解決できるようになるため、「注文はどこですか」というサポートチケットの量が減少します。そして、セッション頻度はむしろ上昇することが多いです：アクティブなLive Activityを持つユーザーはアプリをより多く開く傾向があり、ロック画面が再エントリーポイントになるからです。
