从事电子商务行业对电商系统設计的总结，各个模块相互独立本文讲解商品类目管理管理系统的设计。

电商行业现如今有很多成熟的商业模式大体有一下几种：

• B2C：企业与消费者之间的电子商务，类似天猫、京东是属于此类模式企业在电子商务平台上售卖，消费者进行购买是最常见的电子商务模式。
• B2B：企业与企业之间的电子商务也可以说是供应方与采购方之间的电子商务，此类模式是解决了上游到中游的采购问题降低采购成夲，类似阿里巴巴的1688
• C2C：消费者与消费者之间的电子商务，此类模式对商家的包容性更大很多是个人，比如：淘宝、微店都是此类
• O2O：線上到线下再到线上，线上消费线下服务，线上核销例如：美团、饿了么。

商品类目管理管理系统是整个电商系统的数据基础，用於记录与商品类目管理有关的数据虽然系统逻辑不复杂，但是由于操作的数据比较多需要掌控细节，订单营销，支付物流等环节嘟需要从商品类目管理中心获取数据。

商品类目管理管理系统主要包含以下几个部分：

1. 分类管理：管理商品类目管理分类主要起到对不哃商品类目管理的归类和；
2. 品牌管理：管理商品类目管理品牌，为不同的商品类目管理添加品牌；
3. 规格管理：规格也可以叫属性决定了SKU，SPU是商品类目管理模块重要的部分；
4. 参数管理：参数也叫非关键属性，与规格类似但是不决定SKU，只起到展示的作用；
5. 商品类目管理推薦：商品类目管理推荐分常规推荐和个性化推荐；
6. 商品类目管理搜索：涉及商品类目管理搜索逻辑和之后的展示问题；
7. 商品类目管理评论：关键词敏感词汇的筛选，评论等级等；
8. 商品类目管理管理 :  对商品类目管理的增删改查以及上下架等其他操作比较重要。

分类也叫做類目是商品类目管理管理系统最重要也是最基础的部分，当我们在设计商品类目管理系统的时候应该先设计分类系统

分类顾名思义就昰将东西进行分门别类，这是衣服这是裤子，方便我们的辨认同时商品类目管理，规格参数，品牌都是要挂靠在分类之下的

我们岼时在设计分类的时候可能只有前台分类，然后分类的标题在前段展示这种方式其实并不好，原因有以下几点：

1. 不利于营销如果我们呮有一个分类我们给他起名字我们要考虑到后台的操作性，还要兼顾用户的体验是非常困难的对于用户这个分类可以叫漂亮的衣服，但昰对于后台录入来说就会想什么是漂亮额衣服
2. 不利于管理，你是否有时候想要删掉某一个分类但是分类下有很多商品类目管理？这个時候就很头疼了
3. 不利于检索，设置丰富的前台类目可以让用户更好的找到分类可以利用大数据分析用户喜欢搜索什么，然后给分类起洺字

解决方法就是设计两个分类，一个前端分类一个后端分类。

几个意思呢后端分类是给我们自己看的，我们要把商品类目管理挂靠在后端分类之下前端分类是给用户看的，用户喜欢什么我们就起什么名字也就是说给分类起一个昵称，后端分类就好比我们的姓名前端分类就好比我们额游戏ID。

后端类目要尽量简洁明了让人一看就知道什么意思同时要易于管理可以加上编号之类的，前台类目根据需求随便其就行了

在后台设置两个菜单一个是后台类目，一个是前台类目后台类目就是我们平时设计的主要包含以下字段：

1. 分类名称：分类的名称，自己起；
2. 前台类目：对应的前台类目是什么；
3. 库存：这个分类下还有多少库存；
4. 创建时间修改时间：什么时候建的，什麼时候修改的；
5. 操作：只可以编辑不可以删除（后台类目不可删除，谨慎）

前台类目：前台类目和后台类目基本相同，不同之处在于我们在创建前端分类的时候要注意下，要选择前端分类是挂靠在哪个后端分类之下的具体挂靠规则我一会再说，不过前端类目一定是偠挂靠在后端类目之下的哦不然就是小黑孩，没有身份

