中文字幕无码av不卡一区,亚洲综合AV永久无码精品一区二区,黑人巨大白妞出浆,黄色高清无码免费看,久久久久免费精品国产,久久无码人妻丰满熟妇区毛片,欧美日韩国产综合草草,久久福利网站,亚洲一区二区三区中文字幕在线,av国内精品久久久久影院

編輯導讀：消息中心作為系統信息的集散地，是系統與用戶之間對話的基礎。本文作者梳理了B端產品的消息中心數據流邏輯，希望對你有幫助。

此文是本人從事產品經理工作以來，在設計B端企業內部系統消息中心相關功能時的一些思考，偏重數據流邏輯梳理，內容討論展開多基于B端企業內部產品的消息場景。

一、定位、來源及作用

消息中心作為系統信息的集散地，是系統與用戶之間對話的基礎。通過這個集散地，系統可以向用戶傳達包括且不僅局限于以下信息：

• 企業文化
• 產品價值觀
• 待辦或事務提醒
• ……

特別地，針對IM類產品，消息更多是用戶與用戶之間的對話信息，此類不在這里討論。

不同的系統，因其產品定位不同，其消息中心數據來源和作用也不相一致。一般系統的消息來源在大方向上可以分為2類，一類是站內消息，一類是站外消息。

• 站內消息：指系統本身觸發的消息內容，涵蓋系統公告、待辦提醒等；用于向用戶傳達其在當前系統需要執行或知悉的信息，用戶行為一般限制在當前系統內，不與外界系統產生信息交流或動作交互。當然，也有一些消息來源是站內，但用戶需要在外界系統完成信息處理的，不過相對比較少。
• 站外消息：指外部系統通過當前系統分發機制給用戶同步的提醒信息；用戶在收到此類消息，正常都可以通過當前系統鏈接到對應外部系統去完成信息處理動作，用戶行為不局限于當前系統內，會頻繁與外界系統產生信息交流或動作交互。

例如，某司針對HRBP群體有一個工作臺系統，用于處理HRBP工作事務，其消息中心定位是作為HRBP獲取與其相關的工作事務通知提醒的信息集散地。所以該消息中心的消息來源便不僅有工作臺本身，同時支持外部系統消息接入，如招聘系統接入招聘入職相關消息、360評估系統接入評估提醒相關消息等。用戶可以通過這個系統獲知所有工作相關的信息，并有針對性地對消息進行處理，而不再需要登錄其他40+個HR相關系統獲取信息。

所以，在開展消息中心設計之前，我們一定是需要明確這個功能的定位和數據范圍，也就是梳理清楚戰略層和范圍層的內容，在這之后才能更好地完善功能邏輯和甄別需求。

二、消息流邏輯

無論站內還是站外消息，在消息數據進入消息中心之后，會通過其分發機制觸發給相關用戶，用戶即可在前端系統的消息盒子中查看到具體的消息內容；如果涉及到轉發外部系統提醒的，如郵件中心或短信中心等，則會由消息中心向對應系統發起請求，并觸發短信或郵件至用戶處。可見下面時序圖：

我們可以看到，上述時序圖涉及消息來源、消息中心、消息盒子和外部通知系統。

• 消息來源：含站內消息和站外消息，可以是當前系統本身的提醒或公告，也可以是外部其他系統的提醒。
• 消息中心：當前系統的底層邏輯，用以消息分發、請求外部通知的集中處理模塊。
• 消息盒子：當前系統的消息中心外在表現，用以與用戶交互和信息交流的功能模塊；用戶可以在消息盒子中查閱所有與其相關的消息。
• 外部通知：部分需強提醒或對時效性要求高的消息，會通過一些外部系統輔助消息及時快速觸達，使得用戶沒有登錄當前系統也能獲知消息。此類外部通知系統多指郵件服務中心、短信服務中心、企業微信、飛書、釘釘等。

消息來源請求消息通知時，會向消息中心發送請求，請求中一般包含這些信息：來源標識ID、請求時間、接收對象ID、消息內容（標題+正文）、提醒方式等。消息中心可以理解為包含待發送池、已發送池兩大數據表：

消息來源信息會先進入待發送池排隊，形成一個消息隊列，遵循先進先出規則。消息中心會根據每個消息中所攜帶的接收對象ID進行消息分發，即將該消息發送至對應用戶的消息盒子中；同時根據提醒方式判斷是否調用外部通知系統啟動其他提醒方式。外部通知系統一般有固定的消息模板和提醒邏輯，消息中心需要將提醒對象和應用模板ID、對應模板參數同步給外部通知系統，由外部通知系統判斷并觸發消息模板進行通知。

消息進入消息盒子，則可被用戶所查閱。此時可以根據狀態將消息分為2類，即未讀消息和已讀消息。用戶重點關注會放在未讀消息上，所以優先給用戶呈現新觸達的未讀信息。2類消息之間轉換也很簡單，用戶點擊打開即為已讀；逆操作（即已讀變為未讀）則看具體系統定位和用戶需要，一般不會設置逆操作。

至此，消息流邏輯就基本梳理完成。特別地，消息中心在設計時盡量不要融入復雜邏輯，如定時發送、重復發送等，應盡量保持邏輯簡單以支持大量的消息分發和保持其作為系統底層機制的包容性；而定時發送、重復發送等邏輯應歸類于業務層邏輯，應由業務側決定。

例如，某個少兒美術在線教育公司內部CRM客戶管理系統，其業務上有眾多重復提醒和定時發送提醒的邏輯，如給銷售人員重復提醒某個銷售任務沒有完成，每周二、四晚定時提醒銷售人員準備跟進體驗課，等等。這些邏輯均是設置在業務層，由業務層判斷是否需要觸發提醒，如需要則向消息中心發出請求，傳入相關參數進入消息隊列排隊發送。這樣能保證消息中心簡單而高效運轉，不會因為復雜邏輯產生不必要的消息流問題（如無法兼容多種重發邏輯等）；也把運維的重心都偏移在業務層，使得不同業務消息互不影響。

三、總結

消息中心是B端產品系統的基本功能，一個包容性強且設計合理的消息中心，能更好地支撐系統與用戶之間的對話，傳達我們想要告訴用戶的信息。消息中心設計之初需要先確認系統定位和功能定位，才能規范好數據范圍，從而在實現產品功能價值和滿足業務需求。消息流邏輯也需要盡量梳理清楚，使其成為系統基礎服務，不要與業務邏輯強融合，才能保證其良好地包容性和避免返工。

以上是個人工作過程的一些經驗總結和思考，仍有不足，正在努力。

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

題圖來自Unsplash，基于 CC0 協議