#頭條創作挑戰賽#

在産品設計過程中，會有一類功能沒有界面，這些功能通常是平台的基礎能力，支撐整個産品的正常運行。比如支付系統、消息中心等等。本篇我們來聊聊消息中心怎麼設計。

我們先來回顧一下消息中心的發展過程。

早期的消息提醒出現是在論壇、即時通訊這種應用。比如論壇發的帖子有人回複了，系統會告訴你；比如QQ的未讀消息小紅點。這類消息都是産品内的消息，消息的送達依賴于用戶登錄你的産品才能看到。因此，觸達率不高。

電子郵箱的出現讓消息提醒得以在系統外完成。用戶注冊的時候使用郵箱注冊（國外常見）或綁定郵箱。當有新的消息提醒後，系統除了系統内發送消息外，還同時推送電子郵件提醒用戶。用戶看到郵件提醒後，自然而然會登錄到我們的系統查看具體内容。這就大大地提高了觸達率，能夠有效提高活躍度。事實上，由于國外的特殊性，郵件一直是首選的系統外通知手段。目前國外的大多數平台還在使用郵件這一方式，比如領英、蘋果、Gartner、Dribble等。所以，如果是海外産品，郵箱消息提醒必不可少。

随着手機的普及，短信提醒在國内成為了消息提醒的一個主要手段。早期的2G通訊時代，大家都是“一指禅”——靠大拇指一天能發上百條短信，短信可以說那時候的“延時版”移動端即時通訊。于是，有很多平台開始通過短信和彩信觸達用戶。近年來，由于短信泛濫，短信觸達後的閱讀比例降低了很多，已經淪為了驗證碼接收工具。不過，還是有不少平台使用短信來做消息提醒。比如催費、營銷、重要未讀消息提醒等。

智能手機推出後，蘋果的APNS推送可以讓後台提醒直接在鎖屏狀态下觸達用戶，而且可以點擊直接達到應用内頁面，效果比短信更好。于是，蘋果的消息推送提醒成為了App提高活躍度的必備選項。安卓系統也有統一的消息推送，不過國内用不了。國内安卓各個廠商有自己的推送渠道，這加大了推送的接入難度。于是，滋生了各類推送接入平台，比如極光、友盟。總體來說，安卓的觸達率和跳轉率不如蘋果。

微信消息主要包括公衆号的模闆消息和小程序的服務訂閱消息。選擇微信消息提醒的很大原因是微信成為了“國民應用”，用戶每天打開微信的頻次非常高，這也就使得微信消息的觸達率非常高。于是，大家紛紛打通應用和微信公衆号/小程序，當有消息時會通過微信消息的方式提醒用戶。

面向B端應用的時候，通常會考慮和釘釘、企微打通。對于工作消息提醒，釘釘和企微是非常不錯的選擇。

通過消息提醒的發展史，我們可以看到，消息的推送渠道很多，對業務應用來說，每個功能模塊單獨開發自己的推送功能會顯得效率很低，而且可維護性很差 —— 一旦其他平台的規則改變了，每個功能模塊都需要修改。基于這些原因，消息中心就誕生了。

消息中心，就是将各個業務的消息通知功能集中到一個模塊，實現消息的統一發送。這樣的好處有4個：

1. 消息外發的第三方有變更時，隻需要修改消息中心的開發，業務模塊無需改動，從而可以降低開發工作量；
2. 統一消息監控日志，掌握消息的發送、送達和閱讀情況；
3. 擴展性更強，當有新的業務接入時，可以直接使用消息中心已有的推送模塊；
4. 用戶可以在統一的消息中心界面管理所有的消息，體驗更好。

在沒有消息中心之前，每個業務系統都需要和對應的消息通知做交互，如下圖所示。每個業務系統自己負責消息的發送，導緻整個消息的管理非常混亂。

我們來看一下引入了消息中心後的業務結構，如下圖所示。所有業務系統的消息統一接入到消息中心，再由消息中心負責發送出去。引入消息中心了，整個邏輯清晰很多。這就有點類似現實世界的物流中心，在沒有物流中心前，怎麼送貨都是由出發倉庫的司機自行決定，效率自然不高。有了物流中心後，貨物統一在物流中心集散，統一調度，可以實現全局更優的物流配送方案。

消息中心的概念确定好之後，我們就需要明确消息中心如何支持業務系統的消息發送需求。通常來說，一個基礎的系統需要面向業務定義好輸入和輸出。對于業務系統來說，就是消息怎麼發給消息中心以及怎麼獲取消息狀态，這個狀态包括是否送達和是否閱讀。對于消息中心來說就是如何接收業務系統的消息，以及如何将消息狀态反饋給業務系統。

對于消息接收，通常需要明确下面幾個内容：

• 消息來源：即消息來自于哪個業務系統，甚至哪項功能；
• 消息發送渠道：也就是消息要通過哪個渠道發出去；
• 消息的接收方：即消息要發給誰。這裡需要注意，由于不同的消息渠道的标識不同（例如短信是手機号、微信模闆消息時 openId、電子郵件是郵箱）。為了避免業務系統過多了解消息系統的細節，如果是點對點消息，建議這個接收方通過平台内統一的标識發送（例如用戶 id），由消息中心獲取發送消息時對應的消息渠道的接收者标識。
• 消息唯一标識：通過這個标識，消息中心在發送消息後可以反饋消息狀态給業務系統；
• 消息内容：消息内容會随着不同的消息渠道不同，這個建議内部針對不同渠道的不同消息定義好一套模闆，業務系統按模闆組裝消息内容。也就是消息中心不負責具體的消息内容，而隻承擔發送消息和反饋消息狀态的職責。

對于消息狀态，相對就簡單一些，包括如下内容：

• 狀态：包括待發送、已發送、已送達、已閱讀（閱讀也可以細分為标記已讀和實際閱讀）等。
• 時間：各個狀态對應的時間點。

通過狀态，我們可以統計消息觸達、轉化的漏鬥圖，從而評估消息發送的效果，也可以對消息内容進行 A/B 測試，看看哪種消息的轉化率更高。

消息中心不僅僅是我們在用戶端看到的一個消息列表，而是提高産品開發和運營效率的利器。目前，國内的所有應用都避免不了接入多個消息渠道，因此建議是在産品設計之初就建立消息中心這一基礎設施，更好地支撐業務以及保持良好的系統擴展性。

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!