APP消息推送方案调研

1. 背景

目前行业内有多家消息推送服务供应商，且各家都宣称自家产品的核心指标行业领先。为了不被各家推送厂商忽悠，量化消息推送到达率效果，我们需要整理设计一套消息推送服务对比量化方案，一切以线上实测数据为准，通过线上到达率数据进行效果评判。

当前很多推送服务商宣称自家产品的到达率在90%以上，其实这是厂商玩了一个模糊概念的把戏。厂商所指的到达率是在线到达率，即应用在线，有长连接情况下消息送达的比率，但我们其实更关注“无论应用是否开启的情况下，App整体的消息送达率情况”。

2. 厂商选择

2.1 个推

个推目前来说算是业内市场占有率的领头羊，积累了一批标杆客户。不过实际上也并没有看上去这么美好。个推官网一直将新浪微博放在显眼位置作为标杆客户展示，但反编译微博APK发现并没有集成个推的服务。考虑到它的占有率，作为第一个评测对象。

2.1 极光推送

极光也是推送领域较早的厂商，不过从放出来的文档和社区里的口碑看似乎不是很理想，考虑到他家的占有率也比较高，作为我们的第二个测试对象。

3.3 阿里推送

阿里推送是最近看知乎发现的，主要的优点是背靠阿里这颗大树，像手淘、支付宝等一类大的App的消息转发能提升到达率，所以这里也作为评测对象.

其他的厂商如信鸽、百度云推送大家也可以纳入评测范围，而比如小米、华为这类厂商，主要是针对自己的机型提供的推送通道，不少推送厂商已经做了集成，比如阿里推送就有辅助通道的概念，可以集成小米、华为推送，这里就不作为单独的推送厂商进行评测了。

3. 对比方案

方案的核心思想虽然简单，不过怎么对比还是有讲究的，如果对比策略没有全盘考虑到各种场景以及各家SDK之间的相互影响，测试数据的真实性和客观性就会大打折扣。

所以，在踩过很多坑后，我们终于总结出了两套可行的对比策略:分时测试和分组测试。

3.1 分时测试

同时集成多家推送，在一个测试周期（如一周）内只测试一款推送产品（各家SDK为提升到达率均作了进程保活工作，另外推送会尝试唤醒进程，导致先后测试的不同厂商的推送效果数据被污染，所以不能在同一测试周期内同时测试不同推送服务），终端和服务端在不同推送周期间动态切换推送通道，测试架构可参考下图：

3.2 分组测试

同时集成多家推送产品，将线上终端进行分组（每个厂商对应一个分组，确保分组的终端总量基本一致），不同组别的终端连接不同推送服务。同一测试时间点向各个分组进行消息推送，比较各组推送到达率。测试架构可参考下图:

3.3 分时测试示例

3.3.1 制定测试周期

以个推，极光推送，阿里推送为例，可以以一周为测试周期进行测试，即第一周测试个推，第二周测试极光推送，第三周测试阿里推送。

关键点：
- 单一测试周期内终端只开启单个推送服务(如第一周只启动个推)，其他推送服务不启动。这是为了避免各家推送SDK相互干扰；
- 测试周期不能过短。一方面在测试周期内多测试几次全推可以增加测试样本，避免噪声干扰，另一方面推送服务的切换并非即时生效，测试周期过短会因切换时间与测试周期占比过大而污染测试数据。单个测试周期建议在一周以上，另外在两个测试周期之间预留出2-3天的切换时间；

3.3.2 向对应推送服务商推送消息

根据制定的推送周期表向对应的推送服务商推送消息。

关键点:
- 向各家推送服务商推送消息的策略要保持一致。比较建议通过全量推送来进行测试，并保持消息离线缓存的时间一致；
- 推送的到达率还与App的活跃度有关，比如雪球这类App在股市开盘时的到达率肯定高于其他时间段（因为用户都在线，更容易送达），所以得确保几个厂商的推送测试应该是在相同的时间点，即相同的App活跃度的场景下进行推送；
- 为避免噪音数据干扰，推送的目标设备量一定要大，最好是全量推送，建议底限样本数在10w。
- 为了避免测试用的推送信息给用户带来困扰，需要在终端收到消息回调的时候透明处理该消息，避免终端用户感知；

3.3.3 获取推送总量

