商品是电商的核心，之前的文章电商系统中商品模型与类目体系设计介绍过电商系统中如何设计商品模型及商品周边领域概念，要想深入了解一个具体领域业务，最好的方式是了解它的前世今生，今天简单了解下商品类目的发展史。

一个电商网站上线之初，商品种类和商品数量都很少，简单的管理功能就满足了，但是随着商品数量的越来越多，管理需求也越来越大，可以想到的简单管理能力就是分类，商品更多就变成了多级分类。

分类经过抽象可以分为三部分：前台类目、后台类目、店铺类目。

前台类目便于用户筛选自己的商品，或者平台根据促销活动按照某种方式组合一些商品到某些类目下，可以叫做销售类目或营销类目。

后台类目是商家便于管理自己的商品，将商品挂载到这些类目下。

店铺类目是便于商家对商品进行管理和归类，用户进入店铺内便于搜索和查找商品。

相比来说前台类目更灵活，因为他可能根据平台不同的活动周期或营销需求做不同的组合，后台类目更稳定一些，主要是便于商家、运营操作。店铺类目是店长基于自己商品情况在店铺内部进行的商品再组织。前后台类目之间建立好映射关系。

后台类目

商家在发布商品时，先选择商品对应的后台类目，商品需要挂载在叶子类目上，然后填写商品的基本属性和销售属性信息，属性信息一般为了复用会挂载在类目上，不同类目下挂载的属性可能不一样。

由于这些类目信息及属性信息是平台复用的，所以对于类目的日常管理，如：增删改、基础属性挂载、销售属性挂载、品牌挂载、继承关系整理等。由于后台类目是前台类目的基础，挂载在子类目上的属性后期一般不轻易修改删除，所以需要运营同学操作时考虑尽量周全。

接下来说下类目设计。

一般类目是树状结构，三到四层即可，太深了不便于管理，最底层的类目叫叶子类目，商家发布的商品一般挂载到叶子类目上。

类目元信息包括：类目名称、类目父类目、类目是否禁用属性等。

前面说了后台类目是前台类目的基础，所以建立的后台类目一般不允许删除，不然已经绑定了此类目的商品怎么办？关联了的类目属性怎么办？建立了映射的前台类目怎么办？

实在不删不行的话，就需要发邮件，走通知，让之前绑定此类目的商品重新上架了，风险自控。

类目归根结底是给运营和商家使用的，怎么方便怎么来，做好扩展性，尽量稳定不来回修改删除，商品是挂到子类目上的。

前台类目

前台类目是方便用户找到心仪的商品，或配合平台做活动增加某些商品的曝光度等目的。

前台类目更多是对后台类目的绑定和直接复用，当然为配合营销活动，也会出现前台类目直接挂在sku的情况。

总的来说前台类目主要服务于两个目的：

1. 多样化的运营需求：后台类目比较死板，前台类目可以更灵活的服务于不同场景下的运营需求，将相关商品绑定到指定前台类目下。

2. 丰富后台类目的灵活性：后台类目一般比较死板，适合标准化管理，而且很多时候供应端和需求端是不同的部门，康威定律，跨组织协调成本比较高，分离之后前后台类目自己团队单独管理，互不影响，效率更高。

前台类目一般是对后台类目的映射，那这个映射怎么实现的呢？

前台类目和后台类目之间可以一一映射，也可以多对一映射。

一对一映射：前台类目直接映射一个后台类目：

多对一映射：多个具有相同属性的后台类目通过聚合的方式映射到一个前台类目上，某种程度上是属性和类目的映射关系：

或是将一些没有属性关联的后台类目，以场景角度聚合起来，形成一个前台类目：

另一种映射是对于搜索关键词的映射，或者设置成搜索框的热词：

还有就是活动落地页的类目映射，在电商平台经常做一些营销活动，放一个大的落地页或者是banner，用户点击之后跳转到某一个前台类目下，提高某些商品的流量和曝光度。

前台类目映射可以按照商品属性、店铺ID、商品ID等维度映射。

店铺类目

店铺类目是商家自己创建的，以自己的需求做商品归类和规则制定，便于用户进入店铺之后精准找到想要的产品。

前台类目和店铺类目有一定的相似性，可以按照不同业务场景将商品分门别类归纳起来，满足运营需求。先创建类目名称，绑定商品。

类目只是树形商品管理的能力，一旦商品数量巨大，简单的靠类目进行商品管理是很难实现的。

所以就引入了属性的概念，依靠属性可以解决商品管理分类越来越细、用户搜索个性化等需求了。商品属性抽象来说，是对商品维度信息的描述字段，体现了商品的基本信息。

