編輯導語：你是否遇到過電商平臺公司的致電回訪，有時還會給一系列的優惠，其實電商平臺公司往往為了實現新用戶轉化或者老客復訪復購，會采取一系列的運營活動。本文針對電商促銷活動的產品設計進行分析。歡迎感興趣的小伙伴閱讀哦！

一、活動形式

活動形式可以歸納為三種，一種是優惠券直減或滿減，一種是返現或者返券形式，第三種是低價購買商品。

1. 第一種顧名思義就是像淘寶發放的紅包或者雙十一滿200減30類似的活動，滿足一定的活動規則可以直接付款的時候直接抵扣部分金額。
2. 第二種是像拼多多的拼團，砍價，或者小米有品的下單立返等活動形式，花費一定的金額進行購買，滿足一定運營活動規則后，返還給用戶現金或者紅包。
3. 低價購買商品主要有單個商品金額直減或者加購商品直減，分別可以提高用戶轉化或者客單價。

二、產品設計及模塊分析

圖1? 運營活動產品模塊分析圖

運營活動一般分為前端頁面展示和后端系統支持，為了方便大家理解，腦圖也是按照前端和后端進行區分的：

• 前端主要關注用戶的路徑，所以要對涉及到的頁面進行詳細的拆分，比如一般活動都會有單獨的活動頁面，個人中心會有對應的優惠券或者金額說明，另外還涉及到主路徑上的用戶引導，比如商品詳情頁的活動信息，訂單支付頁的優惠引導以及支付頁面的優惠選擇等。另外還有基礎數據的埋點方便日后做活動的數據分析。
• 后端主要配合運營活動，涉及到的交易系統，需要兼容本次活動的優惠信息或者其他內容，比如一個訂單的多個商品分攤紅包的規則等。另外還有財務系統、售后、客服、CRB系統的信息兼容等。另外因為往往電商活動中的紅包是真金白銀的優惠，所以也會關注羊毛黨，設置相應的防薅規則。

本篇文章主要從后端系統進行更進一步的分析。

三、活動配置

活動在創建的時候，需要進行一系列的配置，還有活動的選品?；顒舆x品一般是通過計算優惠金額比例和商品實際的利潤來選擇的。如果活動讓利太多，商品達不到盈利的效果，那么這個商品就應該被踢出活動池。從而可以看出，活動配置涉及到幾個模塊：活動管理、商品管理、活動商品池管理。

活動管理中應該是對運營的活動開關、活動規則進行配置。比如該活動針對什么樣的人群，活動是不是有地域、渠道、時間的限制，活動返還紅包還是現金，返還哪種形式多少面額的紅包等?；顒庸芾韺σ幌盗械幕顒舆M行控制和顯示，如果平臺活動形式比較多，而且每種活動配置不可通用?？梢栽偌毞侄壞K對不同形式的活動進行管理。

商品管理，是對所有可以參與活動的商品進行展示。包括商品的SPU、SKU、商品的價格、必須屬性、商家名稱、庫存等。另外還需要對商品的庫存變動進行日志的展示。

活動商品池，即每一個活動，對應的可用商品池，可以配置多個商品池，但是在用的，只能有一個。如果該活動有獨立庫存，還需要進行設置，即其他活動不能使用這部分商品的庫存。

最后，整的來說，電商的促銷活動，離不開多種運營活動的規則。理清每一種活動的元素，規則和配置，整合成模塊化的內容，一方面可以滿足產品的擴展性，另一方面可以避免修改規則后前端重新發布版本。

圖2 運營活動系統功能模塊圖

四、交易系統

每一種活動，勢必都會涉及到交易系統的變化或者兼容。交易系統的關鍵，在于訂單類型、訂單狀態、訂單金額、訂單優惠。

前提：我們預設平臺的訂單系統已經普遍適用，做成了訂單中臺服務。所以，有新增活動時，我們一般不去修改訂單現有的邏輯。

訂單類型：如果是和現有訂單邏輯不兼容，那么為了不修改通用規則，可以考慮再現有訂單的基礎上，封裝一層，或者再單獨寫一個獨立的活動單，在用活動單去對應到普通訂單上。比如買一筆訂單，贈送一個商品。為了方便記錄，可以單獨做成活動單，記錄參與贈送活動的資格和該筆贈送商品單的情況。用活動單將普通訂單和贈送商品訂單封裝進行關聯。單獨對活動單進行設計。

訂單狀態：最好不要隨便修改訂單的狀態，因此有新的業務活動，我們考慮活動單的狀態機。分別考慮時機：創建訂單（訂單下單待支付）、訂單支付成功、訂單取消支付、訂單生產中、訂單發貨、訂單收貨、訂單關閉、訂單退款，以及活動單對應不同訂單狀態，對應的活動單狀態。創建訂單時，校驗活動規則，是否可以創建成功。訂單支付時考慮該業務是否可以用各種現有優惠券等。取消支付時，是否超時自動取消還是必須主動取消？訂單退款以后，各種優惠如何返還、愿訂單商品是否可以單獨申請退貨（贈品不退、如何防止羊毛黨）。

訂單金額：如何計算支付金額、將優惠券優惠分攤到各商品、各訂單。退款后各優惠、金額如何返還到用戶賬戶。

舉個例子：用戶的紅包可以疊加使用，但是購買了多個商品。退款之前，用戶有新獲得的紅包，還有賬戶下有紅包到達了過期時間。那么我們考慮退貨時，紅包的退回邏輯：

圖3? 紅包退款邏輯圖

另外，還可以選擇按照退款金額，創建一個新的紅包，這個都視具體的運營規則而定。

五、其他

另外在設計電商促銷活動時，還要考慮必要的前端埋點便于進行后續的數據分析；財務系統考慮新訂單類型、新優惠方式的兼容；CRB要涉及到用戶召回或者活動推送push等；客服系統是要考慮到用戶提問場景以及客服所需要的信息查詢列表等。

六、總結

產品在梳理新玩法的時候，往往涉及的面會很廣，各模塊之間會有上下游的交互，后端模塊也會和前端有關聯。所以細節之處是非常多的，經常和上下游進行好信息的同步是非常重要的。如果有需要可以進行多次內審。另外和技術團隊之間的溝通也需要注意，可能在會議中某模塊的技術團隊只聽了自己直連的產品PRD宣講，沒有聽到關聯模塊的宣講，產品需要提前進行技術的溝通和協調。

最后，系統上線以后要及時和業務方進行培訓、跟蹤用戶反饋、觀察數據，從而進行版本的優化和迭代。

本文由@把個脈吧 原創發布于人人都是產品經理，未經許可，禁止轉載。

題圖來自 Unsplash，基于CC0協議