淺談Web端平臺產品消息系統(tǒng)后臺功能規(guī)劃

28 評論 35134 瀏覽 348 收藏 13 分鐘

看了很多關于消息系統(tǒng)規(guī)劃的文章,普遍的都是說明APP(安卓/IOS)的消息系統(tǒng),但是很少從web端進行分析,而筆者借此簡單記錄下自己在規(guī)劃web端平臺產品消息系統(tǒng)(以后臺為主)功能的一個思路。雖然現在互聯網是移動趨勢,但是web還是重量級的,因為它面向的更多是B端用戶。

平臺產品與B端、C端產品來說是具有一定的差異性:B端和C端產品在目標用戶上有明確的區(qū)分,而平臺產品面向的目標用戶有B端、C端或者BC端都有,簡單粗暴理解就是一個聚合平臺。比如:阿里巴巴平臺、天貓平臺、QQ音樂移動音樂平臺、艾瑞咨詢等等。

而我們平臺產品主要是B端的企業(yè)級用戶,所以本次將簡單整理下近期規(guī)劃的一款web端平臺產品的消息系統(tǒng),僅作為參考。

Tips:消息運營
消息標題如何運營、如何保證觸達用戶?這類問題已經有相關文章提及就不再多闡述了。下面主要以后臺功能邏輯來淺談。

以下為本次消息系統(tǒng)規(guī)劃框架:

一、背景

平臺型產品初建期需要保證產品的完整性,必須搭建可控的消息系統(tǒng),形成產品完整的閉環(huán):

  • 一來滿足產品的完整性;
  • 二來確保讓用戶感知到產品是活的;
  • 三來滿足平臺產品上各個業(yè)務的流程。

二、目的

  1. 讓用戶更加容易獲得提醒;
  2. 讓產品更加直接的與用戶產生交互;
  3. 分類整理消息。

三、用戶人群

主要面向B端(企業(yè)級)用戶

四、場景

  1. 營銷類需要:比如運營策略需要的廣告消息、優(yōu)惠消息、活動消息;
  2. 使用服務后的溫馨提醒:比如購買某某產品后的售后(發(fā)票申請進度、售后申請服務進度等等)、注冊使用產品后的版本更新、優(yōu)化說明等;
  3. 互動提醒:比如工單回復提醒、評論關注回復等提醒;
  4. 任務提醒:比如學習某個視頻更新提醒、下載任務提醒、訂閱某條推送提醒等等。

消息提醒的場景主要分為這4類,當然還會有更多,這里不一一窮舉。對于目前產品能確保以上場景都能實現需求,那就可以了。

因為這就是傳說中的MVP?是的沒錯,下面拓展一下:

MVP:最小價值產品或最小可視化產品,這在精益創(chuàng)業(yè)是中很重要的概念。

將核心的功能最先開發(fā)出來在不斷試錯中迭代和優(yōu)化是我們目前的一種產品開發(fā)規(guī)則。

五、消息系統(tǒng)規(guī)劃

消息系統(tǒng)的需求主要分兩大類:功能性需求和非功能性需求。

  • 功能性需求:該產品具有的功能,讓用戶通過這些功能完成任務或者滿足各類業(yè)務需求的功能,這里統(tǒng)稱為功能性需求。比如:人工push、營銷類消息推送、重大版本更新通知、修復公告等。
  • 非功能性需求:主要是產品的性能、系統(tǒng)、進程提醒等需求。比如:系統(tǒng)提醒、事件觸發(fā)提醒、進度/任務跟蹤提醒等。

Tips:消息狀態(tài)
消息系統(tǒng)中,每條消息都具有唯一的狀態(tài)即已讀、未讀和已關閉(刪除,即不在客戶端展示后臺保留數據跟蹤)。而且每條消息隸屬于每個消息的分類下,即消息標簽。這樣區(qū)分的目的是便于分類管理和易讀性。

消息管理/設置:主要是對接收的消息進行管理/設置,用戶和產品之間存在主動接收和被動接收的關系。

用戶可以主動去拒絕接收部分消息,這樣做可以讓用戶在產品上獲得更大的主動權。不同于普通B、C端的產品的是:平臺產品在此類消息管理/設置中將很多的接收權限交給用戶有選擇性的接收。

并不是所有的平臺產品都會有這個功能,對于一些聚集了很多業(yè)務的平臺來說,有這個功能可以有效的避免接收到多余的消息干擾用戶。如:騰訊云、阿里云、百度云等等。

但是對于業(yè)務區(qū)分不明顯且不是很大業(yè)務量的產品來說,這個功能的存在無關痛癢。如:微信公眾平臺、各大媒體后臺等等。

六、管理后臺規(guī)劃

