プッシュ通知は『一押しで再訪を生む』強力チャネル
プッシュ通知はモバイル・Webアプリのリテンション施策の主役です。本記事では編集部の視点で、設計と運用を公開情報をもとに整理します。モバイルアプリ配信 もご参考に。
FCM/APNs の概要
(1) FCM (Firebase Cloud Messaging)：Android+Web+iOS対応。(2) APNs：Apple 公式の iOS 配信。(3) Web Push：ブラウザ向け。VAPID 鍵で配信。(4) OneSignal / Braze 等のSaaS：マルチプラットフォーム統合。(5) トークン管理：失効/更新の処理が必須。料金・機能は最新の公式情報をご確認ください。
セグメント配信の設計
(1) ユーザー属性：地域/年齢/プラン。(2) 行動セグメント：最終ログイン/購入履歴。(3) イベントベース：特定行動の直後。(4) A/B テスト：文言/タイミング。(5) 除外リスト：解約済み等を除く。
通知タイミングの最適化
(1) ユーザータイムゾーン考慮：UTC で打たない。(2) 頻度の上限：1日3通以下が一般的(公開情報をもとに)。(3) Quiet hours：22時〜8時は控える等。(4) 個人別最適化：機械学習で開封率高い時間を予測。(5) 緊急通知のみ時間問わず。
パーミッション要求の戦略
(1) 初回起動で求めない：拒否率が高い。(2) 価値の理解後：3回目訪問等。(3) プリパーミッション UI：システムダイアログ前にカスタムUI。(4) 具体的なメリット説明。(5) 後から再要求：iOS は1度拒否したら設定アプリ誘導。
計測と改善
(1) 配信率：成功/トークン有効。(2) 到達率：実際に届いたか。(3) 開封率：通知をタップしたか。(4) CV率：通知→目的アクション。(5) 解除率：通知 OFF にしたか。Observability 実践 も合わせて。
実装の落とし穴
(1) トークンの永続化：再インストール対応。(2) サイレント通知の制約：iOS は厳しい。(3) ペイロード上限：FCM 4KB / APNs 4KB(公開情報をもとに)。(4) バックグラウンド配信：OS別の挙動差。(5) 多言語対応：本文のローカライズ。
失敗しがちなパターン
(1) パーミッション要求のタイミング悪い：拒否率高。(2) 通知過剰：解除率上昇。(3) セグメント設計なし：全員に同じ通知。(4) 失敗通知の再送なし。(5) 分析なし：改善できない。対策は、(1)プリパーミッション UI、(2)頻度上限、(3)セグメント駆動、(4)リトライ、(5)KPI ダッシュボード、です。