編輯導語：如今隨著互聯網的發展，電商行業越來越火熱，不少用戶都會選擇在便利優惠的電商平臺消費，電商產品經理也開始涉足電商各類型的運營。本篇文章詳細介紹了電商核心系統的產品設計方案，希望對你有所幫助。

《電商產品經理從0到1》系列文章面向0~3歲的產品經理或者有多年產品工作經驗卻剛接觸電商領域的產品經理。

本系列文章將詳細介紹電商核心系統的產品設計方案，幫助你體系化的認識電商產品。

本文章為《電商產品經理從0到1》系列第二篇：電商·商品中心。

看完本文，你將對以下問題有所了解：

1. 商品中心的定義和職責是什么？
2. 商品中心有哪些核心模塊？
3. 商品中心如何設計？

同時也能體系化地掌握與商品相關的大部分功能模塊的設計思路。

前言

上一篇文章《一文讀懂電商產品架構》整體介紹了電商的基本業務、系統流程以及產品架構，通過三張大圖初步窺探了電商的基本面貌，了解了一個完整電商系統的核心組成，對電商有了概念層面的全局認知。

從本文開始，我們將繼續對每個核心系統的詳細設計思路和方案逐一展開說明。

根據電商各系統的職責順序，我們知道商品系統是最底層、最核心的系統，沒有商品，其他系統都無法運轉，因此，本文將首先帶來《商品中心》的詳細設計思路和方案。

（圖片過大無法正常顯示，請用電腦放大查看）

一、商品中心概述

1. 什么是商品系統？

顧名思義，商品系統是負責管理與商品有關的數據和能力的系統，可以用以下三句話概括：

1. 負責創建和管理商品的系統
2. 負責創建和管理分類、品牌、屬性以及其他所有與商品相關的數據的系統
3. 負責對前臺商品展示以及相關上下游系統提供商品能力的系統

在電商產品體系中，商品是其他所有相關系統的基礎，用技術的術語講，商品系統是其他系統的依賴：從商品采購到庫存管理，從商品自身的創建、上下架管理到商品定價以及前臺展示，從促銷活動到下單支付，從訂單生產到履約配送，電商中的每個流程都與商品相關。

而在這些所有上下游系統之間，商品數據必須是統一的、通用的、標準化的，比如采購系統中的商品A和訂單系統中的商品A需要是同一個A，所以商品系統在很大程度上必須具備中心化服務的能力，因此商品系統也是所有系統中最優先需要設計成中心化服務的系統。

這也是為什么本文的標題是從0到1搭建電商商品中心。

2. 商品中心有什么？商品中心能做什么？

通過一張圖就能看明白：

上圖中間的部分就是商品中心，商品中心的核心模塊可以抽象成4個，分別是：

1. 商品分類：用于創建分類、管理分類，為商品以及其他系統提供分類能力
2. 商品品牌：用于創建品牌、管理品牌，為商品以及其他系統提供品牌能力
3. 商品屬性：用于創建屬性、管理屬性，為商品以及其他系統提供屬性能力
4. 商品：用于創建商品、管理商品，為其他系統提供商品能力

分類管理、品牌管理、屬性管理與商品管理在系統架構上相互獨立存在，單向依賴，是獨立的系統模塊，每個模塊獨立負責各自的職能，既能單獨對外提供服務，又能打包對外提供服務，各個模塊之間又通過特定的對象相互關聯。

分類、品牌和屬性作為商品的基礎組成部分，三者共同組成了商品。

商品中心最基本的職能是向上支撐前臺各個環節的商品查詢、展示功能，同時向下為價格中心、營銷中心、訂單中心、履約中心、采購系統、庫存中心、倉儲以及運輸等下游系統提供商品能力和服務，保證電商體系下所有系統對于商品數據的輸入和輸出的統一。

下面，我們就商品中心的4個核心模塊的通用設計方案分別展開介紹。

二、分類管理

1. 為什么要有分類管理？

（截圖為京東APP分類頁）

