Android平台消息收到数变少的原因?
最新资讯 • U-Push
69399
2019-3-14
摘要:
发现连续两条或者前后几条推送任务的统计结果有较大的变化,一般都可以从以下几个方面来分析

注: 本帖仅针对Android平台

在日常的产品运营中,友盟推送君经常能接到客户反馈“Android推送收到数变少”,一般情况下都是和之前的消息记录做对比,发现连续两条或者前后几条推送任务的统计结果有较大的变化,一般都可以从以下几个方面来分析:

1. 首先要确认消息是否已经过了有效期,如果还没有过了有效期,那么请在有效期过了之后再做对比。因为在整个消息有效期内,离线消息还是有可能不断下发的,所以统计数据是会一直增加的。 此外,我们的SDK为了保证数据的完整性,在网络不好的情况下对请求失败的日志会做缓存处理,待设备下次联网的时候再重新发送统计日志,所以日志会存在延迟发送的情况。一般情况下,等到消息过了有效期之后,数据基本已经稳定了,这个时候得到的统计数据可以认为是最终的结果。

2. 如果消息已经过了有效期,发现前后两条消息的任务在统计指标上有较大出入,那么需要确认前后两条消息的有效期设置的是否一致。这种情况比较多见,比如设置12H和24H的有效期,消息下发数以及送达App数肯定是不一样的。消息有效期越长,消息收到数会越多。

3. 在“浅谈消息推送的送达率”的帖子中,我们给大家普及过送达率的概念,当时提出过一个非常核心的点,就是消息的送达率和App自身的日活是正相关的,即App自身日活基数比较大,那么实际触达的消息也会比较多,反之亦然。 友盟推送(也是第三方推送)的作用就是利用联盟互保的优势,在App自身日活比例的基础上,进一步提升App的送达率。所以如果近一段时间内,消息的送达数有持续下降趋势的话,或者前后两次发消息间隔比较长的话,那么建议开发者需要对照自身App的日活数据看看,看是否存在App自身日活下降的趋势,如果是的话,证明活跃用户比例在减少,那么相应的,推送的送达数也会呈现一个下降的趋势。(小tip: 可以在友盟统计平台或者其它第三方统计平台来查看App自身的日活变化)。 

在实际运营中,我们碰到过不少这样的例子,举几个例子给开发者分享:

案例1: 某动漫类App反馈从9月份起,消息送达数相比8月份,逐步降低。我们协助开发者分析下来,原来是该App的群体主要是学生,7,8月份暑假期间正是该App的活跃期,9月份开学了,该App的活跃数量会有一个非常大的折损,所以消息推送收到数的趋势也跟着下来了。

案例2: 某装修类App反馈1月份起,消息送达数相比12,11月份下降了挺多。根据我们的经验,我们第一时间先让开发者查看App自身的日活是不是有明显下降,据该App反馈,过年期间,是装修市场比较冷淡的时期,用户使用频度非常低,进一步印证了消息送达率和DAU的正相关性。

案例3: 某O2O类App反馈上个月每条广播(即发送给所有人)消息的收到数一直维持在3000左右,最近一周跌倒了1000多。对照DAU趋势分析下来,原来是该电商App上个月刚上线的时候做过较大力度的推广,不过用户质量较差,基本上使用1、2次之后就不再使用了,并不是真实有效的用户。所以拉新活动一停,DAU就会出现大幅度的跌落。

4. 在case 3中提到的“送达率”文章里面,我们给大家解释过友盟推送的作用是利用App互保联盟的作用,来进一步提升App的送达率。那么联盟的作用是什么呢? 简单地讲,假如设备上有A、B、C 3个集成了友盟推送SDK的App,那么我们可以通过技术手段,保证A、B、C这3个App中有一个打开过成为活跃App,那么就可以保证其他两个App(即使没有打开过)的消息也能借助这个打开过的App的通道做下发

但是联盟互保的技术手段目前在国内的Android厂商上(比如小米、华为)越来越受限制,厂商会基于耗电或者流量考虑,会对这种App之间的保活机制做禁用,如图例中的右图所示,这样会导致联盟的效果打折扣,进而会影响送达率以及消息收到数减少。一般来说,厂商发布新的系统,或者发布新的build号的时候,若新ROM系统或者新build号对消息互保拉活机制做了限制,那么就无法再借用联盟互保的通道来下发消息,像华为新的系统上,还会显式在系统通知栏弹出“已禁止XXX App启动XXX App”来提醒终端用户,这种情况也会导致消息的收到数变少,所以这种情况总结下来,就是厂商ROM对于消息推送SDK互保机制的限制会导致消息收到数减少,且一个不可避免的趋势是,越来越多的国内厂商采用了这种策略,所以消息的收到数以及送达率是会逐步下降的。

【延伸】: 基于case 4,我们可以把话题再延伸一下,开发者一定会问到,如果厂商ROM对这种能大幅提升消息送达率的互保机制做了限制之后,那么这些特殊机型上是否有办法保证消息的送达呢?目前在技术层面上,的确是没有办法绕过厂商的限制,并且我们作为平台服务提供商,也尊重厂商的策略。要想保证在这些特殊机型上的消息的送达率,我们建议开发者可以采用聚合的解决方案(其实已经有不少开发者采用了这个方案),同时集成友盟SDK和厂商的SDK,服务器端在下发的时候可以做判断,如果设备机型是某个特殊厂商的,那么走厂商的通道,其它情况下,仍然走友盟的通道,这样就可以保证一个较高的整体送达率。当然友盟自身也为商业付费客户提供了这样的聚合解决方案,由友盟完全托管厂商的推送,开发者只需要对接友盟一个接入方就行,目前友盟推送提供了小米+华为的系统通道。如果开发者使用的刚好是这个聚合解决方案,消息收到数减少还有一个原因,就是可能厂商的推送系统不提供消息回执统计数据,比如华为系统目前就不提供消息回执数据,所以如果是通过华为厂商通道下发的话,这部分的消息送达量是统计不到的。

5. 最后一种情况,可能是开发者新上线的版本集成Push有问题导致的,这种情况虽然不多,但是我们的确也碰到过几次。一般表现是App的DAU看起来也正常,消息的收到数可能从App发新版本之日起,就开始逐步下降。有可能是开发者发新版的时候,集成Push SDK有问题导致的,比如把Push的初始化代码给注释掉了(可能调试阶段调试某个问题的时候注释掉的),或者是打包的时候漏掉了推送的一些资源文件,还有一种可能性是升级Push SDK新版本的时候,没有按照新版的集成文档来升级,漏掉了一些升级点,比如混淆文件漏掉了某个类。所以如果开发者碰到的是这种情况,不妨先排查一下线上的版本推送功能是否正常,包括是否能收到推送消息,是否正常回传日志等(可以通过抓包的方法来查看)。

U-Push官网