編輯導讀：促銷玩法已是如今各個電商平台必不可少的售賣策略，用戶通過低價買到了商品，也給平台帶來了巨大的流量，是電商運營的“法寶”。本文作者圍繞促銷系統展開分析，希望對你有幫助。

一、秀兒的故事

秀兒是一個電商産品經理，有一天，業務方小張把她興沖沖的叫出去，說：秀兒，我們想辦個活動回饋，不用很複雜，簡單點就行。秀兒一聽到“不用很複雜”“簡單點就行”這種字眼就心裡直打鼓。

小張說了他的需求：我們申請下了一批預算，用戶下單支付時滿滿50-3,100-10，而且支付成功後還以可以額外獲得一個贈品，對了忘記說了，如果活動開場前5分鐘付款，還可以享受最優惠的活動價，這樣的話對我們平台拉新引流肯定會有很大的效果，而且還能清一波庫存，你看這個需求已經說的很清楚了，今天能上線嗎？

秀兒此刻的心裡想法：？？？

誠然，促銷玩法已是如今各個電商平台必不可少的售賣策略，用戶通過低價買到了商品，也給平台帶來了巨大的流量，是電商運營的“法寶”，例如兩個電商巨頭JD以及TB，每年平台上的的雙11、618大促是無數個買買買愛好者的天堂，促銷可以在單個商品或者全場商品上生效，可以對商品售價進行促銷，也可以對訂單支付金額進行促銷。

如上文小張提到，支持促銷玩法僅靠一兩句話就可以說清楚嗎，答案當然是否定的，促銷系統與訂單系統、算價服務、及用戶端等其他系統有着不可避免的交互，而其自身也有很多的限制和約束，這裡面的門道可不少。

二、促銷系統相關介紹

1. 什麼是促銷？

促銷簡單點可以理解為是一個“優惠活動”，比如我們去線下的商場逛街時，聽到的“不幹啦不幹啦，清倉甩賣，隻要998“，以此來吸引消費者進店消費，其實這就是一個很典型的促銷活動。那麼線上的促銷可以理解為用戶在線上消費時可以參加的”清倉甩賣“活動。

目前電商促銷類型主要分為以下幾種:

第一種：單品促銷

a.直降，比如一般我們看到的立減、秒殺、團購、特價等

b.折扣. 某個品打多少折，如商品A原價100，活動打9折，那麼實際購買隻需90元即可

顧名思義，單品促銷是作用在單個商品上的，這裡其實還有一點區别，

一個是「降了之後的錢」，比如秒殺、特價。指的是最終的商品優惠價，如商品原價30元，秒殺價5元，就是說不管商品售價金額如何調整，那麼在活動期間，秒殺價就是5元。

另一個是「降了的錢」，比如立減、折扣。都是說在商品售價上進行調整一個固定的優惠值，換句話說，商品售價要是一直在變，那麼折扣或立減的後的優惠的值也會随着商品售價的調整而調整，如果商品價格經常變動的話，這種促銷玩法更适用于運營對于成本的把控。

第二種：贈品促銷

a.買一贈N ，比如買一支牙膏，贈一個牙刷，那麼買的多贈的就約多

b.買N贈N，比如同時買指定的幾件商品，贈某個商品

第三種：滿減促銷

a.滿減或滿折

比如滿50-10，如果訂單實付金額是100，那麼優惠金額是10元，用戶師傅金額是90

例如滿50打9折

b.每滿減，即滿減累計，如滿50-10，如果訂單原價金額是100，那麼減的是20，用戶實付金額是80

c.階梯滿減、階梯滿折

滿減：如每50-10，每80-15等，将滿減分為幾個階梯，最高優惠N元封頂

滿折：如2件8折，3件6折等，最高優惠N元封頂

第四種：其他促銷

a.滿贈 如訂單金額滿n元贈某個商品

b.加價購 如商品A原價30，商品B原價40，但如果買了A的話，可以隻花25元獲得B，這個就是加價購

c.滿返券 訂單确收後，返給賬戶一張優惠券

