【友盟+】开发者社区

谈谈消息推送服务的"送达率"

友盟PUSH 发表于 2017-1-8 14:30:00 |

友盟PUSH
友盟PUSH 发表于 2015-5-24 16:23:39 | 显示全部楼层 |阅读模式
在选择和衡量第三方推送服务的时候,开发者首要考虑的因素就是消息的“送达率”了,那么该如何理解“送达率”呢? 推送服务的“送达率”真的有像某些推送服务商宣传的那么高吗(99%多甚至接近100%),或者该如何理解这么高的送达率呢? 今天我们一起来聊聊这个话题。

以Android平台为例,一次典型的消息推送过程如下图所示(模型已经简化,完整流程可参照"消息推送链路投递流程"):

消息推送过程

消息推送过程


大致的流程可以描述如下:

  • a. 开发者首先将消息推送指令发送给第三方推送提供商(如友盟消息推送),告知第三方推送服务商本次推送任务要发送的内容目标对象。我们假定该推送指令要推送给该App的所有用户(广播),假设该App有100W安装量,那么“发送总数”就是100W
  • b. 第三方推送服务商收到推送指令后,会对推送的设备集合做有效性检查,并且只会针对平台判定的“有效设备”去尝试推送。假设经有效性判断后,识别出有效设备99W,那么这99W设备就是该次推送任务的“接受数”,也称为“受理数”。注: 有效性检查包括多个层面,包括检查设备号device-token的合法性(device-token根据一定的规则生成,如果设备号不符合生成规则,必然是无效设备)等。
  • c. 在步骤b筛选出的合法设备里面,第三方推送服务会选择当时长连通道在线的设备进行消息下发,我们称这部分设备为"在线设备",假设有40W,我们称之为“下发数”,或者称为"服务器送出数"。 注: 这里说的”在线设备“表示的是设备已经联网,并且与服务器端建立了长连通道。“设备联网 & 长连通道建立”是消息下发的前提。上图中的“设备3”就是一个离线设备的例子。
  • d. 第三方服务器对步骤c选择出来的“在线设备”进行消息投递,投递给设备。假设消息成功下发到设备的有39.5W,这个数字我们称之为“送达设备数”。注: 有可能因为网络原因,导致消息下发不成功,比如网络闪断(从而长连通道也会断掉)。一般来说,“送达设备数”和“下发数”非常接近,一般都在98%以上。
  • e. 消息会首先送达设备,送达设备后,会根据App的包名(Android平台以包名作为App的唯一标识)路由给App,路由到App之后,终端用户就可以接收到通知消息了,由此消息推送的整个过程就算完成,上图中消息发到给“设备1”就是这样一个过程。假设成功路由到App的消息数为35W,我们称为“送达App数”。 这个过程牵涉到较多的专业术语,我们可以通过寄快递的例子来帮助大家理解这个过程: 假如你在上海要通过顺丰寄送一个快件儿北京的友盟公司,那么快件儿首先会邮递到顺丰公司在北京的总站点,之后再根据友盟公司的地址投递/路由到友盟,这样一个寄件过程就算完成了。在这里,你要寄送的快件儿就是你要发的“消息”,北京的友盟公司相当于最终“接收消息的App”,顺丰公司在北京的总站点相当于这里提到的“设备”,友盟公司的地址就相当于这个环节里面提到的“包名”。注: 消息送达设备,但最终没有成功路由到App的原因比较多,最常见的原因是App已经被删除,导致路由失败,或者在某些深度定制系统上(比如MIUI)由于做了某些限制,如ROM限制了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日活&送达率正相关

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

上述过程,我们解释了Android平台的消息送达率。对于iOS平台来说,一般来说都是走的苹果官方提供的APNs(Apple Push Notification Service)解决方案,走APNs通道,我们只能拿到“发送总数”、“接受数”、“点击数”这几个数字,其中“接受数”表示成功投递到APNs的数字,也即APNs成功接收的数字,"送达数"以及"忽略数",由于Apple没有开放对应的接口,友盟是拿不到的,所以iOS实际上是统计不了送达率的(一般我们认为成功投递到APNs之后,APNs就会成功下发)。因此,谈到消息的送达率,我们一般都是针对Android平台来说的。现在相信大家对消息推送的重要指标“送达率”有了一定的了解,我们今天的话题就到此结束了,后续会和大家分享更多消息推送相关的内容。欢迎关注我们的微博“友盟推送”来了解更多关于友盟消息推送业务的信息。   
=== 2015.12.5 更新 ===
为了帮助大家更好地理解消息投递链路的流程,以及解答大家对iOS平台推送流程的疑问,我们为大家总结了"消息推送链路投递流程",希望能帮助到大家更深入得理解消息推送投递流程。


