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

本文大纲

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

背景/为什么做

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

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

通知提醒的产品形态

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

通知提醒的技术形态

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

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

如何设计

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

如何设计前台提醒

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

IM即时通讯-7-如何设计通知提醒_第1张图片
前台通知, 一般从业务成本的角度考虑, 会采用二方通道或者自建长连接通道IM的方式接入。

基于端侧消息长连接实现

前台基于长连接做IM的新消息处理。 在新消息处于完成后。 IM的通知模块作为新消息的消费方对接即可。
IM即时通讯-7-如何设计通知提醒_第2张图片

如何设计后台提醒

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

厂商代理通道

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

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

厂商信令通道

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

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

整体的方案

通常从成本的考虑而言, 会采取以下措施:
前台时,采用自己的长连接做基础的通知提醒;
后台时, 采用厂商的信令通道+厂商代理通知。
IM即时通讯-7-如何设计通知提醒_第3张图片

国内三方的推送解决方案

极光推送
个推
信鸽

如何衡量做的好坏

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

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

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

总结

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

你可能感兴趣的:(即时通讯,端到端解决方案,Android,即时通讯,IM,微信,企业微信,消息推送)