notification-strategy-review

通知戦略のレビュー

通知に注意を払う価値を持たせるために、このスキルを使用します。

ワークフロー

1. チャネル、ユーザーのライフサイクル段階、プロダクトの提供価値、メッセージの目的、ユーザーの意図、地域、同意状態、設定状態、コンテンツの機密性、対象者の役割、通知疲れのリスクを特定します。
2. references/notification-strategy-patterns.md を読みます。
3. メッセージを、有用性、緊急性、同意、ライフサイクルのトリガー、頻度、フォールバックチャネル、失敗リスクで分類します。
4. キャンペーンを提案する前に、ライフサイクル、同意／地域、プライバシー／情報の伏せ字、役割／重大度、抑制の各マトリクスを作成します。
5. 明示的な頻度予算を定義します。全体上限、カテゴリ上限、ライフサイクルイベント上限、おやすみ時間中の動作、クールダウン、ダイジェストのしきい値、緊急時の例外ルールを含めます。
6. dedupe_key、チャネルの優先順位、成功時の停止条件、サポート／請求に関する停止条件、古いイベントの有効期限、抑制理由を含む、決定論的なチャネル横断の重複排除を定義します。
7. 通知がすでに通知疲れ、苦情、オプトアウト、サポートへの問い合わせを招いている場合は、送信を追加する前にインシデントの状況を整理します。コホート × チャネル × ライフサイクルイベント × 同意状態 × 頻度区分 × 苦情／配信停止／サポートのシグナルを確認します。
8. 権限を求めるタイミング、設定、フォールバック、測定、サポートによる回復、実験のガードレールを設計します。
9. 通知の分類体系、ライフサイクルジャーニーマップ、チャネル／頻度ポリシー、抑制ルール、同意／設定モデル、インシデント対応／状況整理計画、イベントスキーマ、信頼性指標を作成します。

使用しない場合

• このスキル固有の成果物の要件がなくてもベースモデルが対応できる一般的なアドバイスには使用しないでください。

ガードレール

• プロダクトの提供価値の弱さを補うために通知を使用しないでください。
• トランザクション、セキュリティ、マーケティング、エンゲージメントの同意を混同しないでください。
• ユーザーが管理できる設定、おやすみ時間、明確な配信停止方法を用意してください。
• 明確なエスカレーション価値がない限り、同じライフサイクルイベントについてプッシュ／メール／アプリ内の重複メッセージを送信しないでください。
• 具体的な通知価値をユーザーが実感する前に、プラットフォームのプッシュ通知の許可を求めないでください。
• 拒否された後に繰り返し許可を求めないでください。アプリ内での案内、設定センターからの再設定、ユーザーが開始するOS／ブラウザー設定への再アクセス手段を活用してください。
• 配信、オプトアウト、配信停止、苦情、継続率、長期的な信頼性をガードレールに含めずに、開封数／クリック数だけを最適化しないでください。
• 全体、カテゴリ、ライフサイクルイベント、クールダウン、ダイジェストに関する具体的なルールを示さずに、通知疲れへの対策を「頻度を制限する」とだけ説明しないでください。
• 緊急時の例外を、マーケティング、習慣化を促す通知、呼び戻し、IAP プロモーション、デイリー報酬、エネルギーのリマインダー、リーダーボードのリセット、ライブイベントの緊急性には使用しないでください。セキュリティ、安全、サービス継続性、またはユーザーが明示的に依頼した指定時刻のリマインダーに限って使用し、例外の理由を記録してください。
• ユーザーがコンバージョン、キャンセル、支払い、ワークフローの解決、サポートへの問い合わせ、配信停止、苦情のいずれかに至った後、シーケンスを継続しないでください。
• ロック画面のプレビュー、プッシュ通知のペイロード、SMS の本文、メールの件名に、シークレット、健康／財務情報、正確な位置情報、プライベートメッセージの内容、機密性の高いアカウント状態を表示しないでください。詳細を表示する場合は、認証が必要なディープリンクを使用してください。
• チャネルやカテゴリをまたいで同意があると推定しないでください。メール、SMS、プッシュ、アプリ内、デスクトップ／ブラウザー、トランザクション、マーケティングの各設定は、それぞれ分けて管理してください。

出力形式

Notification objective:
Channels:

Lifecycle matrix:
| Lifecycle state | Trigger | User value | Channel priority | Consent/preference state | Frequency/suppression | Metric |
| --- | --- | --- | --- | --- | --- | --- |

Consent and regional control matrix:
| Channel/region | Permission timing | Required consent/preference | Unsubscribe/opt-out | Fallback if denied | Evidence |
| --- | --- | --- | --- | --- | --- |

Privacy/redaction and deep-link policy:
| Content type | Sensitive fields to exclude | Lock-screen/subject/SMS copy | Deep-link auth | Support-safe evidence |
| --- | --- | --- | --- | --- |

Role/severity routing:
| Audience role | Severity | Allowed channels | Escalation | Audit/owner |
| --- | --- | --- | --- | --- |

Taxonomy and channel policy:
- <message type> -> trigger, user value, channel, priority, frequency, control, suppression/dedupe rule

Frequency and suppression budget:
- Global cap:
- Category caps:
- Lifecycle-event cap:
- Cooldowns:
- Digest/quiet-hours rules:
- Emergency override:

Cross-channel dedupe and stop rules:
| Lifecycle event | Dedupe key | Priority order | Stop condition | Suppression reason | Owner |
| --- | --- | --- | --- | --- | --- |

Preference and recovery model:
| Consent/preference state | Allowed action | Recovery path | Prohibited action | Evidence |
| --- | --- | --- | --- | --- |

Fatigue/incident readback, when applicable:
| Cohort | Channel | Lifecycle event | Frequency bucket | Harm signal | Decision | Owner |
| --- | --- | --- | --- | --- | --- | --- |

Risks and guardrails:
- <risk> -> <guardrail>

Events and trust metrics:
- <event> with channel, category, trigger_event, consent_state, preference_state, suppression_reason, dedupe_key, delivered/opened/dismissed/unsubscribed/complaint/retention outcome