電商前后臺設計全面解析之——商品管理系統

33 評論 51241 瀏覽 436 收藏 23 分鐘

從事電子商務行業,對電商系統設計的總結,各個模塊相互獨立,本文講解商品管理系統的設計。

電商行業商業模式

電商行業現如今有很多成熟的商業模式,大體有一下幾種:

  • B2C:企業與消費者之間的電子商務,類似天貓、京東是屬于此類模式,企業在電子商務平臺上售賣,消費者進行購買,是最常見的電子商務模式。
  • B2B:企業與企業之間的電子商務,也可以說是供應方與采購方之間的電子商務,此類模式是解決了上游到中游的采購問題,降低采購成本,類似阿里巴巴的1688。
  • C2C:消費者與消費者之間的電子商務,此類模式對商家的包容性更大,很多是個人,比如:淘寶、微店都是此類。
  • O2O:線上到線下再到線上,線上消費,線下服務,線上核銷,例如:美團、餓了么。

商品管理系統說明

商品管理系統,是整個電商系統的數據基礎,用于記錄與商品有關的數據,雖然系統邏輯不復雜,但是由于操作的數據比較多,需要掌控細節,訂單,營銷,支付,物流等環節都需要從商品中心獲取數據。

商品管理系統主要包含以下幾個部分:

  1. 分類管理:管理商品分類,主要起到對不同商品的歸類和;
  2. 品牌管理:管理商品品牌,為不同的商品添加品牌;
  3. 規格管理:規格也可以叫屬性,決定了SKU,SPU,是商品模塊重要的部分;
  4. 參數管理:參數也叫非關鍵屬性,與規格類似,但是不決定SKU,只起到展示的作用;
  5. 商品推薦:商品推薦分常規推薦和個性化推薦;
  6. 商品搜索:涉及商品搜索邏輯和之后的展示問題;
  7. 商品評論:關鍵詞,敏感詞匯的篩選,評論等級等;
  8. 商品管理 :? 對商品的增刪改查以及上下架等其他操作,比較重要。

分類管理

分類也叫做類目,是商品管理系統最重要也是最基礎的部分,當我們在設計商品系統的時候應該先設計分類系統。

為什么呢?

分類顧名思義就是將東西進行分門別類,這是衣服,這是褲子,方便我們的辨認。同時商品,規格,參數,品牌都是要掛靠在分類之下的。

前臺類目和后臺類目

我們平時在設計分類的時候可能只有前臺分類,然后分類的標題在前段展示,這種方式其實并不好,原因有以下幾點:

  1. 不利于營銷,如果我們只有一個分類我們給他起名字我們要考慮到后臺的操作性,還要兼顧用戶的體驗是非常困難的。對于用戶這個分類可以叫漂亮的衣服,但是對于后臺錄入來說就會想什么是漂亮額衣服。
  2. 不利于管理,你是否有時候想要刪掉某一個分類,但是分類下有很多商品?這個時候就很頭疼了。
  3. 不利于檢索,設置豐富的前臺類目可以讓用戶更好的找到分類,可以利用大數據分析用戶喜歡搜索什么,然后給分類起名字。

解決方法就是設計兩個分類,一個前端分類,一個后端分類。

幾個意思呢,后端分類是給我們自己看的,我們要把商品掛靠在后端分類之下,前端分類是給用戶看的,用戶喜歡什么我們就起什么名字,也就是說給分類起一個昵稱,后端分類就好比我們的姓名,前端分類就好比我們額游戲ID。

后端類目要盡量簡潔明了讓人一看就知道什么意思,同時要易于管理可以加上編號之類的,前臺類目根據需求隨便其就行了。

那么具體怎么設計呢?

在后臺設置兩個菜單一個是后臺類目,一個是前臺類目,后臺類目就是我們平時設計的主要包含以下字段:

  1. 分類名稱:分類的名稱,自己起;
  2. 前臺類目:對應的前臺類目是什么;
  3. 描述:對分類的描述;
  4. 庫存:這個分類下還有多少庫存;
  5. 創建時間,修改時間:什么時候建的,什么時候修改的;
  6. 操作:只可以編輯,不可以刪除(后臺類目不可刪除,謹慎)。

