營銷中心如果把它單單、看作是發券平臺，就太過簡單了。完整的營銷中心是集活動、券、規則、發放、審核、數據為一體的一站式解決方案。幫助運營人員發現問題、輔助決策、完成運營方案制定；幫助產品人員挖掘有效數據、構建畫像。

營銷中心形態各異，大致可分為：電商、門店和第三方營銷平臺。

淘寶、京東等電商平臺的商家端都會配備營銷中心，主要用于發券、建立活動和數據統計分析；餓了么、美團、盒馬等外賣或新零售平臺主要扎根于實體門店，幫助門店完成線上店鋪的營銷活動發放和線下門店的到店活動；第三方營銷平臺可以不提供線上店鋪服務，僅作為渠道運營商存在，提供券、促銷等運營活動的發放。

筆者給大家分享的營銷中心具有普適性，可以兼容線上線下各場景。

一、營銷中心的實質

營銷中心這個字眼實在太龐大，僅靠一篇文章很難講透徹，筆者接下來講的也都是一些實戰經驗，如果有講的不明白的歡迎踴躍發言討論。

1. 主體

營銷中心的發放/創建主體是一個主題（theme），例如：創建一個主題活動——“三八婦女節，逛吃逛喝我買單”，這個活動里可能會包含線上商城的優惠券、店鋪券，也可能包含滿減活動；其次，主題也可以通過H5頁面傳播，同樣也可以通過線下易拉寶宣傳。

這種組合方式最大化地分離了主題和內容，讓營銷平臺使用起來更明確、數據統計更精確、用戶畫像更準確；同時在接下來的創建、審核和發放環節，同樣益處多多。

2. 規則

上圖是某平臺規則設置頁面的截圖，基本上在規則方面都大同小異，下面這張圖是筆者針對主題和活動概念設置的一些規則。

這里要強調幾點：

規則是需要預設的：

我見過有的營銷平臺，規則都是現加的，更甚者直接在活動創建的代碼里補充上，這是非常不可取的。一方面太過于麻煩，另一方面不便于數據統計和分析，在活動期間發生BUG等突發情況，糾錯難度大

規則不可能全覆蓋：

筆者一開始天真的以為：只要將所有的規則都納入系統邏輯即可，規劃中發現這是不太可能的。因為活動形式有千千萬，新的活動形式也在日益更新，有的新活動就有新的規則，所以在規則預設上不需要太過于追求全面，盡可能覆蓋當前活動形式即可。

不建議使用統一規則設置：

有的營銷系統會將限制規則放在發放階段去做，作為統一收口處。

但筆者不建議如此，其一，不同活動限制規則可能不同（雖然像有效期等規則是相同的，但仍然有不少規則是存在差異的）；其二，統一收口在多人員、多部門協同辦公上可能存在問題，公司里創建活動和最后審核發放的可能是不同的人，關注的點不同，創建的人更關注活動細節，審核的人更關注活動全局，讓審核的人去設定統一規則不太適合。

3. 審核

審核作為可選步驟，在這里主要強調兩點：

如果不需要審核，也請寫進系統邏輯：

審核在許多小企業中是可以跳過的，但是希望大家也督促后端開發將其寫入底層邏輯中，至于審核與否，根據實際業務需求出發。往后如果需要加上審核邏輯，不需要再擔心重大的邏輯變更問題。

多級審核邏輯：

多級審核的概念是指：多名不同級別的人通過多階段的審核流程，批準通過或不通過。

在這里，我著重強調將主題、券、活動分開設置審核邏輯，且需要考慮逆流程。上文已經交代了，不同的人員關注點不同，領導審核主題的宏觀信息，如利潤、成本、時間等，運營人員審核的是活動和券的內容細節。

4. 發放

發放是筆者認為最為復雜和重要的模塊，發放承接了主題（含活動內容），設置發放的信息，最終數據匯總也會受發放時設置的信息影響。

發放階段主要設置以下信息：

發放渠道：渠道一般分為線上（app、小程序、公眾號、雙微等）和線下（門店、賣場、戶外等）；線上線下又可以細分出很多場景，例如：線下自助POS支付后，線下POS支付前，門店活動區域掃碼，線上分享，廣告車/花車巡游，宣傳海報，傳單等。

消費方式限制：又稱為核銷限制，主要作為消費渠道的限制，可以分隔線上線下不同的運營方式、有效地引流和便于數據收集。

