お知らせ・通知の注意点
通知は「送れば届く」ように見えて、送りすぎ・タイミング・誤配信のどれか一つで信頼を失う仕組みです。
ここでは、要件定義の前に把握しておきたい論点を整理します。
%%{init: {"flowchart": {"nodeSpacing": 24, "rankSpacing": 48}}}%%
flowchart LR
R(["お知らせ・通知の注意点"])
A["`**1. 通知疲れと離脱**
配信過多
全部オフしか選べない`"]
B["`**2. 配信タイミング**
深夜・早朝の配信
日付境界のずれ`"]
C["`**3. 誤配信**
対象条件のミス
テスト文面の本番配信
誤配信後の対応`"]
D["`**4. 既読・効果測定**
既読の定義が曖昧
到達の過信`"]
E["`**5. 内容・体裁**
プッシュだけに本文
告知と特典の不一致
負荷集中`"]
A --- R
B --- R
C --- R
R --- D
R --- E1. 通知疲れと離脱
配信過多による通知オフ・退会
プッシュ通知が多すぎると、会員は通知をオフにするか、アプリ自体を削除してしまいます。通知をオフにされると、以後どんな重要な通知も届きません。
- 会員単位の頻度上限を設けます
- 属性・行動で対象を絞り、無関係な会員に送りません
- 開封率の推移を監視し、低下したら頻度・内容を見直します
全部オフしか選べない受信設定
受信設定が「受け取る / 受け取らない」の二択しかないと、一部だけ不要な会員も全部オフにしてしまいます。チャネルごと・カテゴリごとのオン/オフを提供し、期限リマインドなど実益のある通知は独立したカテゴリにして、販促と一緒にオフされないようにします。
2. 配信タイミングの問題
深夜・早朝の配信
定時のバッチ処理や自動配信が深夜に動くと、就寝中の会員にプッシュ通知が届きます。プッシュ通知の配信可能時間帯を設定して時間外の通知は翌朝に繰り延べ、定時処理の実行時刻と通知の配信時刻を分けて設計します。
日付境界のずれ
「誕生月初日に配信」などの日付判定は、システムの時刻設定によってずれることがあります。日付判定の基準を明確に統一し、境界時刻(0時前後)の配信は避けて朝の時間帯に寄せます。
3. 誤配信
対象条件の設定ミス
絞り込み条件の誤りで、意図しない会員に配信される(または対象者に届かない)ことがあります。
- 配信前に対象者数のプレビューを必須にします(想定と桁が違えば気づけます)
- 特定の会員が条件に該当するかを事前確認できるテスト機能を用意します
- 配信は承認フローを経ます
テスト文面の本番配信
テスト用の文面・リンクをそのまま本番の全会員に配信してしまう事故は珍しくありません。テスト配信先(スタッフのみ)と本番配信を明確に分離し、配信直前の確認画面に対象者数・チャネル・文面を1画面で表示します。
誤配信後の対応不備
誤配信に気づいても、取り消し・訂正の手段が用意されていないことがあります。アプリ内お知らせは公開後の取り下げ・差し替えを可能にし、プッシュ通知は取り消せない前提で、訂正通知を出す判断基準(誤配信の影響度)を事前に決めておきます。
4. 既読・効果測定の問題
既読の定義が曖昧
「一覧に表示された」を既読と数えるか「本文を開いた」を既読と数えるかが決まっていないと、集計が使いものになりません。既読の定義を最初に決め、重要通知の到達確認に使う場合は「本文を開いた」を基準にします。
プッシュ通知の到達を過信する
プッシュ通知は端末・OS側の事情(通知オフ、省電力設定、アンインストール)で届かないことがあります。配信数と開封数を分けて集計して到達率の変化を監視し、重要な連絡はプッシュ通知単独に頼らず、アプリ内お知らせ・メールを併用します。
5. 内容・体裁の問題
プッシュ通知だけに本文を載せる
通知欄から消えると会員が内容を確認できず、「さっきの通知は何だったのか」という問い合わせになります。本文は必ずアプリ内お知らせに置き、プッシュ通知は誘導に徹します。
特典告知と特典実体の不一致
「クーポン配信中」と告知したのに、会員が開いた時点ではクーポンが未配信・終了している、という不一致が起こりがちです。特典の公開期間と告知の配信タイミングを連動させ、告知前に特典側の状態(公開中か)を確認する運用にします。
大量配信による負荷集中
全会員への一斉プッシュ配信の直後は、アプリ起動が集中してシステムが過負荷になることがあります。分割配信で起動タイミングを分散させ、配信直後にアクセスが集中する画面(お知らせ一覧、クーポン一覧)の負荷を事前に確認します。