To B 產品的消息推送設計

消息推送越來越成為APP中不可或缺的功能。好的推送可以提升用戶的活躍度、粘性、參與度。但是，設計的不好容易引起用戶的反感，提高產品的卸載率。下面分享的就是我對於消息推送功能設計的過程。

每個新功能的開發都要基於自身產品的定位，明確功能設計的目的。由於我負責產品的定位是To B 端的工具型產品，設計的目的是提醒用戶每日的工作內容，提高用戶的參與度。所以整個功能設計都在這個基調上進行，兼顧一些拓展性。

前期設計參照了幾個市面主流APP的消息推送功能，再結合產品本身的定位進行方案的選擇與調整。整個推送功能的設計分為以下幾個模塊：數據源、推送管理平台、推送消息設置、推送顆粒度設置、歷史倉庫、數據分析、第三方几部分。下文主要闡述推送消息設置、第三方兩部分。

以下是整個設計的框架圖：

推送消息設置

消息分類

消息分類跟產品的定位是緊密相關的。例如：淘寶的定位是商品的交易平台，所以界面上設置了物流消息、通知消息、互動消息等消息入口；噹噹讀書的定位是電子書購買、閱讀、書評的平台，所以設置了小鈴鐺（買書的貨幣）、回復我的、書籍更新等入口；網易雲音樂的定位是音樂播放下載、分享、交流的平台，所以設置了雲音樂秘書、評論等入口。

消息分類的展示樣式：常見的有列表、TAB頁的形式，或者是兩種展現形式進行組合。下圖為不同淘寶、噹噹讀書、網易雲音樂三個APP的消息界面截圖：

我目前設計的產品要實現的是對工作內容的推送，且用戶對每周上線的新功能比較關注，所以將消息分為了上線公告、業務消息、系統消息三大部分。整個消息的界面設計參照了淘寶。在底部進行大類區分，然後在每個大類裡面以列表的形式做二級分類。

• 上線公告：當有新功能上線或對某個問題進行修復時，進行消息推送。
• 業務消息：推送反饋用戶的業務完成情況，提醒用戶完成相應的工作。在業務消息內支持多種業務的推送。
• 系統推送：版本更新、系統優化等功能推送。

界面草圖如下：

消息推送形式：手機通知欄、彈窗、紅點、角標

各種類通知欄的強弱感知如下：手機通知欄>彈窗>角標>紅點。多種形式也可以組合使用。

• 手機通知欄：推送級別較高。支持用戶在未使用APP時進行提醒。刺激用戶打開使用APP。
• 彈窗：打開APP時，進行彈窗消息推送。支持用戶打開APP后，進入新的功能模塊。
• 紅點：往往設置在APP內消息的入口處，屬於較弱的提示。
• 角標：設置在APP圖標上或者APP內菜單入口，提示未讀消息的數量。

下圖是各類消息類型的樣式：

由於我目前產品需求負責人希望實現：用戶在沒有使用APP的情況下，引導用戶進入APP，完成工作內容。所以產品採用的是手機通知欄推送。之後要上線的公告消息、系統消息功能推送，會偏向於使用彈窗推送、角標提示方式，這樣不會頻繁的干擾用戶。

消息推送目的地：消息中心、具體消息頁面

推送的落地頁面往往跟推送的內容有很大關係。如果是推薦一款理財產品、提示一個物流進度，點擊后都是進入相應的消息界面。如果是一次推送多個系統消息，無法法直接跳轉到某個具體界面，只能先進入中心，再選擇閱讀。每個消息都單獨推送是很容易引起用戶反感的。

• 消息中心：提高其它分類消息的曝光度。進入消息中心界面，用戶可重新選擇相應的分類消息進行閱讀。
• 具體消息：一般適用於具體的某次活動、或者是新聞類的資訊。用戶點擊提醒，說明是對消息的內容感興趣，跳轉至詳情頁，直奔主題

我這次的產品設計將目的地設置為了消息中心。原因有二：其一，由於消息入口是新上線的，將目的地引入消息中心，可提高該入口的曝光度，為之後上線的公告推送、系統推送做預熱。其二，為了不打擾用戶，每天只推送一次消息，這一條消息內包含有多條的待辦事項，故不能直接進入對應的具體消息界面。

消息推送時機

• 主要分為定時推送、實時推送。

定時推送：外賣型APP的推送，一般要設置在飯點前推送。也可根據用戶的使用習慣，進行推送的細分。比如用戶點一般在晚上8點的時候點外賣，就可以在7點半的時候進行消息定時推送；也可根據用戶的使用頻率進行推送。如，用戶七天內未使用APP，則進行消息推送等。

實時推送：發生了新的新聞，有新的促銷產生，就會實時進行消息推送。特別是對於有時限性質的消息，如果延遲推送，就可能給用戶造成了損失。

• 遵循克制的原則。對於To B 端的產品雖然不用擔心卸載率，但推送次數過頻繁，推送過多無價值的內容，也容易引起用戶的反感。如果是To C的產品往往容易導致用戶卸載之類的問題。
• 用戶首次安裝APP后，往往會關閉了消息推送功能。有時候需引導用戶打開。引導時機可以是系統更新、有重要業務功能上線。

我這次產品設計，由於是業務上功能上的推送，實時性要求不強，故設計為了定時推送。每天早上9:00點推送一次，每次推送一條，在推送的一條消息裡面提速待辦的工作條數。用戶早上一上班就可以看到要工作的內容，提高了工作效率，減少了對用戶的干擾。

其它消息推送屬性設置

消息與賬戶登錄關係：用戶以遊客模式就可以查詢到消息，還是必須登錄后查詢。比如新功能推送這個就應該支持遊客模式，項積分、酬金類的推送，就必須登錄后才能查看。

目前消息推送主要分為以下三個模塊：手機廠商（小米推送、華為推送）、第三方（友盟推送、極光推送、個推）、BAT推送平台（阿里雲推送、騰訊信鴿、百度雲推送）也可以進行多種推送形式的組合。

由於之前公司的產品已經集成了個推，所以是沿用之前的方案，提高開發的效率。具體在產品測試的時候也有些反饋小米、華為的進程取消后，無法接收到推送的消息。之後產品可能改進為採用個推+小米推送+華為推送的模式。

設計不足之處

本次設計雖然在後台預留了消息推送的多維度（版本、機型、地市）配置。但是由於前期對用戶數據統計分析的不到位，導致無法對於推送消息進行多維度、細顆粒度分析。如：哪些地市的用戶對於消息推送點擊率比較高、用戶對於推送消息的點擊率有多少等。

對於消息的到達率、轉化率沒有定義好，無法衡量第三方推送是否達到了預期效果。無法從數據上獲知小米、華為等機型推送的消息到達率是否有問題。

無法從數據上統計，用戶是否反感這種推送設計，用戶對於設計的推送模板是否感興趣，推送的內容是否影響到了用戶。只能通過用戶的反饋來檢測。

本文由 @張小菜 原創發佈於人人都是產品經理。未經許可，禁止轉載。