商品管理系统如何设计?以商品类目和属性为例

20 评论 52114 浏览 358 收藏 14 分钟

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

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

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

01 类目管理

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

(1) 更符合用户心里预期

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

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

(2) 缩短用户导航路径

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

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

(3) 降低品类的调整成本

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

1.1 后台类目

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

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

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

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

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

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

1.2 前台类目

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

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

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

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

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

02 产品属性

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

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

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

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

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

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

2.1 属性分类

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

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

2.2 属性与属性组

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

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

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

2.3 属性继承

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

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

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

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

03 SKU和SPU

  • 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。

小结

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

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

 

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

题图来自 unsplash,基于 CC0 协议

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 请问,类目关联了属性。那如果类目修改了上级分类,当前类目下又有商品,这时候商品属性会变吗?还是不允许修改类目呢

    来自北京 回复
  2. 属性是否被搜索是怎么处理呢,在前端页面会有怎样的逻辑?

    来自广东 回复
  3. 博主,我有一个地方不太理解,属性组和属性类型有何区别?
    盼回复!

    来自上海 回复
  4. 讲的挺不错的,就是对楼主文中提到的“规则属性”部分相比其他描述会没那么清晰,如果有截图或架构提供的话,可能会更让人理解。

    来自广东 回复
    1. 规格属性也可以理解为:销售属性
      比如颜色、尺码、款式、内存大小,然后SKU就根据这些已选的销售属性进行笛卡尔积,生成结果的数量集SKU;
      举例:现在选了颜色和尺码两个销售属性,颜色属性下有2个色值:红色、白色;尺码属性下有3个色值:M、L、XL
      那么根据笛卡尔积,就会生成颜色(2个)*尺码(3个)=6个SKU
      此时将分别定义到6个SKU。

      来自上海 回复
    2. 笛卡尔乘积应该大家都懂,我的意思是:楼主在文章中描述时可以写下具体的设计架构,让读者更加清晰;特别是多规格时如何设置、每个规格可能单独对应的价格、库存等关联的管理……这些场景都是会用到

      来自广东 回复
  5. 写得太好了!!

    来自北京 回复
  6. 请问文章里的基础属性有单独拿出来区分描述属性的必要吗

    来自江苏 回复
  7. 博主你好,很想了解下品牌的解决方案~急切来电

    来自浙江 回复
  8. 想问下关于类目属性的前台部分 关键词搜索结果商品可能不止一个类目的 类目属性展示哪个类目的呢

    来自上海 回复
  9. 深入浅出,说的真好

    来自上海 回复
  10. 请问叶子类目建好后,可以更换叶子分类的上级分类吗

    来自浙江 回复
  11. 收货颇多,一直做得前台,在尝试搭建整个电商后台

    来自辽宁 回复
  12. 不错

    来自四川 回复
  13. 大 ..大佬,加个好友呗!老喜欢你了

    回复
  14. 深入浅出,感谢!

    来自广东 回复
  15. 很棒的分享~~

    来自湖南 回复
  16. 可否加个微信聊聊

    回复
    1. king_mario

      来自湖南 回复
  17. 学习了,感谢

    来自北京 回复