網站開發的通知系統是網站信息傳播機制的重要的一部分，本文只梳理設計原則供大家參考。 這里的通知包括但不限于公告、提醒或消息(不同使用場景下的功能定義不同)。 

 

通知系統，顧名思義即通知信息的傳達處理系統。目的是為了讓用戶獲得需要得到的消息及提醒并進行處理。

 

這里的“需要得到”有兩層意思： 

1、用戶彼此互動觸發的信息流(留言、評論或者回復、私信等) 

2、網站希望用戶了解關注的信息(系統公告等)

 

通知系統設計的原則可簡單的歸納為： 

1、消息傳播效率最高(獲取、處理、信息傳達、用戶反饋等效率) 

2、避免產生騷擾(噪音、頻繁提示)

 

不用的平臺和產品本身由于對業務的需求不一樣，種類也是有區別的。大致可分為以下幾種：

 

通知系統實現機制，現對這幾個環節分開說明：

 

(一)通知合并

通知在推送之前需要進行匯總合并，目的在于提高消息傳播處理效率;減少騷擾，降低噪音;平衡服務器壓力。

 

　　1)合并周期：

　　固定時間內的消息全部匯總(24小時內/30天等);

　　無固定時間(只要未處理/未讀即匯總)

　　當然一般都組合著用：合并24小時內未處理消息

 

　　2)分類合并

　　同種類進行合并(如n條留言合并為1條)

　　同一發起人合并(如張三給你發來的n條私信)

　　同一時間周期合并(如24小時共收到n條評論)

 

(二)通知分發

通知按照規則匯總完成后，系統將其通過通知管道推送到用戶，以便用戶處理。

 

　　1)分發方式

　　分發方式與Feed系統類似，多采用Push方式，即在指定時間內主動推送給用戶。部分特定類型需要用戶請求(Pull)拉取未讀消息。

　　目前大部分通知優先推送未處理通知合并后的總數，已提醒用戶已有新消息需要處理。用戶點擊數字后再去服務端請求具體的消息內容。此種方式綜合考慮了成本、壓力和體驗。當然，某些極端情況下需要進行優化處理：如未讀消息超過1000，用戶請求時先推送前50條或者放入cache中等。技術童鞋會有各種手段，這里不做詳述。

 

　　2)分發頻率(時間)

　　分發時間主要根據消息的優先級來做區隔：

 

　　3)分發管道

　　分發管道即消息通知的具體推送渠道，根據業務類型可以分為：Web、App、短信、郵件等。

 

(三)用戶處理

 

　　根據前文提到的分發方式，對于通知的處理在邏輯上可以分為兩層：通知狀態的處理和通知內容的處理。

 

　　1)狀態的處理狹義的理解即為是否已讀(已處理)。

　　通常初始數字即為系統推送過來的未讀總量，用戶點擊數字進入相關功能列表查閱后，讀取的動作完成，未讀數字相應減少。

 

　　2)內容的處理狹義的理解即為用戶是否操作。

 

　　3)消息處理后的狀態需要統一。

　　消息需要標記是否已處理的狀態，且狀態在不同的終端是打通的。

　　如：用戶在客戶端對消息進行了查看，在web站點本消息應自動標記為已讀狀態。

 

(四)通知回收

回收主要針對用戶已處理消息的操作。用戶之間觸發的消息一般需要留檔保存。如評論/回復/留言/私信等。產品可提供選項詢問用戶是否超過一定周期自動清理。