編輯導(dǎo)語：推送中心是一個(gè)比較底層比較核心的模塊。本篇文章中作者結(jié)合自身實(shí)戰(zhàn)中的一些經(jīng)驗(yàn)為大家?guī)砹恕巴扑椭行摹痹O(shè)計(jì)的分享，干貨滿滿，感興趣的小伙伴們快來一起看看吧。

一、推送的背景

推送中心是一個(gè)比較底層比較核心的模塊，在企業(yè)不斷擴(kuò)張以及業(yè)務(wù)不斷增加的情況下，怎么做好一個(gè) “體驗(yàn)好”，“安全性強(qiáng)”，“易對(duì)接” 的推送中心其實(shí)是不容易的。

目前市面上有非常多的第三方的推送服務(wù)商可供企業(yè)使用，有同學(xué)就會(huì)有疑問，直接對(duì)接使用不就行了。

如果一個(gè)企業(yè)只有一個(gè)APP那么您可以不用看我接下來的文章，接下來我主要是給哪些公司應(yīng)用或者APP非常多的需要有一個(gè)統(tǒng)一的推送中心的場(chǎng)景下的文章。

那么接下來我將實(shí)戰(zhàn)中的一些經(jīng)驗(yàn)，分享給大家。

二、推送整體架構(gòu)

經(jīng)過一些實(shí)戰(zhàn)中的積累，總結(jié)了一個(gè)推送中心的架構(gòu)分享給大家，接下來分按照不同的模塊進(jìn)行詳細(xì)的說明。

三、模塊拆解

1. 第三方能力的接入

短信跟郵箱就不在這里贅述了，重點(diǎn)說一下APP push的推送通道的接入。

我在實(shí)際推送落地的過程中發(fā)現(xiàn)，要做APP push的話的不要自己做通道，就像你想使用短信發(fā)消息不用自己做一個(gè)短信直接對(duì)接電信服務(wù)商就行，當(dāng)然這個(gè)比較適合中小企業(yè)，如果是那種大型企業(yè)一般都是自己在做，大企業(yè)為了成本與安全性的考慮，一般中小企業(yè)還是最好不要自己做通道了。

2. 目前接入第三方通道的方式有兩種

使用推送的SDK+推送后臺(tái)：這個(gè)方案有如下的缺點(diǎn)

（1）不能結(jié)合大數(shù)據(jù)與用戶畫像給用戶推送消息

這里面因?yàn)榈谌降腟DK與我們自己系統(tǒng)其實(shí)對(duì)于用戶ID定義是不一樣的，這個(gè)其實(shí)用戶最底層身份標(biāo)識(shí)，如果這個(gè)標(biāo)識(shí)發(fā)生了差異，那其實(shí)推送的對(duì)象完全就不是你自己想要的，這和在基礎(chǔ)數(shù)據(jù)表我有詳細(xì)的說明。

（2）不支持web站內(nèi)信（如下圖）

（3）不支持按照設(shè)備ID發(fā)送消息

（4）不能獲取到推送的歷史消息

這樣你想在用戶的APP中做一個(gè)消息中心，記錄用戶所有的推送消息是不能實(shí)現(xiàn)的。

（5）安全風(fēng)控差

如果直接使用第三方的后臺(tái)發(fā)送消息，只要拿到賬號(hào)的人就可以隨意的發(fā)送消息

如果是你自己的系統(tǒng)后臺(tái)，在消息發(fā)送前，結(jié)合自己的內(nèi)部流程系統(tǒng)，進(jìn)行發(fā)送前的消息審核就能規(guī)避很多的安全性的問題

只使用推送sdk：這種方案就是只是用第三方的通道，推送的后臺(tái)，推送的底層數(shù)據(jù)以及數(shù)據(jù)的關(guān)聯(lián)關(guān)系全部由自己維護(hù)，這種就能很好的規(guī)避上面出現(xiàn)的各種問題；所以建議大家按照這種方案進(jìn)行對(duì)接。

3. 基礎(chǔ)數(shù)據(jù)表

（1）基礎(chǔ)數(shù)據(jù)表中我覺得最重要的就是 “用戶設(shè)備應(yīng)用綁定表” 這個(gè)表，這里面主要記錄用戶ID，設(shè)備ID，應(yīng)用ID的綁定關(guān)系，下圖是這幾個(gè)字段的關(guān)聯(lián)關(guān)系：

有了這個(gè)綁定關(guān)系，其實(shí)推送就比較靈活。既可以選擇直接向用戶ID發(fā)消息，也可以精準(zhǔn)到給對(duì)應(yīng)的用戶，設(shè)備及應(yīng)用ID發(fā)送消息。

這樣消息發(fā)送的靈活性就非常的高，可以滿足業(yè)務(wù)的各種組合需求，這也是我們做中臺(tái)很重要的一點(diǎn)。

（2）用戶，設(shè)備及應(yīng)用綁定（與解綁）的流程

通過上面的流程圖不難發(fā)現(xiàn)，推送是非常依賴賬號(hào)的，用戶注冊(cè)后分配的用戶ID是推送最基礎(chǔ)的依賴對(duì)象，推送所需要的關(guān)系表維護(hù)也是依賴于賬號(hào)注冊(cè)的過程。

