本文大纲
本文从为什么做通知提醒， 以及如何设计通知提醒， 以及如何衡量通知提醒三方面解释了如何设计通知提醒。
对于重点的如何设计通知提醒， 通过拆分前台和后台， 前台采用自建或者二方通道， 后台采用厂商信令通道以及厂商代理通道的方式达到目的。
背景/为什么做
作为即时通讯产品， 实现通知提醒有基本的两方面的目的。 业务目的和产品目的
- 业务目的： 提升DAU（促进用户活跃）， 提升业务的转化率（如电商的商家营销消息）。
- 产品目的： 对于消息的接收方而言， 可以及时的接收对方消息。 对于消息的发送方而言， 消息可以及时的被回应。一个词总结： 及时触达
通知提醒的产品形态
- 产品位于前台时， 可以采取通知栏提醒或者应用内提醒的方式
- 产品位于后台时， 采取通知栏提醒的方式
通知提醒的技术形态
通知提醒， 按照App的活跃状态， 区分为前台提醒和后台提醒。
- 前台提醒： 即用户在app打开当前情况下， 有新消息时， 及时的弹出来通知用户（采用通知栏提醒或者应用内提醒）。
- 后台提醒： 用户来了新消息， 在app没有打开的情况下， 将通知展示给用户（通知栏提醒）。
如何设计
从通知的角度看， 一次通知提醒， 划分为以下的几个阶段： 准备发送， 实际发送， 应用到达， 弹窗， 点击/移除/其他。
如何设计前台提醒
消息业务的前台提醒， 可以直接采取系统对接发送推送（包含系统的通知通道，以及三方实现的长连接通道）或者基于端侧消息长连接实现的端侧通知。
前台通知， 一般从业务成本的角度考虑， 会采用二方通道或者自建长连接通道IM的方式接入。
基于端侧消息长连接实现
前台基于长连接做IM的新消息处理。 在新消息处于完成后。 IM的通知模块作为新消息的消费方对接即可。
如何设计后台提醒
后台提醒是用户来了新消息， 在app没有打开的情况下， 将通知展示给用户。设计后台提醒， 需要考虑到app的进程没有此时并没没有存活。 因而要么借助系统进行弹窗（厂商代理通道）， 要么将进程唤起， App的进程做处理后前台弹窗（后台转为类前台， 厂商信令通道）。
厂商代理通道
厂商代理通道， 即厂商代理了消息通知的实际发送发送阶段，以及 弹窗， 点击/移除阶段。 及时通讯系统可以控制的是， 准备发送的消息通知， 以及用户点击后+移除后的行为。 中间阶段均为厂商控制。
国内的小米， Oppo， VIVO， 华为等厂商支持的厂商代理通道， Google的GCM/FCM支持代理通道。
厂商信令通道
厂商信令通道， 即厂商支持发送一条消息通知的信令， 然后厂商将app的进程唤起，App的进程做处理后前台弹窗。即时通讯系统可以控制的是， 准备发送的消息通知， App内收到的唤醒通知， 实际发送量， 弹窗， 点击/移除/其他等均可以控制。
国内的厂商是否支持信令通道的通知， 没有做研究， GCM/FCM是支持信令通道的方式。
整体的方案
通常从成本的考虑而言， 会采取以下措施：
前台时，采用自己的长连接做基础的通知提醒；
后台时， 采用厂商的信令通道+厂商代理通知。
国内三方的推送解决方案
极光推送
个推
信鸽
如何衡量做的好坏
站在通知的角度划分， 准备发送， 实际发送， 应用到达， 弹窗， 点击/移除/其他， 作为主要的依据衡量消息通知链路的数据。 按照PV（量）/UV（用户）的视角查看。
技术指标：
送到率 = 应用到达/准备发送的量
展示率/弹窗率 = 弹窗的量/应用送达的量
点击率 = 点击量/弹窗的量
辅助指标：
通知栏打开率 = 用户打开的UV/打开App的UV
总结
本文从为什么做通知提醒， 以及如何设计通知提醒， 以及如何衡量通知提醒三方面解释了如何设计通知提醒。
对于重点的如何设计通知提醒， 通过拆分前台和后台， 前台采用自建或者二方通道， 后台采用厂商信令通道以及厂商代理通道的方式达到目的。
