編輯導讀:促銷玩法已是如今各個電商平台必不可少的售賣策略,用戶通過低價買到了商品,也給平台帶來了巨大的流量,是電商運營的“法寶”。本文作者圍繞促銷系統展開分析,希望對你有幫助。
一、秀兒的故事
秀兒是一個電商産品經理,有一天,業務方小張把她興沖沖的叫出去,說:秀兒,我們想辦個活動回饋,不用很複雜,簡單點就行。秀兒一聽到“不用很複雜”“簡單點就行”這種字眼就心裡直打鼓。
小張說了他的需求:我們申請下了一批預算,用戶下單支付時滿滿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每日頭條,我们将持续为您更新最新资讯!