引言:把送达率当成系统可用性来对待,而不是一个面子指标

大多数团队每月只看一次 SMS 送达率,而且只看一个百分比数字。

"看起来还不错,大概在 95% 左右。"

而与此同时:

某家美国运营商悄悄开始过滤一个新的促销流程。
一条高价值的 OTP 验证码序列在凌晨 2 点开始失败。
一个一次性号码池逐渐"疲劳",错误码在悄悄攀升。

等到有人发现问题时,你已经:

损失了五到六位数的收入,源于结账或充值流程被放弃。
损害了用户信任("我根本没收到验证码,你们的应用坏了。")。
让运营商把你的品牌标记为高噪音或高风险。

在我们处理数百起送达率事故的过程中,规律非常清晰:把送达率当成站点可靠性(SRE)来管理的团队能够快速恢复;把它当成每周面子指标的团队往往被打个措手不及。

这份指南将向你展示如何:

选出正确的 KPI(并忽略那些容易误导你的指标)。
按运营商、发送号码池、路由和活动对数据进行切分。
搭建一套仪表盘与告警系统,提前发现问题。
用监控来主动提升送达率,而不仅仅是事后汇报。

第一部分:真正重要的核心 SMS 送达率 KPI

你不需要 40 个指标。你需要的是一小组与事故和恢复直接对应的 KPI。

1. 送达率(按运营商、号码池、活动划分)

定义:

送达率 = 收到正向"已送达"回执的消息数 ÷ 总发送尝试数

最佳实践:

始终按以下维度切分:
- 运营商(Verizon、AT&T、T-Mobile,以及国际运营商)
- 发送号码池 / Grid
- 活动 / 流程(OTP、促销、交易类)
- 国家 / 地区

"良好"水平是什么样的(美国 A2P,配置合理的情况下):

核心交易类流程:99% 以上
高量级促销:98%–99% 以上
任何持续低于 97%–98% 的情况都需要排查。

2. 硬失败 / 错误率

定义:

收到明确失败码的消息所占百分比:
- 号码无效
- 用户未知
- 运营商永久拒收

为什么重要:

硬失败率上升通常意味着:
- 号码列表质量不佳。
- 运营商在层面上对特定发送方或内容进行封堵。
- 号码池已经"疲劳"或被烧毁。

需要留意:

单一运营商上的突然跳升。
特定路由或号码池持续出现 >1%–2% 的硬失败率。

3. 软失败 / 重试率

定义:

临时性失败:
- 网络问题
- 拥塞
- 限速 / 限流

为什么重要:

软失败率偏高 = 你对运营商施压过猛,或者正在撞上拥塞的路由。
能反映你的重试策略是在起作用,还是只是在硬撞。

4. 未知 / 被过滤 / "虚假送达"信号

运营商并不总会给出明确的"已过滤"错误码。有些运营商会:

返回通用错误。
即便设备什么都没收到,也照样回执"已送达"(影子过滤)。

可监控的代理指标:

下游行为(点击、登录)出现下降,但回执却显示"OK"。
抽样测试:在每家运营商上放置种子号码,单独记录日志。
新活动出现突然的性能下滑,而其他活动保持稳定。

5. 号码池与 Grid 健康度

如果你使用:

一次性号码池(Burner Number Pools)
私有号码池 Grid(Private Pool Grids)
甚至只是简单的专属号码

……你都应该按号码池/Grid 分别追踪:

送达率
硬失败率
投诉 / 退订率
每个发送号码的每日消息量

健康的模式:

长期保持稳定的表现。
没有任何发送号码越过以下红线:
- 24 小时窗口内硬失败率 >1%。
- 促销活动投诉 / 退订率 >0.3%–0.5%。

第二部分:"送达率立方体"——如何对数据进行分维度切分

一个笼统的全局"送达率"会掩盖所有真实问题。

你需要一个送达率立方体,包含以下维度:

运营商(Verizon、AT&T、T-Mobile 等)
发送方(号码池、Grid、单个号码)
路由 / 产品(网关、地区)
活动 / 流程(OTP、促销、交易类)
内容风险等级(主流内容、高风险内容、SHAFT 类内容)

一个能抓住真实问题的切片示例

Verizon × 促销 × Grid A:
- 48 小时内送达率从 99.1% 跌至 94.4%。
- 硬失败率与软失败率略有上升。
- 其他运营商表现稳定。
应对措施:
- 将 Verizon 的促销流量从 Grid A 切换到 Grid B。
- 排查近期的内容变更和发送速度模式。
- 在测试期间将发送量临时下调至基线 + 20%。

