类目体系设计总结

一、背景

公司窗帘产品在做分类调整，从原先二级类目调整为三级类目，相对于平台电商我们的类目层次结构要简单很多（没有定义商品动态属性等），但对于也有上万款SKU的系统来讲,做好基础的分类对于采购、商品促销、数据报表统计还是有必要的。

二、平台电商类目

类目即分类树，电商平台通常会将类目分成前台类目和后台类目。

1、为什么要分成前后台类目

• 海量的商品，类目树的层次会很深，如买家直接使用后台类目，查找商品将非常困难。

• 日常运营需要经常调整类目，如果前后台类目不做分离，随着节日季节变化，运营人员需要频繁变更商品的类目，工作量巨大。

2、后台类目

• 后台类目即基础数据类目，后台类目面向商家和供应链人员，不可随意变动，商品属性、销售属性及品牌等很多数据都是在基础类目上进行管理。

• 后台类目相对固定，创建之后不能轻易变更或删除，如果类目下挂有商品就不能删除或作废。

• 类目树层次也不能太深，一般三四层左右，类目树最后一层称为叶子类目，商品必须挂载在叶子类目下，商品只与后台类目有直接关系。

3、前台类目

• 展示给消费者看的分类，需要根据季节、销售策略、活动进行变更。

• 前台类目需要支持不同客户端的设置，PC、APP端渠道由于用户群体和界面差异会分别设置不同的前台类目。

• 前台类目不同于后台类目，前台类目可重叠,可删除，可随时变动。

4、前后台类目关联

前台类目对应后台类目，可以一对一、一对多、多对多、自由组合。

三、淘宝Forest系统

11年左右，我们在淘宝用共享平台搭建垂直市场，大致流程就是先申请后台类目，然后申请前台类目，配置好前后台类目的映射关系，然后申请几台机器，做个导购页面，部署发布上去就OK了。

Forest系统介绍

用于管理类目属性的基础服务系统，它提供两种方式读取或写入数据

1、实时服务，通过HSF直接读、写数据库（CRM、商品中心）.

2、提供缓存服务,forest系统相关的数据都会推送到各个系统的内存空间.

当时第一天配置好类目，然后需要第二天才能在你的服务器上收到Forest包（大约在1G左右）,现在已经优化可以实时了吧？

1、所有业务方引用了Forest包，它会将你服务器的IP地址注册到Forest系统。

2、每天晚上Forest系统会从数据库中将类目及属性等重新Build一个最新的Forest包。

3、Forest根据注册的IP地址，推送Forest包到业务方服务器。

4、业务服务器反序列化Forest数据包，替换本地内存，这里使用的是直接内存，而不是Java堆内存

四、收银台项目类目体系

因为我们主要是卖成品窗帘，相对来讲分类比较固定，当前的系统设计如下：

1、不区分前后台类目.

2、类目层次定义为三级，所有商品都挂在第三级叶子类目下（这个当时业务方和我确认的时候我疏忽了，其实只要保证所有商品挂在叶子类目下即可，没有必要都强行搞出一个第三级类目，以后再调整吧）

3、采购系统的类目和销售系统的类目划分不统一，而采购系统的类目来源于工厂ERP，很难统一，将来会是个麻烦事。

4、收银系统对分类重要性不如电商平台，当前需要用到类目的主要是

•   采购系统：做好分类便于订货人员可以快速按门别类进行订购，尽量避 免订错货，乱订货。

•  销售折扣：可以根据不同类目做促销打折活动。

•   库存流转报表、退换货原因等报表需要根据类目进行统计。

五、牛奶系统类目

对于牛奶SKU很少，定义类目其实意义并不大，我们通过  分类+规格+套餐（年卡/季卡/月卡）来确定一个SKU.