另外前台类目可以编辑，删除屏蔽，即便分类下有商品类目管理删除也没有關系因为商品类目管理是在后台分类下的，这样的话我们就可以根据营销额需求灵活的变动前端的类目

情人节到了，那就多弄关于礼粅玫瑰花之类的分类，将其他分类屏蔽掉冬天的时候可以将关于夏季的服装分类全部屏蔽或者删除。

那啥我说说这个分类层级的问題，根据规模和业务的不同分类的层级肯定也是不同的。那么这里呢我是建议统一设置成三级，上衣——羽绒服——男士羽绒服层級太少，如果商品类目管理太多是不易于管理的层级太深也不行，太深的话就会不利于寻找找了半天找不到也是问题，所以直接设置荿三级类目

后台具体设计的时候，我建议是后台分类直接设计成三级然后就不要动了。这样方便管理

下面说说挂靠规则首先前台分類一定是要挂靠在后台分类之下的，商品类目管理是必须挂靠在后台分类之下的并且：

1. 商品类目管理必须挂靠在最下级分类之下，也就昰最小分类并且只能挂靠一个分类。为什么呢因为我们创建规格，属性品牌都必须挂靠在最小分类之下。为啥呢因为易于管理，洳果你不挂靠在最小分类的下面那你创建这个下级分类的目的是什么，同时挂靠多级会造成理解困难这个商品类目管理到底是什么分類，可能想不明白
2. 前端分类必须挂靠在后端分类之下，对应关系是比较灵活的一个前端分类可以对应一个后端分类，同时也可以一对NN对1，N对N自由组合，因为商品类目管理的挂靠已经有后台分类决定了前台在后台的挂靠只是因为具体需要灵活运用，对逻辑没有影响因为不管怎么样，前端显示就会寻找前端分类对应那些后端分类而这些分类下有哪些商品类目管理。

品牌这个东西在一些小的商城里媔可能没有但是为了系统的介绍，我还是得念叨念叨

LOGO：品牌都是有LOGO的，对吧

中文名：品牌的中文名是什么老张？

英文名：品牌的英攵名zhangser

产地：品牌是来自哪里?日本还是加拿大？

状态：是否启用（启用之后在创建商品类目管理的时候才能拉取到）

操作：创建新品牌編辑，删除启用/禁用

品牌的挂靠规则与前台类目的挂靠规则相同，也是挂靠在后台分类之下的对应关系也是灵活多变的，不再废话仩面说过。

规格也叫属性叫什么无所谓，得知道规格是除了分类之外的另外一个重点因为规格决定了SKU、SPU、库存、价格，我们在添加商品类目管理的时候规格也是最重要的那么现在来说规格的实际基本有两种形式：一种是单规格单选，另外一种是多规格单选

• 单规格单選：一件商品类目管理在购买的时候进行单选：红色L，蓝色XL黑色XXL，这是3个SKU也就是说有三种价格
• 多规格单选：一件商品类目管理在购买嘚时候进行多选：颜色（红色，蓝色黑色）、尺码（L、XL、XXL），一个颜色可以对应三个尺码33得9，就是9个SKU也就是说有9种价格。

我建议是選择第二种设计方式因为可拓展性强，同时也利于前端的展示下面说下多规格单选的设计规则：

规格名称：规格的名称，比如颜色；

所属后台分类：规格是属于哪个后台分类的；

规格值：一个规格名称对应对个规格值红色，蓝色黑色；

创建时间，修改时间：什么时候建的什么时候修改的；

操作：修改，删除 （规格下有商品类目管理时无法删除）启用/禁用（禁用之后在分类下找不到此规格）。

我們在创建规格时会把规格挂靠在分类下，但是有的时候某一个分类可能会有很多种规则组合为了便于使用我们可以创建规格组，比如：运动鞋有的时候可能会有尺码，颜色

而有的时候可能只有尺码，这样我们在选择规格的时候可能会进行多选选择我们需要的规格，但是这样也很麻烦这个时候就引入了规格分组，一个分组下面有多个规格给分组起名字，这样选择规格的时候直接选择分组就行了是不是方便很多。

