消息推送機制是 pc 或 app 最常見的信息觸達用戶的途徑之一，在日常使用中，我們碰到比較多的是彈窗設計。本篇文章中筆者對消息機制設計進行了系統的分析，梳理了消息機制設計的整體框架，供大家參考和學習。

作為產品經理，給自己產品設計消息機制的時候，絕不僅僅是一個彈窗就搞定的事情，需要從整個消息機制入手去規劃和設計。

本文從消息機制的幾個要點出發，講解如何較為系統化的設計自己產品的消息機制。

一、消息機制目的和組成

消息機制最初源于互聯網產品屆，主要目的在于拉新促活，提升用戶粘性，增強產品和用戶的關系，當然使用不當也會存在適得其反的效果。

目前消息機制不僅僅在于拉新促活，另一個主要目的是用于統一產品的消息出口，在產品架構設計時，從消息層來告訴用戶產品發生了什么事情，從而做到消息層、主站兩個產品設計架構的分離，并且產品信息層結構更清晰。

消息的組成一般大體上由兩類組成：標題+內容。

一般移動端信息推送或pc端廣告彈窗，消息機制推送的消息的標題會第一時間告訴用戶該消息是什么類型的消息，然后具體內容為文本信息或圖片、video材料，供用戶詳細查看具體消息的詳情，比如是系統要升級了，還是本次推出了什么活動等等，甚至目前的廣告彈窗也遵循這種規則，消息以標題和內容兩部分為主。

二、消息機制的運行狀態

消息機制在用戶側來看，也就是產品表現層，基本上就是彈窗巨多，也是用戶看到最多的一種狀態，即正在執行的狀況。但是作為產品經理，需要考慮消息機制的多種狀態，目前最常見的有如下幾種狀態：

1. 運行態

該消息已經觸達用戶，并且正在運行；以彈窗的消息機制來理解的話，可以認為信息彈窗已經彈出，并且還未消息，正在用戶的app打開的時候或pc網站打開的時候處于用戶可以看到的狀態。

該部分在產品設計中，主要以產品表現層考慮的巨多。

2. 就緒態

該消息即將觸達用戶側；以彈窗的消息機制來理解的話，可以認為是由于某種原因此時此刻不能彈出，下一個即將彈出的信息彈窗，過一段時間（時間長短不同產品設計不同）或用戶觸發了某個操作后就會彈出該消息層。

該部分在產品設計中，主要是考慮消息機制的排隊邏輯時需要考慮，即多個信息到達時，需要如何處理；如果產品經理定義好就緒態，那么就不會出現沖突的情況。

3. 等待態

該消息在消息隊列中，排隊等候；以彈出的消息機制來理解的話，本部分可以認為是多個信息都要彈窗，但是需要排出優先級，一個一個彈，這種情況下，除了下一個彈窗處于就緒態（即第二點描述的狀態），其余的均為等待態，這種狀態下的消息，不緊不慢，還沒到它，當然不急咯。

該部分在產品設計中，產品經理主要考慮好消息機制的排隊邏輯已經優先級邏輯時需要注意，針對多個消息，不僅需要制定排隊邏輯，即按照觸發條件依次排隊準備彈窗，同時考慮好各個消息的優先級，比如系統升級的提醒是否要高于本次活動節日的運營推廣彈窗？

4. 新建態

確該消息剛被放入到消息隊列，等待進入等待態（可以理解為信息剛完成，但是前面有多個消息，所以即將進入等待態）

該部分主要以研發考慮為主，對于一個message，研發需要考慮到新建的信息在新建剛完畢時，以及未投入到隊伍機制前，需要開辟一個存儲空間來對應該消息的存儲，這里面的信息定義為新建態。

5. 結束態

該信息已經運行/彈窗完畢，處于結束狀態；以彈窗的消息機制來理解的話，可以認為是以及結束的彈窗信息，用戶在產品第一界面無法在看到或聽到等等。

該部分對應到產品設計中，產品經理主要需要考慮到消息中心，比如已經完成的信息，是否要新建一個信息中心來放所有的信息，以便于用戶可以去消息中心查看歷史消息？這些問題涉及到結束態消息的處理。

對于以上幾種狀態，這里給出簡單的邏輯流程圖，以便于產品經理參考邏輯圖來設計自己產品的消息機制的流轉邏輯。消息機制中的各消息的多個狀態之間的轉換業務邏輯如下：

