從拼多多事件看電商的促銷模型
前段時間,電商圈出了一件大事情,拼多多再次吸引了大家的眼球。2019年1月20日,拼多多出現了數額巨大的羊毛Bug,起因在於一張無門檻的優惠券,券麵價值100元,可以全場通用(特殊商品除外),有效期一年。如果僅僅從業務角度分析,定義這樣的優惠券自身並沒有任何問題。當然,也有人說像這樣的無門檻券本身就不該用於花費充值、Q幣充值等幾乎等於現金業務的商品,這是從促銷層面去考慮的問題。還有人提到風控問題,為何等到損失達200億(事後拼多多說明這些優惠券涉及到千萬)才發現問題?更有人質疑這是一次別出心裁的炒作。
從薅羊毛的角度看這個Bug,似乎是因為該無門檻券可以被無限次使用導致的。本質上,這確實是一個Bug,我不明白這樣的Bug是如何產生的,是測試不到位,還是說該優惠券本身是一個內部測試資料,被不小心放到生產環境?正好,最近正在考慮如何利用分析模式建立電商系統中的促銷模型,算是應景之作吧。
分析模式對模型的精煉
在領域驅動設計中,透過統一語言與“名詞動詞法”的結合,可以快速獲得初步的分析模型。但是這種方法獲得的模型品質,受限於語言描述的寫作技巧,統一語言的描述更多體現在是對現實世界的模型描述,缺乏深入精準的分析與統一的抽象,使得我們很難發現一些隱含在統一語言背後的重要概念。一言以蔽之,由此獲得分析模型還需要進一步精煉。
對相同或相近的領域進行建模分析時,一定有章法和規律可循。例如同樣都是電商系統,它們的領域模型定有相似之處;如果都為財務系統,自然也得遵循普適性的會計準則。這並非運用行業術語這麼簡單,而是結合領域專家的知識,將這些相同或相似的模型抽象出來,形成可以參考和重用的概念模型,這就是Martin Fowler提出的分析模式。Fowler認為:“分析模式是一組概念,這些概念反映了業務建模中的通用結構。它可以只與某個特定的領域相關,也可以跨越多個領域。”由於分析模式是獨立於軟體技術的,就使得領域專家可以理解這些模式,這是分析建模過程中關鍵的一點。
每個行業都可以定義自己的分析模式,當然我們也可以參考一些已經被別人總結好的分析模式。例如在Martin Fowler的著作《分析模式》中,模式所覆蓋的領域就包括組織結構、單位數量、財務模型、庫存與賬務、計劃以及合同(期權、期貨、產品以及交易)等領域。Eric Evans認為利用這些分析模式,“可以避免一些代價高昂的嘗試和失敗過程,而直接從一個已經具有良好表達力和易實現的模型開始工作,並解決了一些可能難於學習的微妙的問題。我們可以從這樣一個起點來重構和實驗。”
要獲得這樣的分析模式,需要專精的領域專家與軟體設計師共同來完成。只可惜溝通與知識的壁壘讓這樣一個重要的分析工作變得舉步維艱。Martin Fowler撰寫《分析模式》正是希望透過引入更多的模式來降低建模的難度,至少可以做到一定程度的模型複用。然而,分析模式與領域知識息息相關,這就限制了分析模式的通用性;但這並不能說明分析模式不重要。領域驅動設計尤其強調為領域建模,對於那些具有較長生命週期的產品而言,針對產品的核心領域建立一套分析模式絕對值得,因為它是分析階段的重要資產,它的穩定與擴充套件能力可能會直接影響到領域模型中的設計模型與實現模型。
案例:促銷策略的分析模式
促銷(Promotion)是一種運營手段,目的是透過這種手段去刺激消費的各種資訊,把資訊傳遞到一個或更多的目標物件,以影響其態度和行為,提高轉化率。為了拉動消費,無論是線上還是線下,商家總是會絞盡腦汁提供各種促銷手段,這就帶來了促銷策略的複雜性;然而從消費心理角度考慮,要刺激消費,簡單有效的方式就是讓消費者認為花了更少的錢卻買了更多的商品,這就帶來了促銷策略的相似性。從某種意義上講,拼多多的這次促銷極大地“刺激”了消費者的熱情!
促銷策略的業務背景
在電商系統中,對促銷的管理主要牽涉到對促銷活動與促銷規則的管理。同時,促銷還會影響到訂單、庫存、物流以及支付。如果我們將促銷視為核心領域,那麼在為它建立分析模型時,應以促銷領域為主。
促銷活動
促銷活動實際上是針對促銷進行基本屬性管理,負責提供活動方式和商品內容,主要包括:
商品選擇:參加促銷的商品,分為活動商品和贈品兩種;也可以選定商品的品種參與促銷,例如針對圖書類開展促銷。
投放時間選擇:即該促銷的有效時段
投放區域選擇:針對全平臺還是部分平臺(自營或指定店鋪),或者僅針對APP平臺
使用者型別:針對新註冊使用者,VIP使用者等
促銷規則
促銷規則是促銷管理的核心。一個促銷系統的好壞取決於促銷規則設計是否合理,設計時既要考慮到商品的促銷,又要考慮到店鋪的盈利,還要考慮滯銷品和暢銷品的差別,因此促銷規則的制訂是非常靈活的,範圍和促銷力度也各有不同。大體來看,我們可以從平臺、商品種數、促銷方式這三個維度來分別理解促銷規則的制訂:
平臺維度:促銷規則可以分為自營促銷和POP平臺促銷。
商品總數維度:站在商品角度看促銷,則促銷可以分為單品促銷、集合促銷和店鋪促銷:
單品促銷:以單個商品為維度進行的促銷叫單品促銷,例如限時搶。
集合促銷:透過商品集合來滿足促銷規則進行的促銷叫集合促銷,例如滿額減。
店鋪級促銷:以商家店鋪為維度進行的促銷叫店鋪級促銷,例如店鋪級滿額折。
促銷方式維度:
直減類:限時搶、直減、多買多折、VIP專享價、手機專享價等
贈品:滿贈
換購類:加價購,湊單
滿額類:滿額減、滿額折等
返券類:滿額返券
組合優惠類:套餐
預訂類:團購
在配置促銷規則時,還需要考慮規則的優先順序,它會直接影響促銷活動的共享與互斥。例如我們可以按照一定的優先順序完成使用者的優惠享用,如享用了單品促銷,就不能參加集合促銷,滿減優先順序大於代金券;這是互斥的情況。促銷活動也可以共享,例如滿額累促銷可以與滿額包郵共同使用。
對促銷領域的分析建模
我們在為促銷領域進行分析建模時,首先需要甄別出該領域的核心概念,然後分析這些概念在該領域中蘊含的業務意義。基於前面介紹的業務背景,我們知道促銷領域的核心概念包括促銷活動與促銷規則。在管理促銷活動時,需要指定促銷規則,這就產生了二者之間的關聯關係。表面看,是透過促銷活動去配置促銷規則,前者為主,後者為輔;但對於促銷而言,其實是活動與規則合二為一組合形成一種促銷產品(Promotion Product)。這種促銷產品可以是“券(Coupon)”形式,也可以是“禮品卡(Gift Card)”形式,又或者是提供“打折(Discount)”或者“包郵(Free Shipping)”。
模型概念“促銷產品”的獲得實際上是分析建模過程中對關係建模的一種體現。在現實世界中,各種概念之間總是會存在各種錯綜複雜的關係,例如在學校中,有教師與學生之間的師生關係,有院長與教師之間的上下級關係,有教授與研究生之間的科研關係。一旦關係變得越來越多,越來越複雜,僅僅靠體現物件之間的委派關係來體現這種組合就會顯得缺乏表現力,這個時候就可以將“關係”提煉為模型中一個顯式的概念。
建模原則:如果某個型別擁有多種相似的關聯,可以為這些關聯物件定義一個新的型別,並建立一個知識級型別來區分它們。
前面所述的促銷活動與促銷規則在業務上存在一定的重複。例如平臺維度的促銷規則,其實對應的是促銷活動中對投放平臺或區域的選擇。商品總數維度的促銷規則,又與促銷活動中適用商品(品種)選擇的配置重疊了。這是因為我們擴大了所謂“規則”的外延。規則(Rule)不是計劃,更不是策略,而應該是一條條具體的可判斷是否滿足條件的約束規則,例如:
購指定圖書滿100元減20元,滿200元減40元,在2018年12月12日當天有效。
以上描述並非促銷規則,而是一次完整的促銷,該促銷的促銷產品為“券(Coupon)”,券的型別為現金券(若描述中為滿額折扣,就是折扣券)。描述“指定圖書”屬於促銷活動中對適用商品(品種)的配置,描述“2018年12月12日當天有效”則是該促銷的有效時段屬性。唯有描述“滿100元減20元,滿200元減40元”,才是所謂的規則。該規則又包含了兩條金額閾值的條件(Creteria)。面對這種場景,我們就可以在分析模型中引入“規格模式(Specification Pattern)”。
規格模式由Martin Fowler與Eric Evans提出,他們對規格模式的描述如下所示:
問題:
選擇(Selection):需要基於某些條件(Creteria)選擇物件的一個子集,且需要多次重新整理其選擇
驗證(Validation):需要根據確定的目標獲得滿足條件的合適物件
按需構造(Construction-to-order):需要描述物件應該做什麼而無需解釋物件執行的細節,這樣就可以構造一個候選物件來滿足需求
解決方案:
建立一個規格(Specification)物件,它能夠辨別候選物件是否滿足某些條件。規格物件定義了方法isSatisfiedBy(anObject),如果anObject的所有條件均滿足,則返回值true。
結果:
解除需求設計、實現與驗證之間的耦合
提供清晰的宣告式的系統定義
規格物件可以是單一的,也可以是合成的。
一個促銷規則可以包含多個規格,而對於規格而言,在促銷場景又可以分為:
金額(Amount)閾值的規格:例如滿200元減40元,或滿200元9折
數量(Count)閾值的規格:例如滿2件9折,又或者限量購
結合業務分析與模型分析,我們可以得出如下的分析模型:
分析促銷產品時,我們發現模型中的概念並未處於同一個抽象層次,且相互間存在混合關聯的關係。例如打折(Discount)或現金抵用(Reward)可以單獨針對一次促銷提供,也可以和券(Coupon)進行捆綁;禮品卡(Gift Card)和券均可以提供贈品或者包郵。顯然,諸如打折、現金抵用、贈品和包郵等概念並非一種促銷產品,而是一種促銷產品型別,是促銷產品的一種屬性,例如券的促銷產品型別若為打折,就是折扣券,若為現金抵用,就是現金券。這時,促銷產品其實是這些產品型別的一種載體。
在電商系統的促銷策略中,諸如打折、現金抵用之類的促銷手段未必需要透過券或者禮品卡的形式呈現,它們其實是可以作為促銷產品被單獨使用的。但在建模過程中,我們卻不允許概念層次的混亂,因為我們必須要避免領域概念的二義性。例如對於打折(Discount),到底是促銷產品,還是促銷型別,必須分辨清楚。既然概念層次不在同一個抽象層次上,我們就需要針對這些概念建立一層抽象,這個抽象概念是與券、禮品卡處於同一個抽象層次。這個抽象的促銷產品概念就是“優惠(Special Offer)”。因此,前面建立的模型就可以改進為:
建模原則:保證分析模型中的概念遵循單一抽象層次原則。
知識級和操作級
當模型變得漸趨複雜時,《分析模式》引入了操作級(operational level)和知識級(knowledge level)兩個層次來組織模型中的概念。操作級模型記錄該領域每天發生的事件;知識級模型則定義了操作級物件的合法配置,記錄控制著結構的各種通用規則。知識級和操作級二者之間並沒有明確的差異,但Martin Fowler認為“將兩者(知識級和操作級)分開有助於理清建模思路”。為此,我們需要明確這二者之間的差別。
在《分析模式》一書中,Martin Fowler引入了英國國民醫療服務制度的Cosmos專案作為分析模式的案例,這個模型的推導過程清晰地展現了引入這兩個層級是怎麼讓模型變得更加清晰的。
Cosmos作為一個醫療保健系統,需要對醫藥行業的測量和觀察需求建立模型。簡單說來,每個患者的測量結果可以建模為“測量(Meassurement)”。然而針對整家醫院,即使是一個患者也可能存在成千上萬種可能的測量。如果為每種測量定義一個相應的屬性,就意味著一個患者存在著成千上萬種可能的測量操作——測量的介面就會變得格外複雜。分析模型的解決方案是將所有可以被測量的不同事物(身高、體重、血糖水平……)都作為測量物件,並將其抽象為“現象型別(Phenomenon Type)”。這裡,測量屬於操作級,現象型別屬於知識級:
在為測量引入現象型別後,患者可以有許多測量,但是針對某一種現象型別而言,患者就只有一個測量。例如John Smith身高1米75,在上述模型中,該描述資訊整個代表一個測量,其中,患者是John Smith,現象型別是身高,數量是1米75。
那麼為什麼現象型別屬於知識級,測量屬於操作級呢?《分析模式》給出了一條建模原則:“操作級中的物件會經常發生變化,它們的配置由很少發生變化的知識級來約束。”這是從變化的角度來區分的。操作級中的“測量”可以被定義成多種多樣的測量,但知識級的“現象型別”卻是可以窮舉的。因此這裡提到的“變化”表達的並非型別的變化,而是物件值的變化。
領域概念中存在一些定性的描述,例如醫療觀察模型中的血型A現象、汽車分類觀察模型中的汽車油量不足現象,它們都是在系統中確確實實存在的客觀事實,不會因為觀察是否建立而消亡,像這樣的定性描述放到知識級中,可以按照規則來使用它們,這是從領域概念的性質來區分的。
回到電商系統的促銷策略模型,促銷可以被定義為多種多樣,但促銷產品與促銷型別在促銷領域中卻是可以窮舉的,因此促銷應該被定義在操作級,而促銷產品與促銷型別則屬於知識級。當然,各自級別內部的屬性自然也會歸入到各自的級別中,正如數量之於測量,在促銷策略模型中,有效時段就屬於促銷的屬性,因此有效時段也屬於操作級的概念。
促銷活動屬於操作級,因為它類似案例中的測量概念,針對某一種促銷活動型別而言,一次促銷只有一個促銷活動。為了應對操作級物件(促銷活動)的變化,驅動我們引入了知識級的促銷活動型別(Activity Type)概念。
從領域概念的性質看,促銷型別為折扣(Discount)是一種定性描述,券型別為現金券也是一種定性描述,因此促銷型別和券型別屬於知識級。那麼,促銷規格為“滿200元減40元”是一種定性描述嗎?——不是。雖然一旦定義了這樣的規格,它確實是一種不變的事實,但它卻是附著在促銷規則上,一旦促銷規則失效或者被刪除,這樣的規格就沒有存在的意義了。因此促銷規則與規格應屬於操作級的概念。
每個促銷都有屬於自己的類別(Label),這個類別是促銷的一種定性描述,屬於操作級物件。在計算促銷優惠時,不同類別的商品會分別計算,同一類別則可以相容,這相當於分類彙總。對於促銷而言,如果我們將一個具體的促銷例項視為一個實體,在計算促銷優惠時,同一實體的促銷是互斥的,不同實體的促銷可以疊加組合,也可以按照優先順序(Priority)。這個優先順序屬於促銷的屬性。優先順序可以在配置促銷策略時事先配置,也可以由買家指定,例如買家在購買商品時,出現了多種促銷疊加的情況,買家就可以根據具體的購買情況選擇最適合自己的促銷,這時使用者指定的優先順序要高於事先配置的優先順序。
與優先順序屬性相同,我們還需要為“促銷”概念引入“狀態”屬性,例如標記該促銷物件的狀態為“未使用”、“已使用”和“過期”。同一個促銷不能被使用者無限使用,又或者需要給定一個有效期。其中,“已使用”和“過期”都表達了促銷例項的無效狀態。顯然,這個“狀態”屬性應該屬於知識級。再以拼多多為例,剛才提到的優惠券Bug就是促銷的“狀態”屬性未能在使用後設定為“已使用”狀態;又或者說在使用者使用該促銷優惠時,不曾檢查促銷的“狀態”屬性,僅允許在“未使用”狀態下才是有效可用的。
因此,我們引入分析模式中的建模原則與模式,可以獲得如下的分析模型:
對分析模型的驗證
我們可以結合實際的業務場景驗證獲得的促銷分析模型。以京東商城為例,如下圖所示:
上圖給出了兩種促銷類別(Label):聯合促銷活動與玩具元旦特惠。以玩具元旦優惠類別為例,促銷(Promotion)為“跨店鋪滿減”。該促銷的活動型別(Activity Type)包括適用店鋪(值為“跨店鋪”)、適用品種(值為“玩具”)。促銷產品(Promotion Product)為優惠(Special Offer),促銷產品型別(Product Type)為滿減(Reward),規則(Rule)為金額閾值規則,規格(Specification)為滿99.00元減。圖中的兩種玩具都屬於同一個促銷類別,因此在計算滿減時,這兩個商品是可以疊加的。對應的分析模型為:
我們再來看另外一個促銷場景:
上圖展現的促銷場景包含了多種促銷,它們的促銷類別(Lebel)皆為京東自營,因此在進行優惠計算時,這些商品是可以疊加的。這裡包含的促銷實體包括:
活動型別(Activity Type)之適用店鋪為京東自營,促銷產品為券(Coupon),促銷產品型別為滿減(Reward),優惠規則為金額閾值,規格分別為滿49減6、滿158減20、滿258減30、滿388減50等。
活動型別(Activity Type)之適用店鋪為京東自營,適用商品為自營晨光指定商品,促銷產品為券(Coupon),促銷產品型別為滿減(Reward),優惠規則為金額閾值,規格為滿98減10。
活動型別(Activity Type)之適用店鋪為京東自營,促銷產品為優惠(Special Offer),促銷產品型別為包郵(Free Shipping),優惠規則為金額閾值,規格為滿99。
活動型別(Activity Type)之適用店鋪為京東自營,促銷產品為優惠(Special Offer),促銷產品型別為換購(Trade-in),優惠規則為金額閾值,規格為滿30。
在促銷模型中,這些促銷實體就是一個個促銷,在實現時,體現為多個促銷例項,這些促銷例項可以透過促銷活動的“適用商品”活動型別,作用到同一件商品,形成這種促銷優惠的疊加。
目前給出的促銷模型考慮還不全面。一方面這取決於它適用的哪種電商應用場景,例如淘寶與京東的促銷策略就不相同,有的電商僅僅支援虛擬商品,相關的促銷領域邏輯就有所不同了。另一方面,該模型本身還未考慮如何與計算訂單金額、支付以及退換貨這些業務相結合。總之業務越複雜,模型也就變得相應的複雜,但同時也要學會利用抽象將模型化繁為簡,又或者在模型表達中用不同的檢視表達不同的概念,儘量讓模型變得精簡而直觀,同時又不會缺少關鍵的領域概念。
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/31562044/viewspace-2639492/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- 電商類促銷設計經驗小分享
- 144.從拼多多優惠券事件想到的事件
- 如何製作能一鍵分享的電商促銷活動邀請函?
- 從拼多多優惠券事件看到的一些反思事件
- 促銷模組
- 零售資料分析指導銷售:促銷時機看售罄率
- 促銷系統的設計
- 從疫苗事件看民眾的發聲之路事件
- 從Chrome原始碼看事件迴圈Chrome原始碼事件
- 助農進階:從補貼促銷到數字全景
- 從setTimeout說事件迴圈模型事件模型
- 促銷定價協議協議
- 國辦新規3招監管電商平臺雙十一促銷嚴防造假
- 從原始碼看 Android 事件分發原始碼Android事件
- 通過一道題來看React事件模型React事件模型
- 從 Chrome 原始碼看瀏覽器的事件機制Chrome原始碼瀏覽器事件
- Javascript事件模型系列(一)事件及事件的三種模型JavaScript事件模型
- 從語言學角度看詞嵌入模型模型
- 2019年“雙十一” ,您必須瞭解的電商平臺促銷三大趨勢
- 從IPHONE看IP電話的市場營銷問題iPhone
- Epic遊戲商城數次促銷銷售額曝光遊戲
- 微軟正式開啟Xbox聖誕促銷:眾多3A大作目前正在折扣促銷微軟
- 從Turbo Vision原始碼看事件驅動 (轉)原始碼事件
- 從卷積拆分和分組的角度看CNN模型的演化卷積CNN模型
- 電商包裹數背後的秘密,阿里為何緊張拼多多阿里
- 從番茄花園事件看商業軟體的“潛規則”事件
- 從filecoin銷燬機制看fil未來價值
- 跨境電商的營銷秘籍:如何智選營銷工具
- 從技術角度看騰訊雲“資料丟失”事件!事件
- 從wait的原始碼看撤銷偏向鎖的過程(revoke and rebias)AI原始碼
- Unity Assets Store 黑五促銷開啟!Unity
- 從上海地鐵撞車事件看“業務建模”的不可或缺性事件
- JS的事件繫結和事件流模型JS事件模型
- 遊戲營銷不是促銷 瞭解使用者才是關鍵遊戲
- 統一監聽所有模型的模型事件模型事件
- 從聯結器元件看Tomcat的執行緒模型——BIO模式元件Tomcat執行緒模型模式
- 從聯結器元件看Tomcat的執行緒模型——NIO模式元件Tomcat執行緒模型模式
- 事件模型和事件委託事件模型