如果没有维度切分,你只会看到:

全局送达率:97.8% → 96.9%(没什么感觉)。

而有了维度切分,你会看到:

矩阵中某一个输出节点正在被烧坏,而其他节点都很健康。

第三部分:告警阈值,以及触发后该做什么

1. 按运营商划分的送达率告警

推荐阈值(可根据自身基线调整):

当任意主要运营商的送达率:
- 较 7 天中位数下降超过 2 个百分点。
- 或在有实际流量的情况下跌破 97%,且持续 30–60 分钟以上。

应急手册(Runbook):

先确认这不是数据故障(检查仪表盘和原始日志)。
排查:
- 近期部署(内容变更、路由变更)。
- 新活动上线。
- 发送量突增。
缓解措施:
- 临时降低该运营商的发送速度。
- 如果有可用资源,切换到备用号码池 / Grid。
- 暂停针对该运营商的新高风险活动。

2. 号码池 / Grid 健康度告警

满足以下条件时触发告警:

任意号码池或 Grid 的硬失败率在有意义的流量下,持续超过 1%–2% 超过 1 小时。
促销活动的投诉 / 退订率超过 0.3%–0.5%。

应急手册(Runbook):

立即停止在该号码池 / Grid 上发送新活动。
将部分流量切换到更健康的号码池。
排查:
- 是否把高风险内容混入了原本干净的号码池?
- 运营商策略是否发生了变化(例如针对 SHAFT 类关键词出台了新规则)?

3. 影子过滤与"虚假送达"告警

由于你并不总能看到明确的错误码:

进行以下对比:
- 已送达消息数 → 预期转化数(点击、登录、OTP 使用)。
在以下情况触发告警:
- 送达率指标看起来"良好",但某个运营商或活动的下游转化率急剧下降。

这正是以下手段大显身手之处:

每家运营商都布设种子号码,价值巨大。
定期进行实时测试(人工 + 自动化),核实回执与实际情况是否一致。

第四部分:设计 SMS 送达率仪表盘

你的仪表盘不需要花哨。它必须做到在压力之下依然好用。

布局一:高管总览视图

顶层关键指标卡片:

全局送达率(最近 24 小时、最近 7 天)
各运营商送达率(Verizon、AT&T、T-Mobile,以及排名前 3–5 的国际运营商)
消息占比:
- 交易类 vs 营销类
- 主流内容 vs 高风险内容

趋势图:

折线图:
- 各运营商送达率随时间的变化。
- 各运营商的发送量。

用它来回答一个问题:"我们现在是不是出事了,是还是不是?"

布局二:运维 / SRE 视图

按以下维度划分的表格与图表:

运营商 × 号码池 × 活动
号码池健康度指标(送达率、硬失败率、软失败率、投诉率)

示例:

热力图:以运营商为列、号码池/Grid 为行,展示送达率。
可排序的表格:
- "显示今日硬失败率最高的号码池。"

这个视图主要在告警触发时使用。

布局三:分析 / 营销视图

聚焦于:

活动表现:
- 送达率 vs 点击率(CTR) vs 转化率。
A/B 测试:
- 内容变体与送达率的关系。

这个视图把送达率和收入联系起来,让基础设施投入决策更容易得到支持。

第五部分:用指标诊断常见问题

场景一:单一运营商表现暴跌,其他运营商保持稳定

可能原因:

该运营商针对以下方面进行过滤:
- 内容模式。
- URL 域名。
- 发送号码池的信誉评分。

需要检查:

是否有近期的内容或模板变更?
是否使用了新的 URL?(例如更换了短链接服务)
发送量是否在该运营商上爬升过快?

场景二:所有运营商同时性能下滑

可能原因:

全局性的内容变更(例如促销文案变得更激进)。
整体发送量大幅提升。
平台层面的变更(路由逻辑、号码池逻辑)。

需要检查:

最近几次的部署记录。
新上线的高风险活动。
各项管控措施(一次性号码逻辑、各运营商发送上限)是否真正得到执行。

场景三:指标看起来正常,但客服收件箱被"我没收到"塞满

可能原因:

设备层面的过滤(垃圾箱过滤)。
运营商层面的影子过滤,回执信息具有误导性。
受影响的是某些区域性群体(例如特定区域号码段)。