前臺類目:前臺類目和后臺類目基本相同,不同之處在于,我們在創建前端分類的時候要注意下,要選擇前端分類是掛靠在哪個后端分類之下的,具體掛靠規則我一會再說,不過前端類目一定是要掛靠在后端類目之下的哦,不然就是小黑孩,沒有身份。

另外前臺類目可以編輯,刪除,屏蔽,即便分類下有商品刪除也沒有關系,因為商品是在后臺分類下的,這樣的話我們就可以根據營銷額需求靈活的變動前端的類目。

情人節到了,那就多弄關于禮物,玫瑰花之類的分類,將其他分類屏蔽掉,冬天的時候可以將關于夏季的服裝分類全部屏蔽或者刪除。

分類層級

那啥,我說說這個分類層級的問題,根據規模和業務的不同,分類的層級肯定也是不同的。那么這里呢,我是建議統一設置成三級,上衣——羽絨服——男士羽絨服,層級太少,如果商品太多是不易于管理的,層級太深也不行,太深的話就會不利于尋找,找了半天找不到也是問題,所以直接設置成三級類目。

后臺具體設計的時候,我建議是后臺分類直接設計成三級,然后就不要動了。這樣方便管理

掛靠規則

下面說說掛靠規則,首先前臺分類一定是要掛靠在后臺分類之下的,商品是必須掛靠在后臺分類之下的,并且:

  1. 商品必須掛靠在最下級分類之下,也就是最小分類,并且只能掛靠一個分類。為什么呢?因為我們創建規格,屬性,品牌都必須掛靠在最小分類之下。為啥呢,因為易于管理,如果你不掛靠在最小分類的下面,那你創建這個下級分類的目的是什么,同時掛靠多級會造成理解困難,這個商品到底是什么分類,可能想不明白。
  2. 前端分類必須掛靠在后端分類之下,對應關系是比較靈活的,一個前端分類可以對應一個后端分類,同時也可以一對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個步驟,其業務流程是這樣的,看下面:

  1. 輸入關鍵字:首先用戶要輸入關鍵字,這個時候后臺要對關鍵字盡心處理,將用戶輸入的關鍵字進行拆分處理,比如:春季流行青年運動褲,會被拆分成春季、流行、青年、運動褲,三個關鍵詞,根據用戶以往的行為數據找到相關的熱點分類。
  2. 數據查詢:查詢出數據庫后,系統會從數據庫中索引包含關鍵詞的商品,商品搜索時,主要是從商品的標題,分類,品牌,規格等進行關聯搜索。
  3. 搜索排序:搜索完成后找到了先關的商品,下面就要對這些商品進行排序,排序可以根據商品的相關性,就是用戶輸入的搜索詞與商品標題,分類,品牌的關聯度進行排序,關聯度越高排序越靠前。還有其他的排序依據:銷量,價格,評論數,上架時間,根據這些對商品進行排序。
  4. 結果輸出:排序完成就要對商品進行前端的展示。
  5. 搜索篩選:搜索結果頁面一般會支持我們進行商品的篩選,商品篩選可以讓用戶更快的找到自己想要的商品,篩選的依據一般有分類,品牌,服務標簽,價格區間,用戶根據關鍵詞搜索到的商品有可能不是同一個類目之下的,經過分類的篩選就可以找到同一類商品。品牌篩選用于找到這個品牌下的商品,服務標簽是后臺為商品貼的標簽,比如,包郵,分期。價格區間是吧價格分為多個區間用戶進行篩選。

商品評價

商品評價主要是用戶收貨后對商品的評價,功能點主要涉及敏感詞的處理,評價的形式,以及評價的管理。

  1. 敏感詞處理:后臺要建立敏感詞庫,對敏感詞進行處理,當用戶輸入敏感詞匯時進行特殊處理,比如:星號。
  2. 評價的形式:評價形式一般有這幾種,文字評價,圖文評價,視頻評價,星級評價(一到五星),標簽評價(后臺自定義標簽,用戶選擇,比如:服務周到,物流快)。
  3. 評價管理:用戶發布評價后后臺要進行審核,若審核不通過將刪除用戶評價,并給出原因說明,商家同時可以進行回復,另外一點就是涉及評價的排序與展示的問題,用戶如果長時間沒有評價是默認好評還是如何處理,是不是應該將打分高的評價排在前面。

