陈漠沙：如何正确理解推送服务的“送达率”

本文选自《程序员》杂志电子版 2015 年 6 月 B 刊，做者陈漠沙，如需转载请注明出处。

在选择和衡量第三方推送服务时，开发者首要考虑的因素就是消息的“送达率”，那么该如何理解“送达率”呢？ 推送服务的“送达率”能够达到多高？今天和你们一块儿来聊聊这个话题。

一次消息推送的完整流程

以 Android 平台为例，一次典型的消息推送过程以下图所示(模型已经简化):

大体的流程能够描述以下:

开发者首先将消息推送指令发送给第三方推送提供商（如友盟消息推送），告知推送服务商本次推送任务要发送的内容和目标对象。

• 咱们假定该推送指令要推送给该 App 的全部用户(广播)，假设该 App 有 100W 安装量，那么“发送总数”就是 100W 。

1. 推送服务商收到推送指令后，会对推送的设备集合作有效性检查，假设经有效性判断后，识别出有效设备 99W ，这 99W 设备就是该次推送任务的“接受数”。

• 有效性检查包括多个层面，基本的层面包括检查设备号 device-token 的合法性( device-token 根据必定的规则生成，若是设备号不符合生成规则，必然是无效设备)。

1. 在步骤 2 筛选出的合法设备里面，第三方推送服务会选择当时长连通道在线的设备进行消息下发，咱们称这部分设备为“在线设备”，假设有 40W ，咱们称之为“下发数”。

• 这里说的“在线设备”表示的是设备已经联网，而且与服务器端创建了长连通道。“设备联网 & 长连通道创建”是消息下发的前提。上图中的“设备3”就是一个离线设备的例子。

1. 第三方服务器对步骤 3 选择出来的“在线设备”进行消息投递，投递给设备。假设消息成功下发到设备的有 39.5W ，这个数字咱们称之为“送达设备数”。

• 有可能由于网络缘由，致使消息下发不成功，好比网络闪断(从而长连通道也会断掉)。通常来讲，“送达设备数”和“下发数”很是接近，通常都在 98% 以上。

1. 消息会首先送达设备，送达设备后，会根据 App 包名( Android 平台以包名做为 App 的惟一标识)路由给 App ，路由到 App 以后，终端用户就能够接收到通知消息了，由此消息推送的整个过程就算完成，上图中消息发到给“设备1”就是这样一个过程。

假设成功路由到 App 的消息数为 35W ，咱们称为“送达 App 数”。 这个过程牵涉到较多的专业术语，我经过寄快递的例子来解释下这个过程: 假如你在上海要经过顺丰寄送一个快件给北京的友盟公司，那么快件首先会邮递到顺丰公司在北京的总站点，以后再根据友盟公司的地址投递/路由到友盟，这样一个寄件过程就算完成了。

在这里，你要寄送的快件就是你要发的“消息”，北京的友盟公司至关于最终“接收消息的App”，顺丰公司在北京的总站点至关于这里提到的“设备”，友盟公司的地址就至关于这个环节里面提到的“包名”。广义来说，其实快递本质上也能够看作是一种消息推送~

• 消息送达设备，但最终没有成功路由到 App 的缘由比较多，最多见的缘由是 App 已经被删除，致使路由失败，或者在某些深度定制系统上(好比 MIUI )因为作了某些限制，若是 App 在消息送达设备后没有启动过，也会致使路由失败。"设备2"就是一个 App 已经卸载，消息能够下发到设备，可是最终路由不到 App 的例子。

由此来看，消息推送从开发者建立消息推送指令，到最终消息成功送达 App (只有送达 App 后，消息才能够正确展现出来)，中间会通过几个步骤，在每一个步骤中，相关数字都会有损耗。

解读“送达率”背后的那些指标、术语

接下来解释下前面说起的几个数字概念，由此来引出咱们要重点讨论的消息“送达率”定义。

发送总数: 该数字是从开发者的角度出发的，表示从开发者看到的或者认为的该次发送目标集合的个数。

