电商网站,电商产品设计三大核心模块（一）——商品分类体系

电商网站,电商产品设计三大核心模块（一）——商品分类体系

从上图可以看出，每个产品都有一个品类（一级品类），没有子品类。该类别链接到该类别下的所有产品。

三、多级分类

当商品数量上升，达到千、万甚至更多时，一级品类已经不能满足需求，此时出现了多级品类的概念，这就是我们称之为“类别树”。

分类树一般在三级左右，尽量不要超过五级。因为电商有一个公认的铁律，叫做“漏斗模型”，即层级越深，损失越大。就像漏斗一样，嘴越低，嘴越小，所以品类层次不能太深。

三级分类（图片来源百度）

上图是一个三级类别的例子。卖家上传商品时，需要向下选择一级，直到确定叶子类别。

四、类别+属性

当产品的量级达到百万、千万甚至上亿时，新的问题就出现了。比如服装可以分为男装和女装，男装和女装又分为T恤、裤子等，T恤又分为很多品牌，裤子又可以分为九分裤子，七分裤等根据长度。随着树的不断分裂，交叉和重叠是不可避免的，这就变成了一个难以管理的网络。

所以当产品越来越多，分类越来越多，用户搜索越来越个性化时，单靠分类树已经不能满足产品管理的需要。这时出现了另一种维度分类方法，叫做“属性”。

如何理解“属性”，先看下图：

属性

这是对产品“裤子”的描述。我们可以用左边的形容词来形容它。这就是我们通常说的标签。但标签的分类过于精细，数量过多时难以管理。当我们按照右边的方式对标签进行分类时，这些类别名称就变成了我们所说的“属性”，而左边的标签就是我们所说的“属性”。 “财产价值”。

举个常见的例子，我们平时使用微信，通讯录中的联系人按照26个英文字母排序，就像我们上面提到的分类，然后我们根据不同的分类使用不同的联系人。根据他们的特点进行分类，例如“家人”、“高中同学”、“大学同学”等。你也可以根据自己的喜好将他们分类为“前男友”或“前女友”。

这些人为的分类是标签，将相同性质的标签分类成标签组是一个属性（例如，将“高中同学”和“大学同学”分类为“同学”）。这里只是一个例子，微信只支持标签，不支持标签组。

需要注意的一点是，在后台输入商品时电商网站,电商产品设计三大核心模块（一）——商品分类体系，必须在叶子类别下链接属性。比如服装-女装-超短裙，超短裙是一个叶子类，可以附加红色等属性，这样搜索红色超短裙就可以得到直销商品。但是如果要给服装附加属性——女装，女装下面有很多品类，直接把女装附加到红色是没有意义的。

类别+属性：查找模板

上图中的“find stencil”（ ）是一个典型的“category” 在“+attribute”的例子中，钢是按产品名称、材料、规格、钢厂等分类，然后按品牌分类和其他属性。

五、前端类别+后端类别+属性

是否可以使用“类别+属性”来解决所有产品分类问题？

答案当然是否定的。我们先来看一个很常见的场景：

网站运营商需要经常为导购调整分类属性；但卖家并不想为了产品的稳定性和减少不必要的时间消耗而进行调整。这里有矛盾。

矛盾的根源其实是买卖双方的需求差异，经营者会进退两难。扔了。

这里的本质是，一个产品，一套逻辑，并不能很好地满足两个完全不同的用户群。那我们该怎么办？

第一个想到解决方案的人是2008年淘宝的一位产品经理。他有一次去沃尔玛，仔细观察了传统超市的商品分类逻辑：

大超市商品在货架上的陈列方式在不断变化。随着季节、特殊节日、销售情况等因素的变化，商品的陈列方式也会经常调整。

不过大超市里也有仓库。仓库里的货物比较固定，食品在食品区，保洁在保洁区。所以，超市里的商品其实是放在两个地方——后端仓库和前端货架，使用的分类方式也完全不同。

他受此启发，提出了“前端品类+后端品类”的架构设计方案——将一个产品一分为二，一个给买家，一个给卖家，即：

卖家通过后端品类发布产品，买家通过前端品类购买产品。

原来的类别变成了背景类别树，再构建一个前景类别树，然后前景类别树的叶子类别通过映射关系与背景类别关联。任何前景类别的叶类别可以对应任意一个或多个背景类别电商网站，不一定是背景叶类别。

例如：

例如，如果iPhone X卖得好电商网站,电商产品设计三大核心模块（一）——商品分类体系，运营商可以创建一个“iPhone X”的前端类别，然后把后端类别[数码产品]——手机]和属性[品牌= iPhone & Model=X] 链接到这个前景类别电商网站，如下图：

前景类别对应背景类别

我们来看一个实际场景的例子，最常用的淘宝()：