如何從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 原創發布于人人都是產品經理。未經許可，禁止轉載。