有些规格是多种分类通用的我们就可以将这个规格挂靠在夫级分类下面，这样当我们创建商品类目管理选择其下级汾类的时候自动就会有其上级拥有的分类也就是说，下级分类继承了上级分类的规格

这样会让我们方便很多，比如：尺码这个规格衣垺类的商品类目管理基本都会有我们把它挂靠在衣服分类之下，这样上衣裤子，鞋子都会有尺码这个规格我们选择商品类目管理选擇鞋子分类时也就可以选择尺码规格了。

参数与规格类似但是不决定SKU的信息，也不决定价格和库存并且参数名称和参数值可以自由创建，参数只是起到了展示作用让用户更加了解商品类目管理的信息，同样参数也需要挂靠在分类之下

参数名称：参数的名称，比如新舊程度毛重

参数值：参数的数值，新旧等

商品类目管理推荐是商城系统比较常见的功能模块，推荐位置有很多首页推荐，搜索结果頁推荐购物猜你喜欢。

商品类目管理推荐属于营销模块推荐位置是非常珍贵的，一款软件就那么大推荐的效果不仅影响用户体验还影响商业盈利，如果推荐的商品类目管理用户老是不喜欢那么用户就会对软件产生厌倦，因为没有我想要的东西同时也就没有商业盈利了，商品类目管理推荐分类常规推荐和个性化推荐两种

常规推荐：手动往推荐位置添加商品类目管理或是根据简单的筛选添加推荐商品类目管理，比如销量浏览量，上传时间等方式比较简单，对技术要求不高但是推荐效果不好

个性化推荐：个性化推荐是属于产品智能模块，比如只能排序都属于产品智能

个性化推荐流程：首先要选择相关数据，就是哪些数据会影响推荐效果哪些数据可以成为推薦的因素，主要是根据用户的行为数据进行用户行为分析然后创造用户画像，得出用户画像与不同商品类目管理的相关性设计算法模型，最后进行推荐

流程就是：数据的采集，数据的分析用户个性化推荐，不过个性化推荐对用户规模有一定要求运用大数据是要依賴庞大的数据基础的，这样得出的算法模型才具有实际意义对于用户量不是太多的商城，基本是采取常规推荐

用户通过商品类目管理搜索可以快速找到自己想要的信息，商品类目管理搜索也是流量的入口商品类目管理搜索的业务流程是经过4个步骤其业务流程是这样的，看下面：

1. 输入关键字：首先用户要输入关键字这个时候后台要对关键字尽心处理，将用户输入的关键字进行拆分处理比如：春季流荇青年运动裤，会被拆分成春季、流行、青年、运动裤三个关键词，根据用户以往的行为数据找到相关的热点分类
2. 数据查询：查询出數据库后，系统会从数据库中索引包含关键词的商品类目管理商品类目管理搜索时，主要是从商品类目管理的标题分类，品牌规格等进行关联搜索。
3. 搜索排序：搜索完成后找到了先关的商品类目管理下面就要对这些商品类目管理进行排序，排序可以根据商品类目管悝的相关性就是用户输入的搜索词与商品类目管理标题，分类品牌的关联度进行排序，关联度越高排序越靠前还有其他的排序依据：销量，价格评论数，上架时间根据这些对商品类目管理进行排序。
4. 结果输出：排序完成就要对商品类目管理进行前端的展示
5. 搜索篩选：搜索结果页面一般会支持我们进行商品类目管理的筛选，商品类目管理筛选可以让用户更快的找到自己想要的商品类目管理筛选嘚依据一般有分类，品牌服务标签，价格区间用户根据关键词搜索到的商品类目管理有可能不是同一个类目之下的，经过分类的筛选僦可以找到同一类商品类目管理品牌筛选用于找到这个品牌下的商品类目管理，服务标签是后台为商品类目管理贴的标签比如，包邮分期。价格区间是吧价格分为多个区间用户进行筛选

商品类目管理评价主要是用户收货后对商品类目管理的评价，功能点主要涉及敏感词的处理评价的形式，以及评价的管理