活跃度对消息送达率的影响

活跃度对消息送达率的影响



上一篇:接收成功,却不显示通知
下一篇:java sendAndroidUnicast单推怎么给固定的客户端推


huweixiong
huweixiong 发表于 2016-5-31 10:17:15 | 显示全部楼层
送达app数,比送达设备数不等,最大原因是“应用被删除”。我现在想问,应用被删除后,是怎样跟服务器保持长链接的(我原以为一直是友盟service服务跟友盟后台来保持长链接)。

友盟PUSH
友盟PUSH 发表于 2016-6-2 11:25:16 | 显示全部楼层
huweixiong 发表于 2016-5-31 10:17
送达app数,比送达设备数不等,最大原因是“应用被删除”。我现在想问,应用被删除后,是怎样跟服务器保持 ...

pushService必须挂靠在某一个具体集成了友盟推送的App上的,如果你的App被删了,分几种情况:
1. 如果设备上只有你们的App集成了友盟推送,那么删除后,这个设备就不可能再和服务器端建立长链了。
2. 如果设备上有多个App集成了友盟推送:
  2.1 如果pushService是在你们的App头上,那么会重新触发一次选举,选择其它的App作为pushService挂靠的宿主;
  2.2 如果pushService本来就在其它App头上,那么你们App被删除了的话,长连接service不受影响


友盟PUSH
友盟PUSH 发表于 2016-9-1 09:27:10 | 显示全部楼层
skiplow 发表于 2016-8-31 18:32
在线送达率 和 通用送达率  可以在推送统计中看到吗?

通用送达率有,在线送达率这个是纯技术指标,对开发者没意义。



友盟PUSH
友盟PUSH 发表于 2016-10-27 14:59:05 | 显示全部楼层
小九 发表于 2016-10-27 14:50
关闭了通知的应用是在哪一步被去除的呢

ios的话,在投递到APNs服务器的时候就会失败;
android的话,是可以投递到设备,但是在路由到App这一步,可能会失败,这个取决于不同的ROM策略,有的ROM是允许路由,只不过通知不让展示;有的就直接拒绝路由了。

友盟PUSH
友盟PUSH 发表于 2016-10-27 15:01:13 | 显示全部楼层
skiplow 发表于 2016-8-31 18:32
在线送达率 和 通用送达率  可以在推送统计中看到吗?

通用送达率是可以看到的,报表页面有个“+”选项,点开后可以选择“发送数”,发送书就是本次发送的基数。
在线送达率,这个基本上都在96%以上,对一个纯技术指标,对开发者来说没意义不大,所以我们不会开放。

豌豆苗
豌豆苗 发表于 2016-12-11 19:29:06 | 显示全部楼层
好好!学习
wandoumiao.net豌豆苗、霍邱房产网huoqiufc.com

沉于海底的信
沉于海底的信 发表于 2017-1-5 11:29:11 | 显示全部楼层
在线送达率没什么用吗?

友盟PUSH
友盟PUSH 发表于 2017-1-8 14:30:00 | 显示全部楼层
沉于海底的信 发表于 2017-1-5 11:29
在线送达率没什么用吗?

纯技术指标,对集成友盟的开发者而言,不需要关注这个技术指标,只需要关心最终成功送达到App的比例就可以。
您需要登录后才可以发帖 登录 | 立即注册

本版积分规则

发表主题

精彩推荐

友盟启动初始化报错
版本更新后启动一直报这个错误
微信分享音乐类型失败
近期微信官方对音乐类型的分享增加了白名单限制,会导致不在白名单内的APP分享音乐类型失败 出现这种情
运行报错java.lang.NoClassDefFoundError:有人遇到过吗?
在项目中集成友盟分享功能,只加了微信、qq、微博,都是精简版。按照友盟官方的方法操作的。 签名用的友盟

关注我们

新浪微博
微信

欢迎关注友盟官方微博微信!

在线客服
返回顶部 返回列表