商品管理

商品添加

商品添加是商品管理中最重要的功能,因為商品的信息比較復雜,添加時需要填寫的信息比較多,在設計時關鍵的問題是如何將各部分進行分類,讓用戶易于理解,便于操作。

添加商品時需要按照順序填寫下面這些信息,商品添加顧名思義,需要添加關于商品的信息,是信息、不是管理,比如:營銷,折扣問題在添加商品是不要設置。

  1. 分類:對,不是先寫標題,而是先選擇分類,如果是多級分類必須只能選擇最小分類,而且只能選擇一個分類,不可多選。
  2. 標題:設置商品的標題,主要對字數進行控制。
  3. 品牌:顯示已選分類下可選品牌,可多選。
  4. 規格:選擇規格,或者規格組,多個規格和規格值選擇完成后要進行編輯對應的SKU信息,有進貨價格,銷售價格,虛擬價格,庫存,SKU編碼,保存后生成總庫存。
  5. 參數:選擇參數,或者自己設置參數名稱和參數值。
  6. 標簽:選擇標簽,比如七天包退,14天包換,正品包郵。
  7. 商品圖:上傳商品圖片,多張。
  8. 商品詳情:文本編輯器。
  9. 物流信息等:選擇物流模板,或者包郵,選擇物流模板用戶需要承擔運費。

商品修改

商品修改需要將修改后的信息同步到數據庫和前端,需要判斷什么商品可以修改,什么商品不可以修改,比如用戶付費之后的商品是不能同步信息的。

商品刪除

刪除商品需要在商品下架后刪除,商品上架狀態不可刪除,同時生產訂單的商品數據不可刪除。

商品上下架

商品上架后再前端展示,下架后再前端不展示。

價格管理

商品上傳之后支持對價格的動態管理以便應對業務或者營銷的需求。

促銷管理

設置商品的促銷活動需要調取營銷模塊的數據,促銷活動是在營銷模塊設置好的,需要同步促銷活動數據。

標簽管理

對商品額標簽進行動態調整,顯示哪些或者不顯示哪些。

商家管理

如果是多商戶商城,還要管理商家的商品,對商家商品進行審核,違規下架等,商家的商品與平臺的商品數據相互獨立。

庫存管理

商品庫存變更需要及時同步信息到前端。

其他

商品的限購數量,會員折扣,積分等等,很多模塊如果的細致,對商品管理有很大的幫助。

商品的前端展示形式與功能

商品列表頁

商品在前端的展示首先會以列表的形式,可能在首頁,搜索結果頁等其他頁面,不管在什么頁面其展示形式是固定的,一般是每行一個或者每行兩個,展示商品主圖,展示信息主要有商品的標題,價格,原價,標簽,付款人數,點擊進入商品詳情頁面,商品詳情頁面是商品信息展示的重要頁面,商品的信息基本都在閑情頁面展示

商品詳情頁

商品詳情頁面是商品信息展示的重要頁面,商城的信息流也主要是圍繞著商品進行的商品頁面一般有如下信息:

商品的多張圖片,或者視頻介紹,商品的價格區間,商品原價,商品的標題,如果自營顯示自營標簽,商品的點贊人數,分享按鈕,添加購物車按鈕,商品發貨地址,快遞費,銷量,優惠券信息,領券按鈕,服務信息,規格選擇,參數選擇,還有評價,詳情,商品推薦。

詳情頁底部一般有店鋪入口,客服,收藏按鈕,加入購物車和立即購買。

 

本文由 @張先生 原創發布于人人都是產品經理。未經許可,禁止轉載

題圖來自Unsplash,基于CC0協議

