电子商务商品库的产品设计
简单来说，商品中心就是用来管理核心商品数据的。使用维度:从前端为商品展示、订单、营销活动提供商品数据支持；从后端来说，商品中心为订单发货、仓库管理、供应商管理、采购提供基础数据支持。为了更清晰的描述商品中心这个重量级项目，我打算从以上两个维度写两篇文章。本文主要从后端维度介绍商品中心。
一、商品常用概念介绍
首先，介绍几个基本概念:SKU、SPU、属性和范畴。
SKU:库存单位，库存控制的最小可用单位。比如Iphone 7plus？128G白银是SKU，仓库管理，采购，库存展示都是SKU。不同的公司有自己的SKU编码规则。如果他们有自己的仓库，一般会在货物入库时放上自己的SKU码，这样整个库存系统就从上到下打通了。当然还有另外一种方法，就是设置自己的SKU码和供应商条码的对应关系，在订单转换成发票的时候，把自己的SKU码转换成供应商条码。对于大公司来说，推荐前者，而后者往往会因为供应商编码规则或管理规范不同而增加实际操作中的出错率。
SKU编码
SPU:标准产品单元是一组标准化的信息。比如Iphone 7plus就是一个SPU。SPU和SKU有很多关系，可以是一对多，也可以是一对一，如下图所示。SPU信息应包括SPU属性、产品图片、产品描述和产品标签。SPU和SKU通过规范联系在一起。SPU(Iphone 7plus)与SKU(Iphone 7plus？128G银)。SPU的库存由其相应的SKU库存决定。
SPU和SKU
属性:分为关键属性、销售属性和非关键属性。关键属性是指能够唯一确定产品的属性，必须输入。例如，手机的品牌和型号是关键属性；销售属性构成了SKU的特殊属性，或者说规格属性，比如手机的“颜色”和“记忆”；非关键属性是指除了关键属性和销售属性之外的其他属性，比如手机界面的类型。非关键属性不一定是非强制的，有时为了产品信息的完整性，会设置为强制。属性定义与良好的消费体验有着至关重要的关系，在搜索、索引和筛选中起着至关重要的作用。
品类:分类树，电商常用的品类有两种，前台展示品类和后端商品品类。前景品类是指展示给消费者的品类，会根据季节、销售策略、活动而变化；背景类别属于基础数据，不能随意更改。添加SKU时，需要选择类目并绑定。需要注意的是，类别树的层次不要太深，一般是三四级。如果太深，对管理和技术性能都不利。前景类别和背景类别可以任意搭配。在设置前景类别关联时，设置前景类别树的最深一级，使其可以与背景类别的任何一级关联，可以是一对一，也可以是一对多。前台品类也可以对应品牌。
JD.COM前台类别
2.商品基础数据设计
在介绍商品的常见概念时，也透露了很多与产品设计相关的信息。添加SKU时，需要选择一个品牌，填写一些属性，以及关于仓库管理的基础数据(长、宽、高、重、供应商等。).商品中心的基本数据结构如下。首先是品类管理，主要包括品牌管理(中英文名称、可用品类、产地(跨境电商更重要))、属性管理(为品类添加相关属性和属性值)和品类管理(后端品类树最重要，所以确定时要综合考虑，属于基础数据，后续更改比较麻烦。)，大致的产品框架如图所示。
商品中心框架图
添加SKU时，供应商用于关联采购，进而影响仓库中SKU的库存。供应商在添加SKU时可以不选择，但可以在采购系统中添加关联。通过销售属性关联SPU和SKU，相同的SPU在前台显示时可以* *使用相同的产品明细，但是通过规格属性映射到特定的SKU；商品的关键属性和属性值可以用于商品搜索和筛选，一个好的属性定义对缩短客户决策树起着至关重要的作用。
SKU用法
还有一个特殊的概念:组合SKU，主要解决组合商品的销售问题。组合SKU的属性继承自主SKU。组合SKU的应用场景主要是添加赠品和组合销售，不同于前台的商品包装。当一个订单解析成一张发票时，需要将合并后的SKU解析成一张SKU，方便仓库发货和更新库存。
三。重新报价
商品中心后端属于基础数据，会被很多子系统调用，这是电商公司最重要的。商品中心为仓库管理、采购管理、库存管理和订单管理提供接口数据。可扩展的商品中心结构将为公司的业务发展带来巨大的好处。
文章后延伸，很多电商的业务定位是B2B2C。为了扩大SKU，增加用户数量，或者建立一个平台系统，将允许第三方管理平台上的产品，类似于JD.COM和有赞。这类平台的产品结构比较复杂，SKU需要增加自己的商家，产品明细、属性值、库存需要相互独立。SKU和SPU纬度增加了一个商业纬度。这里没有太多展开，感兴趣的朋友可以深入思考。
实物
上面的文章从后端的角度介绍了商品中心使用的一些基本数据设计。接下来主要从商品的前端展示来说说背景设计。用户在购物中通常接触到的是商品展示页面，商品列表和商品详情页的基本信息都是从商品中心获取的。目前产品设计有成熟的产品方案，电商网站的产品结构也大同小异。淘宝上的商品以SPU形式展示，而JD.COM上的商品以SKU形式展示。两种加工方式各有利弊(表述可能不准确，但仔细研究了两者的产品结构，你应该明白我说的区别，下面有解释)。其实我更喜欢淘宝的商品结构，可以支持更灵活的商品解决方案。
JD.COM和淘宝的商品详情页面
商品信息主要由类别、标题、品牌、商品属性、规格(在JD中定义为销售属性。COM)、价格、库存、SKU信息(毛重、长度和宽度等。)、商品地图、商品详细描述、物流信息。至于服务标签(白条、快速退款)、商品标签(热卖)、活动标签(满减、优惠券)、价格标签(集合价、活动价)、类似商品，都是商品信息上的包装层，不在本文讨论范围之内。
1.商品类别和商品基本信息
商品类别分为两层:基础数据类别层和前台展示类别层。新增和管理商品时，商品在基础数据类别层进行管理(如下图)。商品属性、销售属性、品牌等很多数据都是在基础品类中进行管理的，所以品类管理是比较核心的工作，必须从长计议。
添加商品时，需要选择相应的类别。当前景类别显示时，有两种方法来处理它:
前景类别对应背景类别，可以一对一、一对多、多对多，自由组合，动态调整。现在大部分自营电商都用这种类型。
前台类目直接对应商品，适合商品少的小商家，主要是一些电商平台提供给平台上商家的类目服务。添加商品时，直接选择前台显示的类别。
另外，品类一般分为三层，品类树不能太深，否则会影响产品效率。
JD商品类别
设置产品信息和副标题(一般介绍产品卖点和推广)，选择产品对应的品牌。在品牌管理中，有两种方案:
统一品牌管理，商品丰富度少的小公司。
品牌相关品类，选择商品丰富度高的。
基本信息编辑
2.商品属性
商品属性，包括属性名和属性值，一般挂在特定类目的子叶下，有必选和非必选。设置属性值时，需要保持一定的扩展性，部分属性允许自定义。商品属性管理需要很强的品类操作能力。在中小型电商平台，一般都是提供基本属性值，然后打开自定义属性编辑，让用户完善属性数据库数据。
商品搜索的能力除了标题和类目，很大程度上取决于商品属性，条件筛选的基础数据也是商品属性和规格属性。完善商品属性对于良好的用户体验非常重要。
淘宝的商品属性(男装>)；风衣)
3.规格、价格、库存和SKU信息
在购买商品时，我们往往会选择规格(销售属性)，主要包括颜色和尺寸。为了支持多样化的用户需求，我们可以在选择后编辑规格。规格一一确定后，可以分别设置价格、库存、商家SKU，还可以在淘宝添加条码(69码)。也可以设置统一价格，统一库存。填写商户SKU的主要目的是为了方便对应到具体的对象。如上所述，仓库和采购管理都是具体的SKU。
仔细观察后会发现JD。COM的商品标题都加了具体的规格，在选择规格的时候会跳转到SKU，提高了单个数据的效率，但是页面效率和体验都不如淘宝的SPU结构。现在大部分电商采用淘宝的SPU架构，也是不错的选择。
JD规格、价格、库存、SKU设置
在淘宝上选择某个具体规格后，会发现商品缩略图会有变化，这就需要在管理商品时，针对某个规格单独上传图片。这里有一个巧妙的设计，但是不同的颜色需要上传相应的产品缩略图，而尺寸不需要。
淘宝上传不同颜色的特定缩略图，JD.COM可以上传多张图片。
平台价和市场价是为商品设置的，主要是为了在列表中显示商品，不需要选择具体的规格，相当于商品的平均价格。毛重、长度、宽度等数据主要是为物流设置的。自建仓库的自营电商一般在SKU数据层录入这些数据，直接调用。商品编号就是商品编码，在商场购物时会扫描的条形码就是商品编号。货号和SKU码不一样，同样商品码的商品可能是不同规格的不同SKU，所以我们不能直接管理有货号的SKU。
填写JD商品信息
4.商品地图，商品细节描述和物流信息
商品图除了对应不同规格的商品缩略图外，还包括商品主图，一般要求图片质量较高，包括整体图和细节图。商品主图是吸引顾客眼球的必要武器。无论是列表页还是活动页，客户关注的都是价格，主要是商品主图，上架时需要对商品主图保持谨慎。
产品详情页现在一般区分电脑版和手机版。由于它们的使用场景和设备不同，侧重点也不同。为了更好的展示产品特性，我们可以提供不同的产品详情模板，支持不同的富文本编辑。
商品详细信息描述
选择货运服务时，要选择相应的物流模板(包括邮费、按重量、按件数等。).在订单处理中，运费是根据特定的物流模板计算的。运费模板的计算更加多样和复杂。下一篇文章将详细描述和解释与物流运费相关的细节。
商品物流选择
5.其他商品信息
主要包括售后服务(发票、保修服务、退换货)、装箱单等相关说明。
6.上层和下层机架管理
设置好商品基本信息后，设置好装卸时间，也可以直接上架放行。与商品相关的活动，一旦商品下架，活动将失效，无法购买。搜索筛选的商品范围都是货架上的商品范围。
上下框架设置
自营和平台电商的商品区别
在商品经营层面，平台电商提供给平台商家的商品服务和自营电商提供的商品服务有很大的不同。最大的区别是自营电商比平台电商多了SKU管理，库存和属性基于SKU管理。添加商品时，如果必须重新填写，会造成数据冗余。所以一般用数据。
摘要