中文字幕无码av不卡一区,亚洲综合AV永久无码精品一区二区,黑人巨大白妞出浆,黄色高清无码免费看,久久久久免费精品国产,久久无码人妻丰满熟妇区毛片,欧美日韩国产综合草草,久久福利网站,亚洲一区二区三区中文字幕在线,av国内精品久久久久影院

編輯導語：B端商品系統用于滿足B端平臺需求，本文作者分享了B端商品系統的設計思路，介紹了電商平臺、商品簡介、一般平臺型商品中心分析以及B端電商平臺商品中心設計思路的相關內容，一起來學習一下吧，希望對你有幫助。

本文主要從電商平臺商品介紹，再到詳細的設計思路，講述了我自己設計滿足B端平臺需求的商品中心過程。

一、電商平臺介紹

Platform在英文中的意思是平臺（主體——主體）。

用科技鏈接不同的人、鏈接不同的組織、資源來完成交換，如微信平臺。

重新分配，有了新型的中間人。例如，音樂行業的高管們過去主要依靠經紀人來尋找新的人才?，F在，他們一樣會在YouTube上尋找好的歌手，開發同學去Github尋找開發，去抖音上尋找視頻博主一樣。

市場聚合，將分散的市場聚合成為集中化的市場。例如，阿里巴巴為全世界的批發商打造了一個單一的平臺。

將資產與價值分離。你不必購買一輛汽車來作為每天代步的工具，而可以隨時叫一輛滴滴專車來送你上班。

平臺天然能提供壟斷與稅收，也就是平臺的各種服務費，不直接產生產品，但能獲取最多的利潤。

為了能夠提高利潤，降低成本，我們需要增加售賣渠道和產品種類，同時增加供應鏈的復用率，降低供應鏈成本，如果能夠將產品和供應鏈的成本轉嫁到其他人身上那就更好了。

這就解釋了為什么電商公司都逐漸發展成了平臺（發展得好的話），而當前，我們公司也發展到了這一步，所以需要新的商品管理方式。

二、商品簡介

在超市，他是有價格和表面有一系列說明的可購買的最小單位在電商平臺，他是有價格有庫存有規格參數及一系列說明的最小單位。

從商品的信息來推敲后臺該如何設計，才能讓后臺設計更好地滿足用戶需求。大致來說有以下商品信息有以下幾部分：

1. 商品的基本信息：包括標題，型號，說明與相關參數等；
2. 商品的規格參數的信息；
3. 商品價格，從哪發貨，還剩多少的信息；
4. 商品標簽等運營信息。

我們設計商品中臺，就是為了去更好地管理好這些商品信息。

三、一般平臺型商品中心分析

一般來說，平臺電商商品中心包括了以下幾個子模塊：

例如下方的商品后臺示例：

上述的電商平臺商品中心的路徑大同小異，存在的交互路徑可能有所不同，但底層的E-R結構和產品架構是比較類型的，都可以大致看做是以下結構。

發布商品大致的流程是：

這是一些電商平臺商品中心的設計思路，這種設計有以下的一些特點：

1. 同一商品可能有多種參數信息與補充信息；
2. 商品需要維護信息較多，需要商戶投入精力較多；
3. 商品信息的自定義程度高、商品的信息需要平臺進行審核；
4. 能夠自定義商品各種信息，以保證自身商品的競爭力，適合一個商品很多賣家競爭的場景；
5. 店鋪類型決定了能夠售賣的商品品類等，管理較為細致；
6. 系統設計相對復雜，牽扯到例如刪除了規格參數相關已存在SKU如何處理，刪除了SPU類目如何處理SKU，修改了又如何處理等系統行為。

四、B端電商平臺商品中心設計思路

1. 業務模式分析

首先分析一下B端產品交易平臺的需求特點：

