1. 背景
目前行业内有多家消息推送服务供应商,且各家都宣称自家产品的核心指标行业领先。为了不被各家推送厂商忽悠,量化消息推送到达率效果,我们需要整理设计一套消息推送服务对比量化方案
,一切以线上实测数据为准,通过线上到达率数据进行效果评判。
当前很多推送服务商宣称自家产品的到达率在90%以上,其实这是厂商玩了一个模糊概念的把戏。厂商所指的到达率是在线到达率,即应用在线,有长连接情况下消息送达的比率,但我们其实更关注“无论应用是否开启的情况下,App整体的消息送达率情况”。
2. 厂商选择
2.1 个推
个推目前来说算是业内市场占有率的领头羊,积累了一批标杆客户。不过实际上也并没有看上去这么美好。个推官网一直将新浪微博放在显眼位置作为标杆客户展示,但反编译微博APK发现并没有集成个推的服务。考虑到它的占有率,作为第一个评测对象。
2.1 极光推送
极光也是推送领域较早的厂商,不过从放出来的文档和社区里的口碑看似乎不是很理想,考虑到他家的占有率也比较高,作为我们的第二个测试对象。
3.3 阿里推送
阿里推送是最近看知乎发现的,主要的优点是背靠阿里这颗大树,像手淘、支付宝等一类大的App的消息转发能提升到达率,所以这里也作为评测对象.
其他的厂商如信鸽、百度云推送大家也可以纳入评测范围,而比如小米、华为这类厂商,主要是针对自己的机型提供的推送通道,不少推送厂商已经做了集成,比如阿里推送就有辅助通道的概念,可以集成小米、华为推送,这里就不作为单独的推送厂商进行评测了。
3. 对比方案
方案的核心思想虽然简单,不过怎么对比还是有讲究的,如果对比策略没有全盘考虑到各种场景以及各家SDK之间的相互影响,测试数据的真实性和客观性就会大打折扣。
所以,在踩过很多坑后,我们终于总结出了两套可行的对比策略:分时测试
和分组测试
。
3.1 分时测试
同时集成多家推送,在一个测试周期(如一周)内只测试一款推送产品(各家SDK为提升到达率均作了进程保活工作,另外推送会尝试唤醒进程,导致先后测试的不同厂商的推送效果数据被污染,所以不能在同一测试周期内同时测试不同推送服务),终端和服务端在不同推送周期间动态切换推送通道,测试架构可参考下图:
3.2 分组测试
同时集成多家推送产品,将线上终端进行分组(每个厂商对应一个分组,确保分组的终端总量基本一致),不同组别的终端连接不同推送服务。同一测试时间点向各个分组进行消息推送,比较各组推送到达率。测试架构可参考下图:
3.3 分时测试示例
3.3.1 制定测试周期
以个推,极光推送,阿里推送为例,可以以一周为测试周期进行测试,即第一周测试个推,第二周测试极光推送,第三周测试阿里推送。
关键点:
- 单一测试周期内终端只开启单个