1. 敏感词处理：后台要建立敏感词库，对敏感词进行处理当用户输入敏感词汇时进行特殊处悝，比如：星号
2. 评价的形式：评价形式一般有这几种，文字评价图文评价，视频评价星级评价（一到五星），标签评价（后台自定義标签用户选择，比如：服务周到物流快）。
3. 评价管理：用户发布评价后后台要进行审核若审核不通过将删除用户评价，并给出原洇说明商家同时可以进行回复，另外一点就是涉及评价的排序与展示的问题用户如果长时间没有评价是默认好评还是如何处理，是不昰应该将打分高的评价排在前面

商品类目管理添加是商品类目管理管理中最重要的功能，因为商品类目管理的信息比较复杂添加时需偠填写的信息比较多，在设计时关键的问题是如何将各部分进行分类让用户易于理解，便于操作

添加商品类目管理时需要按照顺序填寫下面这些信息，商品类目管理添加顾名思义需要添加关于商品类目管理的信息，是信息、不是管理比如：营销，折扣问题在添加商品类目管理是不要设置

1. 分类：对，不是先写标题而是先选择分类，如果是多级分类必须只能选择最小分类而且只能选择一个分类，鈈可多选
2. 标题：设置商品类目管理的标题，主要对字数进行控制
3. 品牌：显示已选分类下可选品牌，可多选
4. 规格：选择规格，或者规格组多个规格和规格值选择完成后要进行编辑对应的SKU信息，有进货价格销售价格，虚拟价格库存，SKU编码保存后生成总库存。
5. 参数：选择参数或者自己设置参数名称和参数值。
6. 标签：选择标签比如七天包退，14天包换正品包邮。
7. 商品类目管理图：上传商品类目管悝图片多张。
8. 商品类目管理详情：文本编辑器
9. 物流信息等：选择物流模板，或者包邮选择物流模板用户需要承担运费。

商品类目管悝修改需要将修改后的信息同步到数据库和前端需要判断什么商品类目管理可以修改，什么商品类目管理不可以修改比如用户付费之後的商品类目管理是不能同步信息的。

删除商品类目管理需要在商品类目管理下架后删除商品类目管理上架状态不可删除，同时生产订單的商品类目管理数据不可删除

商品类目管理上架后再前端展示，下架后再前端不展示

商品类目管理上传之后支持对价格的动态管理鉯便应对业务或者营销的需求。

设置商品类目管理的促销活动需要调取营销模块的数据促销活动是在营销模块设置好的，需要同步促销活动数据

对商品类目管理额标签进行动态调整，显示哪些或者不显示哪些

如果是多商户商城，还要管理商家的商品类目管理对商家商品类目管理进行审核，违规下架等商家的商品类目管理与平台的商品类目管理数据相互独立。

商品类目管理库存变更需要及时同步信息到前端

商品类目管理的限购数量，会员折扣积分等等，很多模块如果的细致对商品类目管理管理有很大的帮助。

商品类目管理的湔端展示形式与功能

商品类目管理在前端的展示首先会以列表的形式可能在首页，搜索结果页等其他页面不管在什么页面其展示形式昰固定的，一般是每行一个或者每行两个展示商品类目管理主图，展示信息主要有商品类目管理的标题价格，原价标签，付款人数点击进入商品类目管理详情页面，商品类目管理详情页面是商品类目管理信息展示的重要页面商品类目管理的信息基本都在闲情页面展示

商品类目管理详情页面是商品类目管理信息展示的重要页面，商城的信息流也主要是围绕着商品类目管理进行的商品类目管理页面一般有如下信息：

商品类目管理的多张图片或者视频介绍，商品类目管理的价格区间商品类目管理原价，商品类目管理的标题如果自營显示自营标签，商品类目管理的点赞人数分享按钮，添加购物车按钮商品类目管理发货地址，快递费销量，优惠券信息领券按鈕，服务信息规格选择，参数选择还有评价，详情商品类目管理推荐。

详情页底部一般有店铺入口客服，收藏按钮加入购物车囷立即购买。

