讲用户端的时候提到，用户查看商品主要到三个渠道：促销、搜索、分类。
促销和搜索之前的文章已经说过了，今天我们说下分类的部分。
说到分类类目就必须一起说下商品的“档案柜”：商品信息系统。
商品的范畴电商的分类基本是围绕在商品信息进行分类聚合的。
无论是按照商品种类分类还是促销属性、品牌属性等进行归类，都脱离不了商品的范畴。
那下面我们看下商品管理都包含什么。
从商品的基础信息来看主要包括两部分： 分类树：主要通过层级分类定义商品的基本类目归属属性库：包括所有商品相关的属性信息分类类目的定义在电商系统中，商品的种类琳琅满目，如果希望快速查阅自己想要的内容就需要一个快捷的查找方式。
类似于图书馆的分类查找，电商系统中的分类类目也是同样的概念。
分类类目分类类目按照功能分成前台类目和后台管理类目两种。
两者之间是通过映射关系来关联的 前台类目：负责前台类目的展示后台类目：负责商家或运营人员对商品的管理类目设计上有几个要注意的点 可关联商品的类目一定是叶子节点的类目，即最末端的类目。
前台类目与后台类目的关联关系是多对多的关系。
属性库只与后台类目关联，前台类目通过映射关系获取。
属性库属性库是商品管理体系里面最重要的部分，他管理着绝大多数商品信息的内容。
这里面我个人将属性分成两种类型。
商品属性：商品的基础属性，表达商品信息的内容。
主要用于展示。
售卖属性：用于售卖时计算使用。
主要用于订单相关的内容。
商品属性商品属性大多主要应用于前台展示的信息内容。
在电商体系下商品有两种类型：SPU和SKU，名词具体说明大家可以百度了解。
简单的说，SPU用于展示商品是什么，SKU代表可以卖的具体商品怎么卖。
SPU和SKU的关系是一对多的关系。
比如一个IPHONE手机下面有多个规格SPU本身不作为直接售卖的单位，只用于展示。
SPU的价格为下属SKU的所有价格区间SKU价格与规格（如16G 白色 iPhone）相关。
属性一般挂靠在SPU层面，如商品名称、所属分类等。
而决定售卖特征的（如规格、价格等）则放在SKU层面去设置。
对于一些非标品如生鲜类的需要考虑外包装物的概念（即一筐鸡蛋需要有鸡蛋筐的外包装物），此处在设置时需要设置押金金额。
增值服务（延保、优惠类型等）一般不归商品规格属性管理。
商品描述、标题、副标题等属性一般放在CMS中进行管理，部分O2O场景考虑到较电商简单，可考虑合并管理减少CMS系统来实现。
这里面特别说明下规格字段，规格一般是由多个属性值构成，通过不同的属性组合确定商品（SKU）的销售价格（图中的亮黑色和6GB 64GB就是规格属性）。
由于它能够决定商品的特征和价格，一般在电商中会将该属性作为中心词（有的地方也叫关键属性）和品牌词一起处理后用于搜索或者推荐词库中。
通过属性命中情况能够快速定位到用户希望查找的分类类目，提高搜索的精准度。
销售属性销售属性主要是针对价格和库存，还有商品的类型（是否是赠品）。
价格 价格包括售价和定价两部分POP平台价格来自于POP同步到商品系统中，包括售价和定价。
也可分开提供给前端ERP中的实物定价需要同步到商品系统中使用商品系统的价格来自价格系统处理后的结果，当然如果没有比较完善的竞变价系统，可以将基础价格放在商品系统管理，在判断是否促销价格或者VIP价格时单独整合处理。
库存 后端系统之间同步的库存主要是实物库存，在提交前台时可将实物库存分离出显示库存的概念用于前端展示。
两个库存做实时同步。
商品系统的实物库存来自于ERP中如果有POP平台，考虑到商家自己可能对接有ERP系统，商家商品的库存和信息可选择是否同步到自有的商品系统中赠品 赠品数据需要同步给促销系统，以便选择促销赠品时数据保持一致。
赠品也需要有库存管理，但不一定有价格管理。
外部的关联商品系统属于最底层的信息管理系统，他存放这商品最根本的基础“档案”。
各个外围系统都需要经常性的来这里“查阅”。
下图表达了各系统“浏览”的情况，在提供给前端的时候有两个建议： 商品信息的同步除主体信息外，其余信息（如促销信息）可由各个系统单独提供给前端API商品信息需要定期同步给搜索系统，这里包括不限于商品名称、商品规格等结语商品是所有销售的基础，如何建立一套高效的管理工具是值得深挖的。
本文只是简述了一些基础的结构和关系，适用于初级产品快速入门。