電商平臺其實可以看成是實體超市在虛擬網站上的映射，在超市的購物場景中，為了讓消費者快速找到想要購買的商品，超市往往會將商品進行分門別類。

不同的區域放置不同的品類，每個區域用導購牌標識出來，不同的貨架陳列不同的商品，這就是超市的分類，分類可以幫助消費者更方便快捷地找到想要的商品。

而在電商的sku量級是實體商超的千倍萬倍，在電商網站查詢目標商品會變得更加的困難，因此超市的分類功能就很自然的應用到電商平臺中。

對于用戶端：搜索和分類導航是消費者尋找商品時使用的最多的兩個途徑（隨著推薦技術應用程度的加深，搜索和分類的權重有一定程度的下降），分類導航可以幫助用戶快速定位到目標商品，分類導航功能的實現依賴的就是商品的分類管理；

對于運營端：海量的商品管理對于平臺和商家而言也有很大的成本，運營要快速定位到某一個商品除了搜索關鍵詞外，分類管理也是重要的手段，分類可以提高管理商品的效率；

2. 分類管理的底層設計思想（重點）

分類管理的核心設計思想是：前后臺分離，多對多映射。

（1）前后臺分離

指前臺分類和后臺分類設計成兩套分類體系，后臺分類主要面向平臺管理，其主要邏輯是結構化的管理邏輯（iPhone13∈手機分類，衛褲∈服裝分類）；前臺分類主要面向用戶端使用，為運營提供運營空間，為用戶購物提供便捷，其主要邏輯是運營和用戶體驗（如衛褲在前臺的分類可以是”冬季新品“，主要考慮的是運營效果以及用戶是否更好的找到商品）。

（2）多對多映射

前臺分類必須以后臺分類作為分類基礎，在創建前臺分類時，必須要先選擇后臺分類；前臺分類和后臺分類之間是多對多的映射關系，即一個前臺分類可選多個后臺分類，不同前臺分類可選同一個后臺分類。

3. 后臺分類設計方案

產品經理口中常說的“分類管理”、“分類設計”、“分類功能”，一般指后臺分類管理功能，它是企業內部的管理功能，后臺分類是真實的商品分類。

一般情況下，平臺建設初期就已經確定了商品分類模型了，后期只是根據業務的發展（拓展品類）進行升級優化，后臺分類創建后，一般不能輕易修改或者刪除。

從界面的角度講，后臺分類管理主要包含兩部分可視化功能：分類創建和分類管理

（1）分類創建

創建一個新的分類，需填寫兩個主要字段：分類級別和分類名稱，后臺分類的分類名稱一般填寫實物商品的行業類別（如手機），便于維護管理，分類的名稱必須唯一。

分類級別一般設計為3級樹狀結構，一二三級分類層層遞進（級別過多則復雜，過少則達不到分類的目的，具體設計需根據平臺的品類復雜程度等因素綜合考慮）。

當創建一個新分類的級別為二級分類或者三級分類時，則需要選擇父級分類。

分類編碼和分類ID都可以設計成根據一定的規則自生成（如分類名稱拼音+時間戳拼成分類編碼），分類編碼和分類ID必須唯一，分類被其他系統中調用傳參時，可以通過分類編碼或者分類ID來實現。

（2）分類管理

分類管理主要提供分類自身的查詢、排序、修改等功能，同時可設計綁定/解綁分類對應的屬性或品牌的功能（創建屬性或品牌時也具備綁定分類的功能）。

對于分類的刪除或修改，前文提過一般不建議修改（包括修改級別，修改所屬父級分類），修改時需要校驗分類下是否有關聯數據，無關聯數據時可在一定程度上進行修改；而刪除功能則需要更加謹慎設計，一般情況下，分類下只要有關聯數據（如有關聯商品、關聯前臺分類等）則不能刪除，需要分類下沒有任何關聯數據時，才可以操作刪除（建議前期不設計刪除功能，或者設計成需要高級權限才可執行刪除操作）。

