乾貨分享!超全 “推送中心” 設計

語言: CN / TW / HK

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

一、推送的背景

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

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

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