在选择和衡量第三方推送服务时，开发者首要考虑的因素就是消息的“送达率”，那么该如何理解“送达率”呢？推送“送达率”高达98%靠谱吗，该如何理解这么高的“送达率”？今天我们一起来聊聊这个话题。
以Android平台为例，一次典型的消息推送过程如下图所示(模型已经简化):
大致的流程可以分为以下五步:
一，开发者首先将消息推送指令发送给第三方推送提供商（如友盟消息推送），告知第三方推送服务商本次推送任务要发送的内容和目标对象。
我们假定该推送指令要推送给该App的所有用户(广播)，假设该App有100W安装量，那么“发送总数”就是100W。
二，第三方推送服务商收到推送指令后，会对推送的设备集合做有效性检查，假设经有效性判断后，识别出有效设备99W，那么这99W设备就是该次推送任务的“接受数”。
有效性检查包括多个层面，基本的层面包括检查设备号device-token的合法性(device-token根据一定的规则生成，如果设备号不符合生成规则，必然是无效设备)。
三，在步骤b筛选出的合法设备里面，第三方推送服务会选择当时长连通道在线的设备进行消息下发，我们称这部分设备为”在线设备“，假设有 40W，我们称之为“下发数”。
注意，这里说的“在线设备”表示的是设备已经联网，并且与服务器端建立了长连通道。“设备联网 & 长连通道建立”是消息下发的前提。上图中的“设备 3 ”就是一个离线设备的例子。
四，第三方服务器对步骤C选择出来的“在线设备”进行消息投递，投递给设备。假设消息成功下发到设备的有39.5W，这个数字我们称之为“送达设备数”。
有可能因为网络原因，导致消息下发不成功，比如网络闪断(从而长连通道也会断掉)。一般来说，“送达设备数”和“下发数”非常接近，一般都在98%以上。
五，消息会首先送达设备，送达设备后，会根据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%，上文中的步骤d说的就是在线送达率。绝大部分推送服务提供商所宣传的高送达率其实说的就是“在线送达率”。
通用送达率:表示的是，针对该次接受的设备集合，成功送达到App的比例(注意，定义提及的是送到到App，而非设备)。通用送达率=送达App数(35W) / 接收数(99W)。
这里还需要补充一点的是，上述假定的数字都是针对消息创建时刻对长连在线的设备进行下发得出的数字。
实际上，开发者发送的消息都会设定一定的有效期(比如新闻类App的消息有效期一般比较短，而一些公告类的通知有效期可能会比较长)，在消息有效期内，如果仍有设备上线，那么消息会继续下发，“送达设备数”和“送达App数”会继续增长，直至消息过了有效期，当次发送任务生命周期才算结束，从而消息不会再去下发了，这个不会影响“在线送达率”，但是“通用送达率”在消息有效期内是会不断提升，直至消息过了有效期，假设消息最终送达到设备有55W，送达到App有50W，那么最终的“通用送达率”应该是 50W/99W。
看过这两个送达率的定义之后，相信大家就能明白“送达率”的含义了。一般来讲，“通用送达率”和App自身的活跃度以及所属的垂直领域相关度很大。
相信大家也能观察到一个现象：在App集成了推送SDK刚上线的时候，在友盟推送后台看到的通用送达率会很高，之后会发现通用送达率就会随着时间的增长而逐步降低，直至最后稳定在一个数值上。这就说明了通用送达率和App的活跃度有很大的关系。不活跃的App，有可能是因为卸载导致，有可能是因为App没有启动过，导致和服务器的长连接建立不起来，从而导致服务器端无法下发消息(消息下发的前提是设备联网且和服务器的长连通道建立)。
下面我们给出一个线上真实App的某次发送任务，细分到App的活跃区间，来看看App的活跃度对消息送达率的影响:这里的“受理”就是我们定义的“接收数”，“送出”表示“下发数”，“通道送达”表示“送达设备数”，“送达”表示“送达App数”。 上图表明，随着活跃度的下降，会导致消息的“下发数”、“送达设备” 和“送达App数”所占比例均会大幅度的降低。
上述过程，我们解释了Android 平台的消息送达率，对于 iOS 平台来说，一般来说都是走的苹果自身提供的APNs (Apple Push Notification Service) 通道，这个时候，我们只能拿到“发送总数”和“接受数”这两个数字，其中“接受数”表示 APNs 接受的发送数，我们无法进一步获取苹果自身的送达数。因此，谈到消息的送达率，我们一般都是针对Android平台来说的。本文选自《程序员》杂志电子版2015年6月B刊，如需转载请注明出处。
姑婆那些事儿（www.gupowang.com）是互联网推广运营知识分享平台，关注移动推广（android，ios）运营，网站推广运营、校园推广及互联网领域最新动态 。欢迎关注我们的微信（gupo520），新浪微博（姑婆那些事儿）。
本文由姑婆那些事儿发布，转载请注明本文出处，并附带本文链接，违者必究。
