看了很多關于消息系統規劃的文章，普遍的都是說明APP（安卓/IOS）的消息系統，但是很少從web端進行分析，而筆者借此簡單記錄下自己在規劃web端平臺產品消息系統（以后臺為主）功能的一個思路。雖然現在互聯網是移動趨勢，但是web還是重量級的，因為它面向的更多是B端用戶。

平臺產品與B端、C端產品來說是具有一定的差異性：B端和C端產品在目標用戶上有明確的區分，而平臺產品面向的目標用戶有B端、C端或者BC端都有，簡單粗暴理解就是一個聚合平臺。比如：阿里巴巴平臺、天貓平臺、QQ音樂移動音樂平臺、艾瑞咨詢等等。

而我們平臺產品主要是B端的企業級用戶，所以本次將簡單整理下近期規劃的一款web端平臺產品的消息系統，僅作為參考。

Tips：消息運營
消息標題如何運營、如何保證觸達用戶？這類問題已經有相關文章提及就不再多闡述了。下面主要以后臺功能邏輯來淺談。

以下為本次消息系統規劃框架：

一、背景

平臺型產品初建期需要保證產品的完整性，必須搭建可控的消息系統，形成產品完整的閉環：

• 一來滿足產品的完整性；
• 二來確保讓用戶感知到產品是活的；
• 三來滿足平臺產品上各個業務的流程。

二、目的

1. 讓用戶更加容易獲得提醒；
2. 讓產品更加直接的與用戶產生交互；
3. 分類整理消息。

三、用戶人群

主要面向B端（企業級）用戶

四、場景

1. 營銷類需要：比如運營策略需要的廣告消息、優惠消息、活動消息；
2. 使用服務后的溫馨提醒：比如購買某某產品后的售后（發票申請進度、售后申請服務進度等等）、注冊使用產品后的版本更新、優化說明等；
3. 互動提醒：比如工單回復提醒、評論關注回復等提醒；
4. 任務提醒：比如學習某個視頻更新提醒、下載任務提醒、訂閱某條推送提醒等等。

消息提醒的場景主要分為這4類，當然還會有更多，這里不一一窮舉。對于目前產品能確保以上場景都能實現需求，那就可以了。

因為這就是傳說中的MVP？是的沒錯，下面拓展一下：

MVP：最小價值產品或最小可視化產品，這在精益創業是中很重要的概念。

將核心的功能最先開發出來在不斷試錯中迭代和優化是我們目前的一種產品開發規則。

五、消息系統規劃

消息系統的需求主要分兩大類：功能性需求和非功能性需求。

• 功能性需求：該產品具有的功能，讓用戶通過這些功能完成任務或者滿足各類業務需求的功能，這里統稱為功能性需求。比如：人工push、營銷類消息推送、重大版本更新通知、修復公告等。
• 非功能性需求：主要是產品的性能、系統、進程提醒等需求。比如：系統提醒、事件觸發提醒、進度/任務跟蹤提醒等。

Tips：消息狀態
消息系統中，每條消息都具有唯一的狀態即已讀、未讀和已關閉（刪除，即不在客戶端展示后臺保留數據跟蹤）。而且每條消息隸屬于每個消息的分類下，即消息標簽。這樣區分的目的是便于分類管理和易讀性。

消息管理/設置：主要是對接收的消息進行管理/設置，用戶和產品之間存在主動接收和被動接收的關系。

用戶可以主動去拒絕接收部分消息，這樣做可以讓用戶在產品上獲得更大的主動權。不同于普通B、C端的產品的是：平臺產品在此類消息管理/設置中將很多的接收權限交給用戶有選擇性的接收。

并不是所有的平臺產品都會有這個功能，對于一些聚集了很多業務的平臺來說，有這個功能可以有效的避免接收到多余的消息干擾用戶。如：騰訊云、阿里云、百度云等等。

但是對于業務區分不明顯且不是很大業務量的產品來說，這個功能的存在無關痛癢。如：微信公眾平臺、各大媒體后臺等等。

六、管理后臺規劃

相關字段說明：

• 消息類型：公告消息、活動消息等?？赏ㄟ^管理消息類型進行新增、編輯、刪除操作。這里的消息類型對應的客戶端的消息類型。
• 狀態：已發送、未發送、已關閉。這里的狀態指的是消息的推送狀態，其中已關閉指的是消息在客戶端做了隱藏（撤回）的操作。
• 消息標題：根據客戶端的要求，后臺做字符、樣式、位置等限制。
• 消息內容：根據客戶端的要求，后臺做字符、樣式、位置等限制。
• 閱讀量：消息在客戶端打開/閱讀的數量具有唯一性。
• 推送時間：該條消息成功推送到客戶端的時間。
• 創建時間：創建該條消息的時間。

