這篇文章先普及一些商品常用名詞,後面講一下作者在商品設計中踩過的坑,歡迎大家一起討論。
商品作為電商系統中的最小組織單元,像磚瓦一樣撐起了整個電商系統。 商品也是連接前端用戶、(中端平台)、後端商家、末端倉庫的關鍵橋樑。 所以,商品的設計直接影響了整個商城的效率與
這篇文章先普及一些商品常用名詞,後面講一下我在商品設計中踩過的坑,歡迎大家一起討論。
一、商品相關常用名詞
PU(Standard Product Unit,標準化產品單元),是商品信息聚合的最小單位,是一組可複用、易檢索的標準化信息的集合,該集合描述了一個產品的特性。 通俗點講,屬性值、特性相同的商品就可以稱為一個SPU。
如:
SKU(Stock Keeping Unit,庫存量單位),即庫存進出計量的單位,可以是以件,盒,托盤等為單位。 是能夠識別唯一單品的最小單元,通常是各項屬性的選擇後組成的唯一結果。
如:
- UPC(Universal Poduct Code,商品通用條碼),UPC可作為商品的唯一識別碼,一個SKU會對應一個UPC編碼。 UPC通常用做倉庫撿貨的唯一標識。
- 類目/分類:商品的分類、類別。 每個平台根據平台特點不同,會有獨特的分類標準。 通常一個商品僅隸屬一個類目。 如:iPhoneX這件商品,分類可以是:手機數碼-蘋果-iPhone X,也可以是手機-智能手機-iPhone X。
- 屬性&屬性值:一件商品所包含的特點,屬性&屬性值根據平台特點不同,維度及描述也不盡相同。
如:iPhone X這件商品,內存大小便是一個屬性,64G、128G、256G便是一個屬性值。
一般來說,一件商品會有多種屬性,對應到多個屬性值。 每個平台不同,所分的屬性及對標屬性值也有所差異。
每件商品從工廠生產到銷售給電商消費者,一般會經過:產品設計→工廠生產→交付商城→用戶購買等過程,根據這個流程,如果只展示SKU、UPC、分類等信息,是不是會 把你看懵? 是的,除了這些基礎信息外,還需要更多的描述性信息,這部分比較簡單好理解,直接上圖:
大家對哪塊有興趣可以在文章後留言,我們逐一探討。
二、商品管理的後台設計
後台設計大同小異,無非增刪改查幾個基本功能,有興趣的話可以作部分探討。 但是在電商系統設計裡,需要更加註意幾(cai)個(guo)問(de)題(keng):
1.數據唯一性(需要根據平台或店鋪特點定制):
包括但不僅限於:貨號及UPC的全平台唯一、屬性值的唯一性、類目值的唯一歸屬等等。
2.數據之間的調用關係:
商品是整個電商的最底層邏輯,會被各後台及系統反複調用,產品經理需要對商品的實現及各系統之間的調用要非常清楚。
三、類目管理,越早越好
常規來講,一個商品應該對應到唯一類目。 類目的建立要考慮幾個問題:
- 唯一性。 唯一性指的是子類目下的名稱不能與其他子類目下的名稱重名。 如在“鞋子”類目下如果有了“運動鞋”這個類目,那麼“運動鞋”便不應該出現在“運動休閒”這個類目下。 否則會在進行商品統計、數據分析、用戶檢索時傻傻分不清。
- 排他性。 排他性是指商品僅掛落到一個類目樹下,不重複。 (多指後台系統)
- 前台類目與後台類目分別管理。 前台類目的主要功能分為兩個:方便用戶進行檢索、引導用戶轉化。 後台類目功能有一個:將商品作聚類管理。
通常的情況是,每天的運營目標不同,除常規分類外還會配置運營分類。 這裡是非嚴格意義上的分類,更像是靈活配置的運營模塊。 比如今天iPhone X在電子產品的前台分類下,明天便可以放到開學神機這個分類下,但最終商品屬性的後台類目是不變的。
四、什麼時候使用SKU,什麼時候使用SPU?
總的一個原則:涉及到庫存的部分使用SKU,涉及到展示的部分使用SPU。
舉個例子:每個SPU下,會同時存在多個SU信息,如阿迪達斯小綠尾會有36、37、38、39、40碼。 在運營模塊、搜索結果中,只需要讓用戶知道小綠尾這個商品即可,所以用SPU信息(即貨號信息)便足夠。 但是涉及到購買時,有的人需要36碼,有的需要40碼,這時便需要使用SKU信息對最小可操作單元進行管理。
五、商品庫存該如何管理?
庫存是指該商品現有的數量,比如Adidas小綠尾36碼有5個庫存,那麼可以售賣的庫存數便是5。
在電商系統裡,一般會存在多層庫存,包括但不限於:銷售庫存、中轉庫存、實物庫存、良品庫存、次品庫存等等。
較為簡單的系統裡僅有銷售庫存、實物庫存兩類,如果庫存不一致時售賣便會有問題,當銷售庫存>實物庫存時便有可能出現超賣問題! (後續會繼續介紹我在超賣問題上踩過的坑)
那麼,商品的庫存會對用戶側有什麼影響呢? ——商品庫存對售賣狀態的影響。
- 銷售庫存=0時,一般為補貨中或下架狀態,具體如果變更狀態及變更為什麼狀態,根據各司業務不同可自行定義。
- 銷售庫存>0,實物庫存=0的狀態,一般是預售狀態。 預售狀態尤其要注意的是賣出庫存、剩餘庫存的處理關係。
六、商品價格的管理?
一般講,商品的價格系統由三部分構成:成本價、標牌價、現售價,活動期間還會有活動價格。
踩過的坑主要是在活動價這一塊。 隨著各種搶購活動的興起,各種電商也開始了0點開搶大戰。 運營手動改庫存或到點兒批量改庫存肯定是受不了的,所以產品常會接到一個定時改價格的需求。 在改價格的功能中,踩過了一些坑拿出來分享:
1.商品參加活動引發的價格優先級
商城的活動那麼多,一個商品在同一時間可以參加幾個活動呢? 如果參加多個活動價格該如何計算呢?
從銷量角度來講,是支持同一商品參加多場活動的;但是從復雜度來講,限制了商品可以在同一時間段參加同一種類型的活動。 比如同一件商品,可以同時參加大促、秒殺活動,但是不能參加同一時間的兩場秒殺活動(不要問我為啥同一時間有兩場秒殺,一切皆有可能!)。 那麼問題來了,A商品參加大促的價格是100元,參加秒殺的價格是200元,那麼該顯示哪一個價格呢?
這時便需要根據自己平台特點和規則設計價格優先級。
2.商品活動價格引發的對賬問題
對賬時,財務姐姐們不僅收到多少錢,還要精確到每一筆訂單中的每一件商品要收多少錢。 所以當商品的價格變更時一定要在報表中及時同步給對賬的同學們展示清楚。
本文由 @ Löwenzahn 原創發佈於人人都是產品經理。 未經許可,禁止轉載。
題圖來自Pixabay,基於CC0協議