觸達系統進階篇(一):自動化消息
導語:之前分享了從0-1做系統的觸達系統《用戶運營:觸達系統應該如何搭建》,主要講述了觸達系統的從0-1的搭建,重點在于為內部運營人員提供手動發消息的工具;經過了系統多次的迭代和發展,對于觸達系統的認知有了提升,此次來分享自動化消息部分。
一、自動化消息是什么?
區別于運營人員手工創建任務發送的消息,自動化消息是系統根據制訂好的規則進行消息觸發。
自動化消息按照內容類型可以分為通知類消息和營銷類消息。
1)通知類:個人的信息變化通知消息,用于提高用戶的交互頻次和轉化概率,主要有以下幾種:
- 個人狀態變化(如新用戶注冊提醒、會員卡綁定提醒,會員升級、登陸下線等);
- 個人資源變化(如錢包、積分變動等);
- 個人新的互動消息(如聊天、評論、加好友、客服消息等);
- 個人訂單狀態變化(如訂單下單提醒,商品配送提醒,訂單簽收提醒、退款等);
- 個人日程相關提醒(如登機、酒店入住提醒等);
- 個人手動關注的某個主體內容更新(如關注主播上線、關注博主更新等);
- 個人手動關注的活動提醒(如開售提醒、活動開始提醒等);
- 優惠券相關(如卡券到賬提醒、優惠券到期提醒)(注意:此項有爭議,在發送push時,例如小米等渠道會將此認定為營銷類消息,而在發送微信消息時可以使用固定模版進行通知,所以在設定優惠券到期提醒時,需要根據發送方式,確定其使用規范)。
2)營銷類:統一發送的活動通知,區別于手動消息,自動化的消息可以根據營銷規則進行自動通知,節約運營人員的手工操作,并輔以策略用于提高效果。
目前常用的主要有:
- 復購提醒:針對具有復購屬性的商品,在其達到復購期時,精準的觸達復購人群,自動進行復購提醒通知,提升店鋪客戶的復購率;
- 購物車降價提醒: 對用戶加購的商品,計算其當前促銷價格和加入時價格之差是否達到設置的活動通知標準,并針對達到標準的商品進行降價提醒完成轉化;
- 活動提醒:對于用戶感興趣的商品,如果參與了主打活動,對用戶進行活動觸達提醒;
- 關聯銷售:針對具有關聯屬性的商品,對于購買了A商品的用戶,進行B商品的活動提醒;
- 用戶轉化提醒:比如注冊未購買的新客轉化提醒;長期未購買的老客召回;粉絲的轉專屬運營提醒等;
需要注意的是,本文討論的營銷類通知更多的是偏向于自有業務的通知,針對商家的相關規則的設置和自營有所區別,會在之后其它的文章內進行討論。
不同發送方式的服務方式和字段有所區別,比如微信服務號的訂閱通知,模版需要在微信提供的固定字段選擇使用,而push則是直接對接接口,文案可以自己設定,而不同渠道對于通知類和營銷類的發送限制有所區別。
以push舉例:小米限制營銷類的發送總量,但是不限制通知類的發送總量;而vivo兩種都限制。區分營銷類和通知類可以在符合平臺使用規范的前提下增加觸達量。另外,千萬要符合各平臺的使用規范,否則嚴重情況下可能會導致通道被禁用。
而按照觸發方式的不同又可以分為觸發式和定時式:
- 觸發式:以用戶的行為為依據,進行及時觸發;
- 定時式:根據一定規則,系統進行用戶篩選,在設定的時間進行觸發。
定時式和觸發式的系統實現方式有所區別,下面進行一一介紹。
二、觸發類消息的實現方式
觸發類消息有兩種類型:
- 用戶操作后,數據進入業務系統,由業務系統觸發觸達系統進行用戶通知。
- 在觸達系統提前設定好規則,實時采集用戶行為,當用戶的行為滿足設定規則時,及時觸發用戶。
其中前一種的系統形式比較簡單,后一種比較復雜。
先介紹第一種的,第一種主要是需要提供一個通用的發送服務,觸發的節點都是在業務系統控制。符合第一種類型的主要為通知類的,比如訂單發送通知。此流程大概需要三步:
1. 申請模版
此步驟是需要觸達系統提供后臺頁面功能,人工進行模版申請,模版大概需要以下信息:
1)名稱:主要標記模版用途,需要做唯一性校驗;
2)發放方式:不同發送方式決定需要填寫的消息內容。比如短信只需要填寫消息內容,而push需要填寫模版、消息內容和跳轉鏈接等;
3)內容類型:短信和push標注是營銷類還是通知類,此項也會決定消息內容的校驗。比如營銷類的短信必須包含退訂說明,而通知類的則不需要校驗。
4)消息內容:消息內容的設計主要有幾點:
- 根據發放方式的不同展示不同的填寫字段;
- 每個字段的長度限制提示;
- 固定內容和動態字段:固定內容是通過此模版發送的用戶收到的信息全都一致,動態內容則是每人收到的有所不同。而動態內容,可以由觸達系統去查詢,比如“用戶呢稱”,也可以只標記占位,由業務系統傳輸內容,此種可以在觸達系統動態字段選擇“其它”。
5)啟用時間:主要是決定模版是否啟用。有三種生效方式:立即啟用生效,設定時間生效(選擇時精確到分即可)暫不啟用生效。而此三種方式的設計,主要還是在商家和供應商使用的時候更能體現價值。
為什么需要申請模版,而不是直接由業務系統將需要發送的內容通過接口傳輸?
這主要由于:
- 觸達系統比業務系統更清楚的消息規范,能合理控制不同觸達方式的消息的格式規范性;
- 觸達系統比業務系統更容易得知消息規范的變更,如果有變更,可在觸達系統直接操作變更,節約系統的開發成本;
2. 發送
發送節點是由業務系統進行觸發,調用觸達系統提供的通用接口,入參必須的字段有:
- 系統歸屬:標注是哪個系統調用;
- 使用模版;
- 發送用戶:包括用戶id,手機號;
- 動態字段內容:如果模版中有動態字段,需要標注每個用戶的動態內容是什么。
其它字段可根據自己業務自行添加。
而返回的參數則需要返回此次調用的成功和失敗,失敗要標注失敗原因,以及此次調用的任務id;此時的成功和失敗只是接口的調用成功與否,不等于真的觸達到了用戶。
真正觸達用戶的結果因為服務商返回結果的時間差異,需要異步獲得。
3. 結果回執
回執可以有兩種方式:
- 是用發送方提供一個消息接收接口,觸達系統調用其接口將每個用戶的消息狀態返回到其接口;
- 是觸達系統提供通用接口,使用方可以通過此接口查詢結果。
推薦第二種,避免了消息結果需要多個系統存儲造成的數據冗余,也節約了開發量,不需要每次接新系統時都需要觸達系統對接一下接口。
而消息回執需要包含什么呢?
- 每次調用的整體結果:通過任務id,可以查詢任務的發送量、成功量、失敗量等;
- 單個用戶的發送成功:通過任務、用戶查詢用戶的發送成功和失敗。
而任務id是通過發送時返回的,如果通過任務id的查詢需要單獨存儲的話,也可以通過系統+時間+模版來查詢,此種查詢就需要觸達系統進行匯總。
當然,消息回執的接口是非必要的。也可以通過觸達系統的頁面來進行數據的查看。
三、定時類消息的實現方式
定時類消息一般是需要在觸達系統創建規則,然后進行觸發。流程大概分為5步:
1. 創建任務
創建任務和手動有點類似,需要寫明任務的基礎信息、目標用戶規則以及觸達信息的配置:
而這里的創建任務頁面并不是完全配置化的,因為每種策略針對的用戶規則不一樣;比如沉睡用戶可能是針對瀏覽/加購等規則,而生日提醒則是根據生日時間進行提醒;所以新增加一種策略,目標用戶的配置則需要變更。
最初不需要做一種完全通用全部策略的頁面,只需要針對每種策略可能變更的策略支持配置即可;比如對于沉睡用戶的定義,可能會從30天變成15天,這種做個配置頁面方便調整。
而除了用戶的定義,如果是促銷通知類,還需要針對商品進行篩選,確認針對哪些商品進行用戶的篩選和匹配;商品標簽則可以根據品類,品牌,促銷類型,價格區間,利潤率等進行配置。
2. 用戶查找
根據設置的規則進行用戶查詢,此時需要注意查找的時間,為了要在設置的時間進行發送,需要估計系統的處理時間然后提前查找用戶。
3. 消息組裝
此環節之所以提出來專門說,是因為一些策略是需要算法進行匹配的。
比如:促銷通知。針對今天設置的商品規則和用戶規則進行商品和用戶的篩選后,我們為了提高用戶的點擊,我們需要針對每個用戶觸達不同的商品,消息類似于“您感興趣【商品名稱】正在參加【促銷名稱】,快來看看”
而此時我們就需要算法將用戶池和商品池進行匹配,查找用戶最感性的商品,然后觸達系統對于不同用戶的訴求進行組裝并觸達。
4. 發送和結果統計
與手動任務類似,還是要注意用戶的免打擾等,此處不具體提。
四、結語
自動化觸達的設計難點在于策略的制定,要和運營人員進行密切的溝通,根據目標進行策略的提制定,并要及時關注數據進行策略的分析和調整。
另外需要和算法部門密切的溝通和配合,推動算法部門提升算法也是一大重要的工作之一。
本文由 @舉個栗子 原創發布于人人都是產品經理,未經許可,禁止轉載
題圖來自?Unsplash,基于 CC0 協議
你好,看到你貼出的后臺有公眾號消息類的任務創建,但我們知道公眾號消息模版是固定的,無法靈活自定義,那在設計自己的推送系統時公眾號消息這部分該如何設計呢?
你好,想請教一下關于消息觸達規則的設定問題:(1)規則是什么?哪些維度需要設定規則?(2)有無規則管理辦法,比如規則濫用的情況有什么機制/辦法?
想了解下:“用戶操作后,數據進入業務系統,由業務系統觸發觸達系統進行用戶通知?!辈捎媚0宸绞胶?br /> “在觸達系統提前設定好規則,實時采集用戶行為,當用戶的行為滿足設定規則時,及時觸發用戶?!辈捎萌蝿辗绞降脑蚴鞘裁矗?br /> 如果僅是后臺的消息內容的配置發送(無需設好規則)是否采用模板方式即可
是的,兩種方式適用場景不同,系統都應該支持。僅是后臺的消息內容的配置發送(無需設好規則)采用模板方式即可
第一種模版方式,主要邏輯都是在業務系統,且邏輯不復雜,單一業務系統都能完成此類邏輯,比如訂單通知;
而第二種任務方式,處理邏輯相對復雜,單一系統無法自行實現,故采用任務方式。除了適用邏輯復雜場景外,還可對接算法進行算法輔助。如果業務系統自行對接算法,則容易出現混亂且對接方式比較多的情況。場景比如通過算法模型匹配對應的活動進行通知,就適用于任務方式。
感謝~,最近糾結的就是運營使用的觸達后臺之前沒有模板概念,僅是最細粒度的消息未讀,但這有個問題就是無法進行管理,所以想是否用模板去管理,樓主給的建議和我想的一致就沒有太多顧慮了
麻煩問一下,后面的后臺是自己搭建的么,還是第三方平臺呀
是自己搭建的。用三方平臺現在策略層的東西比較少,數據安全也是一個方面。
如果是新起的公司,可以考慮用三方平臺的服務,像有萌和神策等。
公司越來越發展的話,有條件還是要用自己的平臺,數據安全和業務使用上都會比用三方舒服。
好的,謝謝啦