4. 前臺分類設計方案

（京東PC端商品分類截圖）

前臺分類在職責邊界劃分上，屬于“網站/APP運營配置”的功能范疇，不是真正意義上的分類功能，在維護前臺分類時，需要掛在一個或多個后臺分類上，用戶在前端點選分類查找商品時，系統通過【前臺分類——后臺分類——商品】的三級映射關系查詢前臺分類下應該展示哪些商品。

（分類管理界面示例）

前后臺分類多對多映射的設計邏輯主要考慮的運營需求和用戶對于商品的認知差異，由于分類導航的流量非常大，運營往往會配置一些運營分類，如推薦分類、常用分類等，對于推薦/常用這樣的分類本質上和商品屬性沒有直接關系，出于運營選，前臺分類可以關聯多個不同的后臺分類（如很多電商網站中，后臺分類中的手機分類和手機配件分類在前臺對應的分類都是手機）。

三、品牌管理

1. 為什么要有品牌管理？

在大型電商平臺中的系統架構中，品牌管理與分類管理一樣，是一塊獨立的、完整的功能。很多人剛接觸商品系統時，可能見過創建商品時直接簡單地填寫一下商品的品牌的設計方式，那為什么大型平臺要有單獨的品牌管理呢？

在大型電商平臺中，品牌也是用戶查詢篩選商品的重要手段，標準化程度越高的品類，通過品牌篩選查詢商品的使用場景越大（如京東平臺購買手機或者家電時，消費者往往會先選定品牌）。

而品牌數據如果不是結構化的，任由運營或者商家創建商品隨意填寫，則可能會出現同一個品牌的商品被不同業務或者不同的商家填寫成不同的品牌，如商家A把小米填寫成字母“xiaomi”，商家B把小米填寫成中文“小米”，商家C甚至填寫成“showmi”等各種錯誤數據，當底層數據無法統一時，則前臺篩選或者其他系統需要使用品牌數據時，就無法正常使用了。

2. 品牌管理如何設計？

品牌管理主要包含兩部分功能，即品牌的創建和品牌的管理。

（1）品牌創建

品牌的創建場景主要有兩種：一種是平臺側主動創建，初期一般是按照各個品類直接初始化到系統中去；另一種平臺型電商比較常見的申請方式，即由入駐到平臺的三方商家申請品牌（如阿里京東平臺中，如果新入駐的商家是自有新品牌或者未被平臺收錄，則都需要先走品牌申請流程，如早期的淘品牌韓都衣舍等），平臺審核通過后落入品牌庫。

品牌創建一般有幾個核心關鍵要素：

1. 品牌中文名
2. 品牌英文名：建議格式要求大寫
3. 品牌別名：品牌有官方名稱和民間名稱，有時候民間名稱比官方更知名4、品牌注冊人
4. 品牌注冊號
5. 品牌LOGO：一定要限制圖片尺寸和大小，便于系統展示規范
6. 品牌注冊地區
7. 其他字段根據平臺特性或行業資質要求自定

如果是三方申請的方式創建，需填寫的信息與平臺自主創建一致，只不過申請品牌流程填寫完畢后，會提交給品牌進行審核（審核流程設計本文不展開），一旦審核通過，第二個商家再經營同一個品牌的商品時，則直接從品牌庫中選擇即可。

（2）品牌管理

品牌管理就是品牌自身的查詢、修改、停用等功能，即基礎的增查改，需要注意的是品牌在修改或者停用時，也要校驗品牌下沒有關聯的數據（商品、分類等），否則不能操作修改或者停用（部分信息的修改如果不影響其他數據的展示，則可以修改）。

另外就是可設計品牌與商品分類的映射關系的功能，當發品時選擇了分類后，會自動檢索該分類下應該出現的品牌（也可不設計，不設計的邏輯就是當選擇分類后，選擇品牌時檢索的是全量品牌，兩種方案有利有弊）。

四、屬性管理

1. 屬性是什么？為什么要有屬性管理？

