编辑导语：推送中心是一个比较底层比较核心的模块。本篇文章中作者结合自身实战中的一些经验为大家带来了“推送中心”设计的分享，干货满满，感兴趣的小伙伴们快来一起看看吧。

一、推送的背景

推送中心是一个比较底层比较核心的模块，在企业不断扩张以及业务不断增加的情况下，怎么做好一个 “体验好”，“安全性强”，“易对接” 的推送中心其实是不容易的。

目前市面上有非常多的第三方的推送服务商可供企业使用，有同学就会有疑问，直接对接使用不就行了。

如果一个企业只有一个APP那么您可以不用看我接下来的文章，接下来我主要是给哪些公司应用或者APP非常多的需要有一个统一的推送中心的场景下的文章。

那么接下来我将实战中的一些经验，分享给大家。

二、推送整体架构

经过一些实战中的积累，总结了一个推送中心的架构分享给大家，接下来分按照不同的模块进行详细的说明。

三、模块拆解

1. 第三方能力的接入

短信跟邮箱就不在这里赘述了，重点说一下APP push的推送通道的接入。

我在实际推送落地的过程中发现，要做APP push的话的不要自己做通道，就像你想使用短信发消息不用自己做一个短信直接对接电信服务商就行，当然这个比较适合中小企业，如果是那种大型企业一般都是自己在做，大企业为了成本与安全性的考虑，一般中小企业还是最好不要自己做通道了。

2. 目前接入第三方通道的方式有两种

使用推送的SDK+推送后台：这个方案有如下的缺点

（1）不能结合大数据与用户画像给用户推送消息

这里面因为第三方的SDK与我们自己系统其实对于用户ID定义是不一样的，这个其实用户最底层身份标识，如果这个标识发生了差异，那其实推送的对象完全就不是你自己想要的，这和在基础数据表我有详细的说明。

（2）不支持web站内信（如下图）

（3）不支持按照设备ID发送消息

（4）不能获取到推送的历史消息

这样你想在用户的APP中做一个消息中心，记录用户所有的推送消息是不能实现的。

（5）安全风控差

如果直接使用第三方的后台发送消息，只要拿到账号的人就可以随意的发送消息

如果是你自己的系统后台，在消息发送前，结合自己的内部流程系统，进行发送前的消息审核就能规避很多的安全性的问题

只使用推送sdk：这种方案就是只是用第三方的通道，推送的后台，推送的底层数据以及数据的关联关系全部由自己维护，这种就能很好的规避上面出现的各种问题；所以建议大家按照这种方案进行对接。

3. 基础数据表

（1）基础数据表中我觉得最重要的就是 “用户设备应用绑定表” 这个表，这里面主要记录用户ID，设备ID，应用ID的绑定关系，下图是这几个字段的关联关系：

有了这个绑定关系，其实推送就比较灵活。既可以选择直接向用户ID发消息，也可以精准到给对应的用户，设备及应用ID发送消息。

这样消息发送的灵活性就非常的高，可以满足业务的各种组合需求，这也是我们做中台很重要的一点。

（2）用户，设备及应用绑定（与解绑）的流程

通过上面的流程图不难发现，推送是非常依赖账号的，用户注册后分配的用户ID是推送最基础的依赖对象，推送所需要的关系表维护也是依赖于账号注册的过程。

所以一般在产品分组的时候这两个模块一般都会分到一个组或者一个人来维护，就是因为两者有非常大的关联关系。

而且还有一个很重要的点，这个关联关系表其实账号也需要使用，因为如果你想限制一个账号只能登陆几个设备的话，防止黑产，这个数据也是必须的。

4. 统一推送后台

消息审核：在消息发送前会进入到这个流程，这样经过内部的审核流程经过层层的审批，降低恶意推送消息的风险；而且可以自由配置不同的业务推送消息给不同的人来审核

消息测试：这个是给到运营人员使用的，在消息发送前通过这个模块去查看消息的样式是否合适等等，这个限制只能给具体的几个用户或者设备发消息即可

用户分析：这个主要是拉去大数据的用户画像等等，方便运营人员通过用户画像给用户发送消息来使用

推送数据分词：用于统计推送消息的目标数，成功数，送达数，点击数等等

用户推送黑名单：在消息发送前，会过滤这个黑名单，如果有目标的用户或设备在黑名单中，消息是不能发送出去的。

用户标签管理：提供给到运营人员，用户维护用户的标签以及给用户打标使用

消息发送：消息的发送模块

历史消息：所有发送的历史消息管理模块

推送限制管理：限制同一个用户在单位时间收到消息的上限，来解决过多消息对用户的困扰

自动推送规则管理：用于管理预设置的推送消息的自动发送规则

5. 统一推送API

这些API其实主要的使用场景就是，有一些不是人去推送的，而是系统自动判别后给用户推送消息的场景。

例如：用户购买的商品发货后，给用户推送发货提醒时；这些API就不详细介绍了

6. 做个统一的推送中心能解决如下问题

7. 补充说明

推送里面还有一个点需要引起我们的注意，就是如何防止消息重复发送的问题，因为如果同一条消息重复不停的给用户发送，那用户体验将极差。

第三方提供了一个 消息的ID分配接口，这个接口能非常好的规避这个问题，具体做法如下：

这样能防止：

1. 防止接口泄露后的恶意调用
2. 要考虑不能让系统重复的调用，导致用户一直受到消息的情况
3. 运营在发送的时候，多次误点击

四、总结

通过上面的分析其实要做好统一的推送中心有如下几点：

1. 最好只使用第三发推送的通道能力，只对接使用SDK，后台能力以及底层的数据逻辑还是自己开发，这样通用性以及安全性更高
2. 推送其实最重要的底层数据是，用户ID，设备ID与应用ID的绑定关系，有了这个绑定关系，可以灵活的满足业务不同范围目标的消息
3. 推送与账号的关联性极大，一般会将这两个模块分在一个组或同一个人来维护，这个对于产品管理也有好处
4. 推送很重要的一点就是安全风控，不管是发送前审批，还是防止消息重复发送都要注意。

本文由 @陈宏伟 原创发布于人人都是产品经理。未经许可，禁止转载。

题图来自Unsplash，基于 CC0 协议。