To B 產品的消息推送設計

9 評論 52721 瀏覽 477 收藏 11 分鐘

消息推送越來越成為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點推送一次,每次推送一條,在推送的一條消息里面提速待辦的工作條數。用戶早上一上班就可以看到要工作的內容,提高了工作效率,減少了對用戶的干擾。

其它消息推送屬性設置

  • 推送的模板:手機通知欄、彈窗推送的模板設計。手機通知欄設置特定的模板,方便用戶對消息的識別,減少用戶認知難道。但是如果千篇一律的推送,又會造成用戶審美疲勞。標題設計要遵循「AIDA法則」。(何謂AIDA法則:attention-引起注意,interest-產生興趣,desire-喚起欲望,action-點擊或購買行為),個人覺得還是要根據APP本身的定位而定。To B端的APP將意思表達清楚就好,太花俏的文案反而不太適合。
  • 消息推送時的聲音、字體、圖文、動圖設置。
  • 消息與賬戶登錄關系:用戶以游客模式就可以查詢到消息,還是必須登錄后查詢。比如新功能推送這個就應該支持游客模式,項積分、酬金類的推送,就必須登錄后才能查看。

    消息推送平臺

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

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

設計不足之處

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

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

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

 

本文由 @張小菜?原創發布于人人都是產品經理。未經許可,禁止轉載。

更多精彩內容,請關注人人都是產品經理微信公眾號或下載App
評論
評論請登錄
  1. 消息的推送會極大的造成用戶的反感,所以我覺得在做消息推送前一定要先明確每個消息推送的目的和意義。在不影響目的的同時盡可能的減少推送,這樣才能使用戶不屏蔽消息提醒。這篇文章我感覺比較偏向于功能實現,而目的和意義講的比較少。

    來自江蘇 回復
  2. 缺少消息有效期;用來控制消息的發送時間區間。例如你是發給客戶的彈窗消息,那么很長時間沒有登錄,那么一登錄是不是把之前所有都推給客戶?
    還有分類中缺少一個針對所有新用戶的消息分類。每個新戶都會自動接收到幾條消息。

    來自廣東 回復
  3. 其中的消息推送管理平臺能說明下么?

    來自浙江 回復
    1. 我也想了解下消息推送管理平臺如何設計的~

      來自上海 回復
  4. 上線公告:當有新功能上線或對某個問題進行修復時,進行消息推送。
    系統推送:版本更新、系統優化等功能推送。
    這兩個的定義有明顯的區別嗎?我看不出來呀

    來自上海 回復
    1. 上線公告是業務上的,就是顯示每周上線的新功能及在功能上的優化。系統推送是指,版本更新等技術上的更新。不知道這樣有沒有闡述得清楚

      來自福建 回復
    2. 我的理解是版本更新包括了新功能上線、功能優化以及系統優化的,所以看不懂為什么要進一步做區分。還有就是這里的系統推送的這些技術上的更新對于用戶來說有重要到需要單獨設一個tab進行消息推送嗎?

      來自上海 回復
    3. 產品新功能上線公告是屬于業務上的優化,業務每周都會進行調整優化更新,To B端的產品負責人對這塊比較關注,所以單獨拿出來,做一個獨立的模塊。還有個考慮就是,業務部門也要推送一些業務上的公告類消息,以后也放在這個入口里面。像安全加固、系統升級這類消息就不放在這里,做干擾了。對于普通的用戶來說,系統公告一般是不太關注的。

      來自福建 回復
    4. OK謝謝~我倒是覺得這里的系統消息功能可以砍掉

      來自上海 回復