從四方面聊聊,如何從0到1搭建營銷活動后臺
如何從0到1設計一個營銷活動后臺呢?本文作者將從需求、概念設計、原型設計、以及開發與測試這四方面為大家一一解讀,值得一看。
借微信公眾號之便利,目前各個公司(已不局限于互聯網公司)都頻頻利用公眾號開展營銷活動,與用戶進行交互。相比傳統PC/客戶端營銷便捷了不少,前端交互形式不斷簡化,越來越輕,但后端邏輯卻日趨復雜。不論是淘寶、京東這些超級巨頭,考拉、嚴選、唯品會這些一線大牌公司,還是滴滴、同程這些獨角獸,營銷活動的玩法越來越多。
而其中的變數,主要來源于活動邏輯和獎品邏輯,亙古不變,簡單、樸素。
然而,很多中小型/初創公司,為了快速迭代,通常將營銷活動的邏輯寫在具體的活動中,或是只有一個簡單的頁面配置活動的基本信息。這在前期基本適用,但是當業務發展到一定體量,需要靠活動運營、用戶運營發力,進行用戶促活的時候,種種弊端就彰顯出來了。
那么,如何從0到1設計一個營銷活動后臺呢?且往下面看。(看清了是從0到1,不是從0到100,我到不了100,歡迎大家跟我共同沖向100)
一、明確需求,并對業務有一個中長期的認識
與前端產品不同的是,后端產品主要面向的對象是業務/運營人員,雖然也會作為游戲規則制定者影響到用戶,但是關注點還是在業務上。因此,進行后端產品設計時,需要與運營人員進行充分的溝通(如果本身就是運營,那么請多思考),確保系統在完全滿足業務現有需求的基礎上,增加可迭代性。
可以從以下幾點進行思考(不限于此):
- 目前業務發現處于什么階段?
- 業務體量和發展速度是否需要活動運營來支撐?
- 如果需要,用戶更偏向于那種類型的活動?如電商平臺券類活動會多一些,社交平臺曝光量重要一些
- 活動運營的形式能否抽象出來?
- 可以支持的獎勵形式有哪些?
在思考之后,還需要冷靜地對比一下,同行業競品是怎么做的?因為同行業競爭對手往往有著與你類似的市場背景和格局,他們是否著力活動運營,或者已經開始相關客戶關系系統的擴展?
明確需求之后,再開始進行產品設計。詳見魚骨圖:
二、概念設計
在進行概念設計時,需要對后端系統有一個框架性的認識,在大的功能點下,可以逐層進行擴展:
整體架構如下,主要包含全局用戶信息設置、活動類型、活動、獎勵以及數據等幾個方面:
從以下幾個點,逐個進行分析:
1、記得在活動之上,加一個活動類型
有許多活動每個月會定期開展,如各大電商平臺的會員日,但是每次的活動都會有些許不同。類似的業務場景很多,通過活動類型將部分活動進行歸類,可以將共同因子抽象出來。
每個活動類型需要活動id,可以有研發進行定義。
2、具體的活動,邏輯的重中之重
在活動類型之下,就新建不同的活動,每個活動包含活動名稱、描述、活動有效期、數據傳輸方式、條件限制、是否關聯其他活動等字段。
通過活動類型id與活動id,可以唯一定位到一個活動,并且只在活動中開放關聯接口。這么做的好處是:
- 增加活動運營人員的條理性,每個活動都可以進行歸類
- 便于活動數據的調取,一類型活動可以通過活動類型id統一調取數據
- 在保證各個活動獨立性的基礎之上,可以通過活動類型對活動進行統一調控
- 減少外部接口調用風險,對不同商戶,給出固定的活動類型id,對活動id進行更替
其中,活動設置中最核心的就是條件限制,通常會通過等級、新老用戶、注冊時間等多個維度進行條件限制,舉例如下:
- 根據openid限制新老會員參與
- 根據是否X天內是否有購票/消費行為限制參與
- 根據注冊時間限制參與
3、活動的獎勵是什么?請把獎勵單獨拎出來
見過很多活動后臺,在創建活動的時候直接完成了對應獎勵的配置,這導致后續需要修改活動規則的時候,每次都要提交全部信息更新。建議可以將獎勵單獨拎出來,單獨做成一個配置頁。通過選擇對應活動后,完成獎勵的配置,即可完成活動與獎勵的分離。
獎勵具體分為很多種,也都應該有對應的獎勵代碼,通過活動類型id、活動id及獎品id可以唯一定位一個一個獎品。常見的有積分、抵用券、成長值、刷卡金等等,每一種獎勵類型拉出來都可以說一天,尤其是抵用券,支付寶、微信、京東已經把抵用券玩得爐火純青,加上互聯網金融的崛起,抵用券這個概念已經泛化了,想想白條立減/免息券、京券、東券、支付寶紅包、天貓紅包、店鋪紅包、朋友的券……恨不得在所有決策場景中都增加一個抵用券,來促進用戶決策。只有想不到,沒有做不到。
當然大家都這么做肯定是有原因的,也因此催生出了很多抵用券相關的創業機會,這個后續在單獨來談。
初期建議直接采用經典的積分+抵用券的形式,完成基本的用戶回饋、拉留存操作即可。
4、做好配套設置
所謂配套設施,就是貫穿所有活動體系中的一些因子,主要包括:
(1)等級管理
不一定是等級,也可以是成長值、成就、會員級別等等,一定是一個激勵體系。此頁面中,需要對等級、等級對應的經驗、稱號、獎勵、頭像等進行配置。
(2)活動信息管理
即是通過姓名、證件號、手機號郵箱、用戶等級等信息完成用戶個人信息的查詢。
(3)消息發送管理
是否需要消息推送?有些需要,有些不需要。推送消息的目的,是更好的完成促活,所以針對不同的營銷活動,選擇不同渠道進行推送就非常重要。
(4)數據管理
獎勵發放數據、用戶個人數據、消息發送數據,都需要對應的頁面進行查詢和導出,便于后續進行數據分析(盡量少因為調取數據這種事打擾研發大哥可能會被打)
三、原型設計
不同于原型設計在前端產品中的重要地位,在后端產品設計中,原型設計不是特別重要。甚至在很多公司,后端產品是不需要原型設計的。
那么只要有需求文檔就可以了嗎?
在這個階段,顯然有一個比原型圖更重要的東西,那就是數據(字段)。
后端產品可能會頻繁與前端、外部等進行交互,故對接口字段的定義就尤為重要。一個活動的包含了哪些要素?除了活動類型、活動等信息外,還有積分信息、抵用券信息、以及用戶全量信息等。從業務側考慮需要幾張表來存儲信息?信息流是怎么樣的?
這就是后臺系統中的需求文檔。
四、開發與測試
這個階段最核心的是,很多在需求初始階段考慮的問題,在實際開發過程中都很難實現,導致不可避免的對需求的更改。這種情況下,一定要確?;究蚣艿耐旰靡约靶畔⒘鞯耐暾?。
而測試階段,需要以最原始業務的需求進行測試用例的編寫,盡量要求開發給出接口測試的demo,主流程和對應的關鍵接口(如活動參與接口、獎勵發放接口等)一定要跑通。
這塊非產品設計重點,主要是個人的溝通和項目跟進能力。
五、最后
沒錯,按照這個邏輯,一個基本的營銷活動后臺就搭建完成啦?。ú逡痪?,已提離職,恢復自由身不久,歡迎各位來撩)
附帶一個思維導圖,歡迎各位大拿來交流!
作者:whisperbot;公眾號:靈魂為自己找一個伴侶(ID:vashresources)
本文由 @whisperbot 原創發布于人人都是產品經理。未經許可,禁止轉載。
感謝
有一個問題,比如一個活動是一天之內消費滿了1000元的用戶可以獲獎,我要怎么配置這個獲獎規則呢
本文沒提及,一年前寫的,還是有很多不足。
你這個不適合做實時,走日終跑批吧。每日24:00拉用戶當天累計交易數據,滿足條件出發獎勵系統發獎。
謝謝樓主分享,最近負責公司活動體系的搭建,看到了您的文章 幫助很大。
但是有幾點疑問需要求教作者,希望作者看到了 可以回復下
1、數據傳輸方式,可以舉例說明下嗎?
2、是否為鏈條,這個不太理解,是類似于活動的前置和后置活動嗎?
3、關聯其他活動,活動與活動之間是如何進行關聯的?我外的一場活動需要完成幾個訴求,比如一個活動 新用戶是0元購,老用戶是分享得禮物,這樣情況下,我們是如何管理的?
需要指定活動生效的端,PC還是H5,是在你的條件限制里面嗎,謝回答
老哥 能給個聯系方式嗎
請教下:數據傳輸方式是指什么?
好支持作者 ??
好文,收藏。我目前來說。如何保持信息流的完整性是個難題
先mark在看