從四方面聊聊,如何從0到1搭建營銷活動后臺

10 評論 52030 瀏覽 379 收藏 11 分鐘

如何從0到1設計一個營銷活動后臺呢?本文作者將從需求、概念設計、原型設計、以及開發與測試這四方面為大家一一解讀,值得一看。

借微信公眾號之便利,目前各個公司(已不局限于互聯網公司)都頻頻利用公眾號開展營銷活動,與用戶進行交互。相比傳統PC/客戶端營銷便捷了不少,前端交互形式不斷簡化,越來越輕,但后端邏輯卻日趨復雜。不論是淘寶、京東這些超級巨頭,考拉、嚴選、唯品會這些一線大牌公司,還是滴滴、同程這些獨角獸,營銷活動的玩法越來越多。

而其中的變數,主要來源于活動邏輯和獎品邏輯,亙古不變,簡單、樸素。

然而,很多中小型/初創公司,為了快速迭代,通常將營銷活動的邏輯寫在具體的活動中,或是只有一個簡單的頁面配置活動的基本信息。這在前期基本適用,但是當業務發展到一定體量,需要靠活動運營、用戶運營發力,進行用戶促活的時候,種種弊端就彰顯出來了。

那么,如何從0到1設計一個營銷活動后臺呢?且往下面看。(看清了是從0到1,不是從0到100,我到不了100,歡迎大家跟我共同沖向100)

一、明確需求,并對業務有一個中長期的認識

與前端產品不同的是,后端產品主要面向的對象是業務/運營人員,雖然也會作為游戲規則制定者影響到用戶,但是關注點還是在業務上。因此,進行后端產品設計時,需要與運營人員進行充分的溝通(如果本身就是運營,那么請多思考),確保系統在完全滿足業務現有需求的基礎上,增加可迭代性。

可以從以下幾點進行思考(不限于此):

  • 目前業務發現處于什么階段?
  • 業務體量和發展速度是否需要活動運營來支撐?
  • 如果需要,用戶更偏向于那種類型的活動?如電商平臺券類活動會多一些,社交平臺曝光量重要一些
  • 活動運營的形式能否抽象出來?
  • 可以支持的獎勵形式有哪些?

在思考之后,還需要冷靜地對比一下,同行業競品是怎么做的?因為同行業競爭對手往往有著與你類似的市場背景和格局,他們是否著力活動運營,或者已經開始相關客戶關系系統的擴展?

明確需求之后,再開始進行產品設計。詳見魚骨圖:

二、概念設計

在進行概念設計時,需要對后端系統有一個框架性的認識,在大的功能點下,可以逐層進行擴展:

整體架構如下,主要包含全局用戶信息設置、活動類型、活動、獎勵以及數據等幾個方面:

從以下幾個點,逐個進行分析:

1、記得在活動之上,加一個活動類型

有許多活動每個月會定期開展,如各大電商平臺的會員日,但是每次的活動都會有些許不同。類似的業務場景很多,通過活動類型將部分活動進行歸類,可以將共同因子抽象出來。

每個活動類型需要活動id,可以有研發進行定義。

2、具體的活動,邏輯的重中之重

在活動類型之下,就新建不同的活動,每個活動包含活動名稱、描述、活動有效期、數據傳輸方式、條件限制、是否關聯其他活動等字段。

通過活動類型id與活動id,可以唯一定位到一個活動,并且只在活動中開放關聯接口。這么做的好處是:

  1. 增加活動運營人員的條理性,每個活動都可以進行歸類
  2. 便于活動數據的調取,一類型活動可以通過活動類型id統一調取數據
  3. 在保證各個活動獨立性的基礎之上,可以通過活動類型對活動進行統一調控
  4. 減少外部接口調用風險,對不同商戶,給出固定的活動類型id,對活動id進行更替

其中,活動設置中最核心的就是條件限制,通常會通過等級、新老用戶、注冊時間等多個維度進行條件限制,舉例如下:

  • 根據openid限制新老會員參與
  • 根據是否X天內是否有購票/消費行為限制參與
  • 根據注冊時間限制參與

3、活動的獎勵是什么?請把獎勵單獨拎出來

見過很多活動后臺,在創建活動的時候直接完成了對應獎勵的配置,這導致后續需要修改活動規則的時候,每次都要提交全部信息更新。建議可以將獎勵單獨拎出來,單獨做成一個配置頁。通過選擇對應活動后,完成獎勵的配置,即可完成活動與獎勵的分離。

