從0到1搭建消息推送管理平臺
本文意在幫助大家從零到一,搭建一套較為完善的公司內部消息推送管理平臺,對公司內部各業務線、產品線的消息推送進行統一管理、統一發送。
一、推送的定義與價值
個人將推送的定義為消息發送方將信息傳遞給接受者的行為。結合到我們日常的場景,就是公司的運營同學或業務系統將營銷消息或通知消息通過短信、push、微信等渠道發送給用戶的行為。
每天針對用戶的推送消息可以引導用戶參加活動、閱讀資訊、查看賬單等行為,是一塊重要的流量入口,推送是推動業務目標的達成的重要手段。
二、本文目的
搭建一套較為完善的公司內部消息推送管理平臺,對公司內部各業務線、產品線的消息推送進行統一管理,統一發送;這樣既提高了公司的運營效率,又保證了用戶體驗。
本文的目的主要說明系統的產品設計思路,對于深入的短信、push、微信各渠道的發送機制說明在后續文章進行介紹。
三、推送系統流程
一般來說,消息推送有2種發送方式,一種方式為運營活動批量定時投放,需提供系統功能方便運營篩選用戶,然后編輯文案,經審核通過后進行發送。
另一種是需要實時觸發的消息,比如支付成功通知、驗證碼獲取、滿足某種條件觸發的營銷活動等消息,這類時效性要求較高且每個用戶發送的消息內容中涉及到差異化的參數,需要業務應用實時觸發。
觸發的消息需經過一定的過濾與攔截規則,針對于短期內已經覆蓋過用戶進行過濾,異?;蛘卟缓弦幍南⑦M行攔截,按照設定好的渠道進行推送。
四、數據準備
對于消息推送系統,需要獲取投放的目標用戶的賬號數據,往往公司產品的customer ID和對應推送渠道的賬號不一致,需要獲取綁定關系,比如短信需要手機號,push需要SDK上報的token,微信需要使用OPEN ID,相關數據的采集在各個渠道的發送機制的文章里進行闡述。
五、消息創建
5.1 投放人群選擇
日常的運營活動為了更加精準,提高活動轉化率,運營同學會根據一些用戶的特征進行篩選,比如北京地區用戶,近3天內有登錄過APP的用戶等等,因此消息投放系統需與公司內部數據部門的標簽系統進行對接,提供運營同學投放人群選擇。
接口實時觸發的消息,一般需要業務系統監控到用戶行為,將用戶賬號與需要的參數通過MQ或者接口傳遞至消息推送系統進行發送。
也需提供用戶賬號文件上傳功能,以便突發事件需要及時告知用戶,避免來不及對涉及用戶數據錄入標簽系統等問題。
5.2 消息類型與等級劃分
消息的類型的應以消息內容的目的進行劃分,大類可分為通知、營銷、驗證碼等類型。
例如,短信行業內分為通知、營銷、驗證碼類型的消息, 該類型的劃分主要為方便路由短信至SP服務商不同通道,不同的通道觸達率也不同,為了保證重要短信的觸達率,需要將各個內容的短信路由至不同的通道發送。
結合個人經驗,公司內部可以根據實際情況進行更細粒度的劃分,比如增加通知+營銷類型,可能場景為用戶支付成功后,在表述完用戶支付成功信息后,結合適當場景增加領取優惠文案,引導用戶向其他活動轉化。
對于金融借貸類的機構,也可增加還款通知類型,主要為用戶產生逾期行為需要提示還款的消息;原因為特殊期間,還款通知類短信可能會受特別的管制,單獨出來可以進行較好的監控與處理。
對于通知類的消息,也應該按照等級進行劃分,比如用戶支付成功提示消息和優惠券到賬通知消息,顯然不應該是同一等級。支付消息涉及用戶資金變動,通知等級較高;優惠券到賬消息更偏營銷類型,通知等級較低。為避免對用戶產生更多干擾,需要分級進行控制,必要的時候降低等級較低的消息的推送頻率。
5.3 消息內容
不同的渠道的消息,所需要的消息內容不一樣,短信內容僅需要短信對話框內的文案即可,PUSH需要展示標題與內容摘要;微信有模板消息與圖文、語音等多類型的消息內容。
在產品設計時,選擇了對應的投放渠道后,應展示對應渠道所需的字段,且為必填項。
5.4 消息跳轉
消息觸達到用戶后,對于感興趣的用戶需要進一步了解信息,那么目前各類消息的載體不是有足夠的空間來展示所有的信息,因此需要跳轉到落地頁進行詳細信息獲取。
短信類型的消息需要將長鏈轉化成短鏈再進行發送,一是為了節省成本,因為短信是按照字符數進行收費的,二是為了用戶體驗,用戶在手機上看到的不應該是一對長的亂碼。
PUSH需要根據跳轉的不同的頁面設置不同的跳轉類型,如H5頁面和原生頁面,跳轉協議由客戶端提供,消息系統只需要將其配置到系統上,運營同學可以選擇就可以。
微信的消息內容一般模板消息條狀到H5的活動頁,圖文消息跳轉到文章詳情,文本消息中也可以添加超鏈接,跳轉到小程序。
5.5 其他需記錄信息
消息發送部門:此數據是用來作為后期短信費用結算的依據,按照消息發送部門扣減公司內部各業務線的費用,對于PUSH、微信消息等免費的資源,也可分析關系各個業務部門對消息資源的使用情況。
轉化行為口徑:消息點擊后的一個環節一般是轉化,為了更好地衡量消息發送的質量,應該記錄下每條消息下發的目的,比如:訂單、實名、激活、下載、通知等,將消息與轉化行為匹配起來進行數據分析。
產研負責人:在消息發送之前應該記錄好每個任務或模板,對應業務線的產品、研發實際消息的負責人,當消息發生客訴時,通過消息記錄查詢功能,便可迅速定位消息的產研負責人,緊急確認對應消息是否有異常并解決。
5.6 推送時間設置
對于不同發送形式的消息,推送時間不同。創建的消息任務可以預定時間進行發送;對于已經固化下的營銷場景,需設置周期性任務,設置初始執行時間與執行周期,降低運營操作成本。接口觸發的時間一般為實時觸發,觸發時間由業務系統決定。
5.7 在線測試
當消息任務設置好后,需要驗證消息投放出去后展示的效果與相關跳轉是否正常,避免造成線上推送事故。測試需要發送運營設置好的真實內容,推送對象為內部消息創建者。為避免出現消息誤發,測試發送的文案前應添加“測試”,或設置測試白名單,不在白名單內的賬號無法進行測試。
六、消息審核
當消息任務或者消息模板創建好,需要經過謹慎審核后才能發送,避免出現工作失誤產生不良影響。
審核級別一般需要業務線內部負責人審核與公司平臺或者對應職能部門審核。審核要點主要為:消息文案是否符合廣告法、消息跳轉是否正常、發送頻率、時間是否合適等。
七、消息過濾與攔截
消息過濾主要針對營銷類型消息,時段限制(早上9點至晚上8點之間可發送)、頻率限制(用戶7天內只能收到1條短信,針對于周期性任務,同一任務觸達過的用戶可以進一步擴大過濾周期)、黑名單限制(用戶退訂)。
消息攔截主要為限制發送量級,比如每個業務線針對同一用戶每日最多發送5條短信;公司整體對同一個用戶最多發送30條短信;短時間(時間可設置,如300S)內同一用戶重復內容過濾;量級的控制只要為避免由于業務系統故障造成的對用戶消息轟炸,產生不良影響。
關鍵詞攔截,如包含違法、暴力等詞匯。
不同的場景使用的過濾頻率可做適當調整,比如用戶對短信消息的容忍度比push的容忍度較低,因此短信頻率應該更加嚴格。
八、消息發送
目前經過種種邏輯的處理,消息終于到了發送環節。發送環節主要后臺邏輯,重點要優化消息發送的性能,提高消息發送的穩定性,避免業務損失。發送環節應該添加監控并且適當打印日志,以便及發現異常并定位問題。
九、消息路由
短信、安卓push均可接入多個渠道,搭建分發集群??梢愿鶕I務業務邏輯指定通道發送,也可以根據下游通道狀態自動路由。
十、數據分析
對于觸達系統來說,數據分析一般按照消息的全流程進行分析,包括發送數量——觸達數量——點擊數量——轉化數據。
如果涉及消息對APP進行導流,提高APP活躍,也許統計各消息為帶來APP喚起次數。
對于短信來說,涉及到短信費用,需要針對渠道和成功觸達條數進行計費,設計對賬看板。
短信退訂、PUSH關閉等等用戶行為數據也需要進行分析,便于調整后續觸達策略。
十一、后臺管理
通道路由配置
對于短信類型的消息,涉及到簽名與通道,不同的業務場景需要不同的短信簽名,需要將某些賬號、某些模板的消息路由至固定通道側。以及系統需要根據下游通道性能或狀態自動路由消息。
消息發送記錄查詢
針對于近期發送出去的相關消息,需提供客服側或運營側一定的查詢功能,以便用戶來電咨詢相關消息問題,比如未收到驗證碼消息、沒有進行操作卻收到消息等等情況。
黑名單
黑名單功能主要應用于消息過濾,當用戶投訴或退訂后,避免再給用戶發送消息,屏蔽的粒度需根據消息類型進行屏蔽,可適當根據內部業務劃分。
過濾與攔截規則配置
- 需針對同一用戶設置消息發送上限,避免由于業務系統異常導致對用戶造成轟炸。
- 重復內容攔截,需設置一定時間內,完全相同內容進行攔截,避免重復發送。
- 關鍵詞攔截,需針對于違規、違法的關鍵詞進行攔截,避免出現運營事故。
- 針對于營銷消息,需根據不同的觸達方式,控制觸達頻率,避免對用戶造成干擾,反而讓用戶對品牌產生反感心理。
上行管理
上行管理主要應用于短信消息,用戶回復退訂或辦理業務的關鍵詞。由于從運營商到發送者的上行過程不能精確到用戶回復的是哪條消息(也可能用戶主動給某些號碼發送短信),為了保證各場景不互相影響,需控制上行關鍵詞唯一。
以上內容為個人經驗總結,歡迎討論指正。
相關閱讀
本文由 @卓別木 原創發布于人人都是產品經理。未經許可,禁止轉載
題圖來自Unsplash,基于CC0協議
真的很有用!
請問下,如果在平臺針對流程節點觸發短信推送,關于流程管理這塊要,功能設計上能推薦下可以參考哪個產品的樣式嗎?
你好,請問消息推送速度呢,有必要限制嗎
看自己的需求。消息推送的速度跟服務器資源相關,如果資源不是很夠,還是需要限制的,不然推送速度太高,你的平臺未必能穩住
好的,謝謝解答,后面了解到還有另外一種考慮,就是可避免同時引入大流量,導致平臺 hold 不住,據說鏈家就發生過類似的事故
很實在。
寫的很詳細,另外我想問下,在審核環節是否可以在測試之前完成,以最后的測試結果為依據決定是否投放?
目前是人工進行測試,測試有問題或者沒有達到需求方的展示的預期就不會投放,要不然測試的價值就不存在了。測試主要來看消息的文案是否違反廣告法,是否有太大的歧義,還有對應的跳轉是否正確,
很棒!上周我剛做了用戶召回機制,整體和作者一樣,只不過我漏了整體限制和消息過濾、攔截
很全面,剛好最近準備搭建一個消息推送系統,可以加個好友嗎?
可以溝通下哈,QQ712635580
學習了,感謝大佬
流程很全面,感謝大佬