從0到1,搭建營銷中心——認知營銷中心產品架構
營銷中心如果把它單單、看作是發券平臺,就太過簡單了。完整的營銷中心是集活動、券、規則、發放、審核、數據為一體的一站式解決方案。幫助運營人員發現問題、輔助決策、完成運營方案制定;幫助產品人員挖掘有效數據、構建畫像。
營銷中心形態各異,大致可分為:電商、門店和第三方營銷平臺。
淘寶、京東等電商平臺的商家端都會配備營銷中心,主要用于發券、建立活動和數據統計分析;餓了么、美團、盒馬等外賣或新零售平臺主要扎根于實體門店,幫助門店完成線上店鋪的營銷活動發放和線下門店的到店活動;第三方營銷平臺可以不提供線上店鋪服務,僅作為渠道運營商存在,提供券、促銷等運營活動的發放。
筆者給大家分享的營銷中心具有普適性,可以兼容線上線下各場景。
一、營銷中心的實質
營銷中心這個字眼實在太龐大,僅靠一篇文章很難講透徹,筆者接下來講的也都是一些實戰經驗,如果有講的不明白的歡迎踴躍發言討論。
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 協議
還是有點沒懂券和活動的區別,如果設置了一個滿減券,那這個算是活動還是算一個券呢?
優惠是一種活動,
優惠券是活動的形式。
所以活動>優惠,活動和優惠券不是一個東西。
贊
券和活動分離的原因在于實體不一樣
1.券的實體就是券,本質是一種結算的規則具象化
2.活動的實體是基于商品的一種附屬規則,可以給主商品關聯一個副商品就是買贈,給主商品設置優惠價就是單品促銷
完全自由組合那個沒看明白,能再舉個例子解釋一下嗎?
比如設置A商品滿減活動時,會出現所有A商品目前正在進行,未開始,審核中的活動和優惠券,自由勾選互斥
贊!感謝梳理、分享,我目前也正在做類似的系統,雖然2年前也做過類似的工作和思考,但畢竟并非專門花心思在這塊上,好多問題在文中給指了方向,非常有價值,再次感謝
沙發!
?。?!
!