比如”面料“、”颜色“、”风格“、”领子“都是对裙子这个商品的基本信息描述，也就是属性，而对应的”蕾丝“、”青蓝“、”宴会“、”圆领“就是属性对应的属性值了。

属性一般由属性名称和属性值组成：

有了属性之后，用户可以通过商品属性快速了解商品基本信息。

与类目相比，属性更灵活，它以散点方式表现商品信息，而类目是类目树的方式。品牌、季节、风格、颜色、型号都可以视为属性，每一个属性都对应多个属性值，属性也可以包含子属性，这样对于商品的管理与展现也就更灵活了。

由于属性过于灵活，如果不对属性进行很好的管控的话，未来围绕于属性的管理将会很困难，为了更好的管理属性可以对属性进行分类。

属性可以分为：关键属性、销售属性、非关键属性、特殊属性等。

关键属性

值得是那些可以唯一确定商品的属性，可以是一个属性或一群属性集合以确定一个商品或商品集合。比如手机中的品牌和型号可以视为关键属性，因为通过两个属性可以唯一确定商品集合（SPU）。总之关键属性是为了用户可以确定性的找到某个商品。

销售属性

通常是某个商品的规格，一个或多个销售属性可以确定一个SKU。比如关键属性（品牌）（型号）确定了SPU，而销售属性（黑色）（8G+256G）就确定了SKU。用户只有选择到了销售属性维度确定了SKU才可以知道对应的库存和价格，所以很多人用SKU以确定某个具体商品的库存。

非关键属性

听名字这就是一个扩展冗余的属性，有的也叫做通用属性，其实就是关键属性、销售属性之外的其他属性。一般在商品配置时带*号的是必填的一般是关键属性，不带*号的是非关键属性，不是必填的。非关键属性的目的是完善商品信息的完整性。

特殊属性

一般是用于特殊场景下的商品描述，比如带有腐蚀性的商品需要特殊包装，而”具有腐蚀性“这个标签就是一个特殊属性。在商品物流打包环节会进行特殊处理。

了解了类目及属性之后，怎么将他们和商品联系起来呢？

属性和类目关系

之前提到了商品会挂载到子类目上（类目层级一般3-4级），由于商品数量远大于类目数量，所以我们不可能单独为每个商品绑定属性，所以一般是把属性绑定到类目上，发布商品的时候，根据分类选择对应的属性，这样将商品再挂载到子类目上的时候，这个商品就具有了这个类目树下的所有属性了。

属性层级关系

由于类目是由父子继承关系的，每一层类目可以挂在不同维度抽象的属性，这样在最叶子类目上就可以看到自己类目树上所有属性的继承情况了。主要目的是为了减少商家上单商品的工作量，当商家上单一个商品的时候，只需要选择商品挂载的叶子类目，系统就会自动加载出叶子类目继承树上所有的属性了。

属性值输入类型

由于属性非常多，有的是可枚举的，有的是难枚举的，比如季节类的是可以枚举的，商品配置时用下拉框就可以了，比如产地如果全球的话是难枚举的，输入框即可。

属性是为了描述商品的，如果平台类目越来越庞杂，属性的数量势必也会数量巨大，为提高对于属性的控制管理，或避免重复创建属性，需要建立属性库。

上图可以发现，设置一个属性包括：属性名称、属性值类型、是否必填等信息：

属性值：尽可能是可枚举类型，前台可以提供商家扩展功能，或排序功能。

值类型：商家在操作商品属性添加时候，可以进行不同类型属性值的赋值。

是否搜索：属性如果可以用于搜索，可以让用户更直接的找到商品，基础属性（如标题、品牌、品类）等一般会参与搜索，其他属性视需求而定。

为了对同一类的属性进行管理，可以引入属性模板（也叫属性组），同一类特征的多个属性归属于一个属性模板，在属性添加时可以选择加入的目标属性模板，有了属性模板之后就可以批量挂载属性了。

在发布商品时，类目可以获取整个属性模板下面的所有属性，比如存储、基本参数、显示、包装清单等都是一个独立的属性模板。

商品属性是对商品的详细描述和信息的完善，属性值填写的是否准确很大程度上决定了在搜索与匹配的流量是否精准，提高商品的转换率。

电商场景下很多的搜索场景、个性化推送、推荐、找类似都是基于属性实现的。

至此详细对于商品类目及商品属性这两个核心概念有了一定的认知，其实在电商系统下，如果可以很好的消化了商品领域下的系统设计，其他领域的系统设计对你来说将会更简单，因为不管是三高场景还是业务复杂度治理，商品领域都是一个非常完善且具有标准化挑战的领域方向。