屬性是什么？——屬性指商品所特有的性質，如顏色屬性、尺碼屬性、規格屬性等。

屬性的作用？——屬性也是將商品進行分類和聚合的必要且重要的方法，類目和品牌只能在一定程度上將海量的商品進行分類，比如用戶在京東購買“家電”，可以通過類目（如：電視、空調、冰洗···）、品牌（如：格力、小米···）來查詢想要的產品（如：小米電視），但是當用戶想進一步快速定位到最準確的意向結果（如小米電視55寸4K版），類目和品牌就顯得不夠用了，因此如果想實現更細顆粒度的劃分，只能通過屬性的方式來實現。

一個商品所擁有的所有性質，都是這個商品的屬性，如：屏幕尺寸、分辨率、能效等級等。而不同類目下的商品，其擁有的屬性又不一樣（比如服裝沒有屏幕尺寸等屬性，手機沒有尺碼屬性），且隨著品類的豐富，屬性的數據也隨之變得非常龐大，為了更好地管理不同類型的商品的屬性，使其在前臺應用時可以有清晰簡單的邏輯，屬性管理的意義就顯得非常重要了。

2. 屬性管理的設計思想

屬性從結構上可拆分成3塊，分別是：屬性組>屬性>屬性值

1. 屬性組：將大量屬性分類，便于管理，如手機的“外觀屬性”、“性能屬性”等 ；
2. 屬性：即屬性名，指具體的屬性，如顏色、版本、運行內存；
3. 屬性值：指屬性的具體值，如顏色屬性的屬性值有：紅色、黃色、綠；

以上3個模塊就組成了屬性管理，有時候為了在業務層面溝通方便或者口徑統一，又或者其他的應用場景，還會引入屬性分類的設計，在屬性組之上將屬性在進行分類（相對抽象的分類），一般分為基礎屬性、銷售屬性、倉儲屬性、物流屬性、擴展屬性（關于屬性分類，沒有標準設計，結合自身的平臺特性劃分即可，也可不設計屬性分類）。

下面將屬性分類結合3個核心模塊，以手機品類舉例，通過一張表格解釋一下屬性的各個概念：

下圖是京東平臺-iPhone13的商品詳情頁截圖，在京東前臺，這些信息是結構化的字段（并非圖文），其數據就來自于創建商品時填寫的屬性：

3. 屬性管理的設計方案

1. 屬性組的核心功能：創建和管理（查詢、修改、綁定屬性）
2. 屬性的核心功能：創建和管理（查詢、修改、綁定屬性組、綁定分類）
3. 屬性值：依托于屬性功能

（1）屬性組的創建

（2）屬性組管理（列表）

（3）屬性組管理（詳情）

主要功能是支持綁定屬性和解綁屬性以及對屬性組的啟用/停用控制，對于停用操作，需要校驗屬性組下沒有任何關聯數據（屬性等）

（4）屬性以及屬性值的創建

屬性和屬性值的創建也有兩種場景：一種是平臺側主動創建，另一種平臺型電商比較常見的申請方式，即三方商家創建商品時，如果屬性庫中的屬性不夠用，則可以在創建商品的界面直接添加屬性。

平臺側創建屬性

重點說明一下關聯分類：屬性必須要關聯分類，當創建新商品時，第一步就是選擇分類，當后面選擇屬性時，系統就能根據所選分類查詢對應的屬性了（如手機類目下，不會展示服裝尺碼等屬性）三方發品時創建屬性/屬性值。

淘寶三方后臺添加屬性/屬性值功能

京東三方后臺添加屬性/屬性值功能

以上就是屬性管理相關功能模塊的設計介紹，屬性管理（綁定分類、綁定屬性組）的界面與屬性組類似。

屬性的刪除、解綁等操作與屬性組一樣，也需要校驗是否有關聯數據。

五、商品管理

商品管理模塊主要負責創建商品、管理商品，為其他系統提供商品能力，是商品中心最核心的模塊，同時商品管理也依賴分類、品牌、屬性三個模塊。

