編輯導語：推送中心是一個比較底層比較核心的模塊。本篇文章中作者結合自身實戰中的一些經驗為大家帶來了“推送中心”設計的分享，幹貨滿滿，感興趣的小夥伴們快來一起看看吧。

一、推送的背景

推送中心是一個比較底層比較核心的模塊，在企業不斷擴張以及業務不斷增加的情況下，怎麼做好一個 “體驗好”，“安全性強”，“易對接” 的推送中心其實是不容易的。

目前市面上有非常多的第三方的推送服務商可供企業使用，有同學就會有疑問，直接對接使用不就行了。

如果一個企業隻有一個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 協議。

,