Tips：管理后臺消息編輯和客戶端有什么需要注意？
管理后臺的消息標題限制字符以及標題的位置樣式是和客戶端分開的。通常我習慣于將客戶端和后臺需求都提及到避免開發同學忘記了，避免聯調的時候帶來不便。

1.創建消息：

根據不同產品的特性后臺管理也會具有不一樣的功能，但是基本功能都是大同小異的：

• 消息類型：和客戶端對應，將各個消息分類管理。
• 推送時間：定時和立即推送可有效的管控并做好運營策略。
• 推送方式：官網、手機、郵箱等。這里的手機可以采用第三方的接口沒必要在自己開發，當然這里第三方的推送主要是營銷類的短信，對于如果有2B的APP應用則會有不一樣的推送方式這里就不過多說明（因為好多大牛都分析過了）。郵箱的話可以集成公司郵箱的API接口或者采用第三方的營銷API。
• 推送人群：根據產品的用戶特性，可以簡單的區分為普通用戶和會員用戶。當然對于特殊的需求還會有指定的用戶人群。為了方便后續的推送這里面應當可擴展，并不局限于這幾個用戶人群。
• 消息標題：-
• 消息內容：富文本編輯器。
• 新增熱區：單獨把熱區拿出來講一下。

熱區可能對于部分沒接觸過的人來說不是很懂，簡單理解為就是：某個頁面指定區域可以實現點擊跳轉，更簡單粗暴就是超鏈接，點哪里超到哪里。

為什么編輯器要熱區這個功能？

因為我們看到很多的圖片消息都是帶有領取優惠券或者點擊某個按鈕進入到活動詳情，這個時候純圖片和純文本都無法滿足我們的運營需求。所以可視化的熱區功能將提高我們運營的效率和滿足各種營銷策略。

2.編輯消息

• 對已發送狀態消息可以對其進行的操作僅限于“展示”功能（即在客戶端是否展示）。
• 未發送狀態的消息則可以編輯所有字段的內容。
• 已關閉狀態的消息則 不可以進行任何操作在消息后臺中相當于回收站，可以給運營做總結分析。

Tips：為什么發出去的消息還要做隱藏/撤回的處理？為什么不直接進行編輯呢？

這里提醒一下，發出去的消息用戶已經接收了，如果對已發送的消息進行編輯會帶來什么樣的后果以及需要承擔什么樣的風險我們都需要考慮，所以這里不建議直接編輯已發送的消息。

但是我們需要規避已發送的消息是否存在政治敏感、輿論導向或其他，防患于未然才設置一個“展示”的功能。這是一個規避的手段，萬不得已是不會使用的

七、非功能性需求

主要是對系統自身的一個提醒，產品的進度任務跟蹤以及事件觸發的非功能性的需求。規劃：
非功能性需求分類主要有3大類：

• 業務需求：主要是產品各個業務的提醒，如訂閱提醒、任務進度提醒、學習進度提醒等。
• 系統性能：如發生無法訪問、卡頓會有系統提醒，當然這里可以設置一些親切的語句來提醒用戶避免流失。
• 事件觸發：產品使用過程中所觸發的一些事件，如下拉加載時候提示語或者加載動畫。

非功能性需求的消息目標用戶當然是以“觸發”為基準，所有用戶只要達到條件觸發就會由產品自動推送相關的消息，不管是消息中心里面的消息還是一些小小的提示語，都屬于一種非功能性的消息需求。

消息系統的規劃主要還是需要根據產品的特性講消息進行分類。而后臺的功能從根本上來說本質是一樣的，需要注意的是根據客戶端和產品的業務進行邏輯區分，保證能夠觸達用戶。

文章簡單記錄筆者在規劃web端平臺產品時候的一個思路，web端產品面向的當然不僅是眼前的B端用戶，后續還將會有第三方供應商和服務商的加入。但是對于消息系統的本質來說這是推送的目標人群多了，具體的是以新增用戶標簽還是另做規劃還需要以業務形態來決定。

本文由 @Randy俊 原創發布于人人都是產品經理。未經許可，禁止轉載。

題圖來自PEXELS，基于CC0協議