本篇文章目標是通過以通俗易懂的方式向大家介紹消息通知的類型、設計到后期運營的過程，從而使大家盡可能系統的了解基本的渠道和使用方式，希望有用。

消息通知作為系統的基礎功能，雖然很難察覺，卻是完成產品用戶體驗的重要閉環，也是產品經理應該熟知的最基礎功能之一。

網上關于消息通知的文章介紹已經有很多，有的關于樣式，有的描述系統模塊，有些以營銷方式為入口，這些都是非常有參考價值的文章。不過對于我們現階段要做的功能，這些內容相對零碎，我在整理的時候花了一些時間。

本篇文章目標是通過以通俗易懂的方式向大家介紹消息通知的類型、設計到后期運營的過程，從而使大家盡可能系統的了解基本的渠道和使用方式，希望有用。

主要適合：

（1）初步梳理消息通知

從來沒有接觸過消息通知的產品都需要花點時間去了解各個消息的渠道和形態機制，除了網上現有的文章，也需要去翻各個第三方或者平臺的開發文檔，了解功能設計的內容以外，也要了解技術的可行性，對于沒有做過的產品和開發都需要花費一定的時間做取舍和沉淀，本文整理的一些主流的方式以及文檔鏈接可以為這類同學節省時間。

（2）滿足基本用戶體驗閉環需求?

設計完整的消息通知系統是較為復雜的，功能上：營銷可以做到策略機制，考慮推送的類型和推送時機，進行個性化推送、精準營銷；還需要考慮風控機制，如果部門較多，消息資源是統一管理的，需要設計后臺的審核機制系統等。

產品上：可以是主營產品例如一些IM工具，可以作為系統的業務支撐功能，也可以作為CRM等其他B端產品的增值功能技術上：如果用戶并發量大，為了保證消息的及時性和觸達率，可能需要自己完成長鏈接開發，考慮性能優化等。

所以很難一篇文章很難完整的介紹整個消息通知，這篇文章僅以描述滿足用戶基本體驗需求的消息通知設計。

（3）以移動端的消息通知為主

對于不同的產品類型，消息通知的表象差不多，但是內核卻可能千差萬別，甚至極具智慧。整片介紹我們將以最能及時收到信息的移動端通知為主。

文章主要為三個部分：

1. 消息通知的主流渠道和形態；
2. 消息通知的產品設計和維護文檔；
3. 開發中需要注意的問題這些內容我將盡量在較少的篇幅完成說明。

一、消息通知的主流渠道和形態

通知渠道即可觸達用戶的各種渠道，他們的顯示形態，應用方式各不相同，我將它總結為短信、PUSH、橫屏通知、公眾號模板消息、小程序模板消息、通知中心/站內信等，還有其他的通知消息形式，這里主要介紹常用的這六種。

1.?短信

（1）渠道定義

短信時是大家較為熟知的通知渠道，發送的條件限制較少。主要包含三種類型，某第三方的基本介紹：

• 驗證碼短信——接口可以實現給指定手機號發驗證碼短信，用短信驗證碼來驗證操作者的身份，來確保是本人操作，或者是經由本人授權操作。
• 通知短信——短信在實用工具功能和修辭性事功能基礎上又衍生出新的功能形態—文化評判與社會參與功能，而且在這種傳媒體的引導和推動下，這種功能日益得到彰顯和強化。
• 營銷短信——發送一般用于不同行業、不同領域的企事業單位、團體組織機構對于自身產品的推廣和介紹，達到加快速或加深溝通聯系；提高服務質量；加快工作效率（包括商業銷售效率）的手段。

（2）發送前置條件

用戶手機號

（3）優缺點?

觸達率高（觸達率即指發起消息，用戶能收到的概率）。另外未收到短信時主要是這些問題：當地區手機信號不好；手機號被拉為黑名單；獲取較為頻繁。后兩個問題都可以在服務商那里進行對接解決，一般短信商可以設置同一手機號在一定時間內最多能收到多少次，建議將你公司的測試手機設為白名單。

時效性高（時效性則是從發起后用戶收到的時間，收到的時間越短，時效性越高）。

前置條件要求較少，發送的內容限制較少（當然要熱愛和諧，短信模板一般服務商需要審核，不添加模板也可以發送，不過可能會有延遲）。

需要收取費用，不同類型的短信費用不相同。

（4）交互形式?

營銷類短信可以放置短鏈接，點擊后可以跳轉到指定H5頁面。

（5）文檔鏈接

建議查看第三方服務商的技術或設計文檔，具體文檔鏈件我就不放出了，以免廣告的嫌疑，網上有很多渠道可以查看。

2. PUSH

（1）渠道定義

設備系統通知，使用PUSH推送技術，長見于移動端（Macos和ios的設備通知體驗基本一致，Win也有各種形態的通知，這里不再擴展），通知形態包括鎖屏、通知中心、橫幅（頂部彈窗通知）等，也可以同時傳達聲音消息。

（2）前置條件

用戶設備號

（3）優缺點

時效高；內容類型無限制，和短信的一樣發送的內容類型無限制由開發方自行設置。