相關字段說明:

  • 消息類型:公告消息、活動消息等??赏ㄟ^管理消息類型進行新增、編輯、刪除操作。這里的消息類型對應的客戶端的消息類型。
  • 狀態(tài):已發(fā)送、未發(fā)送、已關閉。這里的狀態(tài)指的是消息的推送狀態(tài),其中已關閉指的是消息在客戶端做了隱藏(撤回)的操作。
  • 消息標題:根據客戶端的要求,后臺做字符、樣式、位置等限制。
  • 消息內容:根據客戶端的要求,后臺做字符、樣式、位置等限制。
  • 閱讀量:消息在客戶端打開/閱讀的數量具有唯一性。
  • 推送時間:該條消息成功推送到客戶端的時間。
  • 創(chuàng)建時間:創(chuàng)建該條消息的時間。

Tips:管理后臺消息編輯和客戶端有什么需要注意?
管理后臺的消息標題限制字符以及標題的位置樣式是和客戶端分開的。通常我習慣于將客戶端和后臺需求都提及到避免開發(fā)同學忘記了,避免聯調的時候帶來不便。

1.創(chuàng)建消息:

根據不同產品的特性后臺管理也會具有不一樣的功能,但是基本功能都是大同小異的:

  • 消息類型:和客戶端對應,將各個消息分類管理。
  • 推送時間:定時和立即推送可有效的管控并做好運營策略。
  • 推送方式:官網、手機、郵箱等。這里的手機可以采用第三方的接口沒必要在自己開發(fā),當然這里第三方的推送主要是營銷類的短信,對于如果有2B的APP應用則會有不一樣的推送方式這里就不過多說明(因為好多大牛都分析過了)。郵箱的話可以集成公司郵箱的API接口或者采用第三方的營銷API。
  • 推送人群:根據產品的用戶特性,可以簡單的區(qū)分為普通用戶和會員用戶。當然對于特殊的需求還會有指定的用戶人群。為了方便后續(xù)的推送這里面應當可擴展,并不局限于這幾個用戶人群。
  • 消息標題:-
  • 消息內容:富文本編輯器。
  • 新增熱區(qū):單獨把熱區(qū)拿出來講一下。

熱區(qū)可能對于部分沒接觸過的人來說不是很懂,簡單理解為就是:某個頁面指定區(qū)域可以實現點擊跳轉,更簡單粗暴就是超鏈接,點哪里超到哪里。

為什么編輯器要熱區(qū)這個功能?

因為我們看到很多的圖片消息都是帶有領取優(yōu)惠券或者點擊某個按鈕進入到活動詳情,這個時候純圖片和純文本都無法滿足我們的運營需求。所以可視化的熱區(qū)功能將提高我們運營的效率和滿足各種營銷策略。

2.編輯消息

  • 對已發(fā)送狀態(tài)消息可以對其進行的操作僅限于“展示”功能(即在客戶端是否展示)。
  • 未發(fā)送狀態(tài)的消息則可以編輯所有字段的內容。
  • 已關閉狀態(tài)的消息則 不可以進行任何操作在消息后臺中相當于回收站,可以給運營做總結分析。

Tips:為什么發(fā)出去的消息還要做隱藏/撤回的處理?為什么不直接進行編輯呢?

這里提醒一下,發(fā)出去的消息用戶已經接收了,如果對已發(fā)送的消息進行編輯會帶來什么樣的后果以及需要承擔什么樣的風險我們都需要考慮,所以這里不建議直接編輯已發(fā)送的消息。

但是我們需要規(guī)避已發(fā)送的消息是否存在政治敏感、輿論導向或其他,防患于未然才設置一個“展示”的功能。這是一個規(guī)避的手段,萬不得已是不會使用的

七、非功能性需求

主要是對系統(tǒng)自身的一個提醒,產品的進度任務跟蹤以及事件觸發(fā)的非功能性的需求。規(guī)劃:
非功能性需求分類主要有3大類:

  • 業(yè)務需求:主要是產品各個業(yè)務的提醒,如訂閱提醒、任務進度提醒、學習進度提醒等。
  • 系統(tǒng)性能:如發(fā)生無法訪問、卡頓會有系統(tǒng)提醒,當然這里可以設置一些親切的語句來提醒用戶避免流失。
  • 事件觸發(fā):產品使用過程中所觸發(fā)的一些事件,如下拉加載時候提示語或者加載動畫。

非功能性需求的消息目標用戶當然是以“觸發(fā)”為基準,所有用戶只要達到條件觸發(fā)就會由產品自動推送相關的消息,不管是消息中心里面的消息還是一些小小的提示語,都屬于一種非功能性的消息需求。

消息系統(tǒng)的規(guī)劃主要還是需要根據產品的特性講消息進行分類。而后臺的功能從根本上來說本質是一樣的,需要注意的是根據客戶端和產品的業(yè)務進行邏輯區(qū)分,保證能夠觸達用戶。

文章簡單記錄筆者在規(guī)劃web端平臺產品時候的一個思路,web端產品面向的當然不僅是眼前的B端用戶,后續(xù)還將會有第三方供應商和服務商的加入。但是對于消息系統(tǒng)的本質來說這是推送的目標人群多了,具體的是以新增用戶標簽還是另做規(guī)劃還需要以業(yè)務形態(tài)來決定。

 

