一、概念
1、早期推送服务
在移动互联网以前的手机,如果有事情发生要通知用户,则会弹出一个窗口,告诉用户正在发生的事,可能是未接电话提示、日历提醒或是一封彩信。推送功能最早是被用于Email中,而目前更多地被应用于App中。
2、推送
一般地,当我们开发需要和服务器交互的应用程序时,基本上都需要获取服务器端的数据,而要获取服务器上不定时更新的信息一般有两种方法:
(1)客户端pull(拉)的方式,就是隔一段时间就去服务器获取一下信息,看是否有更新的信息出现,即用户主动发起请求,向服务器获取数据;
(2)服务器使用push(推)的方式,当服务器有新信息了,就把新的信息push到客户端上,这样,客户端就能自动的接受到消息,也就是服务器主动发送数据给客户端。
比较两种方式的优缺点:
两种方式都能实现获取服务器端更新信息的功能,但明显地,push方式比pull方式好,因为pull方式更费客户端网络流量,要主动从服务器端获取最新信息,更主要的是耗费电量,App上还要有程序服务不停地检测服务端的变化。Push使用的场景有两个特点:时间不确定性和时效性,如发送团购信息/发送电子消费账单等。
一般地,利用推送只是告诉手机端服务器发生了某些改变,当客户端收到通知以后,应该主动到服务器获取最新的数据,这样才是推送服务的完整实现。
一般情况下,客户端与服务器之间通讯客户端是主动的,但这就存在一个问题就是一旦服务器数据有更新或者服务器要下发通知给客户端只能等客户端连接的时候才能实现。这种方式使消息失去了实时性。
3、通知和消息的区别
(1)通知:发送后会在系统通知栏收到展现,同时响铃或震动提醒用户。
一般地,实现Android的消息通知栏,必须要用到两个类:NotificationManager和Notification,其中NotificationManager的初始化是通过getSystemService方法,并且通过notify方法来向Android系统发送消息栏通知和显示。
(2)消息:发送后不会在系统通知栏展示,SDK将消息传给第三方应用后需要开发者自己使用代码展示。
开发者在接收到消息数据后,可以将解析出来的数据,显示在自定义的界面上,也就是说,可以自定义通知界面、提醒方式,以Notification的方式让用户看到该消息内容。
二、推送使用场景
三、原理
1、推送方案实现原理
(1)轮询方式(pull): 客户端应用程序需阶段性的与服务器进行连接并查询是否有新的消息到达,你必须自己实现与服务器之间的通信,如消息排队等,并且还要考虑轮询的效率,太慢会导致消息的延迟,太快,会大量消耗网络带宽和电池。
(2)SMS方式(push): 在Android平台上,可以通过拦截SMS消息并解析消息内容来了解服务器的意图,并获取其显示内容进行处理(???),其好处是可以实现完全的实时操作,但成本太高,需要向移动公司缴纳相应的费用。
(3)持久连接(push): 可以解决轮询问题带来的性能问题,但还是会消耗手机电池。
四、如何做好推送
消息推送(push)是APP运营最优质的渠道,运用得当可以帮助产品运营人员更高效地实现运营目标,相反盲目地push也会带来反作用。
1、APP消息推送特点
(1)量大: 用户数即时可push覆盖的数量。假如一个APP有5000万的活跃用户,且都取得了用户授权,那么全量push一个即可触及到5000万的用户,这比靠媒介传播带来的量更大。
(2)精准: 消息推送的受众已经是下载安装且使用过APP的用户,是消息推送最想影响的目标用户,相比之下其他媒介渠道则需要层层过滤才能到达目标用户。
(3)免费: 消息推送的主动权掌握在厂商自己手中,只要按照Android、iOS的协议规则去push,是不需要花任何费用的。当然免费也带来了滥用,如何控制好消息推送(push)的“度”是每个APP运营人员需要学习的一门课程。
2、消息推送对APP运营的影响
优点:
(1)提高产品用户活跃度
(2)带动功能模块使用率
据二八原则,80%的用户之后用到APP20%的功能点,而剩下80%的功能点则需要运营人员加强用户的认知度,使用消息推送则可以引导用户关注以及使用体验新功能。
(3)增加用户粘度
“粘度”是衡量用户忠诚度的重要指标,消息推送在一定程度上可以成为APP内容服务的一部分,以新闻类APP为例,对重大新闻进行第一时间push推送能够极大促进用户关注,提高用户使用率、用户忠诚度。
(4)唤醒沉睡的用户,提高用户留存率
缺点:
(1)对用户形成打扰,招致卸载
(2)用户对推送消息变得麻木
阈值理论、盲目推送用户不感兴趣的内容,等再推送有价值的内容时,用户也会视而不见。
(3)产品丧失用户信任
3、如何使用好消息推送?
(1)细分消息推送的对象,不随意push全量
标签用户或者对用户的行为数据建立用户模型,如用户特征、地域和偏好进行细化后再进行推送。
(2)尊重用户,把主动权还给用户
当用户遇到反感的消息时,应该涕送关闭消息的入口。当用户无法关闭消息时,就会卸载APP,直接导致用户流失。
(3)从用户接受信息的场景反推消息推送的时间
根据APP的特点来推送,比如天气类APP,推送时机最好为早上,抢票APP在抢票时间前推送给给用户。
(4)推送用户感兴趣的内容
永远只推送用户感兴趣,并且选择与用户心理定位相符合的内容。
(5)根据使用频次决定消息推送的频率
工具型APP用户可能每天只打开一次,而社交型APP用户只会打开20次以上,这就是产品类型决定的使用频次差别。用户心理有一个平衡值,恰到好处的消息推送频率会让用户不知不觉对APP形成依赖。
(6)后续动作:尽量引导到开APP,保持友好的用户体验
从APP厂商的角度,一切消息推送皆以用户打开APP为目的,那么用户打开时进入的是不是用户想要看到的界面?消息打开后,直接定位到该消息提示的界面。
五、几种推送方案
1、C2DM云端推送功能
Android Cloud to Device Messaging (C2DM)是一个用来帮助开发者从服务器向Android应用程序发送数据的服务。该服务提供了一个简单的、轻量级的机制,允许服务器通知移动应用程序 直接与 服务器 进行通信,以便从服务器获取应用程序更新和用户数据。C2DM服务负责处理诸如消息排队等事务并向运行于目标设备上的应用程序分发这些消息。
2、MQTT协议实现Android 推送功能
MQTT是一个轻量级的消息发布/订阅协议,它是实现基于手机客户端的消息推送服务器的理想解决方案。
(https://github.com/tokudu/AndroidPushNotificationsDemo)下载该项目的实例代码,并且可以找到一个采用PHP书写的服务器端实现(https://github.com/tokudu/PhpMQTTClient)。
3、XMPP协议实现Android推送功能
4、使用第三方推送技术,如个推、极光、百度云等第三方SDK。
六、第三方推送技术比较
(一)个推(http://docs.getui.com/pages/viewpage.action?pageId=589866)
1、概述
个推是一个端到端的推送服务,通过集成个推SDK,开发者能够及时有效地将服务端消息推送到客户端上,并针对用户画像进行精细化运营,从而积极地保持与用户的连接。
个推是国内最专业的手机消息推送技术解决方案,在第三方推送市场的占有率达90%以上。个推为企业和开发者提供推送SDK,让APP快速集成云推送功能,免去开发成本,有效提升产品活跃度和用户体验。
2、主要功能及特点
(1)个推不仅能提供云端到客户端的推送服务,也可以提供从客户端上传至云端的服务,即推送消息链路支持上下行双向通道,开发者与客户端之间互动更方便。
(2)多个APP合并一条长连接,共享链路,省电更省流量。
(3)SDK接口丰富,可以定制推送模式和通知栏提示样式,也支持增量更新。
(4)通过根据用户属性的分析建立不同标签,也可以进行A/B分组测试,从而进行精细化运营。
(5)保持与服务器的长链接,以便消息能够及时推送到客户端。
(6)提供推送管理平台,运营人员可快速操作推送;同时提供专业服务端API接口,可与自有业务系统深度结合。
智能推送 :(1)根据用户属性分析建立不同标签,帮助开发者做给予标签的精准化推送;(2)AB测试模型改进效果,推送更智能;
【可将用户分为AB两组,在小范围内进行区别推送(例如相同用户推送不同内容、不同用户推送相同内容)测试,根据数据反馈结果,选择最优推送方案】;(3)目标用户:全部、标签(地区、用户属性)、特定(cid、别名)、分组。
个性化设置: (1)根据用户自定义标签推送;(2)定时推送,让用户在适当的时候获取有价值的信息;(3)离线消息设置。
消息展示多样: (1)推送展示形式支持文本、图片、富媒体等;(2)用户点击通知后动作可多选:启动应用、打开链接、下载应用;(3)开发者可自定义消息透传模式,即可自定义消息展示界面。
稳定高效: (1)单台服务器并发支持200-400万,业内领先;(2)推送数据自主加密,安全无忧;(3)推送下发速率可达20万/秒,消息到达率96%以上;(4)专为移动设备优化,独有协议,省电省流量;(5)多个APP何必跟一条长连接,共享链路。
强大统计报表: (1)强大数据报表支撑,智能化分析推送;
功能完善 (1)增量更新,当开发者在个推后台提交APP新版本时,只需下载差量部分文件,提升用户体验与更新率;(2)推送消息链路支持上下行双向通道,云端 <==> 客户端相互推送给。
3、产品收费
4、测试APP推送
(1)每次升级clientId不变,属于通过一个用户;卸载后重新安装clientId是会重新分配,用户注册数会累加一次;
(2)在个推网站后台,推送通知,当应用程序包名,APPID等字段替换后,就可以在确认发送的界面查看当前预计用户人数为1人;
(3)有时立即推送,也会有延时,取决于???;
(4)解释一下个推后台数据统计这块:
1)推送记录:包括推送通知记录、透传消息、分组对比以及API推送记录,其中API推送记录是指使用个推API接口推送的次数;
通知记录:通知标题、推送时间、目标用户、后续动作、状态
透传消息:描述标识、推送时间、目标用户、状态 【推送内容在详情中查看】
分组对比:测试标题、推送时间、测试模式【AB属性不同、AB组接受内容不同】
2)推送数据:给出上述三种推送类型推送后,给出每条消息如下字段列表和推送转化率分析图:
百日内联网用户: 指最近三个月内有登陆过(ClientID与个推服务端建立长链接)的clientid总数
实际下发数: 实际可推送ClientId数(在消息有效期内,有联网并推送进程正常的ClientId,即消息有效期内的在线下发数。消息有效期就是设置的离线时间)
到达数: 客户端SDK接受到消息的ClientID数(通过统计客户端SDK接受到消息后的回执所得)
展示数: 用通知模板推送的通知栏消息在用户手机展示过的ClientId数(注:透传消息不是用通知形式展示,所以不计展示数)
点击数: 点击通知栏消息的Clientid数(注:透传消息不统计点击数)
3)推送统计:过去24小时以上字段的折线图,如今天8-18,则统计8-17的推送趋势图;
(5)在APP上测试的数据并不会显示在推送记录中,也就是从APP自己构建并发出的推送消息是不计入后台推送记录中的 ???
(6)推送消息后,注册过该APPID的用户都会在有效离线时长接收到推送的消息;
(7)再解释下个推后台配置管理这部分:
别名管理:你可以在后台自己添加别名,并且绑定相应的ClientID;
应用标签:应用标签只能通过用户自己设置,并调用SDK接口,在个推后台可以查看ClientID 自定义的标签;
(8)当有两台手机注册同一个APPID的个推APP时,获取的是两个不同的clientId,对应的是两个用户。
(9)一个用户别名可以被多个clientID绑定,但是该clientId之前绑定的别名就被覆盖了。
(10)一个ClientId每天只能设置一次标签。
(11)使用标签用户发送通知时,接受的用户属于标签中的一种或者全部。
测试一:
任务未成功停止时的推送转化率图(通知因延时问题未到达用户手机):
(二)极光推送
1、概述
极光推送,使得开发者可以即时即地向应用程序的用户推送通过之或者消息,与用户保持互动,从而有效地提高留存率,提升用户体验。
2、主要功能及特点
灵活的推送目标 (1)广播推送:(2)标签推送:(3)别名推送:
多种推送方式 (1)通知:推送的文本内容直接展示在用户通知栏;
(2)自定义消息:应用自己处理推送 过来的自定义消息;
(3)富媒体:推送预先编辑好的图文并茂的HTML页面内容;
灵活的推送目标 (1)广播推送:向所有的注册用户发送一条广播消息;
(2)标签推送:根据属性对用户设置标签分组,向群组用户发送;
(3)别名推送:客户端绑定用户别名,向具体的单个用户推送;
(4)多条件组合群组推送:实时筛选,实时推送;
简单易集成 (1)网站后台完成推送以及查看报表;(2)发送与查询API;
统计与报表 (1)“推送报表”与“用户统计报表”呈现推送的效果和应用发展趋势;
推送历史 (1)无论是通过Web发送还是通过API发送的都可在推送历史记录中查询
{http://docs.jpush.io/client/android_sdk/}
假设一台服务器维护10万个长连接,当有1000万用户量时,需要有多达100台的服务器来维护这些用户的长连接,这里还不算用于做备份的服务器,这将会是一个巨大的成本问题。那就需要我们尽可能提高单台服务器接入用户的量,也就是业界已经讨论很久了的 C10K 问题。
C2000K:针对这个问题,我们专门成立了一个项目,命名为C2000K,顾名思义,我们的目标是单机维持200万个长连接。最终我们采用了多消息循环、异步非阻塞的模型,在一台双核、24G内存的服务器上,实现峰值维持超过300万个长连接。
极光和个推(免费版)对比:
1、极光也有自定义消息,该消息不是通知,完全由开发者自己定义,解析收到的自定义消息后,开发者可以自定义界面显示,也可以自定义通知栏显示,并且还可以自定义收到自定义消息的后续动作。极光没有离线消息设置。
注:极光是根据获取的ACTION来判断,当用户是点击 ACTION,就在代码中做相应跳转或者打开链接,由开发人员自定义后续动作。
极光的推送对象:广播(所有人)、标签用户、设备别名、registration id
个推的推送对象:全部用户、标签用户、特定用户(别名)、分组用户(如何设置分组?)
极光有定速推送:
个推只有两种推送方式:
2、极光免费版可以在官网后台发送富媒体,富媒体是以html的形式编辑好的,也可自己修改。
个推免费版不可以发送富媒体。(个推如何推送富媒体???)
极光推送原理:
http://blog.jpush.cn/jpush_wireless_push_principle/
极光和个推两种推送技术比较:主要考虑稳定和免费
特点及功能 |
个推 |
极光 |
|
||
智能推送目标 |
(1)根据用户属性分析建立不同标签,帮助开发者做给予标签的精准化推送; (2)AB测试模型改进效果,推送更智能; 【可将用户分为AB两组,在小范围内进行区别推送(例如相同用户推送不同内容、不同用户推送相同内容)测试,根据数据反馈结果,选择最优推送方案】 (3)目标用户:全部、标签(地区、用户属性)、特定(cid、别名)、分组; (4)如果要给多个应用推送相同的内容,个推可以对应用分组,一次推送,减少重复操作。
|
(1)广播推送:向所有的注册用户发送一条广播消息; (2)标签推送:根据属性对用户设置标签分组,向群组用户发送; (3)别名推送:客户端绑定用户别名,向具体的单个用户推送; (4)多条件组合群组推送:实时筛选,实时推送; (5)目标用户:全部、标签、别名、Registration ID (Registrationid是客户端SDK第一次成功连接到Jpush服务器时,Jpush服务器给分配的。可以通过获取 RegistrationID API来获取Registrationid进行推送。Registrationid对应一个应用的一个客户端)
|
|
||
个性化设置 |
(1)推送方式:即时、定时; (2)可设置离线消息以及离线时长; |
(1)推送方式:立即、定时、定速推送; (2)可设置离线消息保留时长; |
|
||
消息展示 |
(1)推送支持文本、图片、富媒体等多种形式; (2)用户点击通知后,可自定义后续动作; (3)开发者可自定义透传消息模式; |
(1)通知:推送的文本内容直接展示在用户通知栏; (2)自定义消息:应用自己处理推送 过来的自定义消息; (3)富媒体:推送预先编辑好的图文并茂的HTML页面内容;
|
|
||
注:使用两种方式推送消息,开发者一般都是自定义消息展示方式,个推的透传消息和极光的自定义消息是完全相同的,最终是由客户端自己解析消息内容并自定义展示内容方式和后续动作的,这个特性两者并没有很大区别。
|
|
||||
数据统计 |
(1)应用的留存用户、新增用户、在线用户等核心数据一目了然; (2)推送数据、用户点击行为等推送后跟踪效果评估报告方便快捷。 |
(1)“推送报表”与“用户统计报表”呈现推送的效果和应用发展趋势。 |
|
||
注:对比了下个推后台和极光后台的数据报表,个人觉得个推的看起来更详细一些,如果我们自己有好的运营统计数据,不需要此平台上的统计数据,则两者不做比较。
|
|
||||
稳定高效 |
(1)单台服务器并发支持200-400万,业内领先; (2)推送数据自主加密,安全无忧; (3)推送下发速率可达20万/秒,消息到达率96%以上; (4)专为移动设备优化,独有协议,省电省流量; (5)多个APP何必跟一条长连接,共享链路; |
(1)针对这个问题,极光专门成立了一个项目,命名为C2000K,顾名思义,其目标是单机维持200万个长连接。 (2)采用多消息循环、异步非阻塞的模型,在一台双核、24G内存的服务器上,实现峰值维持超过300万个长连接。 (3)目前支持10亿级用户并发访问;
|
|
||
注:个推的数据是在官网上找到的,极光的数据是在其博客上查到的,具体见http://blog.jpush.cn/jpush_wireless_push_principle/
|
|
||||
收费问题 |
个推 |
极光 |
|
||
免费 |
(1)基础消息推送方式和基础数据统计报表可查看; (2)用户数有限制,累计注册用户500万以下; (3)推送速度:2万条/秒(共享); (4)支持5*8客户服务; |
(1)基础消息推送以及数据统计均可查看; (2)最大并发数,高峰期有瓶颈; (3)推送速度:20万条/秒(共享); (4)推送条数无限制; (5)不能使用用户分群推送(?); (6)离线时只能保存5条消息数; (7)仅支持网站问答和邮件技术支持; |
|
||
收费 |
(1)用户注册数无限制; (2)推送速度:10万条/秒(共享)|| 20万条/秒(独享); (3)独立推送通道、公网推送加速方案; (4)7*24专人专线服务; |
(1)最大并发数无限制; (2)推送速度:20万条/秒(独享); (3)推送条数无限制; (4)用户可分群推送; (5)专向高速推送通道; (6)离线消息可保存条数50条; (7)VIP技术支持。 |
|
||
注:1)免费版的个推和极光推送,在有多个用户接收推送消息时,有的手机可以立马收到,有的就有延迟; 2)如何保证消息能够及时推送给用户,测试较单一,网上众说纷纭,暂不比较; 3)具体应该选择哪种推送方式?其实两种推送方式在我们的开发中都只是作为一种传输数据的通道,集成均较简单,其最主要的区别是两者哪种推送的更稳定高效; 4)极光官网上的文档很全,并且有互动问答以及博客长文,但是个推官网上没有; 5)两个官网上都没有明确给出VIP收费标准,价格方面不好做参考。 |
|
问题:
1、情景一:为某房源发起优惠活动,需要将优惠活动消息推送给买房者,优惠活动的内容每次肯定会不一样,暂且称这种消息为一次性消息,那么这样的消息可以通过运营人员在后台直接发起推送吗?
2、情景二:每次业主新发布的房源信息,后台服务器如何及时推送到需要买房的用户?后台服务器是一直处于监听状态(暂且称为监听),当有新的房源信息发布(可客户端发布,可网站发布),就立即推送给买房用户,这种监听方式具体可以怎样实现,也就是怎么知道这条数据是一条新的数据(最有用的方式)?
3、情景三:天气的推送、微博@以及关注推送、QQ空间我的动态推送、用户感兴趣的新闻推送等此种形式的推送,暂且称为常态消息推送,后台服务器又是如何向客户端推送消息的?
分析:
类似在个推网站后台发送一条透传消息给 相应的用户,首先会查出所有的clientID,然后一条消息要推送给其他用户,必定是该用户和对应接受消息的用户都注册了该APP,每个手机设备对应了一个ClientID,在安装了APP后,在个推后台获得ClientID,并将该ClientID传到我们自己的服务器后台,组成映射
卖家A
首先第一步是这条房源信息会存储到我们的后台 {触发条件} ,当后台接受到该条透传信息后,在注册的所有 映射