一、APP PUSH 定义与价值
APP PUSH 定义为在手机终端锁屏状态下通知栏展示或在操作前台顶端弹出的消息通知,点击后可唤起对应的 APP,并在 APP 内跳转到指定页面。
push 消息是通知用户,引导用户参与活动、购买产品的重要手段,而且 PUSH 消息也可以引导用户查看消息,唤起 APP 提高日活,是一块重要的流量。
二、APP 推送分类
从应用的功能来划分,应用主要分为三类:
第一类是IM类APP,如微信、QQ等;
第二类是新闻资讯类,如华尔街见闻等;
其余暂归为工具类,比如支付宝、美团等。
每种类型 APP 对 PUSH 的需求也不同,IM 类 APP 追求实时、稳定的触达,此类 APP 一般通过自己的长连接进行消息推送,保证用户在收到消息的时候能够实时接收消息。另外,一些安卓厂商也会给予头部 APP 的进程一定保护,对相关的进程纳入白名单,在清理进程的时候予以忽略。
新闻资讯类的 APP 与工具类 APP 的 PUSH 推送机制基本一致,仅在频率控制上有差异,新闻资讯类由于新闻资讯较多,需要将突发新闻及时推送给用户。
由于目前工具类的 APP 占大多数,本文将主要讲解工具类 APP 的常见推送机制。
三、PUSH 流程
PUSH 消息在消息系统创建好后进入发送阶段,服务端需要根据用户终端信息进行路由,如果是 IOS 系统,那么会调用苹果自身的推送通知服务(APNs),如果用户的手机是安卓系统,那么根据不同的厂商去调用不同的厂商 SDK。
对于不同的系统版本,支持的消息展示形式也不同。比如 IOS10 之后,当 APP 在前台时,是否通知栏展示;此样式可以根据产品需求来选择,有服务端传输相应通知方式的值即可。如果用的手机非五大厂商内的手机,可以通过自己搭建的长连接或者使用第三方服务进行推送。
如果不是自己直接对接厂商通道,那么内部的服务端可能无需做过多复杂繁琐的开发工作,通过接入第三方消息推送平台来实现消息的推送,比如信鸽、个推等。多数的通道会将消息是否成功推送到客户端 SDK 的回执数据反馈给发送方,需要提供回调地址。
四、底层通道说明
1、推送方式
通道类型一般分为三类:厂商通道、第三方推送服务平台、长连接。
厂商通道是手机终端厂商推出的推送服务,通过接入厂商SDK,内部服务端可以将消息推送到手机系统的服务端,再下发至客户端内部的厂商SDK,由操作系统进行相应展示,点击后唤起相应APP,这样可以避免APP进程被杀死后消息无法触达用户,因此触达率较高。
第三方推送平台是推送服务公司搭建相关的消息服务。并且各个APP使用了同一个平台的推送服务时,客户端都是集成同一个第三方推送平台的SDK,因此形成了一个推送联盟,当联盟中的其中一个APP的消息进程没有被杀死的时候,其他的APP也可以利用进行通知用户,形成了相互唤起,提高触达率。经过一些场景的测试,相互唤起的成功率并不是很高,需谨慎结合自身场景评估。为了提高触达率,第三方推送平台也会集成各大厂商的SDK进行推送。
长连接就是建立手机与服务端的一条链路进行消息数据推送,通过长连接也可以进行APP状态监控,但完全由长连接推送且保证触达的稳定,需要投入的研发资源较多,且需尽量避免自己的长连接进程不要被操作系统杀死。
2、优劣势对比
APP push 功能的搭建需要依据产品自身的情况和公司可投入的资源成本为主,在不同的阶段选择不同的方式。
五、下发推送
1、推送账号
推送时客户端的 PUSH SDK 均会根据用户的设备号生成一个对应关系的 TOKEN。在 SDK 内部,如果使用的是第三方推送服务,则去第三方的 SDK 注册;如果是厂商,则去商城 SDK 注册;如果使用自己长连接,则去自己的 SDK 进行注册,作为后续推送的标识用户的唯一 ID。
2、消息路由
消息路由见上述推送流程的讲解,此处主要讲解根据不同的业务场景,可能会定向推送给不同版本 APP 的用户。因此服务端在通道能力路由的时候,不仅需要能够区分通道,还要进一步能够针对用户的手机终端进行更加精细化的差异推送。
此外,消息通道并不一定是 100%稳定,如果下游通道出现问题,服务端需能够将由于通道问题导致的消息路由到备用通道去发送,以保证业务的稳定触达。
3、全量推送
一般来说,对于公司内部运营或公司的相关数据均是以产品的 customer id 为准,用户数据系统对接消息系统时也多为 customer id,因此需建立 customer id 与推送 TOKEN 的关系,便于运营针对用户进行推送。但对于一些场景会需要针对未登录的用户也进行推送,即全量推送;比如突发重大新闻资讯、大促等活动,所以运营系统需要提供全量推送功能,针对所有 TOKEN 进行推送。
六、数据上报
上报数据包括触达点击关闭退出注册等数据:
对于所有方式的触达消息,都离不开触达与点击,触达的数据通过厂商的需要回调上报,点击数据可以由SDK上报服务端。对于push的关闭,也需要进行考量,评估push是否过度发送,打扰到了用户。
关闭数据有两部分,一部分为app内部的关闭,sdk直接上报给服务端即可;另一部分为用户在手机操作系统上关闭了对应app的push,需要APP在前台时,sdk调用手机终端相关方法获取该用户是否关闭了系统通知,然后上报至服务端。
注册数据即用户首次启动APP时,去相关sdk注册token。一般来说,用户退出账号时,sdk需要上报服务端,解除token与customer id的绑定关系。
七、PUSH 特点
1、强提醒不留痕
push 由于是 app 自己的通知渠道,是运营的一个重要工具。如果用户未关闭 PUSH 通知的话,push 可以从通知栏弹出进行消息显示,具有一定的强提醒性,但 PUSH 点击跳转后便消失,没有痕迹,因此针对于重点的通知消息,需要在 APP 内设置消息中心,在 PUSH 的同时留下通知记录。
2、消息样式
对于各家 PUSH 来说,一些营销消息会加入 EMOJI 表情来吸引用户点击,这也是一个吸引用户点击的一个小方法,只要服务支持传输约定好的 EMOJI 码就可以了。目前安卓系统也支持富媒体推送,推送包含图片、语音等形式,对于资讯类的 APP 可以增加缩略图,吸引用户点击。目前来看,语音场景还有待挖掘。
3、 IOS 和安卓
由于 APP 基于手机操作系统,因此对于 IOS 和安卓的推送的流程及功能基本相同,只不过细节和方法上略有不同,且国内安卓产商都在安卓系统上进行了一定改造,导致国内安卓厂商标准各不相同,需要开发同学仔细对接各个厂商。
八、触达率的提升
触达率提升需要从消息创建到实际通知再到用户来建立一个完整流程,细化每一个交互环节,发现影响触达率的主要瓶颈,并针对性地进行解决或优化方案。除此之外,未采用厂商通道的消息也可以采用自己的长连接和其他推送平台服务同时多条推送,在客户端的 SDK 内增加针对同一流水号的去重,这样可以也可以提高一部分消息的触达率。
以上内容为个人经验总结,欢迎讨论指正。
评论