需要检查:

在各运营商上进行种子设备测试。
按地区 / 区域号码段进行细分统计。
是否存在敏感关键词或敏感模式。

第六部分:送达率监控如何改变你的基础设施选择

一旦你能清楚看到:

哪些号码池最先性能下滑
哪些运营商最敏感
内容和发送量如何影响最终结果

……基础设施为何重要也就一目了然了。

转向以下方案的团队:

私有号码池 Grid(每个 Grid 包含 100+ 张多运营商 SIM 卡)
运营商匹配算法(Verizon→Verizon、AT&T→AT&T)
带自动退役机制的一次性号码池

……可以利用自己的仪表盘来:

主动轮换和冷却发送号码。
不仅测试内容,还对路由策略进行 A/B 测试。
制定针对各运营商的专属应急手册,而不是套用通用修复方案。

我们经常观察到:

部署了完善的监控和基于 Grid 的路由后,事故数量减少 40%–60%。
根因分析(RCA)速度更快,因为日志和指标能够相互对应。
与合规和法务部门的风险沟通更顺畅("我们正是这样精确控制滥用行为并监控投诉的")。

常见问题:SMS 送达率指标与仪表盘

1. 怎样才算是"良好"的全局送达率?

对于架构健全的成熟项目而言:

交易类流程:99% 以上
高量级营销类:98%–99%

核心流程若低于 97%–98%,就是一个危险信号。

2. 应该多久检查一次送达率?

仪表盘:每天查看(活动上线期间应更频繁)。
告警:重大下滑应实时触发。
深度复盘:每周或每月结合趋势分析进行。

3. 真的需要按运营商划分的数据吗?

是的。绝大多数严重事故都是运营商特定的。没有按运营商切分的数据,你就是在盲飞。

4. 对小型发送方来说,这是不是有点过度?

如果你:

发送量很低。
所处行业垂直领域风险较低。
SMS 并非驱动核心收入的渠道。

……那么可以采用更简单的监控方案。但一旦 SMS 成为核心收入来源,你会希望自己早就部署好这一整套体系。

5. 如果当前服务商不提供完善的指标,我该如何起步?

可选方案:

拉取通话详单(CDR)/ 日志,自行搭建汇总统计。
使用Webhook 将送达报告(DLR)记录到自己的数据仓库中。
考虑更换一个天生就能暴露运营商级别数据的网关。

6. 这和 A2P 10DLC 注册有什么关系?

10DLC 合规会影响:

允许的发送量。
受审查的严格程度。
滥用行为的处罚力度。

监控提供的反馈回路能告诉你:

你的活动是否仍在运营商预期范围内运行。
你是否即将触碰某个阈值红线。

7. 监控能解决糟糕的内容或授权问题吗?

不能。它只能告诉你:

情况有多糟。
问题出在哪里。

你仍然需要干净的用户授权(opt-in)、清晰的消息内容,并遵守当地法律法规。

8. 如何检测设备层面的垃圾过滤?

在各运营商和平台(iOS/Android)上布设种子设备。
将**"已送达"回执与真实设备收到的情况**及用户行为进行交叉核对。

9. 隐私保护在这其中扮演什么角色?

一个以隐私为先的网关应当:

最小化存储的个人身份信息(PII)。
提供清晰的数据留存控制选项。
在不泄露敏感内容的前提下,依然提供汇总统计指标。

10. 我需要专门配备一名送达率工程师吗?

不一定。但你确实需要:

明确的责任归属(有人对此负责)。
非专业人员在事故发生时也能照做的应急手册和仪表盘。

结语:在送达率问题变得昂贵之前,先让它变得可观测

你看不见的问题,就无法修复。

一套基础的送达率仪表盘与告警体系可以:

在运营商特定问题爆发之前就将其捕获。
证明更优基础设施(运营商匹配、私有 Grid)带来的投资回报率(ROI)。
把 SMS 从一个黑箱,转变为一套可被运营管理的系统。

如果 SMS 关系到你的收入,就应该把它当成一个 SRE 问题来对待:

为它打造监控埋点。
为它设置告警。
围绕它建立应急手册。

一旦这些都已就位,你就处在一个绝佳的位置上,可以评估一个私有的、运营商匹配型网关是否值得投入——因为你将拥有确凿的数据,清楚地展示出当前服务商正在让你白白损失多少收益。