PMBear從事電子商務行業，對電商系統設計的總結，各個模塊相互獨立，本文講解商品管理系統的設計。
電商行業商業模式
電商行業現如今有很多成熟的商業模式，大體有一下幾種：
- B2C：企業與消費者之間的電子商務，類似天貓、京東是屬於此類模式，企業在電子商務平台上售賣，消費者進行購買，是最常見的電子商務模式。
- B2B：企業與企業之間的電子商務，也可以說是供應方與採購方之間的電子商務，此類模式是解決了上游到中游的採購問題，降低採購成本，類似阿里巴巴的1688。
- C2C：消費者與消費者之間的電子商務，此類模式對商家的包容性更大，很多是個人，比如：淘寶、微店都是此類。
- O2O：線上到線下再到線上，線上消費，線下服務，線上核銷，例如：美團、餓了么。
商品管理系統說明
商品管理系統，是整個電商系統的數據基礎，用於記錄與商品有關的數據，雖然系統邏輯不複雜，但是由於操作的數據比較多，需要掌控細節，訂單，營銷，支付，物流等環節都需要從商品中心獲取數據。
商品管理系統主要包含以下幾個部分：
- 分類管理：管理商品分類，主要起到對不同商品的歸類和；
- 品牌管理：管理商品品牌，為不同的商品添加品牌；
- 規格管理：規格也可以叫屬性，決定了SKU，SPU，是商品模塊重要的部分；
- 參數管理：參數也叫非關鍵屬性，與規格類似，但是不決定SKU，只起到展示的作用；
- 商品推薦：商品推薦分常規推薦和個性化推薦；
- 商品搜索：涉及商品搜索邏輯和之後的展示問題；
- 商品評論：關鍵詞，敏感詞彙的篩選，評論等級等；
- 商品管理 : 對商品的增刪改查以及上下架等其他操作，比較重要。
分類管理
分類也叫做類目，是商品管理系統最重要也是最基礎的部分，當我們在設計商品系統的時候應該先設計分類系統。
為什麼呢？
分類顧名思義就是將東西進行分門別類，這是衣服，這是褲子，方便我們的辨認。同時商品，規格，參數，品牌都是要掛靠在分類之下的。
前台類目和後台類目
我們平時在設計分類的時候可能只有前台分類，然後分類的標題在前段展示，這種方式其實並不好，原因有以下幾點：
- 不利於營銷，如果我們只有一個分類我們給他起名字我們要考慮到後台的操作性，還要兼顧用戶的體驗是非常困難的。對於用戶這個分類可以叫漂亮的衣服，但是對於後台錄入來說就會想什麼是漂亮額衣服。
- 不利於管理，你是否有時候想要刪掉某一個分類，但是分類下有很多商品？這個時候就很頭疼了。
- 不利於檢索，設置豐富的前台類目可以讓用戶更好的找到分類，可以利用大數據分析用戶喜歡搜索什麼，然後給分類起名字。
解決方法就是設計兩個分類，一個前端分類，一個後端分類。
幾個意思呢，後端分類是給我們自己看的，我們要把商品掛靠在後端分類之下，前端分類是給用戶看的，用戶喜歡什麼我們就起什麼名字，也就是說給分類起一個昵稱，後端分類就好比我們的姓名，前端分類就好比我們額遊戲ID。
後端類目要盡量簡潔明了讓人一看就知道什麼意思，同時要易於管理可以加上編號之類的，前台類目根據需求隨便其就行了。
那麼具體怎麼設計呢？
在後台設置兩個菜單一個是後台類目，一個是前台類目，後台類目就是我們平時設計的主要包含以下字段：
- 分類名稱：分類的名稱，自己起；
- 前台類目：對應的前台類目是什麼；
- 描述：對分類的描述；
- 庫存：這個分類下還有多少庫存；
- 創建時間，修改時間：什麼時候建的，什麼時候修改的；
- 操作：只可以編輯，不可以刪除（後台類目不可刪除，謹慎）。
前台類目：前台類目和後台類目基本相同，不同之處在於，我們在創建前端分類的時候要注意下，要選擇前端分類是掛靠在哪個後端分類之下的，具體掛靠規則我一會再說，不過前端類目一定是要掛靠在後端類目之下的哦，不然就是小黑孩，沒有身份。
另外前台類目可以編輯，刪除，屏蔽，即便分類下有商品刪除也沒有關係，因為商品是在後台分類下的，這樣的話我們就可以根據營銷額需求靈活的變動前端的類目。
情人節到了，那就多弄關於禮物，玫瑰花之類的分類，將其他分類屏蔽掉，冬天的時候可以將關於夏季的服裝分類全部屏蔽或者刪除。
分類層級
那啥，我說說這個分類層級的問題，根據規模和業務的不同，分類的層級肯定也是不同的。那麼這裡呢，我是建議統一設置成三級，上衣——羽絨服——男士羽絨服，層級太少，如果商品太多是不易於管理的，層級太深也不行，太深的話就會不利於尋找，找了半天找不到也是問題，所以直接設置成三級類目。
後台具體設計的時候，我建議是後台分類直接設計成三級，然後就不要動了。這樣方便管理
掛靠規則
下面說說掛靠規則，首先前台分類一定是要掛靠在後台分類之下的，商品是必須掛靠在後台分類之下的，並且：
- 商品必須掛靠在最下級分類之下，也就是最小分類，並且只能掛靠一個分類。為什麼呢？因為我們創建規格，屬性，品牌都必須掛靠在最小分類之下。為啥呢，因為易於管理，如果你不掛靠在最小分類的下面，那你創建這個下級分類的目的是什麼，同時掛靠多級會造成理解困難，這個商品到底是什麼分類，可能想不明白。
- 前端分類必須掛靠在後端分類之下，對應關係是比較靈活的，一個前端分類可以對應一個後端分類，同時也可以一對N，N對1，N對N，自由組合，因為商品的掛靠已經有後台分類決定了，前台在後台的掛靠只是因為具體需要靈活運用，對邏輯沒有影響。因為不管怎麼樣，前端顯示就會尋找前端分類對應那些後端分類，而這些分類下有哪些商品。
品牌管理
品牌這個東西在一些小的商城裡面可能沒有，但是為了系統的介紹，我還是得念叨念叨。
設計乾貨
LOGO：品牌都是有LOGO的，對吧
中文名：品牌的中文名是什麼？老張？
英文名：品牌的英文名，zhangser
產地：品牌是來自哪裡?日本還是加拿大？
備足：備足說明下
狀態：是否啟用（啟用之後在創建商品的時候才能拉取到）
操作：創建新品牌，編輯，刪除，啟用/禁用
掛靠規則
品牌的掛靠規則與前台類目的掛靠規則相同，也是掛靠在後台分類之下的，對應關係也是靈活多變的，不再廢話，上面說過。
規格管理
規格也叫屬性，叫什麼無所謂，得知道規格是除了分類之外的另外一個重點，因為規格決定了SKU、SPU、庫存、價格，我們在添加商品的時候規格也是最重要的。那麼現在來說規格的實際基本有兩種形式：一種是單規格單選，另外一種是多規格單選。
- 單規格單選：一件商品在購買的時候進行單選：紅色L，藍色XL，黑色XXL，這是3個SKU，也就是說有三種價格
- 多規格單選：一件商品在購買的時候進行多選：顏色（紅色，藍色，黑色）、尺碼（L、XL、XXL），一個顏色可以對應三個尺碼，33得9，就是9個SKU，也就是說有9種價格。
我建議是選擇第二種設計方式，因為可拓展性強，同時也利於前端的展示，下面說下多規格單選的設計規則：
設計乾貨
規格名稱：規格的名稱，比如顏色；
所屬後台分類：規格是屬於哪個後台分類的；
規格值：一個規格名稱對應對個規格值，紅色，藍色，黑色；
創建時間，修改時間：什麼時候建的，什麼時候修改的；
備註：加以備註說明；
操作：修改，刪除 （規格下有商品時無法刪除），啟用/禁用（禁用之後在分類下找不到此規格）。
規格分組
我們在創建規格時，會把規格掛靠在分類下，但是有的時候某一個分類可能會有很多種規則組合，為了便於使用我們可以創建規格組，比如：運動鞋，有的時候可能會有尺碼，顏色。
而有的時候可能只有尺碼，這樣我們在選擇規格的時候可能會進行多選，選擇我們需要的規格，但是這樣也很麻煩，這個時候就引入了規格分組，一個分組下面有多個規格，給分組起名字，這樣選擇規格的時候直接選擇分組就行了，是不是方便很多。
規格在分類中的繼承
有些規格是多種分類通用的，我們就可以將這個規格掛靠在夫級分類下面，這樣當我們創建商品選擇其下級分類的時候自動就會有其上級擁有的分類。也就是說，下級分類繼承了上級分類的規格。
這樣會讓我們方便很多，比如：尺碼這個規格衣服類的商品基本都會有，我們把它掛靠在衣服分類之下，這樣上衣，褲子，鞋子都會有尺碼這個規格，我們選擇商品選擇鞋子分類時也就可以選擇尺碼規格了。
參數管理
參數與規格類似，但是不決定SKU的信息，也不決定價格和庫存，並且參數名稱和參數值可以自由創建，參數只是起到了展示作用，讓用戶更加了解商品的信息，同樣參數也需要掛靠在分類之下。
設計乾貨
參數名稱：參數的名稱，比如新舊程度，毛重
參數值：參數的數值，新，舊等
備註：設置備註
商品推薦
商品推薦是商城系統比較常見的功能模塊，推薦位置有很多，首頁推薦，搜索結果頁推薦，購物猜你喜歡。
商品推薦屬於營銷模塊，推薦位置是非常珍貴的，一款軟件就那麼大，推薦的效果不僅影響用戶體驗還影響商業盈利，如果推薦的商品用戶老是不喜歡，那麼用戶就會對軟件產生厭倦，因為沒有我想要的東西，同時也就沒有商業盈利了，商品推薦分類常規推薦和個性化推薦兩種
常規推薦：手動往推薦位置添加商品，或是根據簡單的篩選添加推薦商品，比如銷量，瀏覽量，上傳時間等，方式比較簡單，對技術要求不高，但是推薦效果不好
個性化推薦：個性化推薦是屬於產品智能模塊，比如只能排序都屬於產品智能。
個性化推薦流程：首先要選擇相關數據，就是哪些數據會影響推薦效果，哪些數據可以成為推薦的因素，主要是根據用戶的行為數據進行用戶行為分析，然後創造用戶畫像，得出用戶畫像與不同商品的相關性，設計算法模型，最後進行推薦。
流程就是：數據的採集，數據的分析，用戶個性化推薦，不過個性化推薦對用戶規模有一定要求，運用大數據是要依賴龐大的數據基礎的，這樣得出的算法模型才具有實際意義，對於用戶量不是太多的商城，基本是採取常規推薦。
商品搜索
用戶通過商品搜索可以快速找到自己想要的信息，商品搜索也是流量的入口商品搜索的業務流程是經過4個步驟，其業務流程是這樣的，看下面：
- 輸入關鍵字：首先用戶要輸入關鍵字，這個時候後台要對關鍵字盡心處理，將用戶輸入的關鍵字進行拆分處理，比如：春季流行青年運動褲，會被拆分成春季、流行、青年、運動褲，三個關鍵詞，根據用戶以往的行為數據找到相關的熱點分類。
- 數據查詢：查詢出數據庫后，系統會從數據庫中索引包含關鍵詞的商品，商品搜索時，主要是從商品的標題，分類，品牌，規格等進行關聯搜索。
- 搜索排序：搜索完成後找到了先關的商品，下面就要對這些商品進行排序，排序可以根據商品的相關性，就是用戶輸入的搜索詞與商品標題，分類，品牌的關聯度進行排序，關聯度越高排序越靠前。還有其他的排序依據：銷量，價格，評論數，上架時間，根據這些對商品進行排序。
- 結果輸出：排序完成就要對商品進行前端的展示。
- 搜索篩選：搜索結果頁面一般會支持我們進行商品的篩選，商品篩選可以讓用戶更快的找到自己想要的商品，篩選的依據一般有分類，品牌，服務標籤，價格區間，用戶根據關鍵詞搜索到的商品有可能不是同一個類目之下的，經過分類的篩選就可以找到同一類商品。品牌篩選用於找到這個品牌下的商品，服務標籤是後台為商品貼的標籤，比如，包郵，分期。價格區間是吧價格分為多個區間用戶進行篩選。
商品評價
商品評價主要是用戶收貨后對商品的評價，功能點主要涉及敏感詞的處理，評價的形式，以及評價的管理。
- 敏感詞處理：後台要建立敏感詞庫，對敏感詞進行處理，當用戶輸入敏感詞彙時進行特殊處理，比如：星號。
- 評價的形式：評價形式一般有這幾種，文字評價，圖文評價，視頻評價，星級評價（一到五星），標籤評價（後台自定義標籤，用戶選擇，比如：服務周到，物流快）。
- 評價管理：用戶發布評價后後台要進行審核，若審核不通過將刪除用戶評價，並給出原因說明，商家同時可以進行回復，另外一點就是涉及評價的排序與展示的問題，用戶如果長時間沒有評價是默認好評還是如何處理，是不是應該將打分高的評價排在前面。
商品管理
商品添加
商品添加是商品管理中最重要的功能，因為商品的信息比較複雜，添加時需要填寫的信息比較多，在設計時關鍵的問題是如何將各部分進行分類，讓用戶易於理解，便於操作。
添加商品時需要按照順序填寫下面這些信息，商品添加顧名思義，需要添加關於商品的信息，是信息、不是管理，比如：營銷，折扣問題在添加商品是不要設置。
- 分類：對，不是先寫標題，而是先選擇分類，如果是多級分類必須只能選擇最小分類，而且只能選擇一個分類，不可多選。
- 標題：設置商品的標題，主要對字數進行控制。
- 品牌：顯示已選分類下可選品牌，可多選。
- 規格：選擇規格，或者規格組，多個規格和規格值選擇完成後要進行編輯對應的SKU信息，有進貨價格，銷售價格，虛擬價格，庫存，SKU編碼，保存後生成總庫存。
- 參數：選擇參數，或者自己設置參數名稱和參數值。
- 標籤：選擇標籤，比如七天包退，14天包換，正品包郵。
- 商品圖：上傳商品圖片，多張。
- 商品詳情：文本編輯器。
- 物流信息等：選擇物流模板，或者包郵，選擇物流模板用戶需要承擔運費。
商品修改
商品修改需要將修改後的信息同步到數據庫和前端，需要判斷什麼商品可以修改，什麼商品不可以修改，比如用戶付費之後的商品是不能同步信息的。
商品刪除
刪除商品需要在商品下架后刪除，商品上架狀態不可刪除，同時生產訂單的商品數據不可刪除。
商品上下架
商品上架后再前端展示，下架后再前端不展示。
價格管理
商品上傳之後支持對價格的動態管理以便應對業務或者營銷的需求。
促銷管理
設置商品的促銷活動需要調取營銷模塊的數據，促銷活動是在營銷模塊設置好的，需要同步促銷活動數據。
標籤管理
對商品額標籤進行動態調整，顯示哪些或者不顯示哪些。
商家管理
如果是多商戶商城，還要管理商家的商品，對商家商品進行審核，違規下架等，商家的商品與平台的商品數據相互獨立。
庫存管理
商品庫存變更需要及時同步信息到前端。
其他
商品的限購數量，會員折扣，積分等等，很多模塊如果的細緻，對商品管理有很大的幫助。
商品的前端展示形式與功能
商品列表頁
商品在前端的展示首先會以列表的形式，可能在首頁，搜索結果頁等其他頁面，不管在什麼頁面其展示形式是固定的，一般是每行一個或者每行兩個，展示商品主圖，展示信息主要有商品的標題，價格，原價，標籤，付款人數，點擊進入商品詳情頁面，商品詳情頁面是商品信息展示的重要頁面，商品的信息基本都在閑情頁面展示
商品詳情頁
商品詳情頁面是商品信息展示的重要頁面，商城的信息流也主要是圍繞着商品進行的商品頁面一般有如下信息：
商品的多張圖片，或者視頻介紹，商品的價格區間，商品原價，商品的標題，如果自營顯示自營標籤，商品的點贊人數，分享按鈕，添加購物車按鈕，商品發貨地址，快遞費，銷量，優惠券信息，領券按鈕，服務信息，規格選擇，參數選擇，還有評價，詳情，商品推薦。
詳情頁底部一般有店鋪入口，客服，收藏按鈕，加入購物車和立即購買。
