本文詳細介紹了商家后臺商品字段的設計思路，希望能對你有幫助。

一、背景&前言

1. 拍賣業務模式概述

為了方便理解，大家可以聯想一下線下的拍賣場，在一個一個“位置”展出商品，由用戶出價來贏得商品。

整個拍賣過程中，全部商品1元起拍，參與競價是免費的，如果贏了就去付款。針對一個商品，每次有用戶出價，將拍賣時間延長10秒，直到確定最后的贏家。

目前該業務只在美國開放。

2. 商品常用專業名詞解釋

在開始講具體功能模塊之前，這里先普及一些商品常用名詞，以便大家統一概念，后續閱讀更順暢。

SPU：Standard Product Unit，標準化產品單元。通俗點講，屬性值、特性相同的商品就可以稱為一個SPU。如優衣庫上新了一款裙子A，那么這個裙子A就是一個SPU，與這款裙子的顏色、尺碼都沒有關系。

SKU：Stock Keeping Unit，庫存量單位。通俗點講，是對每一個產品和服務的唯一標示符。還用上面的例子，如優衣庫的裙子A，有紅色的M碼、藍色的M碼、白色的M碼三種顏色+尺碼組合，那么這三種各自是一個SKU?？梢院唵卫斫鉃橛胁煌膸齑媪?，所以是獨立的SKU。

3. 關于每個字段信息的限制

這里只是提供思考方向和示例。

好，鋪墊完了，接下來開始核心內容。本文從實際場景出發，分析商家管理商品信息的設計思路。

二、商家后臺商品信息結構

商家后臺商品信息結構圖：

1. 基礎信息

商品基礎信息是不考慮額外附加意義的、商品客觀本質的信息，如標題、圖片、品牌等。如果商家后臺沒有商品基礎信息，那么商家維護商品將變得十分困難，因為僅憑其他信息很難對應商品是哪一個。后期商家不管是更新商品信息還是發貨，有基礎信息的展示都能大大提升商家的工作效率。

另外商品基礎信息通常會直接決定用戶對商品的“第一印象”，基礎信息越簡潔、清晰、明了，商品越容易吸引用戶的注意。

所以基礎信息是所有信息中最重要的部分，這部分的信息幾乎都需要必填。

1.1 標題

標題通常是用文字來描述一個商品是什么。

由于是做海外電商，我們會要求標題只支持使用字母、數字、空格、-和_。再加上我們希望標題幫助商品被搜索引擎收錄，所以根據主流搜索引擎的建議，把商品標題的長度定在不超過80字符；同時字符限制也可以使商家填寫的標題更加精準、不冗余。標題需要商家必填。

1.2 描述

商品描述用于對商品的補充說明。另外商家對自己的商品肯定有“王婆賣瓜”的話要說，都可以寫在這里。

通常情況下商品描述都會有大段文字內容，這就導致我們一方面要考慮商家編輯的描述是否合規，另一方面也要考慮用戶看商品描述的可讀性。所以我們不允許描述中帶有鏈接，長度要在50~1000字符，支持換行和使用無序列表（如下圖示例）。描述需要商家必填。

1.3 品牌

品牌能夠提升用戶對商品的信任度，也是商家凸顯自己商品的一個亮點。

我們支持商家從常用品牌中選擇，也支持自定義品牌，自定義品牌長度不能超過20字符。品牌非必填，沒有品牌、小品牌的商品也可以不填品牌信息。當然，對品牌要求高的平臺也可以不支持自定義且要求品牌必填。

1.4 圖片

圖片能讓人更直觀的感受到商品的情況，如功能、材質、款式等。

圖片分為封面圖和詳情圖。封面圖即在商品列表展示的商品主圖，其作用是展示商品功能、吸引用戶注意；詳情圖則是需要到商品頁才能看到的更多圖片，其作用是展示商品更多功能、細節。

商家可以上傳1張封面圖和9張詳情圖，封面圖是必填的。為了展示效果，我們要求所有圖片比例為1:1，大小不超過3M。

2. 價格信息

價格信息包含最低成交價、運費、劃線價。價格本質是商品的一個運營屬性，因為價格并不是一成不變的。

拍賣業務中的價格和傳統電商稍有不同：

