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

 

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

 

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

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

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

 

通知系統(tǒng)設計的原則可簡單的歸納為： 

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

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

 

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

 

通知系統(tǒng)實現(xiàn)機制，現(xiàn)對這幾個環(huán)節(jié)分開說明：

 

(一)通知合并

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

 

　　1)合并周期：

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

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

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

 

　　2)分類合并

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

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

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

 

(二)通知分發(fā)

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

 

　　1)分發(fā)方式

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

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

 

　　2)分發(fā)頻率(時間)

　　分發(fā)時間主要根據(jù)消息的優(yōu)先級來做區(qū)隔：

 

　　3)分發(fā)管道

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

 

(三)用戶處理

 

　　根據(jù)前文提到的分發(fā)方式，對于通知的處理在邏輯上可以分為兩層：通知狀態(tài)的處理和通知內(nèi)容的處理。

 

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

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

 

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

 

　　3)消息處理后的狀態(tài)需要統(tǒng)一。

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

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

 

(四)通知回收

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