通过服务商提供的接口可以获取实际发送数量，但为了保证数据的客观一致性（避免厂商统计数据带来的影响），在采用全量推的场景下我们可以用App本身的装机量或月活作为统一的基数，简单的形容即“我有这么多设备，看谁送达的多”。

极光推送	个推推送	阿里推送
send_a	send_b	send_c

采用相同基数如装机量或月活的情况下，send_a == send_b == send_c。

3.3.4 上报到达消息

在终端上通过各推送SDK提供的消息回调函数将到达消息事件上报统计服务器（携带推送渠道标识），统计服务器做汇总统计。

3.3.5 生成对比数据报告

服务端将客户端上报的到达消息根据推送渠道标识进行聚合，最终得到各自渠道的实际到达总数:

极光推送	个推推送	阿里推送
arrive_a	arrive_b	arrive_c

根据实际发送总数和App装机量或月活计算到达率:

极光推送	个推推送	阿里推送
arrive_a / send_a	arrive_b / send_b	arrive_c / send_c

4. 测试结果

我们采用了分时推送的方式，每个服务商测试周期为一周，每天进行早晚两次全量测试推送，分母基数选取我们App的月活数据，对比数据如下（送达率均值）：

极光推送	个推推送	阿里推送
22%	25%	31%

欢迎大家留言提供下各自评测的结果数据。

附录: 推送服务接入文档

集成推送服务是个体力活，有时集成一家推送就得折腾半天，更别说同时集成好几家推送了。顺便吐槽下，有些推送厂商的集成文档杂乱无章，找个demo或者SDK的下载地址都得找半天。这里给大家整理了极光推送，个推以及阿里推送服务接入流程，如果还有接入其他推送服务的需求，可自行到相关网站参考接入文档。

1 个推

1.1 创建账号

创建个推开发者账号，请访问个推开发者平台，申请个推帐号，如下图所示：

1.2 创建应用

请登录 http://dev.getui.com ，选择登记应用并填写应用名称和包名信息，完成应用创建：

点击应用配置，获取到相应的AppID、AppKey、AppSecret信息：

1.3 Android SDK集成

个推推送支持通过maven库自动集成:个推快速集成，需要手动集成的用户请参考：Android Studio标准集成

1.4 iOS SDK集成

个推推送 iOS SDK接入请参考:http://docs.getui.com/mobile/ios/overview/

1.5 服务端 SDK集成

个推推送支持多种语言以及REST API方式，请参考:Server SDK接入

2 极光推送

2.1 创建账号

要创建极光推送开发者帐号，请访问极光推送官方网站

2.2 创建应用

使用注册账号登陆，进入极光控制台后，点击“创建应用”按钮。创建帐号进入极光推送后，首先显示的是创建应用的界面。填上你的应用程序的名称，注册Android服务需要填入包名，注册iOS服务需要上传APNs证书以及填写相关密码

2.3 Android SDK集成

极光支持通过jcenter自动集成，接入及调试方法请参考：极光推送Android SDK接入指南

2.4 iOS SDK集成

极光推送 iOS SDK接入请参考:https://docs.jiguang.cn/jpush/client/iOS/ios_guide_new/

2.5 服务端 SDK集成

极光推送服务端提供REST API，同时也提供各种语言的SDK，Java SDK集成请参考:JPush Server Library

3. 阿里推送

3.1 创建账号

登陆阿里云官网，注册阿里云开发者账号。

3.2 创建应用

到阿里推送控制台创建应用，应用创建完成以后，进入移动推送相关模块进行设置，具体操作请参见创建APP。

在应用中完成应用配置，请注意PackageName务必和App的包名一致，否则推送将无法正确初始化。
查看AndroidManifest.xml中根元素package属性；
查看工程build.gradle中applicationId设置，默认AndroidManifest.xml中的package属性保持一致，如果不一致，以applicationId为准

3.3 Android SDK集成

阿里推送Android SDK请参考:Android SDK配置

3.4 iOS SDK集成

阿里推送iOS SDK接入请参考：
https://help.aliyun.com/document_detail/30072.html?spm=5176.doc30071.6.646.3sE4BH

3.5 服务端 SDK集成

阿里推送服务端支持持多种语言以及REST API方式，接入指南请参考：https://help.aliyun.com/document_detail/30074.html?spm=5176.doc30064.6.556.kVH9cK