今天，我们来聊聊商品类目的设计思路。

商品是电商的根基，核心目标是销，也就是卖货。卖货可以多层理解，卖给谁，怎么卖，什么货，其实就是人货场的概念。

我理解的货，不仅是商品层面，更是围绕商品搭建起的交易架构，从货的产生到货的流转。新零售时代，货的定义更是被重构，货能够独立满足用户需求，也可以说是货来源于用户需求数据，来自于c2b的定制化数据。

我们在政治课上学过商品的概念，它是人类社会生产力发展到一定历史阶段的产物，是用于交换的劳动产品。

是交易的介质，能够满足人类的需要。商品的存在形态不限于实物形态，也包含虚拟类商品如延保服务，售后服务等。

电商商品的出现，把线下的商品形态搬到了线上环境，也就是把线下庞大的商品数据同样拿到了线上。当商品规模较小时，对于平台来说管理起来并不是很复杂，随着商家的增多，商品的数量会呈现指数型增长。

此时，如果没有好的商品管理方式，平台运营的压力将是史无前例的巨大。这个时候，需要一套“用的舒服”的商品管理体系，而管理体系的根基就是商品的类目库。

商品类目api接入测试

taobao.cat_get 获取淘宝分类信息：通过传入cid:商品分类ID，可以用cid=0来获得所有一级类目。

taobao.item_cat_get获取淘宝商品的分类信息：通过传入商品ID可以获取该商品的分类和子分类。

jd.cat_get获取京东分类信息：通过传入cid:商品分类ID，可以用cid=0来获得所有一级类目。

老王把商品管理体系分为以下三趴，分别是：

• 商品信息：包含商品基础信息，标题，图片，商品属性，商品的品牌，商品库存以及商品价格分布，还有编码，资质等

• 产品库：产品可细分为SKU和SPU两种模型

• 类目库：分为前台类目和后台类目

电商的商品管理体系参考了传统行业的管理思路，毕竟传统行业已经发展多年，吃的盐比电商吃的饭还多。

它的意义就在于，对于用户而言，能够迅速找到商品，查看商品详情；对于平台而言，减少运营工作量，火箭式的提升效率。

现在在淘宝京东上挑选商品时，用户可以通过类目导航迅速定位到喜欢的商品，也可以通过关键词搜索商品，大数据推荐用户喜欢的商品。

用户还可以通过商品详情页面及商品评价等内容了解商品的全部信息，而这些信息要比线下更加丰富，这些能力都要归功于-商品管理体系。

商品类目的必要性

产品在初期的时候，由于商品数量和种类不是很多，可以简单的用2级分类即可描述商品类目。比如一级分类手机，二级分类品牌，或者直接将商品放到导航上，如小米电商网站的类目导航。

但若是商品种类繁杂，涉及的商品数量巨大时，这种分类结构会变得越来越深。比如服饰下男装，男装下牛仔衣，牛仔衣下的款式，款式下的大小，依此类推。

这么多的类目层级会让运营和用户一脸懵逼，用户在页面难以找到这么深层级的商品，运营也没办法维护如此巨大的数据量。

所以先吃螃蟹的淘宝制定了一套规则，首次引入了类目属性的概念，制定了“类目主导+属性辅助”的商品管理形态，沿用至今。

并且规定了类目的数量不能超过4级，这套规则在业界也广泛流传。目前京东也是使用的这套规则管理商品。

管理商品类目的意义非常大，笔者认为主要有以下几点：

• 帮助平台，商家高效管理商品体系，减少非必要性工作量。

• 提升前台的导购效率，能够在特定的时间点上，提供对应的类目导购策略。

• 便于用户进行类目搜索，快捷查找商品。

电商商品管理面向三方角色，商家角色，平台运营和消费者。平台运营设置后台的类目管理标准，并根据情况设定前台类目展现形式。

商家根据运营后台的类目，进行店铺商品的录入，商品维护，品牌管理以及最后的商品发布。

消费者在前台进行类目搜索，根据类目查找商品。通过运营设定的前台类目，查看特定场景的商品组合。

电商的商品类目管理灵感来源于线下实体店，线下实体经过多年的发展，总结出一套高效的商品管理模式，即大前台小后台。

简单来讲，就是把商品类目分为前台类目和后台类目。前台类目面向用户，突出导购内容，让用户看得到，摸得到，吸引购买。后台类目面向运营或商家，负责商品底层的维护建设，操作效率，方便管理。