發放人群：不在設置活動和券的時候做，是因為發放人群是針對主題而言的，作為統一收口限制的規則。

發放位置：這塊主要考慮到線上線下不同場景；同時便于運營人員在沒有開發的配合下，就能完成運營活動的投放。

5. 數據

營銷中心內的數據模塊，主要展示活動相關，如：活動GMV，利潤，拉新，促活，成交筆數，領取數量，使用數量，分享數量，用戶畫像等。

數據是作為運營分析和決策制定的關鍵因素，但數據模塊過于龐大，筆者就不在這里展開談論，想要詳細了解大家可以自行搜索相關文章。

二、券和活動的區別設計

剛才在講主題的時候，有提到過券和活動的概念。那么，現在就來講一下：為什么故意要將活動形式分為券和活動（也可以理解為促銷）兩種呢？

籠統地將兩者混為一談，在系統設計開發上會造成邏輯混亂——規則設置、數據統計、運營目的都不同。券的概念類似紅包，有立減和滿減兩種性質，都是在金額上滿足消費者的需求；而活動更多樣化，規則限定更靈活。

在結算時，也通?？梢钥吹?，活動是進入結算頁面后自動計算的，而券（紅包、獎勵金等）是需要手動勾選使用的。同時，分開設計也可以將兩者的可延展性最大化。

三、規則限制和互斥性

上文已經提到了規則，但是互斥性沒有詳細說明?；コ庑缘闹饕康脑谟冢?/p>

1. 明確系統和業務邏輯

互斥性可以梳理活動與活動、活動與券、券與券之間的使用關系，對運營人員把控活動進度，開發人員編寫代碼都有很大的幫助；同時，消費者在使用或向消費者說明時，可以更明確，避免糾紛和爭論。

2. 方便支付收銀系統作出校驗判斷

營銷中心的職責不僅僅是創建活動和券，發放使用就完事了。對后續的收銀支付同樣有深刻的影響。如果不明確互斥性，結算時系統無法或直接跳過校驗，會直接導致經營虧損或系統報錯。

3. 控制成本支出

互斥性對運營人員來說，控制成本是非常大的職責。

大家使用餓了么或美團外賣都會發現：商家的活動有很多，但是同享的并不多，滿X元減X元是無法與商品特價同時生效。

這就是商家在做促銷活動時，計算成本利潤后作出的決定。

4. 盡可能避免系統BUG導致的大規模虧損

互斥性在一定程度上可以減輕由系統BUG造成的嚴重后果，例如：設定券和活動的互斥性，就可以避免當券可以無限領取時，導致的可能性的虧損。

那么，筆者是如何設置互斥性的呢？

完全自由組合：

這是筆者在面對著N多個活動和規則，抓耳撓腮后的想法。

完全自由組合的意思就是：當需要設置互斥性時，通過當前活動或券的適用范圍（商品、店鋪、品類、品牌等），來判定該適用范圍有無進行中或審核中的活動或券，自由勾選后互斥。

舉個例子：當設置NIKE所有商品的滿減活動時，可以看到當前NIKE正在進行中和審核中的所有活動和券信息。勾選某個活動后，被勾選的活動和當前設置的滿減活動就形成互斥關系。

這樣做的好處只有一個：方便。

筆者不是偷懶的人，在設想完全自由組合的邏輯上，并不是覺得這樣方便設計，而是考慮到之后線上線下共同運營時的潛在問題。

我之前做過大型超市的部門負責人，對線下活動了解的比較清楚，深知其中的自由度其實非常高。如果在營銷中心設計上，做過多的限制，那么對線下而言無疑斷送的不少財路。

所以，筆者通過規則去約束、通過自由的互斥性設置去放開活動組合的可能性。

五、結言

最后，筆者想補充一句：本文是筆者和開發、運營人員共同參與討論、商議、梳理出來的底層邏輯，并不涉及原型設計，也沒有教大家應該怎么去設計。

筆者強調的是底層邏輯，只有明確了大體框架和脈絡流程，才能設計出正確的交互原型圖，才能寫出完整的產品PRD文檔。

對本文如有疑問或發現問題，歡迎指正，歡迎留言交流。

本文由 @小雞腿 原創發布于人人都是產品經理，未經許可，禁止轉載

題圖來自 Unsplash，基于 CC0 協議