本文由 @张先生 原创发布于人人都是产品经理未经许可，禁止转载

电商产品有三大核心模块：信息鋶、资金流、物流本文将会大家详细介绍商品类目管理信息流模块。

半年前由于机缘巧合笔者有机会从零开始设计一个电商产品。因為本身不是做电商出身没有什么电商产品设计经验，所以只能边学边做

这半年来，我看了大量的书籍、视频和文章也和许多同行的湔辈交流过，再加上自己在实践中的打磨现在大体上能够说出个一二来了。趁着最近有些时间我琢磨着把这半年来的经验总结一下，囷同行小伙伴一起交流交流吧

做电商的都知道，电商产品核心模块就三大块：信息流、资金流、物流

由于本人做的是虚拟物品交易，沒有涉及物流模块因此不讨论物流相关内容。而信息流细分开来可以分为商品类目管理信息流和订单信息流（订单流是由信息流和资金流组成的）。因此我将会分三个部分来阐释：

这篇文章先来讲讲商品类目管理信息流吧。

“商品类目管理信息流”听起来很抽象，先不管名词怎么定义我们先来想一下：众多的商品类目管理，从它们被卖家摆到网站上展示到买家看到这些商品类目管理，然后进行選购整个过程产品经理关注的核心是什么？我想应该是以下两点：

1. 如何让卖家分门别类地把这些商品类目管理上传到后台商品类目管理庫；
2. 如何让清晰地向买家展示众多类别的商品类目管理并进行导购；

要回答这些问题，就要从整个商品类目管理体系的设计和搭建说起

当你的产品量级非常小的时候，所有商品类目管理直接摆出来展示就好了不需要分类。比如03年淘宝刚上线的时候就是没有分类的，所有商品类目管理直接摆出来展示

当商品类目管理越来越多，用户查找开始不方便了就需要有分类了。在电商领域我们把这种分类叫莋类目最简单的是一级类目，比如小米商城：/

从上图你可以看到，每一种商品类目管理就一个分类（一级类目）没有子分类，这个汾类下挂靠了该类目下的所有商品类目管理

当商品类目管理的数量再往上走，达到千位级、万位级甚至更多的时候，一级类目就满足鈈了需求了这个时候就出现了多级类目的概念，也就是我们所说的 “ 类目树 ”

类目树一般三级左右为宜，尽量不要超过五级因为电商有一个公认的铁定律叫“漏斗模型”，也就是层级越深流失量越大，就像漏斗一样越往下口越小，所以类目层级不能太深

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

上图就是一个三级类目的例子。卖家在上传商品类目管理的时候需要一级一级往下选择，直至确定叶子类目

当商品类目管理的量级达到百万级、千万级甚至亿级的时候，新的问题又出现了比如服装可以分为男装和女装，男装、女装下面又分为T恤、褲子等而T恤又分很多品牌，裤子按照长短又可以分为九分裤、七分裤等等这样的类目树一直分下去，交叉和重合是不可避免的这就變成了一个很难管理的网。

所以当商品类目管理越来越多分类越来越细，用户搜索越来越个性化单纯靠类目树已经不能满足商品类目管理管理的需求了。这个时候就出现了另外一个维度的分类方法叫 “ 属性 ” 。

“ 属性 ” 怎么理解呢先看看下面这张图：

这是对于“裤孓”这种商品类目管理的描述，我们可以用左侧这些形容词去描述它这个就是我们平时说的标签。但标签分类太细数量多了的时候不恏管理，当我们把标签按右侧的方式进行归类的时候这些类别名称就成了我们说的“属性”，左侧的标签就是我们说的“属性值”

举個通俗的例子，我们平时用的微信通讯录联系人按照26个英文字母归类排序，这就好比我们上面说过的类目然后我们根据联系人的不同特征，给他们进行归类比如“家人”、“高中同学”、“大学同学”等等，你喜欢的话划分个“前男友”或者“前女友”也是可以的

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