本文由 @Randy俊 原創(chuàng)發(fā)布于人人都是產品經理。未經許可,禁止轉載。

題圖來自PEXELS,基于CC0協(xié)議

更多精彩內容,請關注人人都是產品經理微信公眾號或下載App
評論
評論請登錄
  1. 你好 可以加個微信嗎??

    來自廣東 回復
    1. 主頁可以加。謝謝閱讀

      來自廣東 回復
  2. 超贊! 多謝分享

    來自北京 回復
  3. 效果圖看不清?

    來自福建 回復
    1. 看不清

      來自浙江 回復
  4. 想問一下,非功能性的消息,也要在管理后臺展示出來嗎?

    來自浙江 回復
    1. 展示出來便于維護和后期運營

      來自廣東 回復
  5. Minimum Viable Product

    來自湖南 回復
  6. 消息的跳轉,可否詳細說明下,對于不同類型的消息不同場景下,用戶收到消息后的跳轉是什么?求指教

    來自北京 回復
  7. 非常完善!干貨滿滿?。。?!

    來自上海 回復
  8. 基礎消息系統(tǒng)已經非常全了,
    后續(xù)自動化配置、管理、分發(fā)tag其實還可以更好

    回復
    1. 你好,我最近也想了解下關于后續(xù)自動化配置這一塊,前輩有什么資料嗎?小白表示還沒有頭緒。 ?

      來自北京 回復
    2. 你好,我最近也想了解下關于后續(xù)自動化配置這一塊,前輩有什么資料嗎?小白表示還沒有頭緒

      來自廣東 回復
  9. 請問熱區(qū)跳轉的鏈接,是在哪里配呢?

    回復
  10. 希望有更多 像本篇一樣的優(yōu)秀實用的好文章 贊! ??

    來自上海 回復
  11. 正好需要設計這個功能,正好搜索到了這篇文章。感謝作者的解惑,寫得很詳細,看完之后有了詳細的思路,很受用,大大的贊

    來自廣東 回復
  12. 有些地方不太懂,想請教一下。關于非功能性的業(yè)務上消息,如訂單的流轉的一些提醒,在后臺設計中,該怎么設置(譬如這個消息的文字模板之類的:“敬的客人,您好。您于2018-04-12 12:22:44下單的商品 xxxxxxx商品 尚未完成訂單,請盡快支付>>>>”)?

    來自廣東 回復
    1. 一般做法:1.先把產品的信息流轉過程用流程圖梳理出來;2.結合思維導圖將每個業(yè)務線需要的推送窮舉出來;3.再表現形式上可以設計消息模板列表、變量列表。
      這里的變量比如,你提到的XXX商品,就是一個變量。訂單狀態(tài)也是一個變量。變量程序后臺設置好,文案我們可以隨時在后臺管理做編輯就可以了。

      來自廣東 回復
  13. 方便加個微信不

    來自北京 回復
    1. 可以呀randyjun1993 ??

      來自廣東 回復
  14. 背景寫的著實佩服

    來自浙江 回復
    1. ??

      來自廣東 回復
  15. 功能描述的很詳細,但是我覺得作為一個項目的痛點,下面兩個明顯不是。
    ———————————————
    一來滿足產品的完整性;
    二來確保讓用戶感知到產品是活的;
    ———————————————
    需不需要發(fā)消息,是業(yè)務需要,使用場景決定的。不完整又怎么滴,滿足用戶才是第一。
    第二點,覺得用”活的”這個詞,不夠精確。

    來自浙江 回復
    1. 滿足用戶雖然是第一,產品完整雖然對用戶來說不痛不癢,但是我們作為產品對自己一手策劃的肯定是希望能保證一個完整的產品架構。
      首先最主要的還是滿足各個業(yè)務場景的需求,畢竟最接觸商業(yè)變現價值的也就這個背景;
      其次產品完整性和感知活的是根據不同階段的產品才會有的,產品發(fā)展前期這個消息功能是完善用戶體驗其中一個功能。
      “活的”可能不夠精確,不過表達的意思是:一個作為B端平臺服務于用戶,更好的觸達用戶。讓用戶知道我們產品是不斷完善和更新,而不是一個“死的”玩意。

      謝謝你的評論。一起加油! ??

      來自廣東 回復
    2. 有點挑刺的回復,居然得到解釋。
      作者的修養(yǎng)讓我佩服,祝你越來越順。

      來自浙江 回復
    3. 淡定淡定,完全沒這個意思。-。-, 解釋是因為別人瀏覽了文章給自己意見和看法,背后肯定會梳理和想方設法去維護自己的立場(當然有時候肯定會陷入無法自拔)。

      PS,也許我立場維護的太過自我,讓你產生誤解。不過還是很感謝有人評論回復,這樣才有更多多巴胺分泌。 ??

      來自廣東 回復
  16. 寫得很詳細,很受用,辛苦了,贊

    來自浙江 回復
    1. 感謝你的閱讀。分享出來增加自己的印象。

      來自廣東 回復