1. 平臺會有默認的起拍價，商品的最終成交價格是由用戶決定而不是商家決定的；
2. 拍賣業務沒有直接銷售商品的價格。

2.1 最低成交價

最低成交價即商家定義的商品最小的售出價格。

在拍賣業務中商品的最終價格由買家決定，為了保護商家的權益， 需要允許商家去決定起拍價或者最低成交價。又因為我們業務需要把全部$1起拍作為宣傳點、賣點，所以商家端的設計中，就得讓商家定最低成交價。

最低成交價不顯示給用戶，范圍$0-$999，必須是整數，可以選填。如果商家不填，則默認為0。 適合拍賣的商品大多是新奇特小商品或者長尾商品，所以價格上限定為$999。必須是整數則是因為業務中用戶出價都是出整數。

2.2 運費

運費是指商品的運輸費用。商家如果需要單獨收取運輸費用，將金額填寫到運費這一字段即可。

運費可以選填，范圍$0-$60，必須使用整數，商家不填默認為0。運費上限范圍是根據國際物流的情況定的。而必須使用整數是因為在拍賣業務中，運費會展示在比較明顯的位置，如果使用多位小數會顯得業務不夠大氣，對用戶的參與度有影響。

2.3 劃線價格

劃線價格即顯示給用戶的劃掉的價格。通常商家可以把商品的原零售價填在資格字段。劃線價格給用戶一種這個商品現在在打折的感受，可以促進用戶下單。

這個字段可以選填，支持2位小數，不填默認為空。商家填寫的劃線價格需要大于等于最低成交價，小于最低成交價的100倍。因為用戶會用當前出手的價格和劃線價格比較，太離譜的劃線價格會降低用戶信任度，失去對這件商品的熱情。

3. 商品運送信息

商品運送信息是影響商品送達時間的所有信息。商品運送信息是電商平臺都需要關注的重點信息，因為用戶會特別關心什么時候能收到商品。

通常情況下商品送達時間會受到發貨地，商品體積、重量，所用快遞（比如郵政慢，順豐快），目的地等的影響。

我們拍賣業務只在美國開放，所以目的地對商品送達時間的影響會相對比較統一，不是關鍵因素。

初期為了快速上線，加上綜合其他幾個影響因素，決定在功能上省去“物流管理”這個大模塊，選擇使用貨源所在國家和預計物流天數作為商品運送信息最關鍵的兩個指標。

貨源所在國家，即發貨地，對海外電商而言發貨地主要是看貨源所在國家。預計物流天數，即商家自己根據經驗來判斷商品體積、重量以及自己使用的快遞公司來預估物流天數。

商家想讓自己的商品從其他商品中脫穎而出，商品快速送達不失為一個大賣點。

3.1 貨源所在國家

貨源所在國家即商品所在的國家、商品從哪個國家發貨。

我們提供給商家國家列表，商家選擇一個即可。因為其重要性，所以要求商家必填。

3.2 預計物流天數

預計物流天數即商品大約多少天能運送到用戶手里。也是商家的一個服務承諾。

物流時間很難100%準確預估，所以這個字段是一個天數的區間，只能填寫整數，后面的數必須大于前面的數。

4. 屬性

屬性是從相似的商品中找出不同點后歸納出來的信息。為什么要對商品進行歸納呢？試想一下，假如某一款裙子有紅、橙、黃、綠、青、藍、紫七個顏色，又各自有XS、S、M、L四個尺碼，除此之外這款裙子的其他信息都是一模一樣的。

在商家后臺紅色XS碼要創建一個商品，紅色S碼要創建一個商品，紅色M碼又要創建一個商品……你是商家的話，你不累嗎？所以我們的后臺既要將相似的商品統一管理，又要能區分出商品的不同，這就需要SPU來做統一管理、屬性來區分出商品的不同。

平時我們在傳統電商平臺遇到過有商品屬性的商品，如手機的顏色和內存、鞋子的顏色和尺碼、凳子的顏色和高矮等；也有無商品屬性的商品，如一副銀耳釘，一罐100g的菊花茶，一個吹風機等。因此我們把屬性歸類為顏色和尺寸，內存、尺碼、高矮等都可以歸類到尺寸中；無屬性的商品并不是真的無屬性，它是只有一個顏色、一個尺寸的商品。