更多精彩內容,請關注人人都是產品經理微信公眾號或下載App
評論
評論請登錄
  1. 寫的很棒

    來自江蘇 回復
  2. 給分類配置屬性組,屬性組里面的某些屬性可以作為篩選條件,需要篩選的話就配置屬性值。然后創建類別,從屬性組里面選規格,從屬性組里面選參數。添加商品時,先選擇分類,之后選擇類別,配置規格sku,配置商品參數,保存提交。

    來自山西 回復
  3. 怎么覺得跟 《電商產品經理寶典:電商后臺系統產品邏輯全解析》這本書一模一樣,剛好我昨天在重溫

    來自廣東 回復
  4. 這其實算不上抄襲,是一種統一的設計形式。并不能說是抄襲。因為有些模塊設計來設計去其實就那些需求,你不能說是抄襲,這樣的認知太狹隘了。就比如說1 1=2,都知道等于2,你說二他說二就是抄襲嗎

    回復
  5. 目前電商平臺框架基本固定了,作者這種較為淺顯的大而全的寫作方式難免被人說抄襲,建議以某個具體的問題或案例為切入點,再系統的介紹電商平臺對應模塊或系統。這樣相對來說能夠寫的更深入些。

    回復
    1. 好的,我明白你的意思,但是我要先寫宏觀的,這樣能有一個全面的了解,然后再某一個地方進行解析

      來自山東 回復
    2. 寫的好,希望多點這種電商前后臺交互的內容,做到宏觀認識,還有,作者能推薦相關的書嗎?謝謝!

      來自廣東 回復
  6. 寫的不錯 和千米電商云后臺設計的是一樣的

    來自陜西 回復
  7. 搜索商品是按分類搜還是標簽搜?

    回復
  8. 業務邏輯

    回復
    1. 同學,竟然在這遇見了??

      回復
  9. 寫的不錯。。以后配原型吧

    來自廣東 回復
  10. 這就是個功能描述,要是能配合產品原型講解可能更好些。

    來自湖北 回復
  11. 類目前后分離的好像在哪里見過,忘記了。。。

    來自北京 回復
    1. 基本上大點的電商平臺都是前后端類目分離的

      回復
  12. 分類、品牌、規格是并列關系,在創建商品時,賦予商品的屬性,怎么能說品牌和規格要掛在分類下面呢

    回復
    1. 同意,品牌和分類本來就是多對多的關系,根本沒有掛靠一說,只能說他們有關聯關系
      同樣,對于前端分類,也不贊同是掛靠在后臺分類下,前端分類與后臺分類可以是一對一,也可以是一對多,但不能是多對多甚至多對一,所以也不能說掛靠在后臺分類下,硬要說掛靠也是后臺分類掛靠在前端分類下

      來自上海 回復
  13. 想想哥在4年前也是做這些東西的,還挺感慨。

    來自北京 回復
    1. 那你現在做啥

      回復
  14. 有蠻多共鳴點的,學習了. ??

    來自上海 回復
  15. 感謝大家收藏點贊,因為市面上很多都是一些理論的文章,而實戰性的文章很少,我的文章偏向告訴大家具體怎么設計,因為剛開始寫,肯定有很多不足,我會寫補充文章,然后會把整個商城系統做成系列文章

    來自山東 回復
  16. 你這是直接從書上抄襲過來的吧,還以為有啥看點呢,失望

    回復
    1. 有病你

      回復
  17. 品牌管理那里備注寫錯了。。

    來自廣東 回復
  18. 挺好的,正好目前要跟一個商品管理系統,很多想法和功能點跟你的不謀而合

    來自湖北 回復
  19. 溫故而知新,可以為師矣

    來自廣東 回復
  20. 為什么一定是三級而不是可以自己設置是幾級就是幾級呢?

    來自廣東 回復
    1. 級別太少,不利于后期拓展
      級別太多,路徑太深
      統一設置為3級,是大平臺培養出來的用戶習慣

      回復
  21. 首先,這是我總結的一些東西,希望對大家有幫助,剛開始寫文章,不足的地方也請大家指出,不過澄清一點,我是讀過不少的書,但是絕沒有搬運和抄襲,

    來自山東 回復
    1. 有一些錯別字,你可以檢查一下

      來自湖北 回復
    2. 謝謝提出

      來自山東 回復
  22. 學習了。謝謝

    來自江蘇 回復
    1. o

      回復