消息送达率下降或漏斗异常时，用 Sent 消息 ID…

当用户询问消息为何未送达、送达率/阅读率下降、回退是否生效、是否被运营商过滤或活动表现异常时，基于 Sent 消息 ID、状态、活动时间线和 Webhook 事件做分层诊断。

适用场景

解决思路

1. 先把用户的问题重述为可度量的对比，例如把“WhatsApp 表现很差”变成“周一至周三从 profile A 发出的订单模板，WhatsApp DELIVERED 率是否下降”，并在计算前固定以下维度：profile 或发送方身份、模板 ID/名称、渠道、国家、发送时间窗、收件人分群，以及是否请求了回退或多渠道广播。
2. 以 Sent 的 message_id 作为主要统计单元：一次 v3 发送在指定多个渠道时，会为每个收件人和渠道组合分别生成消息；在终态汇总中每条 Sent 消息只计一次，去重后再做收件人或活动级汇总。
3. 区分活动历史与最新状态快照：活动历史能证明其中包含的状态迁移；而 status=DELIVERED 的快照只能证明当前观察到的结果，不能证明导出数据也观察到了 QUEUED、ROUTED 或 SENT；无法获得的迁移分母记为 N/A，不要填 0，也不要凭空补全缺失的迁移。
4. 不要用 WhatsApp wamid、SMS 运营商 ID 或 RCS 消息 ID 等提供商 ID 作为主连接键，除非导出的证据缺少 Sent ID；提供商 ID 可用于升级排查，但 Sent API 和仪表盘按 Sent message ID 跟踪状态。
5. 按 Sent 文档中的生命周期状态做第一层漏斗：QUEUED、ROUTED、SENT、DELIVERED；READ 仅作为 WhatsApp 和 RCS 的独立互动指标，绝不作为 SMS 的送达要求；把终态失败、延迟/在途消息、入站 RECEIVED 消息以及格式错误/未知记录，仅依据证据中存在的字段分到不同桶中。
6. 在诊断投递之前先检查 Webhook 健康：确认 Webhook 是否存在、是否处于活跃状态、订阅了哪些事件、近期事件历史以及测试投递；只有在用户明确要求或怀疑凭据泄露时才轮换密钥，因为轮换会立即让旧密钥失效。
7. 按渠道拆分后再归因根因：SMS、WhatsApp 和 RCS 的失败方式不同，除非用户明确要求混合 KPI，否则不要把它们平均在一起；先比较各渠道的漏斗，再比较汇总。
8. SMS 的首批切分维度包括国家、发送方/profile、10DLC 活动、退订、运营商家族，下一步证据包括合规状态、品牌/活动就绪情况、退订日志和吞吐模式；WhatsApp 的首批切分维度包括模板、语言、类别、收件人国家、质量/层级症状，下一步证据包括模板状态、已读回执、会话窗口以及存在的 Meta 侧错误；RCS 的首批切分维度包括 Agent 就绪情况、自动路由、固定渠道失败、文本/建议芯片渲染，下一步证据包括 Sent RCS 设置状态、所选路由以及确切的活动/错误详情。
9. 在给出修复建议前量化影响：同时报告原始计数和比率，例如 15 条消息中 40% 失败与 150,000 条消息中 4% 失败是完全不同的决策；将全局总数与每个渠道 × 方向分组对账，保留显式的 unknown 分组，不要静默丢弃不完整维度；排除待处理消息、测试流量、沙箱发送、重试和重复渠道扇出。
10. 分析表应包含：发送数、最新状态分布、失败数、失败率相对基线的变化、出现次数最多的确切错误字符串/代码、首次观察到的时间戳、受影响的模板、受影响的国家和受影响的 profile。
11. 最终给出一个主要诊断、一个置信水平和一个下一步验证动作，避免罗列通用修复建议，每条建议都要与观察到的证据挂钩。
12. 不要因为缺少客户侧 Webhook 就推断投递失败，必须先检查 Sent Webhook 事件历史和端点响应，因为 Webhook 摄入失败经常伪装成投递失败。
13. 不要仅凭小样本就把活动标记为“被运营商过滤”；过滤是在完成分群隔离后得出的结论，需要对比基线、国家、发送方/profile 和模板，而不是“失败”的同义词。
14. 不要混淆广播与回退：省略 channel 或使用 ["sent"] 会启用自动路由；显式指定一个渠道会固定投递；显式指定多个值会创建多条独立消息；每个返回的 message_id 只计一次，并报告实际选中的渠道。
15. 按验证清单逐项检查：分析是否以 Sent message_id 为主单元；分群是否固定了时间窗、profile/发送方身份、模板、渠道和收件人分群；状态计算是否使用每条 Sent 消息 ID 的最新已知状态；迁移计算是否使用观察到的活动历史且没有从仅含最新状态的记录回填阶段；待处理或在途消息是否被排除或单独报告；SMS 送达分析是否止于 DELIVERED，WhatsApp/RCS 的 READ 是否标注为互动；全局与渠道 × 方向总数是否对账，包括格式错误和显式 unknown 桶；当症状是缺少回调时，是否检查了 Webhook 配置、事件历史和端点测试结果；是否在报告汇总比率前拆分了渠道特定失败；提供商或运营商代码是否按观察到的原样引用，而不是从查找表编造；最终建议是否指明一个下一步验证动作及其依据的证据。
16. 当泄漏指向美国 A2P SMS 合规、品牌注册、活动注册或选择加入/退出证据时，转交 sms-10dlc-registration；当症状指向 RCS Agent 审批、上线就绪、能力缺口或回退设计而非实时投递分析时，转交 rcs-agent-onboarding；当问题是租户/profile 隔离、Webhook 路由、凭据作用域或多品牌发送方设计时，转交 sender-profile-architect；当根因是 WhatsApp 模板类别、审核状态、模板负载结构或编写工作流时，转交 waba-template-author 或 template-builder-ui；共享 Sent 术语和路由时使用 sent 技能。
17. 使用捆绑的 references/mdr-status-codes.md 规范化观察到的 SMS、WhatsApp 和 RCS 提供商错误，避免在技能正文中放入长代码字典；使用 references/performance-diagnosis-playbook.md 获取先调查哪个信号的决策树、渠道特定诊断模式、跨技能交接矩阵和升级标准；运行 scripts/analyze_mdr_funnel.py 读取 MDR 导出（CSV 或 JSON），按渠道 × 方向分组结果，分离投递迁移与互动，并保留格式错误/未知行；从技能根目录运行：python scripts/analyze_mdr_funnel.py path/to/mdr.csv（可使用 --threshold N、--show-errors 或 --format json）；退出码 0 表示未观察到迁移违规，2 表示输入错误/无可用分群，3 表示观察到违规；JSON 在分母不可用时使用 null，文本使用 N/A；可用 scripts/fixtures/good.json 作为健康漏斗的合成 MDR 导出，用 scripts/fixtures/bad.json 作为故意制造超过 50% SENT→DELIVERED 下降的合成 MDR 导出。

适用边界 · 注意事项

• 不要用此技能注册 10DLC、设计 Sender Profile、接入 RCS 或编写 WhatsApp 模板；在隔离出性能症状后，把这些工作流交给相关技能。
• 不要在没有检查 Sent Webhook 事件历史和端点响应之前，就根据缺少客户侧 Webhook 推断投递失败。
• 不要仅凭小样本、且未对比基线、国家、发送方/profile 和模板，就把活动标记为“被运营商过滤”。