營銷中心如果把它單單、看作是發券平臺，就太過簡單了。完整的營銷中心是集活動、券、規則、發放、審核、數據為一體的一站式解決方案。幫助運營人員發現問題、輔助決策、完成運營方案制定；幫助產品人員挖掘有效數據、構建畫像。
營銷中心形態各異，大致可分為：電商、門店和第三方營銷平臺。
淘寶、京東等電商平臺的商家端都會配備營銷中心，主要用於發券、建立活動和數據統計分析；餓了麼、美團、盒馬等外賣或新零售平臺主要紮根於實體門店，幫助門店完成線上店鋪的營銷活動發放和線下門店的到店活動；第三方營銷平臺可以不提供線上店鋪服務，僅作為渠道運營商存在，提供券、促銷等運營活動的發放。
筆者給大家分享的營銷中心具有普適性，可以兼容線上線下各場景。
一、營銷中心的實質
營銷中心這個字眼實在太龐大，僅靠一篇文章很難講透徹，筆者接下來講的也都是一些實戰經驗，如果有講的不明白的歡迎踴躍發言討論。
1. 主體
營銷中心的發放/創建主體是一個主題（theme），例如：創建一個主題活動——“三八婦女節，逛吃逛喝我買單”，這個活動裡可能會包含線上商城的優惠券、店鋪券，也可能包含滿減活動；其次，主題也可以通過H5頁面傳播，同樣也可以通過線下易拉寶宣傳。
這種組合方式最大化地分離了主題和內容，讓營銷平臺使用起來更明確、數據統計更精確、用戶畫像更準確；同時在接下來的創建、審核和發放環節，同樣益處多多。
2. 規則
上圖是某平臺規則設置頁面的截圖，基本上在規則方面都大同小異，下面這張圖是筆者針對主題和活動概念設置的一些規則。
這裡要強調幾點：
規則是需要預設的：
我見過有的營銷平臺，規則都是現加的，更甚者直接在活動創建的代碼裡補充上，這是非常不可取的。一方面太過於麻煩，另一方面不便於數據統計和分析，在活動期間發生BUG等突發情況，糾錯難度大
規則不可能全覆蓋：
筆者一開始天真的以為：只要將所有的規則都納入系統邏輯即可，規劃中發現這是不太可能的。因為活動形式有千千萬，新的活動形式也在日益更新，有的新活動就有新的規則，所以在規則預設上不需要太過於追求全面，儘可能覆蓋當前活動形式即可。
不建議使用統一規則設置：
有的營銷系統會將限制規則放在發放階段去做，作為統一收口處。
但筆者不建議如此，其一，不同活動限制規則可能不同（雖然像有效期等規則是相同的，但仍然有不少規則是存在差異的）；其二，統一收口在多人員、多部門協同辦公上可能存在問題，公司裡創建活動和最後審核發放的可能是不同的人，關注的點不同，創建的人更關注活動細節，審核的人更關注活動全局，讓審核的人去設定統一規則不太適合。
3. 審核
審核作為可選步驟，在這裡主要強調兩點：
如果不需要審核，也請寫進系統邏輯：
審核在許多小企業中是可以跳過的，但是希望大家也督促後端開發將其寫入底層邏輯中，至於審核與否，根據實際業務需求出發。往後如果需要加上審核邏輯，不需要再擔心重大的邏輯變更問題。
多級審核邏輯：
多級審核的概念是指：多名不同級別的人通過多階段的審核流程，批准通過或不通過。
在這裡，我著重強調將主題、券、活動分開設置審核邏輯，且需要考慮逆流程。上文已經交代了，不同的人員關注點不同，領導審核主題的宏觀信息，如利潤、成本、時間等，運營人員審核的是活動和券的內容細節。
4. 發放
發放是筆者認為最為複雜和重要的模塊，發放承接了主題（含活動內容），設置發放的信息，最終數據彙總也會受發放時設置的信息影響。
發放階段主要設置以下信息：
發放渠道：渠道一般分為線上（app、小程序、公眾號、雙微等）和線下（門店、賣場、戶外等）；線上線下又可以細分出很多場景，例如：線下自助POS支付後，線下POS支付前，門店活動區域掃碼，線上分享，廣告車/花車巡遊，宣傳海報，傳單等。
消費方式限制：又稱為核銷限制，主要作為消費渠道的限制，可以分隔線上線下不同的運營方式、有效地引流和便於數據收集。
發放人群：不在設置活動和券的時候做，是因為發放人群是針對主題而言的，作為統一收口限制的規則。
發放位置：這塊主要考慮到線上線下不同場景；同時便於運營人員在沒有開發的配合下，就能完成運營活動的投放。
5. 數據
營銷中心內的數據模塊，主要展示活動相關，如：活動GMV，利潤，拉新，促活，成交筆數，領取數量，使用數量，分享數量，用戶畫像等。
數據是作為運營分析和決策制定的關鍵因素，但數據模塊過於龐大，筆者就不在這裡展開談論，想要詳細瞭解大家可以自行搜索相關文章。
二、券和活動的區別設計
剛才在講主題的時候，有提到過券和活動的概念。那麼，現在就來講一下：為什麼故意要將活動形式分為券和活動（也可以理解為促銷）兩種呢？
籠統地將兩者混為一談，在系統設計開發上會造成邏輯混亂——規則設置、數據統計、運營目的都不同。券的概念類似紅包，有立減和滿減兩種性質，都是在金額上滿足消費者的需求；而活動更多樣化，規則限定更靈活。
在結算時，也通常可以看到，活動是進入結算頁面後自動計算的，而券（紅包、獎勵金等）是需要手動勾選使用的。同時，分開設計也可以將兩者的可延展性最大化。
三、規則限制和互斥性
上文已經提到了規則，但是互斥性沒有詳細說明。互斥性的主要目的在於：
1. 明確系統和業務邏輯
互斥性可以梳理活動與活動、活動與券、券與券之間的使用關係，對運營人員把控活動進度，開發人員編寫代碼都有很大的幫助；同時，消費者在使用或向消費者說明時，可以更明確，避免糾紛和爭論。
2. 方便支付收銀系統作出校驗判斷
營銷中心的職責不僅僅是創建活動和券，發放使用就完事了。對後續的收銀支付同樣有深刻的影響。如果不明確互斥性，結算時系統無法或直接跳過校驗，會直接導致經營虧損或系統報錯。
3. 控制成本支出
互斥性對運營人員來說，控制成本是非常大的職責。
大家使用餓了麼或美團外賣都會發現：商家的活動有很多，但是同享的並不多，滿X元減X元是無法與商品特價同時生效。
這就是商家在做促銷活動時，計算成本利潤後作出的決定。
4. 儘可能避免系統BUG導致的大規模虧損
互斥性在一定程度上可以減輕由系統BUG造成的嚴重後果，例如：設定券和活動的互斥性，就可以避免當券可以無限領取時，導致的可能性的虧損。
那麼，筆者是如何設置互斥性的呢？
完全自由組合：
這是筆者在面對著N多個活動和規則，抓耳撓腮後的想法。
完全自由組合的意思就是：當需要設置互斥性時，通過當前活動或券的適用範圍（商品、店鋪、品類、品牌等），來判定該適用範圍有無進行中或審核中的活動或券，自由勾選後互斥。
舉個例子：當設置NIKE所有商品的滿減活動時，可以看到當前NIKE正在進行中和審核中的所有活動和券信息。勾選某個活動後，被勾選的活動和當前設置的滿減活動就形成互斥關係。
這樣做的好處只有一個：方便。
筆者不是偷懶的人，在設想完全自由組合的邏輯上，並不是覺得這樣方便設計，而是考慮到之後線上線下共同運營時的潛在問題。
我之前做過大型超市的部門負責人，對線下活動了解的比較清楚，深知其中的自由度其實非常高。如果在營銷中心設計上，做過多的限制，那麼對線下而言無疑斷送的不少財路。
所以，筆者通過規則去約束、通過自由的互斥性設置去放開活動組合的可能性。
五、結言
最後，筆者想補充一句：本文是筆者和開發、運營人員共同參與討論、商議、梳理出來的底層邏輯，並不涉及原型設計，也沒有教大家應該怎麼去設計。
筆者強調的是底層邏輯，只有明確了大體框架和脈絡流程，才能設計出正確的交互原型圖，才能寫出完整的產品PRD文檔。
對本文如有疑問或發現問題，歡迎指正，歡迎留言交流。
題圖來自 Unsplash，基於 CC0 協議
閱讀更多 人人都是產品經理 的文章