1. B2B交易，交易相對平常購物的網站頻次更低；B端客戶更為理性，對營銷信息更慎重；
2. 用戶需要的元器件商品的參數信息需要嚴格且準確，不能提供錯誤的參數信息；
3. 商品是高度標準化的，并且商品一般只有一個供應商生產此商品；
4. 一個品牌的商品進行售賣的商家不會很多，不是淘寶/天貓那樣的大市集；
5. 一個商品可能在一段時間進行持續供貨（一段時間生產周期內），商品信息的穩定性較高；
6. 平臺商家普遍不止一個渠道進行管理與銷售;
7. 對于自營店，商品量大，種類眾多，管理難度相對較大。

所以有以下的幾點簡單推論可以得到：

• 對平臺：核心需求是通過多店鋪的商品管理，加強平臺的供應鏈能力，并在此基礎上仍能保障商品的參數正確性，并不是一個商品幾百家商家；
• 對用戶：商品信息嚴格準確，并盡量使商品有貨可售-前臺呈現模塊；
• 對商家：維護商品的難度很低，不需要耗費很多時間，核心是把貨放在平臺上賣，而不是考慮貨長什么樣，怎么更能吸引消費者（這是原廠產品性能考慮的東西）。

2. 商品術語定義

• ON：商品的完整參數信息，除商品的價格和庫存等銷售信息外的所有信息；
• 商品：最小的可售單元；
• 商家：平臺上的服務商；
• 店鋪：商家在平臺上開的店鋪，平臺進行服務費管理、店鋪管理的最小單位；
• 商品屬性：商品的基礎屬性，表達商品信息的內容，主要用于展示；
• 售賣屬性：用于售賣時計算使用，主要用于與訂單相關的內容。

3. 商品中心模型

平臺化場景：即多個商家銷售多個商品時；自營店或其他店鋪都可以新建商品，但新建的商品都公用一套平臺審核通過后的商品的信息內容（但框架上保留自定義內容空間）；保證平臺商品參數的正確性，若商家認為商品參數有誤，可以進行編輯并提交商品參數的審核，商家直接引用平臺通過審核后的商品參數則不再需要審核了。

這時候就能看到我們和某淘/某東的商品管理基本結構上的相似點。

• 同一個SPU：該規格下的所有SKU都分享同一份商品圖片和商品描述等信息
• 同一個ON：該ON下所有商品都分享同一份ON的信息內容

思想其實是類似的先聚合，再細分，最后把價格和庫存管理在最小的可售賣單元上。

• 聚合的是什么，是SPU、類目、規格等可以復用的信息
• 細分的是什么，每個商品都有細分的不同的商品參數、價格與庫存

4. 商品中心特點

商家引用平臺審核通過商品參數再形成商品的策略，就顯得十分均衡；

1. 元器件電商的規格參數需要很強的嚴謹度，保證了規格參數的嚴謹程度；
2. 對于平臺的商家，自行維護這一部分參數信息門檻很高，并很難做到準確；
3. 平臺非一個商品幾百個商家售賣的“大賣場”，不一定需要同樣商品（對用戶）建立多樣化的商品信息；
4. 降低了維護難度，也滿足了敏捷開發的目標，沒有那么復雜的規格、品類之間互相關聯的關系；
5. 多店鋪多平臺的結構，商品中心的業務中臺能夠同時支撐英文獨立站和中文站的商品體系；
6. 基于商品機構，可以直接再迭代多語言化的商品信息場景，來滿足多語言平臺站點的不同需求，通過店鋪所屬站點，發布地址來判斷，直接將商品的多語言版本上架前臺；

即：商家將平臺提供的商品參數提供進行引用，商家自行管理商品的上下架、價格、庫存等信息，同時平臺能夠有對商品總體的控制，避免風險。

五、總結

本文主要介紹商品管理的設計思路而非具體設計方案，在B端設計中，先搭建好設計的框架才能進行具體的功能設計，商品管理系統在電商系統中是常見的核心系統，有非常多的設計案例和思路（電商類、ERP類），根據商業模式。

業務類型來建立真正適合自己的商品系統才能提供產品價值。很多設計是大同小異的。

本文由 @浮云志 原創發布于人人都是產品經理，未經許可，禁止轉載。

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