如何提升即时通讯出海送达率?

送达率是出海 IM 项目里最磨人的指标之一。在线消息相对好做,真正难的是离线消息和推送送达——用户没在 app 里,消息有没有到他手上、什么时候到、有没有丢,常常说不清。这篇按”先讲清楚送达率到底怎么定义 → 在线和离线分别怎么提升 → 各通道的具体优化 → 实测怎么对账”四段走,目标是把这个抽象指标做实。

送达率到底怎么定义

讲清概念再谈优化。送达率不是一个数字,要拆成几个维度看。

第一,在线送达率。用户在线时,服务端发出消息到客户端确认收到的比例。健康水位 99.9% 以上,低于这个数代表长连或客户端有问题。

第二,离线推送送达率。用户离线时,推送通道(APNs、FCM、本地厂商通道)实际把通知送到用户设备的比例。健康水位常见 85%-95%,跨地区差异很大。这是经验区间,受运营商、设备、系统限制影响很大,不是固定值。

第三,端到端送达率。从发送方点击发送,到接收方真正看到消息(无论在线离线)的整体比例。这是用户感知最直接的指标。

第四,送达时延。送达不仅看”有没有到”,也看”什么时候到”。离线推送如果几小时后才到,用户体验上等于没到。

只盯着”99.99% 送达”是常见误区。要把”在线、离线、端到端、时延”四个指标分开看,优化才有方向。

在线送达率怎么提升

在线场景下,送达率主要被长连接质量和客户端可靠性影响。

长连接质量

• 跨洋链路用 QUIC over UDP,弱网下抗丢包能力比 TCP 强,直接降低消息丢失率。
• 心跳自适应。Wi-Fi 下 60-120 秒、移动网络 30-60 秒、弱网 15-30 秒,既要保活又不能太频繁。
• 多 IP 列表回落。一个域名解析失败时客户端能自动尝试备用 IP,避免 DNS 故障导致全断。
• 接入点多线路冗余,单线路抖动时能自动切换。

消息确认机制

• 客户端 messageId + 服务端 ACK + 客户端重发,这是 IM 的标配。没有这套机制,任何一次网络抖动都会丢消息。
• ACK 超时阈值要合理。太短会反复重发增加压力,太长用户感知卡顿。常见 3-5 秒后重发。
• 重发要带去重,服务端按 messageId 判断是否已处理。

客户端可靠性

• 后台保活。iOS 用 VoIP/Silent Push、Android 用前台服务+保活策略,避免被系统杀掉就丢消息。
• App 启动后立即拉取漫游消息,补齐离线期间错过的内容。
• 网络恢复后自动重连+补拉,而不是等用户手动刷新。

这一层做扎实,在线送达率到 99.9%+ 是合理预期。

离线送达率才是出海的真考验

离线场景下,主要靠推送通道。出海项目最常踩的坑都集中在这里。

第一,只接 APNs+FCM 不够。海外不同地区的实际情况差异很大,要分地区做通道选择。

这是经验配置,具体要按自己业务的真实用户机型分布调整。

第二,推送内容要做兼容。

• iOS 静默推送(Background)和提示推送(Alert)分开使用。重要消息用 Alert 保证用户看到,内容更新走 Silent。
• Android 不同厂商通道对推送内容有限制,标题长度、内容长度、是否支持自定义按钮各有差异,要做适配。
• 通知文案要按用户语言本地化,默认英文是常见漏洞。

第三,推送优先级和分类。

• iOS 用 interruption-level 控制提醒方式(active、time-sensitive、critical),不要所有消息都用同一个级别。
• Android 12+ 必须配置通知通道(Notification Channel),不配置直接被系统折叠。

第四,失败兜底机制。

• 一通道失败立即触发第二通道(比如 FCM 失败转小米通道)。
• 极端重要消息(支付、登录验证)用短信兜底。
• 所有失败要有定位日志,能区分是哪个通道在哪一步失败。

把这四点做透,离线送达率从 70%-80% 提升到 90%+ 是常见结果。

容易被忽略但收益很高的几个点

下面几个点不写在主流程里,但实战中收益很大。

第一,送达回执对账。每个通道(APNs、FCM、本地通道)都有回执机制,要拉到一个统一的对账系统里,定期统计真实送达率。光发不对账,丢失永远定位不了。

第二,推送 token 管理。用户卸载、重装、换设备都会让 token 失效,要有定期清理无效 token 的机制,否则推送量虚高、送达率虚低。

第三,免打扰时段。海外不同地区时差大,北京早上 9 点是欧洲半夜,推送过去用户体验极差。按用户所在地做免打扰时段,既提升体验又避免被举报降权。

第四,频次控制。短时间内大量推送会被系统厂商限流(尤其是华为、小米、OPPO),且会导致用户关闭通知权限。建议每用户每小时不超过 3-5 条非必要推送。

第五,用户行为反馈。app 内用户点击通知后的行为(打开 app、忽略、清掉),要回流到推送系统做权重调整。比如即构 ZIM 这类提供端到端送达回执打通(从 IM 服务端到推送通道再到客户端确认)+多通道智能调度的方案,可以把”哪一段在丢、哪个通道效果好”这件事直接量化,不用自己拼监控。

第六,关键消息双通道。极重要消息(账户安全、支付确认)同时通过推送和应用内消息双下发,任何一个通道到了就算成功。

实测怎么对账

光有指标没用,要建立持续的对账机制。

第一,服务端记录每条消息的全链路状态。发送时间、入库时间、推送通道选择、推送下发时间、推送回执时间、客户端确认时间,每一步都要打点。

第二,定期采样真机验证。每周从目标市场抽样几十台真机,模拟离线场景,验证推送是否真的到了、到了多久。回执说送达不代表用户真看到,真机验证才能闭环。

第三,失败定位漏斗。把”未送达”的消息按失败原因分类:token 失效、用户禁用通知、系统限流、通道故障、网络丢失。每一类有不同的优化方向,不能笼统归为”丢了”。

第四,长尾用户分析。送达率均值往往掩盖问题,P10 用户(送达率最差的 10%)单独看,通常能发现某个机型、某个地区、某个网络的系统性问题。

实测对账机制建起来,送达率优化才能形成持续闭环。

小结

提升出海 IM 送达率不是某个开关,而是把在线、离线、端到端、时延四个指标拆开,对在线场景做长连质量+消息确认机制+客户端保活,对离线场景做分地区多通道组合+推送内容适配+失败兜底,再用送达回执对账、真机采样、失败漏斗做持续监控,送达率才能稳步从 80% 推到 95%+。