顏色和尺寸的排列組合即為SKU，因為這個依賴關系，這里把SKU編號歸類到屬性下。（如果以字段設計目的來說，也可以將其歸類到管理類信息中。）

屬性還達到“商家一次曝光，用戶多種選擇”的目的，增加出單的概率。商家想要提高成單率，歸納、完善商品屬性可以作為一個方法。

注：傳統電商的商品價格往往是每個SKU都可以有不同的價格，但是由于拍賣業務的特殊性，一個拍賣位置不可能同時展示兩種價格，這就要求每一個SPU下的SKU必須是統一的價格。所以這個業務里，價格字段是在SPU上的。如果有不同的價格還是需要商家把該SKU當做成一個獨立的SPU。這一點和傳統電商平臺稍有不同。

4.1 Color, Size

為了防止不同商家對顏色和尺寸描述的差異會導致系統需要記錄過多的“垃圾”顏色和尺寸，我們直接提供盡可能豐富的顏色和尺寸供商家選擇，如果商家需要自定義新增也只能從已有的顏色和尺寸中組合。屬性為選填字段，因為有些商品只有一種屬性，就沒必要精細化管理了。

4.2 SKU編號

SKU編號是識別商品最小規格的唯一編號?？梢詭椭碳腋鷤}庫核對商品等。

根據常見的SKU編號，我們要求SKU編號只能使用字母、數字、@、-和_，不超過20字符，必填。同一個商家使用SKU編號不允許重復，以確保其唯一性。如果商品沒有屬性，我們可以默認有一個隱藏的SKU編號=SPU編號去處理，在用戶端起到“屬性如圖所示”的一個作用，開發處理起來邏輯也不會太復雜。

5. 庫存

商品庫存是指商品現有的數量。

商品總庫存（SPU庫存）影響整個商品的售賣狀態。商品上架且其他信息正常時，總庫存>0則可以售賣，總庫存=0則顯示為售罄。
商品某一屬性的庫存（SKU庫存）影響某一屬性是否能售賣。商品上架且其他信息正常時，某一SKU庫存≥0，則該屬性可以售賣；SKU庫存=0時，對用戶隱藏該屬性或者顯示該屬性待補貨。

5.1 SKU庫存

庫存管理需要精細化到SKU庫存，比如紅色的M碼的裙子還剩10件。SKU庫存需要是≥0的整數。

5.2 SPU庫存

SPU庫存是一個商品的總庫存。SPU庫存需要必填。一般情況下SPU庫存可以通過計算SKU庫存之和所得；商品沒有SKU的情況下也需要直接管理SPU庫存，SPU庫存需要是≥0的整數。

6. 管理類信息

管理類信息是商家或平臺管理商品所必須的信息。這類信息用戶一般看不到，或者不關注，比如SPU編號，商品品類。但這并不代表這類字段就不重要，相反這類信息非常重要，它們主要為商家或平臺管理商品提供便利。

6.1 SPU編號

SPU編號是識別商品的唯一編號?？梢詭椭碳腋鷤}庫核對商品等。

根據常見的SPU編號，我們要求SPU編號只能使用字母、數字、@、-和_，不超過20字符，必填。同一個商家使用SPU編號不允許重復，以確保其唯一性。

6.2 品類

品類是將商品的某些特性統一歸納后的產物，如所有使用電的商品都可以劃分到電子品類。

根據拍賣業務不需要用戶去做搜索的特性，這里只劃分一級品類，由商家選擇使用即可。品類可以幫助平臺和商家統計商品分布情況、分析用戶喜好等，所以品類需要必填。

三、寫在最后

很多功能和信息久而久之就成了大家眼中的“標配”，你認真想過它們信息究竟有什么業務意義嗎？它真的適用于你的業務場景嗎？商品信息看似簡單，但是每一個字段背后的邏輯都值得反復推敲。

千萬不要小看任何一個基礎模塊，對產品設計要抱有同理心、敬畏心。

作者：粒粒醬；公眾號：粒粒醬的筆記本，剛開始記錄自己工作中產品、運營、開發的那些事兒。歡迎來勾搭~

本文由 @粒粒醬 原創發布于人人都是產品經理，未經作者許可，禁止轉載。

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