APP消息推送:推14万,打开147个

题主挖了一个好深的坑啊。鉴于你说的这种情况,14W用户,最终只有147个点击用户,结论只有一个: 统计部分的逻辑或者代码有bug,其它原因想都不用去想了。友盟+消息推送作为一个第三方推送服务提供商,可以给你说说整个链路的数据流向: APP消息推送:推14万,打开147个

【APP消息推送:推14万,打开147个】 发送总数: 表示当次发送任务覆盖的总设备数,这个定义是站在开发者的角度来定义的。比如: App的总安装数是100W,如果发送任务是发送到“所有人”,那么“发送总数”就是100W。
有效设备: 友盟平台会基于“发送总数”,把无效设备剔除掉。 无效设备主要包括: 卸载App的设备,以及token发生过变化的设备(比如卸载重装,新的token生效,旧的token就失效了)。“有效设备”是友盟推送平台认为的“发送总数”。一般来说,“有效设备”是接近“发送总数”的,前提是友盟推送平台会定期从数据库清理掉无效设备,尽可能保证库里的设备有效。
服务器推送设备: 基于“有效设备”的基础上,服务器端会探测设备是否与服务器端建立了长连接。消息能够顺利下发到设备的前提是设备与服务器端建立好稳定的长连接通道。对于建立长连接的设备,服务器端会将消息推送下去,这个数字我们称为“服务器推送设备”,是从服务器的角度来定义的。
设备送达: 在”服务器端推送设备”的基础上,成功送达到设备的数量。一般有可能由于网络原因,或者客户端的原因,导致服务器在下发的瞬间,长连接状态发生变化,导致发送失败。这种情况下,友盟平台是会重复投递,保证消息的可靠性。理论上,“设备送达”是无限逼近“服务器推送设备”。
App送达: 在“设备送达”的基础上,消息还需要一定的机制路由到正确的App上。在Android原生系统上,设备送达后,就可以保证App送达。但是在一些定制系统上,有可能“路由”这个事件被disable掉。 比如MIUI在App没有启动过的情况下,路由是不work的(但是只要有App启动过,还是可以通过友盟的互保联盟来保证消息路由成功的)。“App送达”后,才表示一个完整的消息投递流程结束。
消息点击: 在“App送达”的基础上,表示消息点击的数量。
消息忽略: 在“App送达”的基础上,表示消息被忽略的数量。
题主的问题中,14W对应的是“发送总数”,147对应的是“消息点击”。 一般“App送达”在“发送总数”的比例基本上是和App DAU的比例正相关的。 这么低的点击率,一般可以认为就是在消息统计环节有bug导致的。最后,你可以关注和了解友盟+消息推送(友盟消息推送|app推送), 使用一段时间后,相信你会对消息的送达率、点击率有更多sense,我们的论坛也有不少数据运营方面的汇总帖: 友盟消息推送常见问题索引(开发者必读)_U盟友盟消息推送论坛 ,欢迎查阅。官方微博账号: http://weibo.com/umengpush
■网友
首先,安卓的送达率太低。如果你的app下载量达到数百万的话,那么我们可以说你的发送总数应该与你的App安装量至少保持在一个量级的。你说的14w 送达数,这个数据表达的就比较模糊了,因为不确定你们平台具体统计的是那个数值(建议你应该和你们技术同事确认一下,你们统计的的送达数具体是什么),我暂且把他理解为通知在通知栏被展示出来的数量,也就是上面说的App 送达数。
接下来,就Android平台来说,按照你所说的,你们的用户量有260万,而送达数只有900。 这个问题首先很大的可能是你们的统计环节存在bug。 另外,很重要的一点,Android的推送靠的是长连接,只有长连接存活才能收到消息,长连接越稳定,送达率越高。这也就是目前业内一些做第三方推送服务的优势所在了。比如你提到的友盟推送,他很大的优势就是他们采用的是多路复用机制,也就是靠宿主App去维持长链接,也可以理解为,任何一个集成过友盟推送的App打开都能够拉起长连接,保证你的应用即使没打开,或者被杀死,也是能够成功下发消息的。而友盟推送具备一个非常大的互保联盟,包括淘宝系,友盟系,UC系,各个系内部是可以唤醒的,系与系之间是通道层面共享的,这样就大大提高了消息的送达率。最后补充一点,目前轮询技术已经属于一个比较低端的技术了,效率很低,又费电,又费流量。所以建议你们可以切换第三方推送,否则没有技术层面上的支持你的运营功力再厉害用户是看不到的。


推荐阅读