看了很多關於消息系統規劃的文章，普遍的都是說明APP（安卓/IOS）的消息系統，但是很少從web端進行分析，而筆者藉此簡單記錄下自己在規劃web端平臺產品消息系統（以後臺爲主）功能的一個思路。雖然現在互聯網是移動趨勢，但是web還是重量級的，因爲他面向的更多是B端用戶。
平臺產品與B端、C端產品來說是具有一定的差異性，B端和C端產品在目標用戶上有明確的區分，而平臺產品面向的目標用戶有B端、C端或者BC端都有，簡單粗暴理解就是一個聚合平臺。比如：阿里巴巴平臺、天貓平臺、QQ音樂移動音樂平臺、艾瑞諮詢等等。
而我們平臺產品主要是B端的企業級用戶，所以本次將簡單整理下近期規劃的一款web端平臺產品的消息系統，僅作爲參考。
Tip：消息運營
消息標題如何運營、如何保證觸達用戶？這類問題已經有相關文章提及就不再多闡述了。下面主要以後臺功能邏輯來淺談。
以下爲本次消息系統規劃框架：
一、背景
平臺型產品初建期需要保證產品的完整性，必須搭建可控的消息系統，形成產品完整的閉環。一來滿足產品的完整性；二來確保讓用戶感知到產品是活的；三來滿足平臺產品上各個業務的流程。
二、目的
1.讓用戶更加容易獲得提醒
2.讓產品更加直接的與用戶產生交互
3.分類整理消息
三、用戶人羣
主要面向B端（企業級）用戶
四、場景
營銷類需要，比如運營策略需要的廣告消息、優惠消息、活動消息；
使用服務後的溫馨提醒，比如購買某某產品後的售後（發票申請進度、售後申請服務進度等等）、註冊使用產品後的版本更新、優化說明等；
互動提醒，比如工單回覆提醒、評論關注回覆等提醒；
任務提醒，比如學習某個視頻更新提醒、下載任務提醒、訂閱某條推送提醒等等。
消息提醒的場景主要分爲這4類，當然還會有更多，這裏不一一窮舉。對於目前產品能確保以上場景都能實現需求，那就可以了。因爲這就是傳說中的MVP？是的沒錯，下面拓展一下：
MVP:最小价值產品或最小可視化產品,這在精益創業是中很重要的概念。將核心的功能最先開發出來在不斷試錯中迭代和優化是我們目前的一種產品開發規則。
五、消息系統規劃
消息系統的需求主要分兩大類，功能性需求和非功能性需求。
功能性需求：該產品具有的功能，讓用戶通過這些功能完成任務或者滿足各類業務需求的功能，這裏統稱爲功能性需求。比如：人工push、營銷類消息推送、重大版本更新通知、修復公告等。
非功能性需求：主要是產品的性能、系統、進程提醒等需求。比如：系統提醒、事件觸發提醒、進度/任務跟蹤提醒等。
Tip：消息狀態
消息系統中，每條消息都具有唯一的狀態即已讀、未讀和已關閉（刪除，即不在客戶端展示後臺保留數據跟蹤）。且每條消息隸屬於每個消息的分類下，即消息標籤。這樣區分的目的是便於分類管理和易讀性。
消息管理/設置：主要是對接收的消息進行管理/設置，用戶和產品之間存在主動接收和被動接收的關係。用戶可以主動去拒絕接收部分消息，這樣做可以讓用戶在產品上獲得更大的主動權。不同於普通B、C端的產品的是，平臺產品在此類消息管理/設置中將很多的接收權限交給用戶有選擇性的接收。
並不是所有的平臺產品都會有這個功能，對於一些聚集了很多業務的平臺來說，有這個功能可以有效的避免接收到多餘的消息干擾用戶。如：騰訊雲、阿里雲、百度雲等等。但是對於業務區分不明顯且不是很大業務量的產品來說，這個功能的存在無關痛癢。如：微信公衆平臺、各大媒體後臺等等。
管理後臺規劃
消息類型：公告消息、活動消息等。可通過管理消息類型進行新增、編輯、刪除操作。這裏的消息類型對應的客戶端的消息類型。
狀態：已發送、未發送、已關閉。這裏的狀態指的是消息的推送狀態。其中已關閉指的是消息在客戶端做了隱藏（撤回）的操作。
消息標題：後臺字符限制
消息內容：後臺字符限制
閱讀量：消息在客戶端打開/閱讀的數量具有唯一性。
推送時間：該條消息成功推送到客戶端的時間。
創建時間：創建該條消息的時間。
Tip：管理後臺消息編輯和客戶端有什麼需要注意？
管理後臺的消息標題限制字符以及標題的位置樣式是和客戶端分開的。通常我習慣於將客戶端和後臺需求都提及到避免開發同學忘記了，避免聯調的時候帶來不便。
創建消息：
根據不同產品的特性後臺管理也會具有不一樣的功能，但是基本功能都是大同小異的。
消息類型：和客戶端對應，將各個消息分類管理
推送時間：定時和立即推送可有效的管控並做好運營策略
推送方式：官網，手機，郵箱等。這裏的手機可以採用第三方的接口沒必要在自己開發，當然這裏第三方的推送主要是營銷類的短信，對於如果有2B的APP應用則會有不一樣的推送方式這裏就不過多說明（因爲好多大牛都分析過了）。郵箱的話可以集成公司郵箱的API接口或者採用第三方的營銷API。
推送人羣：根據產品的用戶特性，可以簡單的區分爲普通用戶和會員用戶，當然對於特殊的需求還會有指定的用戶人羣。爲了方便後續的推送這裏面應當可擴展，並不侷限於這幾個用戶人羣。
消息標題：-
消息內容：富文本編輯器。
新增熱區：單獨把熱區拿出來講一下。
熱區可能對於部分沒接觸過的人來說不是很懂，簡單理解爲就是某個頁面指定區域可以實現點擊跳轉，更簡單粗暴就是超鏈接，點哪裏超到哪裏。
爲什麼編輯器要熱區這個功能，因爲我們看到很多的圖片消息都是帶有領取優惠券或者點擊某個按鈕進入到活動詳情，這個時候純圖片和純文本都無法滿足我們的運營需求。所以可視化的熱區功能將提高我們運營的效率和滿足各種營銷策略。
編輯消息
對已發送狀態消息可以對其進行的操作僅限於“展示”功能（即在客戶端是否展示）。
未發送狀態的消息則可以編輯所有字段的內容。
已關閉狀態的消息則 不可以進行任何操作在消息後臺中相當於回收站，可以給運營做總結分析。
Tip：爲什麼發出去的消息還要做隱藏/撤回的處理？爲什麼不直接進行編輯呢？
這裏提醒一下，發出去的消息用戶已經接收了，如果對已發送的消息進行編輯會帶來什麼樣的後果以及需要承擔什麼樣的風險我們都需要考慮。所以這裏不建議直接編輯已發送的消息。但是我們需要規避已發送的消息是否存在政治敏感、輿論導向或其他，防患於未然才設置一個“展示”的功能。這是一個規避的手段，萬不得已是不會使用的
非功能性需求
主要是對系統自身的一個提醒，產品的進度任務跟蹤以及事件觸發的非功能性的需求。
非功能性需求分類主要有3大類：
業務需求：主要是產品各個業務的提醒，如訂閱提醒、任務進度提醒、學習進度提醒等；
系統性能：如發生無法訪問、卡頓會有系統提醒，當然這裏可以設置一些親切的語句來提醒用戶避免流失；
事件觸發：產品使用過程中所觸發的一些事件，如下拉加載時候提示語或者加載動畫。
非功能性需求的消息目標用戶當然是以“觸發”爲基準，所有用戶只要達到條件觸發就會由產品自動推送相關的消息，不管是消息中心裏面的消息還是一些小小的提示語，都屬於一種非功能性的消息需求。
消息系統的規劃主要還是需要根據產品的特性講消息進行分類。而後臺的功能從根本上來說本質是一樣的，需要注意的是根據客戶端和產品的業務進行邏輯區分，保證能夠觸達用戶。
文章簡單記錄筆者在規劃web端平臺產品時候的一個思路，web端產品面向的當然不僅是眼前的B端用戶，後續還將會有第三方供應商和服務商的加入。但是對於消息系統的本質來說這是推送的目標人羣多了，具體的是以新增用戶標籤還是另做規劃還需要以業務形態來決定。