消息推送渠道那么多，该怎么设计消息中心？

在产品设计过程中，会有一类功能没有界面，这些功能通常是平台的基础能力，支撑整个产品的正常运行。比如支付系统、消息中心等等。本篇我们来聊聊消息中心怎么设计。

消息通知发展史

我们先来回顾一下消息中心的发展过程。

系统内消息

早期的消息提醒出现是在论坛、即时通讯这种应用。比如论坛发的帖子有人回复了，系统会告诉你；比如 QQ 的未读消息小红点。这类消息都是产品内的消息，消息的送达依赖于用户登录你的产品才能看到。因此，触达率不高。

邮件消息

电子邮箱的出现让消息提醒得以在系统外完成。用户注册的时候使用邮箱注册（国外常见）或绑定邮箱。当有新的消息提醒后，系统除了系统内发送消息外，还同时推送电子邮件提醒用户。用户看到邮件提醒后，自然而然会登录到我们的系统查看具体内容。这就大大地提高了触达率，能够有效提高活跃度。事实上，由于国外的特殊性，邮件一直是首选的系统外通知手段。目前国外的大多数平台还在使用邮件这一方式，比如领英、苹果、Gartner、Dribble 等。所以，如果是海外产品，邮箱消息提醒必不可少。

短信提醒

随着手机的普及，短信提醒在国内成为了消息提醒的一个主要手段。早期的 2G 通讯时代，大家都是“一指禅”——靠大拇指一天能发上百条短信，短信可以说那时候的“延时版”移动端即时通讯。于是，有很多平台开始通过短信和彩信触达用户。近年来，由于短信泛滥，短信触达后的阅读比例降低了很多，已经沦为了验证码接收工具。不过，还是有不少平台使用短信来做消息提醒。比如催费、营销、重要未读消息提醒等。

手机推送消息

智能手机推出后，苹果的 APNS 推送可以让后台提醒直接在锁屏状态下触达用户，而且可以点击直接达到应用内页面，效果比短信更好。于是，苹果的消息推送提醒成为了 App 提高活跃度的必备选项。安卓系统也有统一的消息推送，不过国内用不了。国内安卓各个厂商有自己的推送渠道，这加大了推送的接入难度。于是，滋生了各类推送接入平台，比如极光、友盟。总体来说，安卓的触达率和跳转率不如苹果。

微信消息

微信消息主要包括公众号的模板消息和小程序的服务订阅消息。选择微信消息提醒的很大原因是微信成为了“国民应用”，用户每天打开微信的频次非常高，这也就使得微信消息的触达率非常高。于是，大家纷纷打通应用和微信公众号/小程序，当有消息时会通过微信消息的方式提醒用户。

其他

面向 B 端应用的时候，通常会考虑和钉钉、企微打通。对于工作消息提醒，钉钉和企微是非常不错的选择。

通过消息提醒的发展史，我们可以看到，消息的推送渠道很多，对业务应用来说，每个功能模块单独开发自己的推送功能会显得效率很低，而且可维护性很差 —— 一旦其他平台的规则改变了，每个功能模块都需要修改。基于这些原因，消息中心就诞生了。

消息中心的作用

消息中心，就是将各个业务的消息通知功能集中到一个模块，实现消息的统一发送。这样的好处有 4 个：

1. 消息外发的第三方有变更时，只需要修改消息中心的开发，业务模块无需改动，从而可以降低开发工作量；

2. 统一消息监控日志，掌握消息的发送、送达和阅读情况；

3. 扩展性更强，当有新的业务接入时，可以直接使用消息中心已有的推送模块；

4. 用户可以在统一的消息中心界面管理所有的消息，体验更好。

在没有消息中心之前，每个业务系统都需要和对应的消息通知做交互，如下图所示。每个业务系统自己负责消息的发送，导致整个消息的管理非常混乱。

我们来看一下引入了消息中心后的业务结构，如下图所示。所有业务系统的消息统一接入到消息中心，再由消息中心负责发送出去。引入消息中心了，整个逻辑清晰很多。这就有点类似现实世界的物流中心，在没有物流中心前，怎么送货都是由出发仓库的司机自行决定，效率自然不高。有了物流中心后，货物统一在物流中心集散，统一调度，可以实现全局更优的物流配送方案。

消息中心的设计

消息中心的概念确定好之后，我们就需要明确消息中心如何支持业务系统的消息发送需求。通常来说，一个基础的系统需要面向业务定义好输入和输出。对于业务系统来说，就是消息怎么发给消息中心以及怎么获取消息状态，这个状态包括是否送达和是否阅读。对于消息中心来说就是如何接收业务系统的消息，以及如何将消息状态反馈给业务系统。

对于消息接收，通常需要明确下面几个内容：

• 消息来源：即消息来自于哪个业务系统，甚至哪项功能；

• 消息发送渠道：也就是消息要通过哪个渠道发出去；

• 消息的接收方：即消息要发给谁。这里需要注意，由于不同的消息渠道的标识不同（例如短信是手机号、微信模板消息时 openId、电子邮件是邮箱）。为了避免业务系统过多了解消息系统的细节，如果是点对点消息，建议这个接收方通过平台内统一的标识发送（例如用户 id），由消息中心获取发送消息时对应的消息渠道的接收者标识。

• 消息唯一标识：通过这个标识，消息中心在发送消息后可以反馈消息状态给业务系统；

• 消息内容：消息内容会随着不同的消息渠道不同，这个建议内部针对不同渠道的不同消息定义好一套模板，业务系统按模板组装消息内容。也就是消息中心不负责具体的消息内容，而只承担发送消息和反馈消息状态的职责。

对于消息状态，相对就简单一些，包括如下内容：

• 状态：包括待发送、已发送、已送达、已阅读（阅读也可以细分为标记已读和实际阅读）等。

• 时间：各个状态对应的时间点。

通过状态，我们可以统计消息触达、转化的漏斗图，从而评估消息发送的效果，也可以对消息内容进行 A/B 测试，看看哪种消息的转化率更高。

总结

消息中心不仅仅是我们在用户端看到的一个消息列表，而是提高产品开发和运营效率的利器。目前，国内的所有应用都避免不了接入多个消息渠道，因此建议是在产品设计之初就建立消息中心这一基础设施，更好地支撑业务以及保持良好的系统扩展性。