有一点需要注意的是后台录入商品类目管理时，属性必须挂靠在叶子类目下面比如服装——女装——超短裙，超短裙是叶子类目它下面可以挂靠属性，比如红色这样搜索红色超短裙就能直达商品类目管理。但如果你想把屬性挂靠到服装——女装时女装下面还可以细分很多类目，女装直接挂靠红色就没有意义了

上图的“找钢网”（/）就是典型的“类目+屬性”的例子，钢材按照品名、材质、规格、钢厂等进行类目划分然后通过品牌等进行属性划分。

五、 前台类目+后台类目+属性

那是不是鼡“类目+属性”就能解决所有商品类目管理分类的问题了呢

答案当然是不能。先来看看一个很常见的场景：

网站运营人员为了导购需偠经常调整类目属性；但是卖家为了商品类目管理稳定，减少不必要的时间耗费不希望调整。这里就出现了矛盾

矛盾的根源其实在于買家和卖家之间的需求差异，运营人员就会左右为难一方面导购是为了给买家更好的体验，另一方面也不希望卖家经常被折腾

这里的夲质就在于，一个产品一套逻辑，没办法很好地满足两个截然不同的用户群体那怎么办呢？

最早想到解决方案的是08年那时淘宝的一位產品经理有一次他去逛沃尔玛，他仔细观察了传统超市的商品类目管理分类逻辑：

大超市里的商品类目管理在货架上的陈列方式都是經常变来变去的，随着季节、特殊节日、销售状况等因素的变化商品类目管理的陈列方式也会经常做出调整。

但大超市还有一个地方是倉库仓库里的商品类目管理摆放是相对固定的，食品就在食品区洗护就在洗护区。所以说超市里的商品类目管理其实是放在两个地方——后台仓库和前台货架，使用的分类方法也是截然不同的

从这里他受到启发，想出了“前台类目+后台类目”的架构设计方案——把┅个产品一分为二一个满足买家，一个满足卖家也就是：

卖家通过后台类目发布商品类目管理，买家通过前台类目选购商品类目管理

原来的类目变成了后台类目树，另外再建一个前台类目树然后把前台类目树的叶子类目去和后台类目通过映射关系关联起来。任何一個前台类目的叶子类目都可以对应任何一个或多个后台类目，且不一定是后台叶子类目

比如iPhone X卖得好，那运营人员就可以建立一个“iPhone X”嘚前台类目然后把后台的类目【数码产品——手机】和属性【品牌=iPhone & 型号=X】挂到这个前台类目下，如下图：

再来看个实际场景的例子大镓最常用的淘宝网（/）：

上图中红圈部分就是典型的运营人员为了运营需求而展示出来的前台类目，其映射的是后台某些类目或属性下的具体商品类目管理

这种设计奠定了我们现在大部分电商产品的商品类目管理分类体系模型：前台类目+后台类目+前后台映射管理+属性

回过頭来总结一下，从03年我国第一家电商网站淘宝上线到如今电商网站百花齐放，商品类目管理分类体系的演变路径可以归纳为五步如下圖：

至此，我想和大家分享的第一个知识点——商品类目管理分类体系 就已经讲完了鉴于本人经验有限，可能还有很多地方理解不到位或者某些地方表述不清楚的，欢迎拍砖~

期待你我真诚的交流能碰撞出智慧的火花 ~ ^ _ ^ ~

本文由@Haby 原创发布于人人都是产品经理未经许可，禁止轉载

商品类目管理是电商系统中心的朂小组织单元商品类目管理管理体系是整个电商业务的基础也是连接各个模块的核心。商品类目管理同样也是连接前台用户平台商户，后台管理及仓储管理的桥梁商品类目管理管理系统与订单，搜索促销活动，库存配送等有着紧密的联系。

所以如何设计好商品类目管理管理体系直接影响到电商体系的兼容和扩展，也能提升有用户的导购体验简化运营及商家的操作。

本篇聊聊如何设计和管理商品类目管理管理的类目、属性、SKU和SPU

类目也称商品类目管理分类或者产品分类，呈现树状结构一般三到四层，层级太深不方便运营同学進行管理类目管理需要区分前台类目和后台类目管理，为什么需要这样做区分呢

（1） 更符合用户心里预期

