電商產品 | 再談促銷實現邏輯
京東618大促落下帷幕，伴隨着1199億元的銷售業績使人瞠目，如此龐大的促銷活動，是如何作到的？若是一個商品既參與了特價銷售、又參與了平臺跨萬店滿減、還參與了店鋪內的優惠券減額等等促銷活動，那這個商品會不會存在不要錢白送的狀況？javascript
固然，你能夠認爲筆者在杞人憂天，就算虧那也是京東的事情，可是筆者並非要討論京東賺了或者虧了多少錢，而是要說這考驗的是產品設計者的智慧。html
在閱讀本文以前，筆者建議你先閱讀前一篇文章：「電商促銷業務邏輯盤根錯節？試試脫離場景從系統計算邏輯上思考」 。在這篇文章中，筆者總結了設計電商促銷系統的基本原則：前端
同類型經過實體進行互斥、不一樣類型能夠相互疊加。
vue
若是沒有時間看上一篇文章，爲更好的理解本文，筆者大體描述這條原則以下：在你設計促銷功能時，須要考慮當前促銷功能是屬於如下哪一種促銷類型，再使用這條原則經過實體（這裏說的實體是商品或者訂單）和其餘促銷功能進行邏輯互斥。java
三種促銷類型：修改價格類型、修改商品小計金額類型和修改訂單金額類型web
例如：若是你設計的促銷功能是 秒殺，那麼這個活動就屬於第一種：「修改價格類型」 的促銷活動，它須要經過實體（商品）來和 同類型其餘促銷活動 進行互斥，也就是說：在設計秒殺活動功能時須要考慮到參與秒殺活動的商品不能同時參與其餘修改價格類型的促銷活動。而，這種類型的促銷活動有：拼團、限時折扣、降價拍等等。微信
以上爲背景和回顧，下面正式進入本文內容架構
就如筆者以前所述：這條原則是沒有考慮任何使用場景、徹底基於系統計算邏輯總結的規律，可是就連筆者也沒法迴避電商產品是由運營驅動的殘酷現實。這也就決定了，這條原則若是不符合用戶使用場景，不能提升運營效率也終將是一個自嗨的結論，沒有任何價值可言。那麼今天，筆者就將進一步闡述這條原則可否知足實際使用場景的要求。app
所謂實際使用場景，無非就是線上和線下兩種狀況，本文將結合電商購物車這個促銷重要載體來對如下五種不一樣的狀況進行逐一分析：ide
第一種狀況：針對線上，若是一個商品可以同時參與兩個不一樣的第一種促銷類型，會如何？
第二種狀況：針對線上，若是一個商品可以同時參與兩個不一樣的第二種促銷類型，會如何？
第三種狀況：針對線下，若是一個商品可以同時參與兩個不一樣的第一種促銷類型，會如何？
第四種狀況：針對線下，若是一個商品可以同時參與兩個不一樣的第二種促銷類型，會如何？
若是一個商品同時參與了上述三種促銷類型活動，能夠嗎？
第一種狀況
針對線上，若是一個商品可以同時參與兩個不一樣的第一種促銷類型，會如何？
常見的第一類促銷活動有：拼團/階梯拼團、團購、秒殺、限時折扣、降價拍等
假如你是產品經理，如今要你設計一個第一種類型促銷活動，好比限時折扣。你把玩了各類競品的前端交互，並開始設計設計本身的限時折扣活動，然而競品並無告訴你若是和其餘促銷衝突時該如何處理，你也沒有考慮到若是有其餘促銷的狀況，你的產品也順利上線了（假設）。好了，運營喵們開心的去策劃促銷活動，SKU A 先是被一個運營喵參與了秒殺活動，而後另外一個運營又選擇了這 SKU 參與你設計的限時折扣的活動，結果會如何？
由於同一個SKU 在同一段時間內具有了兩個價格（一個秒殺價格，一個折扣價格），這時候系統該選擇哪一個價格做爲這個SKU的價格呢？若是一個用戶剛好添加了這個SKU 到購物車，那麼購物車的促銷怎麼展現？畫風是這樣的，你們感覺一下：
很明顯，這種可能性即便在線上使用場景下也是不容許發生的，也就是說同一個SKU 不能同時參與第一類促銷活動，這是在產品設計之初就須要考慮並告知開發者的。
第二種狀況
假如一個SKU 同時參與了兩個不一樣的第二種類型的促銷活動，會如何？
咱們再來歸類一下如今經常使用的第二類促銷活動：指定商品的（品牌、類目、店鋪等不一樣維度）滿減、滿贈、折扣，N元任選、加價購。
假如一個SKU A既參與了包含SKU A 的 滿50減5 活動，又參與了包含SKU A的 99元任選3件 的活動會發生什麼呢？
首先，在商品詳情頁，SKU A 須要標記兩個促銷活動，對於商品詳情頁面來講最重要的是提升頁面的轉化率，過多的促銷會不會形成用戶舉棋不定？增長用戶考慮成本從而下降商詳頁轉化率？
其次，用戶即便將SKU A加入了購物車，如何解決同一個SKU的兩個以上促銷展現問題？無論如何處理，對於第二種促銷類型 這個SKU 都只能參與其中一個活動，既然只能參與一個活動，那就必須在全部知足的活動中定一個優先級優先只展現一個給用戶，那這個優先級規則又將如何定義？
再者，購物車還須要承擔提示用戶湊單的重任，也就是說：須要一個肯定的促銷活動將知足這個活動的全部商品歸類到一組提示用戶進行湊單，若是一個商品知足多個促銷活動能夠任意切換，切換以後又須要對切換後的活動商品進行從新組合並再次計算知足的促銷條件及湊單金額，這對於系統計算工做量來說...並且對於用戶而言，他們真的不會被購物車同一商品多個促銷活動搞懵逼了嗎？
基於上述種種考慮，對於第二種類型的促銷活動而言，在產品設計時就應作出限制（同一商品不得參與多個第二種類型促銷活動）是最明智的選擇。
那麼，有沒有例外？ 答案是：有的，好比京東
京東已經把購物車的促銷展現作到了極致，更重要的是：它容許同一個SKU參與多個第二種類型促銷活動，它是如何處理同一SKU參與多個促銷的呢？以下圖所示：
若是一個SKU 同時參與了兩個第二類促銷，提供給用戶修改的入口，用戶能夠自定義選擇參與哪一個促銷，這樣處理存在的問題是什麼？
1. 數據處理量大，購物車對數據時效性要求極高，用戶對購物車商品任意增刪改都須要實時計算。同時，若是用戶切換商品的促銷活動，系統首先須要將切換後同一類型促銷活動商品歸爲一組，再計算本組商品價格與促銷活動門檻金額進行比對比作出對應提示，例如：再購多少元知足本優惠。還須要將本組促銷活動的其餘商品歸類到一塊兒，給出湊單入口，並提醒用戶去湊單。。。如此巨量的計算任務須要在短期內作出響應，不是通常的團隊可以勝任的。筆者親測：即便是京東，從滿減切換爲滿贈，購物車頁面也等待了兩秒多種才完成切換。
2. 用戶體驗並不佳，從京東的購物車頁面能夠看到琳琅滿目的各類促銷條件，任意不一樣的促銷活動商品都會被劃分爲一組，不一樣商家的商品會被歸類爲一組、京東自營的又會與其餘商家區分開，一旦用戶添加購物車商品過多，會給用戶形成不少干擾，筆者問過不少京東的重度用戶（包含PLUS會員），當我告訴他們，有些商品下面有個修改的按鈕能夠改這個商品的促銷活動，他們中的大部分人作出的反應都是，啊。。。？ 沒有注意過啊？
既然是這樣，京東爲何還要這樣作呢？
所謂：「全部能經過技術解決的問題都不是問題」，因此第一個問題對於京東來說並非問題，對於對二個問題，這是產品向運營妥協的結果：一個運營負責不一樣的店鋪、品牌、商品類目，這在平時若是僅僅店鋪內促銷還行，遇到618這樣的大促，平臺牽頭帶領店鋪進行跨店鋪促銷，每一個人都但願爭取到更多的資源和流量來提升GMV，若是限制一個商品只能參與一個第二類促銷，這樣不被承認也是情理之中，可是對於大部分電商而言，是否也須要這樣處理呢？筆者認爲並不可取。
第三種狀況/第四種狀況
針對線下，若是一個商品可以同時參與兩個不一樣的第一/第二種促銷類型，會如何？
既然是線下，咱們去實地考察下線下的促銷場景就什麼都明白了，看下下圖：
很明顯的是：商場促銷活動時，會把全部參與同一促銷的商品歸類到一塊兒，而後插上吊牌：特價xxx，滿xx減xx 等等，一個活動就是一個獨立的區域不可能一個商品同時存在於兩個不一樣的活動區域的，即便被你看見了，那也是商場工做人員的失誤，由於結算時若是你告訴收銀員這個商品有多個能夠選擇的優惠，那麼他必定會崩潰的。
第五種狀況
一個商品同時參與了上述三種促銷類型活動，能夠嗎？
答案是：邏輯上是沒有任何問題的，可是實際場景中並不常見（在業務層面通常不容許這樣操做），至少筆者沒遇到過這樣的好事，以下圖所示：
好比：一罐原價200的奶粉，既參與了 特價180 銷售，又參與了指定奶粉類型的 滿100減10 的活動，還使用了全場通用的 滿150減10 的優惠券，最後支付金額爲160。
因此
這條原則：
同類型經過實體進行互斥、不一樣類型能夠相互疊加。
即便是在實際使用場景中，也仍然具有它的實際價值，筆者再次總結以下：
第一種類型促銷：即：商品低價促銷，有：拼團/階梯拼團、團購、秒殺、限時折扣、降價拍等
第二種類型促銷：即：商品小計促銷，有：指定商品的（品牌、類目、店鋪等不一樣維度）滿減、滿贈、折扣，N元任選、加價購。
第三種類型促銷：即：訂單金額促銷，有：全場滿減、滿贈，全場滿xx包郵，優惠券等
當你設計促銷類產品時，你應該這樣作：
首先，你須要先和 架構師/項目經理 從總體上定義好各類促銷活動之間的關係（如上所述），搭好架構；
其次，當你實際設計促銷產品時，須要判斷你設計的促銷產品屬於哪一種類型，歸爲同一類型的促銷活動須要經過商品進行互斥；
例如：同爲針對商品的促銷，不能同時對同一個商品進行滿減和滿贈；
針對訂單的促銷，須要定義優先級，例如：全場滿減的促銷計算應該在全場滿x包郵以前。也就是說計算包郵的金額應該是全部促銷計算完成後的金額，也就是用戶實付金額。
最後，不一樣類型之間能夠進行疊加，例如：針對商品金額的促銷能夠和針對同一商品的滿減促銷進行疊加。
在咱們知道這些以後再來看看關於促銷的時序圖，經過它能夠幫助你完成任意形式的促銷產品設計：
對該時序圖簡要描述以下：
1. 當用戶打開產品、並把商品加入購物車，而後用戶進入購物車進行結算
2. 這時，系統首先須要將購物車商品與促銷引擎的商品池進行比對，將全部參與第一類促銷的商品所有拿出來並作好標記與沒有參與第一類促銷的商品區分開；
3. 再次將購物車全部商品與促銷引擎的商品池進行匹配，將全部參與第二類促銷活動的商品按照促銷活動不一樣進行分組展現，同一促銷活動商品歸爲同一組，不一樣活動則分爲不一樣的組，沒有參加活動的歸爲一組，每組活動根據促銷金額門檻和當前組商品金額提示用戶進行湊單；
4. 針對訂單的促銷活動，做爲全局條件在購物車頂部或者底部進行展現（不針對商品因此沒有分組），並根據用戶購物車勾選的商品進行提示須要再作哪些購買操做才能知足全局優惠條件
5. 將這些結果返回給購物車並顯示給用戶，引導用戶作出選擇。
這個冬天有點冷，單身狗窮得只剩褲衩了