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