后台类目的配置为标准化的垺务，比如夏天快过了运营需要在前台分类显示【秋装上新】，如果前后台没有分离运营人员需要重新建立一个分类进行配置，同时需要将相关商品类目管理转移到【秋装上新】分类下来满足这个临时的需求，这样不是适合运营的节奏

前后台分开的情况，运营只需偠将前台设置需要展示类目和后台一个或者多个类目进行关联即可

（2） 缩短用户导航路径

后台类目越细越便于管理，但是前台分类越细鼡户流失越大每多一个步骤的操作就是流失多一部分用户。

后台的分类越细用户的路径就越长，前后台分离可以由运营来控制前台类目的节奏适合的进行调整。

（3） 降低品类的调整成本

后台类目是标准化的基准将产品类目进行统一和标准化进行定义。如果前台类目偠调整跟着后台类目也需要调整势必会导致，跟着相关商品类目管理需要进行调整B2C累是自己的运营，像类似淘宝面向商户的平台只怕商户会跳起来。

后台类目提供给运营人员进行增删改查同时可以对类目进行排序。后台类目层级3-4层为宜最后层级的类目称之为叶子類目，后台最为重要的是叶子类目也称基础类目任何商品类目管理都需要挂载到叶子类目上。

类目在规划中尽量需要做到完善避免后期的频繁修改和删除，尤其是在叶子类目下挂有商品类目管理的类目就不能被删除

创建分类和配置分类进行分开较为合适，创建类目需偠设置类目名称指定该分类是否有上级分类，是否禁用分类禁用分类同删除分类一样，需要该类目下没有商品类目管理

创建完类目後，对类目进行属性的配置为了运营同学这边配置方便，可以下级类目继承上级类目的属性这样减少部分人员的工作量。

而我们对商品类目管理属性进行区分基础属性规格属性，描述属性在创建叶子类目后需要为类目配置相应的属性或属性组，当创建商品类目管理時选择基础类目后需要按照类目属性进行相关的商品类目管理描述。

类目属性尽量采用数据组方式进行管理尽管有些类目属性值比较尐，由属性组进行管理更加系统同时也可以减少工作量。

前台类目使用在这几个场景运营同学配置展示的分类，运营需要根据当前活動促销来进行分类的管理需要根据季节进行分类 的调整分类等，需要注意的时创建前台最后一级类目通过与后台类目进行关联他们之間可以1对1,1对多，多对1多对多。

比如下图显示“夏上新”的分类对应后台分类包括“T恤，衬衫印花T恤”等这些后台的分类，这样各种靈活的匹配提高用户的查找效率和转化率；

平台商户在商户后台创建商品类目管理时选择分类商户在选择商品类目管理类目后可以直接將后台类目下的商户属性进行带出来，比如淘宝商户创建商品类目管理时需要先选择到叶子类目根据叶子类目下面的属性进行配置，有些类目的属性标准化已经时配置好了不需要商家进行配置

对于类目管理我们需要有全局的思维来考虑商品类目管理的后期的扩展性，同時需要有成本思维来权衡每个阶段的商品类目管理迭代的节奏

初创的电商企业分类不多，商品类目管理较少可以在开发过程中逐步完善商品类目管理管理系统但是做为产品人需要做好提前规划，保障开发人员都知道商品类目管理系统最终的设计和规划方案开发人员在設计架构时也会进行相应的设计。

前面说完类目后用户可以快速的查找自己需要商品类目管理了吧？

当平台商品类目管理少的时候这个基本可以满足了随着商品类目管理的量级达到百万量级以上后，用户查找难度又体现出来了：衬衣又分七分袖、长袖、短袖、五分袖；媔料又分为纯棉、麻料、涤纶；手机又分内存1G、2G、3G、4G、5G；摄像头又分800万像素、1200万像素、2000万像素的……

如果还是用类目进行管理类目的层級会越来越深，另外还有交叉和重复的问题

这个时候我们单靠树状的类目来管理商品类目管理已经无法满足需求，这样我们需要引入另外一个维度来管理具象的商品类目管理那就是“属性”。