接受数: 表示第三方推送服务提供商认定的合法的发送设备数。"接受数"是真实的发送总数，表示该次任务计划下发的总数。
通常来讲，“接受数”和“发送总数”是很是相近的。

下发数: 表示当次发送任务建立时刻，长连在线设备的个数（上文提到，设备联网且设备长连在线是消息可以下发的前提），推送服务商会选定这些长连在线的设备，作消息下发。

送达设备数: 表示消息送达到设备的数字，注意这个仅表示送达到设备层面的数字。
送达 App 数: 消息送达到设备后，成功路由到 App 的数字。

概念明确以后，咱们给出两个送达率的定义，“在线送达率”和“通用送达率”。

在线送达率: 针对长连在线的设备进行消息下发，成功送达到设备的比例(注意，定义说起的只是送达到设备，而非送达到 App 这个层面)。
在线送达率 = 送达设备数( 39.5W ) / 下发数( 40W ) 或者在线送达率=送达设备数/接收数*在线设备率≈ 98.75% ，上文中的步骤 4 说的就是在线送达率。
绝大部分推送服务提供商所宣传的高送达率其实说的就是“在线送达率”。

通用送达率: 针对该次接受的设备集合，成功送达到 App 的比例(定义说起的是送到到 App ，而非设备)。
通用送达率 = 送达 Ap p数( 35W ) / 接收数( 99W )。

这里还须要补充一点的是，上述假定的数字都是针对消息建立时刻对长连在线的设备进行下发得出的数字。

实际上，开发者发送的消息都会设定必定的有效期(好比新闻类 App 的消息有效期通常比较短，而一些公告类的通知有效期可能会比较长)。在消息有效期内，若是仍有设备上线，那么消息会继续下发，“送达设备数”和“送达App数”会继续增加，直至消息过了有效期，当次发送任务生命周期才算结束，从而消息不会再去下发了，这个不会影响“在线送达率”，可是“通用送达率”在消息有效期内是会不断提高，直至消息过了有效期。假设消息最终送达到设备有 55W ，送达到 App 有50W，那么最终的“通用送达率”应该是 50W/99W 。

通用送达率和 App 活跃度的关系

看过这两个送达率的定义以后，相信你们就能明白“送达率”的含义了。通常来说，“通用送达率”和 App 自身的活跃度以及所属的垂直领域相关度很大。

相信你们也能观察到一个现象：在 App 集成了推送 SDK 刚上线的时候，在友盟推送后台看到的通用送达率会很高，以后会发现通用送达率就会随着时间的增加而逐步下降，直至最后稳定在一个数值上。

这就说明了通用送达率和 App 活跃度有很大的关系。不活跃的 App ，有多是由于卸载致使，有多是由于 App 没有启动过，致使和服务器的长链接创建不起来，从而致使服务器端没法下发消息(消息下发的前提是设备联网且和服务器的长连通道创建)。

下面咱们给出一个线上真实 App 的某次发送任务，细分到 App 的活跃区间，来看看 App 活跃度对消息送达率的影响:

这里的“受理”就是咱们定义的“接收数”，“送出”表示“下发数”，“通道送达”表示“送达设备数”，“送达”表示“送达 App 数”。

上图代表，随着活跃度的降低，会致使消息的“下发数”、“送达设备” 和“送达 App 数”所占比例均会大幅度的下降。

上述过程，咱们解释了 Android 平台的消息送达率，对于 iOS 平台来讲，通常来讲都是走的苹果自身提供的 APNs (Apple Push Notification Service)通道，这个时候，咱们只能拿到“发送总数”和“接受数”这两个数字，其中“接受数”表示 APNs 接受的发送数，咱们没法进一步获取苹果自身的送达数。

所以，谈到消息的送达率，咱们通常都是针对 Android 平台来讲的。

相信你们对推送的重要指标“送达率”有了必定了解，想了解更多推送指标和使用技巧？访问友盟论坛-推送版块http://bbs.umeng.com/forum-push-1.html

关于做者：陈漠沙，友盟研发总监，消息推送业务线负责人，曾就任于雅虎北京软件研发中心，担任系统开发工程师。新浪微博@贝克汉姆老了