獎勵具體分為很多種,也都應該有對應的獎勵代碼,通過活動類型id、活動id及獎品id可以唯一定位一個一個獎品。常見的有積分、抵用券、成長值、刷卡金等等,每一種獎勵類型拉出來都可以說一天,尤其是抵用券,支付寶、微信、京東已經把抵用券玩得爐火純青,加上互聯網金融的崛起,抵用券這個概念已經泛化了,想想白條立減/免息券、京券、東券、支付寶紅包、天貓紅包、店鋪紅包、朋友的券……恨不得在所有決策場景中都增加一個抵用券,來促進用戶決策。只有想不到,沒有做不到。

當然大家都這么做肯定是有原因的,也因此催生出了很多抵用券相關的創業機會,這個后續在單獨來談。

初期建議直接采用經典的積分+抵用券的形式,完成基本的用戶回饋、拉留存操作即可。

4、做好配套設置

所謂配套設施,就是貫穿所有活動體系中的一些因子,主要包括:

(1)等級管理

不一定是等級,也可以是成長值、成就、會員級別等等,一定是一個激勵體系。此頁面中,需要對等級、等級對應的經驗、稱號、獎勵、頭像等進行配置。

(2)活動信息管理

即是通過姓名、證件號、手機號郵箱、用戶等級等信息完成用戶個人信息的查詢。

(3)消息發送管理

是否需要消息推送?有些需要,有些不需要。推送消息的目的,是更好的完成促活,所以針對不同的營銷活動,選擇不同渠道進行推送就非常重要。

(4)數據管理

獎勵發放數據、用戶個人數據、消息發送數據,都需要對應的頁面進行查詢和導出,便于后續進行數據分析(盡量少因為調取數據這種事打擾研發大哥可能會被打)

三、原型設計

不同于原型設計在前端產品中的重要地位,在后端產品設計中,原型設計不是特別重要。甚至在很多公司,后端產品是不需要原型設計的。

那么只要有需求文檔就可以了嗎?

在這個階段,顯然有一個比原型圖更重要的東西,那就是數據(字段)。

后端產品可能會頻繁與前端、外部等進行交互,故對接口字段的定義就尤為重要。一個活動的包含了哪些要素?除了活動類型、活動等信息外,還有積分信息、抵用券信息、以及用戶全量信息等。從業務側考慮需要幾張表來存儲信息?信息流是怎么樣的?

這就是后臺系統中的需求文檔。

四、開發與測試

這個階段最核心的是,很多在需求初始階段考慮的問題,在實際開發過程中都很難實現,導致不可避免的對需求的更改。這種情況下,一定要確?;究蚣艿耐旰靡约靶畔⒘鞯耐暾?。

而測試階段,需要以最原始業務的需求進行測試用例的編寫,盡量要求開發給出接口測試的demo,主流程和對應的關鍵接口(如活動參與接口、獎勵發放接口等)一定要跑通。

這塊非產品設計重點,主要是個人的溝通和項目跟進能力。

五、最后

沒錯,按照這個邏輯,一個基本的營銷活動后臺就搭建完成啦?。ú逡痪?,已提離職,恢復自由身不久,歡迎各位來撩)

附帶一個思維導圖,歡迎各位大拿來交流!

 

作者:whisperbot;公眾號:靈魂為自己找一個伴侶(ID:vashresources)

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

更多精彩內容,請關注人人都是產品經理微信公眾號或下載App
評論
評論請登錄
  1. 感謝

    來自北京 回復
  2. 有一個問題,比如一個活動是一天之內消費滿了1000元的用戶可以獲獎,我要怎么配置這個獲獎規則呢

    來自北京 回復
    1. 本文沒提及,一年前寫的,還是有很多不足。
      你這個不適合做實時,走日終跑批吧。每日24:00拉用戶當天累計交易數據,滿足條件出發獎勵系統發獎。

      回復
  3. 謝謝樓主分享,最近負責公司活動體系的搭建,看到了您的文章 幫助很大。
    但是有幾點疑問需要求教作者,希望作者看到了 可以回復下
    1、數據傳輸方式,可以舉例說明下嗎?
    2、是否為鏈條,這個不太理解,是類似于活動的前置和后置活動嗎?
    3、關聯其他活動,活動與活動之間是如何進行關聯的?我外的一場活動需要完成幾個訴求,比如一個活動 新用戶是0元購,老用戶是分享得禮物,這樣情況下,我們是如何管理的?

    來自河南 回復
  4. 需要指定活動生效的端,PC還是H5,是在你的條件限制里面嗎,謝回答

    來自上海 回復
  5. 老哥 能給個聯系方式嗎

    來自上海 回復
  6. 請教下:數據傳輸方式是指什么?

    來自廣東 回復
  7. 好支持作者 ??

    來自北京 回復
  8. 好文,收藏。我目前來說。如何保持信息流的完整性是個難題

    回復
  9. 先mark在看

    來自廣東 回復