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

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

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

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

1、商品中心的定義和職責是什麼？

2、商品中心有哪些核心模塊？

3、商品中心如何設計？

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

全文8000 字，閱讀時間大約需要40分鐘，建議收藏和使用電腦閱讀。

前言

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

從本文開始，我們将繼續對每個核心系統的詳細設計思路和方案逐一展開說明。根據電商各系統的職責順序，我們知道商品系統是最底層、最核心的系統，沒有商品，其他系統都無法運轉，因此，本文将首先帶來《商品中心》的詳細設計思路和方案。

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

01

01 商品中心概述

1、什麼是商品系統？

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

1、負責創建和管理商品的系統

2、負責創建和管理分類、品牌、屬性以及其他所有與商品相關的數據的系統

3、負責對前台商品展示以及相關上下遊系統提供商品能力的系統

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

而在這些所有上下遊系統之間，商品數據必須是統一的、通用的、标準化的，比如采購系統中的商品A和訂單系統中的商品A需要是同一個A，所以商品系統在很大程度上必須具備中心化服務的能力，因此商品系統也是所有系統中最優先需要設計成中心化服務的系統。這也是為什麼本文的标題是從0到1搭建電商商品中心。

2、商品中心有什麼？商品中心能做什麼？

通過一張圖就能看明白：

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

1、商品分類：用于創建分類、管理分類，為商品以及其他系統提供分類能力

2、商品品牌：用于創建品牌、管理品牌，為商品以及其他系統提供品牌能力

3、商品屬性：用于創建屬性、管理屬性，為商品以及其他系統提供屬性能力

4、商品：用于創建商品、管理商品，為其他系統提供商品能力

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

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

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

02

02 分類管理

1、為什麼要有分類管理？

（截圖為京東APP分類頁）

電商平台其實可以看成是實體超市在虛拟網站上的映射，在超市的購物場景中，為了讓消費者快速找到想要購買的商品，超市往往會将商品進行分門别類，不同的區域放置不同的品類，每個區域用導購牌标識出來，不同的貨架陳列不同的商品，這就是超市的分類，分類可以幫助消費者更方便快捷地找到想要的商品。 而在電商的sku量級是實體商超的千倍萬倍，在電商網站查詢目标商品會變得更加的困難，因此超市的分類功能就很自然的應用到電商平台中。

對于用戶端：

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

對于運營端：

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

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

分類管理的核心設計思想是：前後台分離，多對多映射；

前後台分離：

指前台分類和後台分類設計成兩套分類體系，後台分類主要面向平台管理，其主要邏輯是結構化的管理邏輯（iPhone13∈手機分類，衛褲∈服裝分類）；

前台分類主要面向用戶端使用，為運營提供運營空間，為用戶購物提供便捷，其主要邏輯是運營和用戶體驗（如衛褲在前台的分類可以是”冬季新品“，主要考慮的是運營效果以及用戶是否更好的找到商品）；

多對多映射：

前台分類必須以後台分類作為分類基礎，在創建前台分類時，必須要先選擇後台分類；

前台分類和後台分類之間是多對多的映射關系，即一個前台分類可選多個後台分類，不同前台分類可選同一個後台分類；

3、後台分類設計方案

産品經理口中常說的“分類管理”、“分類設計”、“分類功能”，一般指後台分類管理功能，它是企業内部的管理功能，後台分類是真實的商品分類。

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

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

3.1、分類創建

創建一個新的分類，需填寫兩個主要字段：分類級别和分類名稱，後台分類的分類名稱一般填寫實物商品的行業類别（如手機），便于維護管理，分類的名稱必須唯一。分類級别一般設計為3級樹狀結構，一二三級分類層層遞進（級别過多則複雜，過少則達不到分類的目的，具體設計需根據平台的品類複雜程度等因素綜合考慮）；

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

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

3.2、分類管理

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

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

4、前台分類設計方案

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

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

（分類管理界面示例）

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

03

03 品牌管理

1、為什麼要有品牌管理？

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

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

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

2、品牌管理如何設計？

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

2.1、品牌創建

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

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

1、品牌中文名

2、品牌英文名：建議格式要求大寫

3、品牌别名：品牌有官方名稱和民間名稱，有時候民間名稱比官方更知名

4、品牌注冊人

5、品牌注冊号

6、品牌LOGO：一定要限制圖片尺寸和大小，便于系統展示規範

7、品牌注冊地區

8、其他字段根據平台特性或行業資質要求自定

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

2.2、品牌管理

