电商系统 | 后台设计 | 电商商品管理踩坑集合
这篇文章先普及一些商品常用名词,后面讲一下作者在商品设计中踩过的坑,欢迎大家一起讨论。
商品作为电商系统中的最小组织单元,像砖瓦一样撑起了整个电商系统。商品也是连接前端用户、(中端平台)、后端商家、末端仓库的关键桥梁。所以,商品的设计直接影响了整个商城的效率与
这篇文章先普及一些商品常用名词,后面讲一下我在商品设计中踩过的坑,欢迎大家一起讨论。
一、商品相关常用名词
SPU(Standard Product Unit,标准化产品单元),是商品信息聚合的最小单位,是一组可复用、易检索的标准化信息的集合,该集合描述了一个产品的特性。通俗点讲,属性值、特性相同的商品就可以称为一个SPU。
如:<iPhoneX>便是一个SPU。
SKU(Stock Keeping Unit,库存量单位),即库存进出计量的单位,可以是以件,盒,托盘等为单位。是能够识别唯一单品的最小单元,通常是各项属性的选择后组成的唯一结果。
如:<iPhoneX 深空灰色 全网通64G>便是一个SKU。
- UPC(Universal Poduct Code,商品通用条码),UPC可作为商品的唯一识别码,一个SKU会对应一个UPC编码。UPC通常用做仓库捡货的唯一标识。
- 类目/分类:商品的分类、类别。每个平台根据平台特点不同,会有独特的分类标准。通常一个商品仅隶属一个类目。如:iPhoneX这件商品,分类可以是:手机数码-苹果-iPhone X,也可以是手机-智能手机-iPhone X。
- 属性&属性值:一件商品所包含的特点,属性&属性值根据平台特点不同,维度及描述也不尽相同。
如:iPhone X这件商品,内存大小便是一个属性,64G、128G、256G便是一个属性值。
一般来说,一件商品会有多种属性,对应到多个属性值。每个平台不同,所分的属性及对标属性值也有所差异。
每件商品从工厂生产到销售给电商消费者,一般会经过:产品设计→工厂生产→交付商城→用户购买等过程,根据这个流程,如果只展示SKU、UPC、分类等信息,是不是会把你看懵?是的,除了这些基础信息外,还需要更多的描述性信息,这部分比较简单好理解,直接上图:
大家对哪块有兴趣可以在文章后留言,我们逐一探讨。
二、商品管理的后台设计
后台设计大同小异,无非增删改查几个基本功能,有兴趣的话可以作部分探讨。但是在电商系统设计里,需要更加注意几(cai)个(guo)问(de)题(keng):
1.数据唯一性(需要根据平台或店铺特点定制):
包括但不仅限于:货号及UPC的全平台唯一、属性值的唯一性、类目值的唯一归属等等。
2.数据之间的调用关系:
商品是整个电商的最底层逻辑,会被各后台及系统反复调用,产品经理需要对商品的实现及各系统之间的调用要非常清楚。
三、类目管理,越早越好
常规来讲,一个商品应该对应到唯一类目。类目的建立要考虑几个问题:
- 唯一性。唯一性指的是子类目下的名称不能与其他子类目下的名称重名。如在“鞋子”类目下如果有了“运动鞋”这个类目,那么“运动鞋”便不应该出现在“运动休闲”这个类目下。否则会在进行商品统计、数据分析、用户检索时傻傻分不清。
- 排他性。排他性是指商品仅挂落到一个类目树下,不重复。(多指后台系统)
- 前台类目与后台类目分别管理。前台类目的主要功能分为两个:方便用户进行检索、引导用户转化。后台类目功能有一个:将商品作聚类管理。
通常的情况是,每天的运营目标不同,除常规分类外还会配置运营分类。这里是非严格意义上的分类,更像是灵活配置的运营模块。比如今天iPhone X在电子产品的前台分类下,明天便可以放到开学神机这个分类下,但最终商品属性的后台类目是不变的。
四、什么时候使用SKU,什么时候使用SPU?
总的一个原则:涉及到库存的部分使用SKU,涉及到展示的部分使用SPU。
举个例子:每个SPU下,会同时存在多个SU信息,如阿迪达斯小绿尾会有36、37、38、39、40码。在运营模块、搜索结果中,只需要让用户知道小绿尾这个商品即可,所以用SPU信息(即货号信息)便足够。但是涉及到购买时,有的人需要36码,有的需要40码,这时便需要使用SKU信息对最小可操作单元进行管理。
五、商品库存该如何管理?
库存是指该商品现有的数量,比如Adidas小绿尾36码有5个库存,那么可以售卖的库存数便是5。
在电商系统里,一般会存在多层库存,包括但不限于:销售库存、中转库存、实物库存、良品库存、次品库存等等。
较为简单的系统里仅有销售库存、实物库存两类,如果库存不一致时售卖便会有问题,当销售库存>实物库存时便有可能出现超卖问题!(后续会继续介绍我在超卖问题上踩过的坑)
那么,商品的库存会对用户侧有什么影响呢?——商品库存对售卖状态的影响。
- 销售库存=0时,一般为补货中或下架状态,具体如果变更状态及变更为什么状态,根据各司业务不同可自行定义。
- 销售库存>0,实物库存=0的状态,一般是预售状态。预售状态尤其要注意的是卖出库存、剩余库存的处理关系。
六、商品价格的管理?
一般讲,商品的价格系统由三部分构成:成本价、标牌价、现售价,活动期间还会有活动价格。
踩过的坑主要是在活动价这一块。随着各种抢购活动的兴起,各种电商也开始了0点开抢大战。运营手动改库存或到点儿批量改库存肯定是受不了的,所以产品常会接到一个定时改价格的需求。在改价格的功能中,踩过了一些坑拿出来分享:
1.商品参加活动引发的价格优先级
商城的活动那么多,一个商品在同一时间可以参加几个活动呢?如果参加多个活动价格该如何计算呢?
从销量角度来讲,是支持同一商品参加多场活动的;但是从复杂度来讲,限制了商品可以在同一时间段参加同一种类型的活动。比如同一件商品,可以同时参加大促、秒杀活动,但是不能参加同一时间的两场秒杀活动(不要问我为啥同一时间有两场秒杀,一切皆有可能!)。那么问题来了,A商品参加大促的价格是100元,参加秒杀的价格是200元,那么该显示哪一个价格呢?
这时便需要根据自己平台特点和规则设计价格优先级。
2.商品活动价格引发的对账问题
对账时,财务姐姐们不仅收到多少钱,还要精确到每一笔订单中的每一件商品要收多少钱。所以当商品的价格变更时一定要在报表中及时同步给对账的同学们展示清楚。
本文由 @ Löwenzahn 原创发布于人人都是产品经理。未经许可,禁止转载。
题图来自Pixabay,基于CC0协议
您好 我们目前初步打算做组合商品,其实我们目前想要的是多个SPU可以切换选择,这一块后台如何设计呢?
问一下商品有从ERP系统中导入过来的吗
有
问个问题,一个sku参加不同的活动商品的描述及价格会有所不同,在不同的终端(比如App和网页端)描述和价格都有所不同,这种Erp中怎么管理呢?
这个就跟你谈两个女朋友一样,至于怎么管理,新手肯定麻烦些,老手就得心应手了。再软件设计上,后台区分下就可以。
加油!
你好,这阵子一直在研究电商后台,感觉得到的信息比较零散,不知是否可以加微交流,我的微信:suifengma19901110
你好,我这阵子也开始做电商的前后台,尚有好多不懂的,不知是否方便加个微信请教一下呢 😐 我的微信:1185845034
可以加我的~ smilelove_
一个商品同事参加几个活动的话,时间节点一定不能在重合,要不然客户会买单,
最简单的处理方式是时间不能够重合,一件商品只能参加同一个活动。但是如果已有系统不支持或其他原因,就需要考虑各活动间的优先级问题。
通过这篇文章队将我之前对电商的一些零散的认识进行了一次归纳整理。多谢分享。还有,能写一篇电商各体系之间的数据交互的文章吗?对这一块总是理解上有问题。
后面会有这个计划。调研一下,想了解的各体系之间包含哪些内容呢?
期待继续更新哈
不错,对场景有理解的。
价格优先这块,在购物车上面显示的是最低价格,如果不限购的话,应该可以买2见,同一个价格“最低价格”
加入到购物车里的价格是唯一价格(SKU上的价格),不会存在价格区间的。价格优先级的判断是在活动间进行的判断,判断节点是在加载商品详情页前已经做完判断。
请问,最后接受,购物车的价格=SKU价格-活动优惠价格?如果这样判断,如何判断几个活动的价格(场景:该商品参加秒杀, 同事也参加了任选3件立减30元)
你的问题中我提炼几个点:
1.多个活动之间的关系:是否可以共存?
——这个需要根据自己的系统进行设置,比如我们的规则是秒杀活动与其他活动不可并存,比如商品A参加了秒杀活动,便不能参加拼团或满减活动;满减活动可以和买赠活动并存(这时便需要有优先级的判断),比如满减过后满足条件仍可参加满赠活动。具体情况需要根据平台自行设定。
2.购物车价格的计算
——购物车里的价格通常是单个sku的价格(如果此sku价格在活动中则取活动价),在订单确认页,会对整体订单(多个商品)的价格进行重新核对,活动价格也是在订单确认页面进行优惠扣减的。
希望能够帮到你~
醍醐灌顶,谢谢
有问题可以继续讨论哈~
虽然电商有一套共通的体系,但是也会根据自己的业务不同有所调整的。 😉
沙發讚
親們還沒起床嗎?
等待持续发表ing
会持续的把自己踩过的坑整理出来的~ 一起交流~