d.套裝 套裝是兩個及兩個以上的商品打包在一起，套裝的價格比單品總和的價格要更加優惠，用戶必須一次性購買套裝裡的所有商品才可以享受套裝價

實際case舉例

購物車頁面其實就需要調用促銷的算價服務來進行算價，如果金額在用戶預期内，那麼用戶會提交訂單，完成支付，看一個C端用戶感知購買命中促銷的實際的case：

某電商APP：

購物車展示訂單金額，點擊【結算】後跳轉下單頁

下單頁，點擊【立即支付】，訂單落庫

2. 促銷和他的兄弟系統

促銷是影響交易鍊路的一環，若新增一種新的促銷玩法，必須核心鍊路感知并配合改造，不然即便促銷系統自己獨立上線了，那麼也隻是個沒有任何意義的“假促銷”。回歸本質，促銷主要目的為了促成用戶交易，那麼核心系統一定離不開算價服務、訂單系統（訂單和支付系統的交互、訂單和售後系統的交互這裡不多贅）。

1）兄弟系統交互

由于訂單落庫後，數據不可變更，所以嚴謹的來說，訂單在落庫前會再次調用算價服務的接口，将最新的訂單金額與請求下單時的金額進行數據一緻性校驗，校驗通過才會生成訂單落庫，若校驗失敗說明當前優惠已時效，需要用戶重新提單。

這種臨界場景還是比較常見的，如用戶在購物車頁面停留太久，促銷活動恰好做了調整、或者提單的時候，恰好過了零點活動失效等等。一般訂單上也需要記錄此次命中的促銷活動ID、促銷金額等促銷信息，方便後續售後系統獲取進行相應售後服務單處理

2）b端後台頁面

其實當底層模型搭建已經很清晰的話，頁面其實落地很快的。B端頁面把握四個要點「增」「删」「改」「查」，然後根據前期和業務的溝通，考慮到提示日常業務的使用效率，對于系統上的交互、展示的數據做進行梳理，最後落地成方案。

這裡很重要的一點由于促銷和錢極為相關，系統需要前置做很多安全相關的數據校驗、規則校驗（譬如不同促銷是否互斥、如果是可以同一時間、同一sku的促銷可以相互疊加，那麼算價規則是鍊式疊加或者平行疊加）以及系統預警（促銷價低于一定阈值時系統預警）等，防止由于配置失誤被惡意薅羊毛。

三、PM的一點思考

每一個在線上生效的促銷活動，背後一定是有無數的各方業務溝通、以及最終配置、啟用的。

對于産品來說，我們應該明确三點：

1. 底層系統的設計

初期需要在設計中要明确模型，考慮【可拓展性】，如果後面要新增促銷玩法時，你設計的這一套東西不能複用，需要重構或者重新做一套，這樣成本過高顯然是不合适的，這一點不隻針對于促銷，任何系統都是一樣的。比如目前業務訴求是支持秒殺，後期如果想支持折扣的話，其實不需要涉及促銷模型的調整，隻是在原有模型上新增一種類型即可，這樣做成本小、上線快；反之，如果在設計初期沒有深入考慮，隻是新增一個case，解決一個case的話，在後期的疊代中，研發和業務都苦不堪言。

2. 業務的sop

線上的促銷其實就像我們最早接觸到的線下的各種打折、甩賣的活動一樣，也是需要有人發起、有人參與、還需要明确活動的時間、活動面向的人群、活動的預期效果，最重要的是活動的預算由誰來承擔。這不隻是業務要做的事，産品也需要知道此次活動的sop是什麼，甚至在業務不清晰的時候需要驅動業務指定規範的sop，如果沒有明确的sop，那麼促銷的效果會大打折扣，而且會造成額外的資損，這些都是需要重點關注和考慮到的。

3. 促銷本身

大部分的電商行業都離不開促銷，促銷系統可做大可做小，複雜的可以通過角色來配置促銷活動，同一個sku可以在同一個時間疊加不同的促銷玩法，這就需要産研前置考慮到各種并發情況。促銷的手段千變萬化，對于每年某寶雙十一的玩法複雜到筆者早已敗下陣來

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!

查看全部