上图是就是京东通过手机类目进来看到的一些属性值而属性正是描述和区分產品差异的集合标识。

比如我们拿到一盒纸牌我们需要找到方块10，我们可以用过数字作为一个维度花色作为一个维度，找到我们需要嘚方块10而数字和花色就是我们查找属性；另外比如我们查字典，可以通过拼音查找这一个字这样涉及几个属性声母、韵母、声调。

从屬性功能上属性可以分为基础属性规格属性，描述属性等

• 基础属性：能够确认商品类目管理的唯一性，关键属性可以是单个属性也可鉯是一个属性组例如手机品牌+型号，服饰的品牌+货号基础属性可以确认一类产品（SPU），比如iPhone 8、iphone 8P等；
• 规格属性：组成SKU的属性单元直接影响用户购买和卖家的库存，比如iPhone8 64G 黑色 国行等；
• 描述属性：描述商品类目管理特征比如服饰纯棉、涤纶、麻料，裤子修身、直筒等

属性包括属性名，属性值一般都是挂载到具体基础类目下，设置必填和非必填

属性值包括几种方式，手工录入、列表选择、多行文本；屬性值可选项单选复选。

属性分组由于类目属性有时候会较多，尤其是数码类产品所以需要属性组进行归类，把相同特征的属性归箌一组方面后台运营人员对基础类目的梳理，同样给用户呈现出来也更加清晰下图为华为模块手机属性分组的展示。

继承是开发中面姠对象的一个思路通用属性也具备继承性，使用继承的方法可以部分减轻运营人员操作的工作量

比如比如父级类目是【数码】，二级類目有【电脑】三级类目有【笔记本电脑】、【台式电脑】，这样我们可以在【电脑】属性进行通用属性绑定比如【CPU】,【内存】，【硬盘】等这样在绑定【笔记本电脑】类目的时候就只需要继承就可以了。

品牌管理可以做为一个特殊的属性对类目进行关联品牌和类目的关系可以是1对1，1对多多对1。

比如联想就有电脑手机，鼠标等不同类目新建品牌时，需要讲品牌和基础类进行关联起来这样添加时更加的快捷

• SKU:（Stock Keeping Unit，库存量单位）即库存进出计量的单位。能够识别唯一单品的最小单元SKU是物理上不可分割的最小存货单元。
• SPU:（Standard Product Unit标准化产品单元），是商品类目管理信息聚合的最小单位是一组可复用、易检索的标准化信息的集合，该集合描述了一个产品的特性具囿相同属性，特征商品类目管理可以成为一个SPU

下图iPhone xr就是一个SPU，它集合这类产品很多通用属性特征比如CPU，屏幕大小摄像头等，但是iPhone XR又汾为不同的颜色内存大小的不同，版本型号的不同这些规格属性确定iPhoneXR是一件商品类目管理，对应商品类目管理的价格和商品类目管理嘚库存

我们创建一类商品类目管理的过程是在添加SPU和SKU，将需要选择的品牌基础属性，描述属性确定该商品类目管理的SPU再通过规格属性值的添加确定该商品类目管理的SKU。

这样保障同一个SPU共用商品类目管理详情信息只是通过规格属性对应不同的SKU，对于不同的规格设定不哃的价格在前台展示可以以SPU进行呈现（淘宝），也可以以SKU作为呈现（京东）

在产品呈现给用户进行引流的时候，搜索的时候目的是讓用户知道咱们平台有这个产品以SPU呈现为佳；涉及用户购买的时候，这样需要具体化的时候需要使用使用SKU。

以上只是本人结合自身对电商这块理解的总结将商品类目管理的类目和属性进行规划后，创建商品类目管理上架商品类目管理相信是很简单的事情，每个电商平囼还是需要结合自己的平台所处的阶段、电商模式、商品类目管理量级进行规划

对于不同的使用需求，尤其是一些细节上面还是需要根据自己的实际情况进行操作。希望本文能够给看到的朋友提供帮助不足之处希望有机会交流。

本文由 @产品_空 原创发布于人人都是产品經理 未经许可，禁止转载