B2C自營商城的商品設計方案
去年我們的美妝社區APP,上線了自有商城。之后經過多次版本迭代,商城系統的模塊已經基本健全,值此時間分享一些經驗出來,希望可以共同交流。
主要講講服務端的架構設計以及商品呈現邏輯。可能對某些PM來說有點難理解,但是我認為這是設計商城系統的PM必須具備的架構能力,而且算是比較基礎和底層的部分。
一、商品的基本概念
1.1、對用戶而言
一般來說有產品、商品、贈品等概念。
1.2、對數據庫而言
可能只有spu,sku兩個概念,這是最底層的實體。
- SPU(Standard Product Unit)是指標準化產品單元,是商品信息聚合的最小單位。比如iPhone6。
- SKU(Stock Keeping Unit)是指庫存量單位,即庫存進出計量的基本單元。比如iPhone6國行白色16G。
1.3、對功能而言
至少有產品,標準化商品,下單商品3個概念。
- 下單商品??隙ㄊ且粋€spu下的sku,對應著商品編碼。
- 標準化產品。對應著spu,是幾個sku的集合。
- 產品。顯示在商城貨架上,可能是一個spu,可能是不同spu的組合。
注意所謂的sku可能不是單個物理實體,比如美妝行業經常把2款化妝品用膠布綁在一起作為一個sku,存入倉庫。
二、商品的存儲
一般而言,B2自營商城選擇租用第三方倉庫并對接其系統,當規模很大的時候才會考慮自建倉庫。
目前我們業務剛剛起步沒多久,所以只有一個倉庫,比較簡單。
如果倉庫有多個的時候,一般會根據“選擇最近倉庫-庫存是否足夠”的原則來處理配貨發貨,當然可能還涉及到合并包裹的問題。
三、商品的實體關系
以上講了商品架構中需要涉及到的實體,而他們的屬性和關系決定著數據庫中商品表該如何設計。
可以參考這篇文章《如何用ER圖繪制業務實體模型 》,了解關于實體關系模型的更多知識。
四、商品狀態機
商品的上下架狀態是用來區分商品是否展示給用戶,以及是否可以成功下單。
贈品是一種特殊的spu,支持上架并支持用戶購買,但是建議設為已下架并且是正確價格。
需要說明的是,售完下架和我下架的,是為了方便運營客服童鞋操作商城運營系統而設計的,采用了和淘寶賣家的商品狀態機相似的做法。
可以參考這篇文章《如何繪畫狀態機來描述業務變化》來了解其原理。
五、商品的呈現
大部分電商的商品詳情,呈現邏輯是相似的。
另外京東自營會根據收貨地址和倉庫的位置進行匹配、部分電商會在進入該頁面的時候會選中sku并且自動跳過庫存不足的。
六、總結
我沒有講到類目、商品標簽、商品關鍵屬性、銷售屬性、其他屬性,包括商品庫存。
不是覺得不重要,而是我只講了最基礎最底層的設計,其他的都是根據業務在此基礎上面演變而來。
更多關于商品設計的內容,可以點擊DEMO。
相關閱讀
#專欄作家#
浪子,業務型PM,浪子PRD系列51prd.com,公眾號:langzisay。
本文由 @浪子 原創發布于人人都是產品經理。未經許可,禁止轉載。
不是技術出身的我,沒看懂m、n、1是什么意思,能針對這點再解釋下嗎?
代表2個實體的數量關系,這個直接百度更清晰。
好比1個SPU肯定是M個SKU,M≥1。
而商品和SPU應該是m:n的關系。
嗯嗯,百度百科那里有個E-R圖的條目,把那個又看了一遍,基本上了解了,謝謝你
樓主,我有個總是。既然贈品設置為支持上架和購買,那為什么要設置為已下架呢?
滿足贈品除了可贈之外,也可購買的業務場景。
既然為滿足可購買的業務場景,為什么要設置為已“下”架呢?就保持已上架狀態就可以了吧?話說已下架狀態的商品應該是無法購買的吧。
有時候部分贈品不能賣,比如活動前。所以需要已下架狀態。活動后可能又能賣了,所以使之具備普通商品的特性。
已下架狀態的商品,不可以買家選購。但是可以系統根據規則自動加進去。
哦。懂了。多謝。
多謝分享。SPU和商品應該是nSPU > 1商品的關系吧?感覺沒見過1個SPU由多個商品組成的情況呢。
商品是一個泛泛的概念,設計商品功能底層的時候,我們只說spu,sku等精確概念。
1個spu=n個sku。
商品呈現那里,狀態是手動下架,為什么顯示已下架按鈕,而不直接不顯示此商品。上下架和該商品的展示沒有關系,而是在另外的地方控制是否展示?
手動下架的商品不能直接根據此狀態來隱藏該商品詳情,有這樣一些場景還是需要展示相關信息的,比如已購商品被下架了而用戶需要查看下當時的信息(和目前沒有做商品快照也有一點關系)。
商品的展示狀態,目前沒有做過多涉及,僅做了已刪除會用一個特殊頁面來表示,和你說的不顯示應該是同一個意思。
一般情況 下,已下架商品的商品詳情一般會保留在store ,但是不會被用戶搜索到。也就是用戶通過搜索是搜索不到已下架商品的,但是通過URL訪問,可以進入到已下架商品的詳情頁面, 如用戶點擊訂單里的商品。