品牌管理就是品牌自身的查詢、修改、停用等功能，即基礎的增查改，需要注意的是品牌在修改或者停用時，也要校驗品牌下沒有關聯的數據（商品、分類等），否則不能操作修改或者停用（部分信息的修改如果不影響其他數據的展示，則可以修改）。另外就是可設計品牌與商品分類的映射關系的功能，當發品時選擇了分類後，會自動檢索該分類下應該出現的品牌（也可不設計，不設計的邏輯就是當選擇分類後，選擇品牌時檢索的是全量品牌，兩種方案有利有弊）。

04

04 屬性管理

1、屬性是什麼？為什麼要有屬性管理？

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

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

而不同類目下的商品，其擁有的屬性又不一樣（比如服裝沒有屏幕尺寸等屬性，手機沒有尺碼屬性），且随着品類的豐富，屬性的數據也随之變得非常龐大，為了更好地管理不同類型的商品的屬性，使其在前台應用時可以有清晰簡單的邏輯，屬性管理的意義就顯得非常重要了。

2、屬性管理的設計思想

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

1、屬性組：将大量屬性分類，便于管理，如手機的“外觀屬性”、“性能屬性”等 ；

2、屬性：即屬性名，指具體的屬性，如顔色、版本、運行内存 ；

3、屬性值：指屬性的具體值，如顔色屬性的屬性值有：紅色、黃色、綠；

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

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

屬性分類	屬性組	屬性	屬性值
基礎屬性	屏幕屬性	屏幕分辨率	1080P、2K
		屏幕尺寸	6.95英寸、5英寸
		屏幕材料	LCD、AMOLED
	功能屬性	攝像頭像素	800萬、1億
		指紋類型	屏下指紋、屏後指紋
		刷新率	90HZ、120HZ
銷售屬性	外觀屬性	顔色	白色、黑色
	性能屬性	運行内存	4G、8G
		機身内存	128G、256G
倉儲屬性	倉儲屬性	體積	手動填寫
		重量	手動填寫
物流屬性	物流屬性	配送方式	冷鍊配送、普通配送
擴展屬性

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

3、屬性管理的設計方案

1、屬性組的核心功能：創建和管理（查詢、修改、綁定屬性）

2、屬性的核心功能：創建和管理（查詢、修改、綁定屬性組、綁定分類）

3、屬性值：依托于屬性功能

3.1、屬性組的創建：

3.2、屬性組管理（列表）：

3.3、屬性組管理（詳情）：

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

3.3、屬性以及屬性值的創建

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

平台側創建屬性

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

三方發品時創建屬性/屬性值

淘寶三方後台添加屬性/屬性值功能

京東三方後台添加屬性/屬性值功能

以上就是屬性管理相關功能模塊的設計介紹，屬性管理（綁定分類、綁定屬性組）的界面與屬性組類似。屬性的删除、解綁等操作與屬性組一樣，也需要校驗是否有關聯數據。

05 商品管理

商品管理模塊主要負責創建商品、管理商品，為其他系統提供商品能力，是商品中心最核心的模塊，同時商品管理也依賴分類、品牌、屬性三個模塊，以創建商品為例，創建商品時需要填寫的字段中，最重要的就是選擇分類、品牌、屬性，可以說商品是建立在分類模塊、品牌模塊和屬性模塊之上的模塊。

1、兩個概念——spu&SKU

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

以下是百度百科對SPU和SKU的解釋：

SPU(Standard Product Unit)——标準化産品單元。是商品信息聚合的最小單位，是一組可複用、易檢索的标準化信息的集合，該集合描述了一個産品的特性。通俗點講，屬性值、特性相同的商品就可以稱為一個SPU

SKU(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的方式。

2.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價、學生價、新人價、），同時加上促銷價，此時商品系統已經無法支撐各類形式的價格需求了，所以在系統架構上，商品和價格是完全獨立的、分離的兩個系統。

06

06 總結

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

1、商品中心的職責是什麼？

1、負責創建和管理商品

2、負責創建和管理分類、品牌、屬性以及其他所有與商品相關的數據

3、負責對前台商品展示以及相關上下遊系統提供商品能力

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

1、商品分類：用于創建分類、管理分類，為商品以及其他系統提供分類能力

2、商品品牌：用于創建品牌、管理品牌，為商品以及其他系統提供品牌能力

3、商品屬性：用于創建屬性、管理屬性，為商品以及其他系統提供屬性能力

4、商品：用于創建商品、管理商品，為其他系統提供商品能力

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

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

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

本文由公衆号@電商産品經理從0到1原創發布于PMCAFF，轉載請聯系作者獲得許可，并注明來源。

歡迎關注公衆号：

,

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!

查看全部