基本免費，可以自行開發（開發成本較高，但觸達率和時效性都很高，后期需求量大時可以使用刺中方式），也可以使用第三方，長用的有極光和友盟（如果用戶量不大的時候接入免費服務即可，極光客服反饋如如果需要保證安卓觸達（安卓廠商優化系統，在殺死進程后不能到達）可以接入付費，其他暫無收費項目，不過根據其他信息來源在單位時間內api的調用次數可能會有區別，這個可以根據需求機械能對接，另外這里贊一聲極光的客服反饋特別迅速。

觸達率不穩定，用戶需要下載app并打開系統通知，才能收到，同時跟手機廠商，性能，以及網絡等原因相關，極光開發文檔給的觸達率是80%。

（4）交互形式

安卓、蘋果可跳轉APP指定頁面、安卓點擊通知欄可下載軟件，彈窗樣式字數要求可以看各個開發文檔；如果需要接入聲音，例如語音播報，蘋果和安卓有不同的處理方式，這里不再擴展，需要的話可以另外交流。

3.?橫屏通知

（1）渠道定義

應用前臺的頂部彈窗通知，使用的也是PUSH技術，樣式比較多樣，可由我方自行定義，應用場景是當用戶在在用用前臺時需要進行彈窗通知時，需要更多的通知內容和交互形式都可以使用此種通知類型，蘋果和安卓都可以使用第三方推送，界面自行開發。

（2）前置條件

拿到用戶的設備號

（3）優缺點

觸達率高；時效性低，由于需要用戶在前臺時才能展示，內容類型無限制，交互可自行定義。

（4）交互形式

指定跳轉，以及其他交互，交互以及界面樣式多樣。

4.?公眾號模板消息

（1）渠道定義

模板消息僅用于公眾號向用戶發送重要的服務通知，常用于支付成功后，預約等服務類型消息通知。

（2）前置條件

用戶需關注公眾號，用戶需與公眾號有交互，才能發起通知。

（3）優缺點

由于微信的普及率，模板消息觸達率高、時效性高、接口不需收費。

前置條件滿足較難需要引導用戶關注公眾號由交互（可以通過活動公眾號引流，有支付功能業可以通過微信支付后臺設置支付成功后自動關注等等），內容限制較大（設置模板較麻煩、規則多，限制發送內容，如營銷類信息）。

公眾號通知開發需要進入公眾號開發者模式，進入后公眾號自帶的導航欄、關鍵詞等將不能使用且不能使用其他第三方，需要自行開發。

（4）交互形式

可跳轉H5鏈接

（5）文檔鏈接

https://developers.weixin.qq.com/doc/offiaccount/Message_Management/Template_Message_Interface.html

模板消息僅用于公眾號向用戶發送重要的服務通知，只能用于符合其要求的服務場景中，如信用卡刷卡通知，商品購買成功通知等。不支持廣告等營銷類消息以及其它所有可能對用戶造成騷擾的消息。

1. 所有服務號都可以在功能->添加功能插件處看到申請模板消息功能的入口，但只有認證后的服務號才可以申請模板消息的使用權限并獲得該權限；
2. 需要選擇公眾賬號服務所處的2個行業，每月可更改1次所選行業；
3. 在所選擇行業的模板庫中選用已有的模板進行調用；
4. 每個賬號可以同時使用25個模板。
5. 當前每個賬號的模板消息的日調用上限為10萬次，單個模板沒有特殊限制。

可添加模板，但需要符合規則和通用性。

5.?小程序通知

（1）渠道定義

小程序提供的一種模板通知，基于微信的通知渠道，提供了可以高效觸達用戶的模板消息能力，以便實現服務的閉環并提供更佳的體驗，使用場景例如拼團成功、下單成功等等。

（2）前置條件

拿到用戶的openid，用戶需在小程序完成支付或發送表單，需使用公眾號已有的消息模板（新模板需微信審核）。

（3）優缺點

觸達率高，時效高，前置條件滿足較難，內容容限制最大（設置模板較麻煩、規則多，限制模板，限制發送內容，如營銷類信息）。

（4）交互形式

可跳轉指定小程序頁面。

（5）文檔鏈接

https://developers.weixin.qq.com/miniprogram/dev/framework/open-ability/template-

（6）其他

小模板消息于2020年1月10號即將下線，小程序提供了另外的“訂閱模板”，和小程序一致需要申請模板，如果在小程序已經申請過模板，很不幸，需要從頭來過，另外通知的前置限制更加嚴格，需要用戶同意訂閱后才能通知。

https://developers.weixin.qq.com/miniprogram/dev/framework/open-ability/subscribe-message.html

6.?通知中心/站內信

（1）渠道定義

服務、業務、營銷、即時通訊等各個類型的通知的應用內通知中心。

（2）前置條件

大部分需要用戶登錄查看，部分公共信息無需登錄。

（3）優缺點

觸達率高、時效低、前置條件較難滿足需要用戶下載且登錄、內容無限制。

（4）交互形式

交互形式較為自由。

二、結語

以上的通知形態即可以單獨出現，也可以組合配合，另外還有其他的通知渠道，例如電話（無障礙設計）等，具體運用和優先級產品形式定位相關。了解了相關的條件基礎，只是第一步，重要的是怎么運用這些渠道形態，設計消息內容。

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

題圖來自Unsplash，基于CC0協議