以創建商品為例，創建商品時需要填寫的字段中，最重要的就是選擇分類、品牌、屬性，可以說商品是建立在分類模塊、品牌模塊和屬性模塊之上的模塊。

1. 兩個概念——SPU&SKU

在具體說明商品模塊之前，有必要先說明兩個名詞“SPU和SKU”，不止電商平臺，大部分涉及交易的系統都可能涉及SPU和SKU相，相信大部分人都接觸過這兩個名稱。以下是百度百科對SPU和SKU的解釋：

SPU(Standard Product Unit)——標準化產品單元。是商品信息聚合的最小單位，是一組可復用、易檢索的標準化信息的集合，該集合描述了一個產品的特性。

通俗點講，屬性值、特性相同的商品就可以稱為一個SPUSKU(stock keeping unit)——SKU即庫存進出計量的單位，可以是以件、盒、托盤等為單位；SKU是一個可以售賣的商品。

通俗地講，SPU定位一個產品，SKU定位為商品。例如手機這個類目下，iPhone 13就是一個SPU，iPhone 13 256G 黑色就是一個SKU（京東的SKU還會加上公開版等屬性）一般情況下，基礎屬性可以看成是spu的屬性，如手機的屏幕尺寸、CPU型號、像素等基礎屬性；銷售屬性以及倉儲物流屬性存儲在sku上，如顏色、版本等銷售屬性。

2. 創建商品

創建商品功能從界面上看比較簡單，就是填寫一堆字段，然而根據平臺的大小、復雜程度、垂直專業程度等因素的不同，可以抽象成兩種設計方案：

方案1：同時創建多個sku，同步生成關聯spu，整體方案是直接創建sku，維護多個不同的屬性即意味著生產維護多個sku；該方案適用于大部分2C類綜合型電商平臺（如淘寶和京東POP創建商品就是這種方式）

方案2：先創建spu，基于spu創建sku，整體方案是由平臺的主數據團隊負責維護spu，由商家（包括自營和POP）運營（或采銷）基于spu維護sku，創建sku時，先選擇spu（spu中的基礎屬性已經由數據團隊維護完畢），在spu基礎上維護銷售屬性、物流屬性等，然后生成sku；該方案適用于專業性非常強的垂直B2B行業，如汽車、醫藥等。

產生兩種方向的原因是：垂直B2B平臺的商家（行業傳統，商家老板年紀較大）運營能力有限，維護商品屬性的錯誤率遠高于2C平臺的商家，而平臺對于商品結構化的管控要求較高，為了避免同一個商品被不同的商家維護成多個不同的屬性（如汽車輪胎的胎面寬、尺寸等屬性），平臺往往選擇由專門的數據團隊維護商品的基礎屬性，即維護spu。

且B2B垂直電商的品類少、sku量級相對較小，品類標準化程度高，由平臺統一維護的可行性高。

而綜合電商成千上萬個品類，靠平臺的數據團隊統一維護不太現實，或者像服裝這樣的非標品類，對于商品的結構化管理訴求低，因此綜合平臺（京東、淘寶）與垂直平臺的設計方向就出現了差異。

實際情況下，即使是綜合平臺（如京東），不同的品類也會出現不同的設計方法，有的品類垂直縱深，也是采用的平臺維護spu，商家創建sku的方式。

（1）創建sku設計方案，以方向1說明

這種方法比較常見，見過淘寶、京東等主流電商后臺的同學應該有一定的印象，邏輯就是直接創建sku，生成sku的同時，生成相應的spu，如下圖的淘寶商家后臺：

（淘寶三方后臺創建商品-填寫銷售信息截圖）

從圖中可以看出，基礎屬性相同的多個sku對應同一個spu，顏色屬性+飛行種類屬性確定一個sku，價格和庫存存儲在sku上（即使批量填充一樣的價格和庫存，在數據底層也是按照sku的維度存儲；而在前臺則以spu的維度展示（體驗更好），切換銷售屬性即是在同一個spu維度下，切換不同的sku：

