IM即时通讯-7-如何设计通知提醒

本文大纲

本文从为什么做通知提醒， 以及如何设计通知提醒， 以及如何衡量通知提醒三方面解释了如何设计通知提醒。
对于重点的如何设计通知提醒， 通过拆分前台和后台， 前台采用自建或者二方通道， 后台采用厂商信令通道以及厂商代理通道的方式达到目的。

背景/为什么做

作为即时通讯产品， 实现通知提醒有基本的两方面的目的。 业务目的和产品目的

1. 业务目的： 提升DAU（促进用户活跃）， 提升业务的转化率（如电商的商家营销消息）。
2. 产品目的： 对于消息的接收方而言， 可以及时的接收对方消息。 对于消息的发送方而言， 消息可以及时的被回应。一个词总结： 及时触达

通知提醒的产品形态

1. 产品位于前台时， 可以采取通知栏提醒或者应用内提醒的方式
2. 产品位于后台时， 采取通知栏提醒的方式

通知提醒的技术形态

通知提醒， 按照App的活跃状态， 区分为前台提醒和后台提醒。

1. 前台提醒： 即用户在app打开当前情况下， 有新消息时， 及时的弹出来通知用户（采用通知栏提醒或者应用内提醒）。
2. 后台提醒： 用户来了新消息， 在app没有打开的情况下， 将通知展示给用户（通知栏提醒）。

如何设计

从通知的角度看， 一次通知提醒， 划分为以下的几个阶段： 准备发送， 实际发送， 应用到达， 弹窗， 点击/移除/其他。

如何设计前台提醒

消息业务的前台提醒， 可以直接采取系统对接发送推送（包含系统的通知通道，以及三方实现的长连接通道）或者基于端侧消息长连接实现的端侧通知。

前台通知， 一般从业务成本的角度考虑， 会采用二方通道或者自建长连接通道IM的方式接入。

基于端侧消息长连接实现

前台基于长连接做IM的新消息处理。 在新消息处于完成后。 IM的通知模块作为新消息的消费方对接即可。

如何设计后台提醒

后台提醒是用户来了新消息， 在app没有打开的情况下， 将通知展示给用户。设计后台提醒， 需要考虑到app的进程没有此时并没没有存活。 因而要么借助系统进行弹窗（厂商代理通道）， 要么将进程唤起， App的进程做处理后前台弹窗（后台转为类前台， 厂商信令通道）。

厂商代理通道

厂商代理通道， 即厂商代理了消息通知的实际发送发送阶段，以及 弹窗， 点击/移除阶段。 及时通讯系统可以控制的是， 准备发送的消息通知， 以及用户点击后+移除后的行为。 中间阶段均为厂商控制。

国内的小米， Oppo， VIVO， 华为等厂商支持的厂商代理通道， Google的GCM/FCM支持代理通道。

厂商信令通道

厂商信令通道， 即厂商支持发送一条消息通知的信令， 然后厂商将app的进程唤起，App的进程做处理后前台弹窗。即时通讯系统可以控制的是， 准备发送的消息通知， App内收到的唤醒通知， 实际发送量， 弹窗， 点击/移除/其他等均可以控制。

国内的厂商是否支持信令通道的通知， 没有做研究， GCM/FCM是支持信令通道的方式。

整体的方案

通常从成本的考虑而言， 会采取以下措施：
前台时，采用自己的长连接做基础的通知提醒；
后台时， 采用厂商的信令通道+厂商代理通知。

国内三方的推送解决方案

极光推送
个推
信鸽

如何衡量做的好坏

站在通知的角度划分， 准备发送， 实际发送， 应用到达， 弹窗， 点击/移除/其他， 作为主要的依据衡量消息通知链路的数据。 按照PV（量）/UV（用户）的视角查看。

技术指标：
送到率 = 应用到达/准备发送的量
展示率/弹窗率 = 弹窗的量/应用送达的量
点击率 = 点击量/弹窗的量

辅助指标：
通知栏打开率 = 用户打开的UV/打开App的UV

总结

本文从为什么做通知提醒， 以及如何设计通知提醒， 以及如何衡量通知提醒三方面解释了如何设计通知提醒。
对于重点的如何设计通知提醒， 通过拆分前台和后台， 前台采用自建或者二方通道， 后台采用厂商信令通道以及厂商代理通道的方式达到目的。