前台类目

前台类目即给消费者展现的类目。会随着季节，时间，节日等场景展现不同的类目特征。主要是为了结构化类目信息，让用户能够直观的找到所需商品。

有时候为了促销或者销售增量的目的，会将一些商品摆放到很显眼的地方。举个例子，日本7-11便利店的货架上，总共上架不超过3000种商品，为了达到利润最大化，店内的生鲜食物类产品必须日销，也就是每种商品每天库存很有限。

一个新来的店员把原本订3瓶的早餐酸奶，订成了30瓶。如果卖不出去的话，她将自己掏腰包支付剩余的酸奶费用。

不过她人比较机灵，将放在另一个货架的酸奶和其他早餐放到了一起，还写上纸条：早餐配酸奶更有益健康哦～最后，酸奶卖脱销了。此后，7-11边将这个混合搭配模型传承了下来。

我们接着说，前台类目也同样呈现树状结构，从一级类目到叶子类目。一级类目是最基础的类目，叶子类目是最尾部的类目，前者类似于树根，后者则是树叶。

为了方便用户查找商品，类目数量一般是不能超过4级，这一点在整个电商貌似达成了共识一般。

 上图就是前台类目的例子，叶子类目为第4级，所有的商品只且只能挂在叶子类目下。二级类目不单单分为男士上装和男士夏装，还根据场景新增了潮流和当季2个分类。

前台虽然只展示潮流，其实在后台可能挂了很多叶子类目在上面。潮流属于这些商品的共同属性（关于属性，接下来会讲），后台挂的子类目都具有同样的属性，意味着所有关于男性潮流的商品，都会合在一起。

淘宝有十几亿的商品数量，商品的所有分类如果全在前台展示，基本是不现实的。前台类目寸土寸金，其展现形式有大体三种：

• 一对一关系类目。即后台的类目关系与前台类目是一对一的，直接映射过来。如后台类目名称叫男装，前台也叫男装。

• 一对多关系类目。前台类目在后台关联了多个叶子类目的形式，如潮流男装对应多个潮流相关的叶子类目。

• 关键词类目。通过搜索关键词，查询对应的类目商品列表。典型的就是iphone上市时，回了推广手机，会在前台类目列表中，添加iphone的文字链接。

• 链接类目。以某个样式展现，点击后实际上进入了某个落地页。

第一种类目形式在产品初期时，可以直接复用。一旦网站的商品量剧增时，大前台小后台的管理方式是不可或缺的。满意以上的类目形式，需要灵活的类目管理体系。

后台类目

后台类目主要面对的是商家和平台运营，他们负责搭建类目，挂载商品到叶子类目下。一些比较知名的公司会把一部分店铺运营工作交给第三方，如代运营公司，也就是外包公司。

还有一个场景，当你负责的电商产品A影响力较大时，会吸引平台型电商B公司入驻，例如苏宁入驻天猫，一号店入驻京东。

B的商品数据量也是巨大的，此时则需要通过其他方式来获取商品，并对应到A的后台类目上。一般是通过一套通用的对接方案，结合类目预测和类目纠错算法进行匹配，当然，同需要人工的参与。

后台类目按照使用情况，可以分为三种状态：

• 可用状态：类目是可以使用的正常类目状态

• 屏蔽状态：类目处于屏蔽状态，商家是无法看到的。

• 不可用状态：类目已经无法使用了，一般情况会给商家提示状态。

上图是淘宝的后台类目，每个商品在创建时，必须有对应的归属类目。当选择类目后，才可以填写商品属性。

一般来说，为了防止后台数据冗余和杂乱无章，商品后台类目层级不超过4级，3级类目形式相对占比较多一些。

在后台类目树上，能够结出很多“果实”。包含以下几方面：

• 属性库：表达商品和类目的特征，如颜色，尺码，规格参数等。属性分商品属性和类目属性，包含关键属性，销售属性，商品属性，绑定属性，以及特殊属性。

• 品牌库：商品的品牌数据管理，品牌的基本字段组成为logo，中英文名称，产地等数据组成，品牌下可以挂载多个类目商品。

• 型号库：商品的基本信息，表示同一个商品的不同规格，用编码表示已达到区分的目的

• 条码库：包含条形码和二维码，扫描后，能够查询到商品的全部信息。

• 资质库：商品自制，生产标准，专利，认证等材产品库：又称为SKU库，一类商品的集合。

• 商品库：SKU库，最小库存单元集合。