以上為天貓PC端-iPhone13的商品詳情頁，可以看出，iPhone13+黑色+128G和iPhone13+粉色+128G是兩個獨立的SKU（skuid不同），兩個sku對應的SPU是同一個（spuid相同）

以上就是方案1的核心設計邏輯：即創建商品的時候，維護不同的銷售屬性就是維護了多個不同的sku，但最終同步生成了同一個spu。

了解了設計邏輯以后，對于功能設計就非常簡單了，不論是自營后臺還是三方pop后臺，創建商品的界面大同小異，可按照流程大約分為7個步驟：

第一步：選擇類目（商品分類），注意選擇類目時，調用的是后臺分類（這里就用上了分類管理的服務了）：

（圖：淘寶商家后臺-創建新商品-選擇分類）

當選擇分類后，系統自動加載該分類下對應的品牌數據（有的類目則是在填寫商品信息時選擇品牌）。

后面的步驟比較簡單，只是填寫對應的字段內容即可，就不過多展開了，直接附上一張后臺截圖供參考：

（圖為淘寶商家后臺發布商品的截圖）

以上就是創建商品的設計方案，方案2與方案1的區別是：創建sku時，需要基于spu創建sku，即spu由內部數據運維團隊負責創建、維護，運營以及三方商家創建sku時需要先選擇spu（如果沒有則需要提交申請），具體界面與方案1區別不大，本文也不做展開。

3. 商品管理其他模塊

商品創建完成后，還需要經過審核才可上架展示到前臺，而這其中又涉及商品的狀態機的設計，但是也比較簡單，本文也不做展開說明。

最后就是關于價格的說明：不知道是否有人會有疑問，商品中心全篇沒有提及價格，很多人的認知里，商品和價格是一體的，創建商品的時候就必須要填寫價格，其實這是一個誤區。

在業務初期只有零售價的時候，還可以直接填寫零售價、劃線價等簡單的價格，隨著業務的發展，業務形態越來越復雜，創建商品的時候直接填寫價格的方式很快就無法滿足業務的需求了。

比如京東后面發展出企業購業務，又發展出各類用戶價格（plus價、學生價、新人價、），同時加上促銷價，此時商品系統已經無法支撐各類形式的價格需求了，所以在系統架構上，商品和價格是完全獨立的、分離的兩個系統。

六、總結

最后回答一下文章最開始的幾個問題：

1. 商品中心的職責是什么？

1. 負責創建和管理商品
2. 負責創建和管理分類、品牌、屬性以及其他所有與商品相關的數據
3. 負責對前臺商品展示以及相關上下游系統提供商品能力

2. 商品中心有哪些核心模塊？—— 四個核心模塊

1. 商品分類：用于創建分類、管理分類，為商品以及其他系統提供分類能力
2. 商品品牌：用于創建品牌、管理品牌，為商品以及其他系統提供品牌能力
3. 商品屬性：用于創建屬性、管理屬性，為商品以及其他系統提供屬性能力
4. 商品：用于創建商品、管理商品，為其他系統提供商品能力

3. 商品中心各模塊如何設計？—— 一張圖看懂各模塊核心重點

商品中心作為其他上下游系統的依賴，是與其他系統交互最多的系統之一，因此對于商品中心而言，合理的架構設計、良好的拓展性是重中之重，前期打好基礎，避免后期隨著業務的發展反復重構系統。

以上就是商品中心的全部內容，主要介紹了商品中心各個模塊的概念和職責，以及各個模塊的核心設計思路，建議大家研讀文章的同時，也可以體驗一下不同的平臺，結合文章多分析多總結，然后得出自己的全面的理解。

作者：道格森咸魚王；公眾號：道格森咸魚王

本文由 @道格森咸魚王 原創發布于人人都是產品經理，未經許可，禁止轉載。

題圖來自Unsplash，基于CC0協議。