在複雜的零售市場業務邏輯下，產品設計團隊要怎麼做好促銷系統設計？這篇文章里，作者分模塊介紹了促銷系統的概要設計，並總結了促銷系統設計過程中應當避開的「坑」，一起來看看吧，或許會對你有所啟發。
在複雜的零售市場業務邏輯下，產品設計團隊要怎麼做好促銷系統設計？這篇文章里，作者分模塊介紹了促銷系統的概要設計，並總結了促銷系統設計過程中應當避開的「坑」，一起來看看吧，或許會對你有所啟發。
23年上半年，我在上一家公司負責面向香港市場的yuu APP（背後運營者是香港本地兩大零售商之一的Dairy Farm – 牛奶集團，旗下有：惠康超市、Market Place by Jasons超市、711、萬寧、美心等業務）的促銷引擎升級項目，大型商超業態+超卷的香港零售市場疊加導致了複雜的業務邏輯，在此記錄總結一下。
（圖：DF直接運營、代運營、參股的零售品牌）
本文行文的順序是：先分模塊介紹促銷系統的概要設計，然後總結應避免的坑。
一、從業務角度來講，促銷活動的目標只有一個
期望刺激用戶買得更多、更頻繁，產生更高的GMV。
超市業態很特殊，它的凈利潤率（Net profit margin）很低，是「低頭撿鋼鏰」的民生生意，需要薄利多銷。例如，國內經營水平很好的永輝超市2018年至2022年的銷售凈利潤率分別為1.41%、1.71%、1.77%、-4.94%、-3.33%。在我目前的認知中——商超的促銷規則是複雜度最高的，其他零售業態的促銷玩法可以視為其子集。
二、促銷系統的核心組成部分
從後台的角度來說，可以增、刪、改、查促銷規則。
從前台應用的角度來說，主要有兩個場景：
通過不同的維度創建促銷，會產生以下的常見類型：
這裡的類型，會影響促銷價格、標籤展示（查價），也會影響促銷的算價，一般都是以特定的優先級，算完一級優惠之後剩餘的金額再參與下一個優先級的優惠計算。
2. 創建促銷
上面的每一種創建的維度之下，如果把促銷的玩法抽象出來，可以認為是：每一個促銷都像符合這樣一個描述：
Buy (門檻條件 + 門檻商品）+ Get （獎勵類型+獎勵商品）
Buy (門檻條件 + 門檻商品）+ Get （獎勵類型+獎勵商品）
拆解來說：
【門檻條件 + 門檻商品 – Threshold】：購買特定商品，滿足一定的金額或滿足一定的件數（滿額 – Amount或滿件 – Quantity），比如：「買¥10香蕉，則達到門檻」、「買3支香蕉，則達到門檻」
【獎勵類型 + 獎勵商品 – Reward】：參與促銷的獎勵類型有折扣、贈品、換購，以及獎勵商品列表的設置：
在以上三個要素的組合下，會形成一個確定的促銷規則，比如「買3件A，送1件B」。在此基礎上，我們希望鼓勵用戶買得越多省得越多，因此又衍生出兩個機制：
【翻倍 – Repeat】：在翻倍的情況下，意味著可以重複達到相同的門檻，再多次領取相同的獎勵：If 每買XX達到 【門檻】, then 分別獲得【獎勵內容1； 獎勵內容2；獎勵內容N】，最高翻倍N次。如：每買滿¥10香蕉，打8折；最高翻倍5次。
【階梯 – Tiers】在階梯的情況下，意味著促銷的門檻和獎勵類型會升級（進階）：
查價是相對靜態單個商品的促銷信息查詢，不涉及計算（只會計算單品促），信息包括：商品價格、促銷標籤、促銷標籤靜態描述語，線上呈現的場景是商詳、列表頁。線下則是紙質價簽、電子磅秤、電子價簽。
4. 促銷算價（及分攤）
算價，狹義來講是指：給定數量的商品，計算訂單的優惠總金額（及待支付總金額）。
算價的設計策略是分而治之。
我在2.1中提到了多種促銷類型，這些促銷類型如果混著算會非常亂，如果可解釋的程度差，甚至可能會導致財務統計的問題。不同公司根據業務規則不同，會有區別，但是大同小異，我將通過以下例子說明。
假設我買了10件商品，原價總計是100元。如果跳過中間步驟（促銷湊單），直接計算結算價格，那麼首先需要考慮問題是：計算的順序是什麼。比如，可以按這個順序計算：單品>品類>品牌>品牌>店鋪>整單。
具體來說：
上述是算價的骨幹邏輯，也是無論線上線下都需要應用。
在此基礎上，線上APP由於UI交互需要，增加了促銷算價的複雜度。因為線下場景用戶把商品一股腦都塞給售貨員就行了，POS機只計算一個最終價格以及總優惠即可。但是線上場景有加購、湊單的過程，在這個過程中要體現進度、體現下一個階梯/翻倍的條件，優惠需要預先演算，並呈現給用戶。因此還有如下算價相關的難題需要解決：
這些問題需要購物車系統、湊單系統，結合促銷引擎的能力，提供針對線上購物體驗定製化的設計。
5. 促銷的非核心的組成部分還包括但不限於
我個人的經驗有限，就不一一列舉了，熟悉上下游業務的朋友也可以在評論中替我補充。
三、需要避免的坑 1. 促銷上游數據
線下數字化改造的項目，或Saas服務會遇到這個問題，一般自主研發的促銷系統不會有這個問題。這裡說的是：當存在兩套促銷系統時，兩套系統之間需要進行邏輯映射、數據同步。就這個問題而言，應該以最快的速度切換成一套系統。否則，會剪不斷理還亂。會遇到各種邏輯轉換的問題、兼容問題、數據實時性問題。
2. 算價
我在做這個項目的時候，業務規則上有個很變態的要求，簡單來說是：有4個類型的促銷，之間沒有優先級，哪個優惠節省的金額最高，就應用哪個。
業務這樣做的原因是，香港的商超零售競爭激烈，每家超市都希望提供最優惠的價格，而且大部分的讓利是供應商承擔的，如果按照上述優先級規則計算，可能用戶最終獲得的優惠並不是理論上最優惠的。這樣的處理，在線下不會有問題，因為顧客只需知道最終的優惠結果。
但是放在線上由於需要引導用戶湊單，整個過程就變得不可解釋了，違背了don』t make me think原則——用戶購物車命中的促銷，會隨著加購商品的變化而變化。UI無法設計成有穩定預期的引導，只能告知促銷算價的結果。針對這一點，我建議是：促銷算價還是要有優先級的，不應該為了追求極致的優惠而損失了顧客的可理解程度。
3. 湊單
雖然有上述業務限制，但是在跳著腳銬跳舞的情況下，產品團隊和設計團隊還是儘量讓湊單的過程更清晰，展示明確的門檻目標（雖然會變）。不好的設計總是讓用戶捉摸不透，無法擁有穩定的預期。
本文由 @阡之陌路 原創發布於人人都是產品經理，未經作者許可，禁止轉載。
題圖來自Unsplash，基於CC0協議。