如何设计电商系统商品中心?
商品中心作为电商系统的核心模块之一,承载着电商系统的核心基础数据,是电商系统中比较复杂的模块,商品中心的设计影响到后续的许多模块,所以一个好的商品中心,需要多方面考虑,包括后续的可拓展性、前端营销活动及业务需求等方面。
整篇文章将从4个部分来开展:什么是商品中心、商品中心的基础名称解释、如何设计商品中心、总计。
一、什么是商品中心
从使用层面来讲,商品中心分为前端和后端。
前端商品为商城、购物车、订单、营销活动等提供商品基础数据支撑;后端为供应商管理、采购订单等提供数据支持。采购、销售、库存等核心业务都离不开商品中心的支撑。
因此商品中心的重要性毋庸置疑。在做商品中心时,需考虑公司当前及长远的业务考虑。
二、商品中心的基础名词
相信接触过商品的人,或多或少都听过一些名词, SPU、SKU、类目、属性等等,那么这些名词到底是什么意思呢,针对这些名词做了如下整理:
1. SPU(Standard Product Unit)
标准化产品单元。是商品信息聚合的最小单位,是一组可复用、易检索的标准化信息的集合,该集合描述了一个产品的特性。
通俗点讲,属性值、特性相同的商品就可以称为一个SPU。例如Iphone X就是一个SPU。
2. SKU(Stock Keeping Unit)
库存量单位。是对每一个产品和服务的唯一标示符,例如iPhone X 128G 银色就是一个SKU,该系统的使用SKU的值进行数据管理,使公司能够跟踪管理,如仓库商品的库存情况。SKU需要有独立的条形码,方便仓库进行统计管理等。
我们创建一类商品的过程是在添加SPU和SKU,将需要选择的品牌,基础属性,描述属性确定该商品的SPU,再通过规格属性值的添加确定该商品的SKU。
这样保障同一个SPU共用商品详情信息,只是通过规格属性对应不同的SKU,对于不同的规格设定不同的价格。
在产品呈现给用户进行引流的时候,搜索的时候,目的是让用户知道咱们平台有这个产品,以SPU呈现为佳;涉及用户购买的时候,这样需要具体化的时候,需要使用SKU。
3. 类目
类目也称商品分类或者产品分类,呈现树状结构,一般三到四层,层级太深不方便管理。类目管理分为后台类目和前台类目,那么后台类目和前台类目得区别是什么呢?
一般前台类目面向用户,主要方便用户查找商品,很灵活,可以经常调整。
后台类目用来承载商品和属性模板,比较稳定很少变化,进销存业务都是和后台紧密关联的,从商品进货到商品库存,再到商品销售,最后到财务核算很多都是以后端分类为维度进行的。
后台类目和前台类目是多对多的关系,一个后台类目可以映射到多个前台类目,一个前台类目也可以包含多个后台类目。
举个例子:比如说某些商品既可以放在"夏季服装",也可以同时放在"女士服装"类目下,而后端类目是固定的,每件商品只能挂靠在一个叶子类目下。没有前端类目,单纯靠调整后端类目来满足运营需求,工作量大,繁琐,可能导致活动效果不好。
4. 属性
当平台商品少的时候类目基本可以满足用户得需求,但是随着许多平台商品量级的增加,用户想快速找到自己所需的商品,难度就大大增大了。如果仅靠树状的类目来管理商品,已经无法满足需求,这时就需要引入另外一个维度来管理具象的商品,那就是“属性”。
那么什么是属性呢,比如衣服颜色有红色、黄色、黑色、白色等,手机内存有16G、64G、128G、256G,这些都称为属性。
从功能上属性可以分为公共属性,销售属性,关键属性等。
- 公共属性:指其他类目可以公用的属性。例如鞋子尺码,37码、38码、39码等;
- 销售属性:组成SKU的属性单元。直接影响用户购买和卖家的库存,比如iPhone8 64G、黑色等;该属性是组成SKU的特殊属性,直接影响到买家的购买和商家的库存管理。
- 关键属性:能够确认商品的唯一性,关键属性可以是单个属性也可以是一个属性组,描述商品特征,比如服装面料、舒适度等。
三、如何设计商品中心
基于上面对商品中心的定义以及商品中心名词的解释,相信大家已经大致了解了商品中心。
那么l就可以开始进行商品中心设计了,在开始设计之前,可以基于公司现有业务及未来业务的发展方向,可以整理出商品中心的大致框架。以下是我结合自己对商品中心的理解整理出的商品中心大体结构。
将大体的框架梳理出来后,可以基于各个模块开始模块设计。
1. 类目管理
商品类目分为后台类目层、前台类目层,在添加和管理商品时,都是在后台类目层对商品进行管理。商品属性、销售属性及品牌等很多数据都是在后台类目上进行管理,所以类目管理属于较为核心的工作,一定要从长远角度考虑。
① 后台类目
每个商品在后台添加时均需选择相应的后台类目,最后一级类目称为叶子类目。后台类目相对稳定,不能随便删除,叶子类目不能重复,每个类目下都可以添加新的类目,修改相应类目。
②前台类目
前台类目需对应后台类目,前台类目与后台类目为多对多的关系。前台类目的核心功能点如下:
- 新增类目:新增类目时,同层级下类目名称不允许重复。层级叶子类目时,需选择该类目对应的后太类目,可多选。
- 显示/不显示类目:若选择显示类目,则该类目可在前端正常显示,若选择不显示类目,则该类目及该类目下子级类目均不显示。
- 删除:删除类目时,若该类目下挂有商品,则不可进行删除操作。
下图为前台类目模块的原型参考:
2. 属性管理
叶子类目可设置类目属性,完成类目树叶子目录与属性建立关联关系,后台添加商品时,根据商品选择的类目,可按照类目属性进行相关的商品属性的设置。若类目和属性很多时,需要创建一个属性管理池,叶子类目可以直接从属性池中选择相应的属性,而无需反复创建。
属性包括属性名,属性值,一般都是挂载到具体基础类目下,设置必填和非必填。
属性录入方式也分为两种列表选择和手工录入,选择列表选择要在下面可选值文本框里把你想要加的商品属性写进去,一行代表一个属性,选择手工录入的可以直接在添加商品时候自定义商品属性。
属性管理页面参考原型如下:
属性继承:如果业务所包含的属性重复度很好,可以考虑属性继承的功能,直接选择将属性挂靠在叶子目录下。每一级类目都可以挂靠属性,且每一级都会继承上一级的属性。
eg: 1级类目有属性A,2级类目有属性B,3级类目有属性C,那3级类目下的商品就具有属性A、B、C。这样可以减少属性挂靠的工作量。
3. 商品管理
商品是电商平台的核心资源,商品信息一般在客户端的商品详情中展示,商品信息主要包括商品名称、商品分类、spuid、skuid、售价、库存、商品属性、详情描述等。
在后台创建商品时,需要将商品绑定在销售分类(即后台分类),便于后续统计库存等信息,同时也需要绑定在前端分类,维护好商品信息后,在客户端就可以看到相应的信息。
参考原型如下:
上方的原型只列出了部分设置的内容,在实际的业务中还涉及到许多需要设置的商品信息,包括图片设置等信息。
4. 商品上下架管理
商品商下架,可以从商品库中国勾选需要上下架的商品,可以设置自动上架或自动下架,选择相应的上架/下架时间即可完成设置。
四、总结
商品中心其实在许多公司中都已经是比较成熟的模块,各个公司的商品中心可能基于公司业务不同会有细微的区别,但是其核心是相通的。
以上内容基于工作时涉及的商品管理模块以及阅读书籍《电商产品经理宝典》的一些整理思考,希望对大家有帮助,也欢迎大家提出问题,一起交流讨论,共同进步。
本文由 @搞笑君同学 原创发布于人人都是产品经理,未经作者许可,禁止转载。
题图来自Unsplash,基于CC0协议。
请教2个问题:
1. 品牌是单独的 和类目、属性有关系吗? 有的话怎么来限定的
2. 手机一般会有型号 如iphoneX 这个会放在销售属性中吗?
前台类目的图片上错了吧?
像请教一下,区分前后端的类目(商品分类)的必要性有多大呢?是必须的吗
后端是固定类目,不轻易删除,便于后台查询和挂钩商品使用,前端的类目是在客户端上直接体现可以随时增删改
第二条SKU的英文全称错了:SKU: stock keeping unit
感谢纠正 ➡
您好,请教个问题;
像分类排序这种,采用手输 数字 的形式,如果输入的数字和其他分类的数字一样,怎么处理?在输入的数字的时候,给限制?
或者有其他比较好的方法吗?
谢谢
在处理分类的时候,一般是会有两种类型:
1、如果分类的数量较多时,比如你提到的分类排序,可以选择限制录入的数字不允许重复或者说不限制录入的数字是否重复,数字相同时可以按照创建时间再进行排序,可以看下实际的业务对于排序的要求度。
2、如果数量较少的情况,比如需要对几个活动顺序进行排序,可以直接在列表增加排序按钮,采用上移下移来展示,这个的优点是方便运营可以直观的看到各个活动的排序情况,缺点是只适用于数量少时,数量多时不方便处理。
多谢分析🙏
能分享下原型吗 😐
原型是我针对此次的文章单独整理的,只有页面上展示的这部分原型哦