備注：由上述業務流程圖可以看到，從新建態到結束態的主流程是消息機制的主邏輯，正向的主流程。紅色線代表的是插入性信息，會導致運行態消息被插入的信息打斷，從而轉換為等待態，再根據排隊機制，進行排隊等待，轉換為就緒態，等待運行。

三、消息機制的處理機制

消息機制的業務邏輯（此處以我設計的產品的部分機制為例）

1. 排隊機制

【定義】系統將會維護一個或多個消息隊列，所有產生的消息都會被放入或是插入隊列中；

【實現邏輯】所有彈窗信息，按照觸發時間/優先級，依次排隊；等到上一級彈窗倒計時/關閉后，隊伍順次移動；

2. 優先級機制

【定義】系統根據消息的優先級在隊列中取出對應的一條或多條消息，然后參考相應的規則來進行彈層；

【實現邏輯】在排隊機制中，根據已經彈窗的狀態，系統判定下一個彈窗的具體對象，根據優先級/異常機制來進行彈窗

3. 異常邏輯

【定義】當按照正常策略執行的過程中，遇到異常時，系統執行該異常策略，從而避免用戶感知到系統bug，提升用戶體驗；

【實現邏輯】在按照正常邏輯/策略執行彈窗時，如果恰好彈窗剛準備彈/已經剛彈但也沒未刷新出/其他情況下，需要給予用戶相關信息提醒/圖案顯示。

四、消息機制的推送方式

對于目前市面上常見的消息機制，常見的推送方式有兩種：PULL和PUSH。

1. PUSH方式可以理解為系統主動推送，根據用戶的興趣、需求，按時按量按類別等要求將信息主動推送到用戶端。該方式較為普遍，適用于普遍用戶；
2. PULL可以理解為是用戶主動索取，主動索取系統相關信息，主動給系統發出請求索取相關信息。PULL的優勢在于針對性較強，由于用戶主動索取，所以能夠較好的滿足用戶的個性化需求。

兩種方式各有優缺點，在產品設計時，產品經理如果能夠更好的理解兩種方式的優缺點，那么就可以在和工程師溝通的過程中更好的進行理解技術框架和技術方案。

五、消息機制類型

消息機制的類型，總體來說分為：內容提醒類和系統通知類。

系統通知類的消息一般為系統的容錯機制，更好的保障系統的運行、升級、出錯、崩潰等。如：系統升級提醒框、系統崩潰后的信息提醒。

如上圖，兩款APP的系統通知類信息（以升級提醒為主），其觸發條件均為 打開APP后觸發，并且推送方式為PUSH，系統自動推送給用戶，優先級較高；

當用戶打開APP時就可以看到，但是同時這種彈窗最好給用戶選擇的余地，否則就會適得其反，太強制的操作會導致用戶反感，所以我們可以看到上面的兩個彈窗，用戶可以選擇更新，也可以選擇不更新。

內容提醒類消息為消息機制里的主體部分，產品的消息機制的設計，圍繞著消息機制的運營、促活、拉新等，都可以在內容提醒彈框內做文章，包括運營活動、產品迭代等等。

六、消息機制的優先級

產品設計過程中除了策劃好上述五點的內容外，還需要額外考慮消息機制里的消息的優先級。

比如，如果正在給用戶提示系統升級的彈窗（優先級為B），此時如果有優先級為A的消息提醒，如何處理？針對不同優先級、同等優先級的消息機制里的信息，產品經理需要考慮好如何進行產品設計的處理。

規劃優先級的這塊，在產品設計里不僅能夠很好的處理產品消息層面的容錯，同時當把產品的定位往平臺方向轉變時，能夠統一規劃產品的對接第三方服務。

這里的建議，結合我自己產品的設計，給大家的建議是：

1. 首先，將自己產品的所有消息類型思維導圖出來，按照系統通知類、內容提醒類分兩類。
2. 根據不同需要，先給兩大類定優先級，然后在類別內在進行細類的優先級劃分。
3. 如果自己的產品還存在對接第三方系統，第三方也存在消息機制，那么就需要根據產品定位，對第三方也一并進行考慮，比如第三方服務是僅僅為了商業合作？還是第三方能夠很大程度的給自己拉新促活？不同的對接目的優先級不同，產品經理需要額外關注。

以上就是產品設計過程中，如果涉及到消息機制的話，產品經理需要初步考慮的一些注意事項，歡迎大家一起討論。

本文由 @楠柯一夢 原創發布于人人都是產品經理，未經作者許可，禁止轉載。

題圖來自Unsplash，基于CC0協議。