所以一般在產(chǎn)品分組的時(shí)候這兩個(gè)模塊一般都會(huì)分到一個(gè)組或者一個(gè)人來維護(hù)，就是因?yàn)閮烧哂蟹浅４蟮年P(guān)聯(lián)關(guān)系。

而且還有一個(gè)很重要的點(diǎn)，這個(gè)關(guān)聯(lián)關(guān)系表其實(shí)賬號(hào)也需要使用，因?yàn)槿绻阆胂拗埔粋€(gè)賬號(hào)只能登陸幾個(gè)設(shè)備的話，防止黑產(chǎn)，這個(gè)數(shù)據(jù)也是必須的。

4. 統(tǒng)一推送后臺(tái)

消息審核：在消息發(fā)送前會(huì)進(jìn)入到這個(gè)流程，這樣經(jīng)過內(nèi)部的審核流程經(jīng)過層層的審批，降低惡意推送消息的風(fēng)險(xiǎn)；而且可以自由配置不同的業(yè)務(wù)推送消息給不同的人來審核

消息測(cè)試：這個(gè)是給到運(yùn)營(yíng)人員使用的，在消息發(fā)送前通過這個(gè)模塊去查看消息的樣式是否合適等等，這個(gè)限制只能給具體的幾個(gè)用戶或者設(shè)備發(fā)消息即可

用戶分析：這個(gè)主要是拉去大數(shù)據(jù)的用戶畫像等等，方便運(yùn)營(yíng)人員通過用戶畫像給用戶發(fā)送消息來使用

推送數(shù)據(jù)分詞：用于統(tǒng)計(jì)推送消息的目標(biāo)數(shù)，成功數(shù)，送達(dá)數(shù)，點(diǎn)擊數(shù)等等

用戶推送黑名單：在消息發(fā)送前，會(huì)過濾這個(gè)黑名單，如果有目標(biāo)的用戶或設(shè)備在黑名單中，消息是不能發(fā)送出去的。

用戶標(biāo)簽管理：提供給到運(yùn)營(yíng)人員，用戶維護(hù)用戶的標(biāo)簽以及給用戶打標(biāo)使用

消息發(fā)送：消息的發(fā)送模塊

歷史消息：所有發(fā)送的歷史消息管理模塊

推送限制管理：限制同一個(gè)用戶在單位時(shí)間收到消息的上限，來解決過多消息對(duì)用戶的困擾

自動(dòng)推送規(guī)則管理：用于管理預(yù)設(shè)置的推送消息的自動(dòng)發(fā)送規(guī)則

5. 統(tǒng)一推送API

這些API其實(shí)主要的使用場(chǎng)景就是，有一些不是人去推送的，而是系統(tǒng)自動(dòng)判別后給用戶推送消息的場(chǎng)景。

例如：用戶購(gòu)買的商品發(fā)貨后，給用戶推送發(fā)貨提醒時(shí)；這些API就不詳細(xì)介紹了

6. 做個(gè)統(tǒng)一的推送中心能解決如下問題

7. 補(bǔ)充說明

推送里面還有一個(gè)點(diǎn)需要引起我們的注意，就是如何防止消息重復(fù)發(fā)送的問題，因?yàn)槿绻粭l消息重復(fù)不停的給用戶發(fā)送，那用戶體驗(yàn)將極差。

第三方提供了一個(gè) 消息的ID分配接口，這個(gè)接口能非常好的規(guī)避這個(gè)問題，具體做法如下：

這樣能防止：

1. 防止接口泄露后的惡意調(diào)用
2. 要考慮不能讓系統(tǒng)重復(fù)的調(diào)用，導(dǎo)致用戶一直受到消息的情況
3. 運(yùn)營(yíng)在發(fā)送的時(shí)候，多次誤點(diǎn)擊

四、總結(jié)

通過上面的分析其實(shí)要做好統(tǒng)一的推送中心有如下幾點(diǎn)：

1. 最好只使用第三發(fā)推送的通道能力，只對(duì)接使用SDK，后臺(tái)能力以及底層的數(shù)據(jù)邏輯還是自己開發(fā)，這樣通用性以及安全性更高
2. 推送其實(shí)最重要的底層數(shù)據(jù)是，用戶ID，設(shè)備ID與應(yīng)用ID的綁定關(guān)系，有了這個(gè)綁定關(guān)系，可以靈活的滿足業(yè)務(wù)不同范圍目標(biāo)的消息
3. 推送與賬號(hào)的關(guān)聯(lián)性極大，一般會(huì)將這兩個(gè)模塊分在一個(gè)組或同一個(gè)人來維護(hù)，這個(gè)對(duì)于產(chǎn)品管理也有好處
4. 推送很重要的一點(diǎn)就是安全風(fēng)控，不管是發(fā)送前審批，還是防止消息重復(fù)發(fā)送都要注意。

本文由 @陳宏偉 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止轉(zhuǎn)載。

題圖來自Unsplash，基于 CC0 協(xié)議。