继续创造,加速生长!这是我参加「日新计划 10 月更文挑战」的第13天,点击检查活动详情
谈谈电商体系中的产品模块规划
电商体系基本是开发者接触的最多的体系了,关于一个电商体系,产品模块显然是其中心功用,产品模块规划的好坏直接决定后续的开发进度和维护本钱。
sku与spu
sku
和 spu
是用来描绘产品的结构,所以咱们想要规划一个好的产品模块需求先了解这两个概念
spu
SPU = Standard Product Unit (标准化产品单元)
-
SPU
是产品信息聚合的最小单位,是一组可复用、易检索的标准化信息的调集,该调集描绘了一个产品的特性。即产品单元。
文言:你发工资了,想整台 iphone 11
,这个时分 iphone 11
便是 spu
,是一组可复用、易检索的标准化信息的调集, iphone 11
就包含了 内存、颜色、版别,等信息,是他们的这些可复用信息的调集。 spu
便是某个产品,可是咱们去购买产品,是需求具体的标准特点的,咱们真正购买的 库存单元-sku
sku
SKU = Stock Keeping Unit (库存量单位)
-
SKU
即库存进出计量的单位, 能够是以件、盒、托盘等为单位。 -
SKU
是物理上不可分割的最小存货单元。在使用时要依据不同业态,不同管理模式来处理。
文言:上面咱们提到要整一个 iphone 11
,可是吧,咱们去商店购买的时分营业员肯定是会问咱们需求一个啥样的 iphone 11
?啥颜色?啥内存?啥版别? 红色-128G-国行
能够形容一个具体的产品,这些特点的组合便是咱们的 sku
,咱们最终购买也是 sku
,商家去进货也是进具体的样式,所以咱们的库存是跟 sku
挂钩的,而不是直接和产品挂钩。
产品根底数据库相关规划
咱们需求将上面的概念抽象进行数据库规划。咱们是需求将以下的关联数据存储到数据库
基于以上规则,咱们规划产品的根底数据表
表说明
- product 产品根底表
keyword 用于做查找的关键词
warning_stock 用于做库存预警
- product_sku 产品sku表
咱们采用 data
字段以 json
格局进行存储,存储格局能够为
[
["id" => 1, "value" => "套餐一"],
["id" => 2, "value" => "土豪金"],
["id" => 3, "value" => "256G"],
]
像以前咱们会用一个独自的 varchar
字段,特点值以某种契合进行衔接处理,例如:1_2_3
, 标识 套餐一 土豪金 256G
,关于 json
格局的存储这种缺点也清楚明了,有时分不需求一味地追求数据库规划范式,特别是 Mysql
参加 JSON
支持之后,只要不涉及到查找查询的都能够往 JSON
字段里丢。
- product_detail 产品详情
产品的详情属于存储字符比较多,所以独自处理,也能够使用这个表扩展相关产品描绘字段
- product_spec 产品标准表
- product_spec_item 产品特点表
如何依据事务做出适宜的产品模块?
上面数据表仅仅规划的最根底的产品的存储,假如咱们要规划出好的模块,先要确认几个点:
- 渠道仍是自营
- 现在和未来运营的类目是标品仍是非标品
- 公司运营的产品种类
- 是否有分仓发货事务,库存是否要绑定
电商自营和电商渠道的区别
电商自营,意味着所有的 item
和 sku
都是由己方的运营操控,供货商也稳定为自营的一家,所以从惯例意义上来说,电商渠道一定需求 SPU
的模块,而自营电商不一定需求 SPU
模块,例如某东。
SPU
主要是用来处理相同产品多 item
的标准和描绘信息一致的问题,而且方便运营做整个渠道的产品管理。后期的实践事务中,假如渠道运营走的是相似天猫这样对商家操控比较严厉的路子,商家在进行产品管理,也需求对产品可操作的 SPU
进行授权管理,以及分润比例操控。这些都是能够基于 SPU
进行的。
运营类目是标品仍是非标品
假如参加了 SPU
的模块,则需求了解运营类目是标品仍是非标品。假如是标品,则能够在 SPU
层面参加 SPU
模版,以达到进一步对商家或许发布的 SKU
的操控,确保渠道的产品可靠性。例:已知 iPhone X
只有 银色64G、银色256G、灰色64G、灰色256G这四种标准,那么渠道是能够在设置 iPhone X
的 SPU 时,直接设置好 iPhone X
下的这四个标准的特点。这样商家在创立时能够直接结用这四个特点的信息进行产品创立,标准了渠道产品的同时也达到了减少商家工作量的目的。
公司运营的产品种类
这个一般不会对 SPU
和 SKU
的结构关系造成影响,可是也是咱们前期需求考虑的点。因为不同的产品种类或许会对之后的买卖订单履约流程造成影响。扼要归纳产品种类包含如下:
- 什物产品服务(打车,团购)
- 虚拟财物(话费,游戏币)
- 信息(卡密、简历、数据)
一般电商渠道咱们常见的产品种类主要仍是什物产品和虚拟财物,而服务类产品多见于线下 O2O
项目,信息类产品大多是笔直范畴。所以假如或许涉及到多种类的产品买卖,则需求在规划 SPU
或 item
时就考虑到产品种类的设置。假如是在现有的体系根底上去新增产品类型,其实也能够通过指定后台类目产品类型的方法进行后续的订单履约事务。
是否有分仓
发货事务,库存是否要绑定相同的,这个事务也不会影响 SPU
和 SKU
的结构关系,可是在规划中也是很重要的点。假如有分仓发货事务,则需求考虑以下几个关键:
- 仓与仓之间是否具有跨仓发货的条件
导致这个问题的或许性有很多,如本钱高,距离过远则物流质量无法确保等。
假如不具有跨仓发货条件,那或许需求依据实践事务来对每个分仓设置其所配送区域规模(依据事务需求能够准确到省/市/区县/街道),再对上架 SKU
设置其在不同分仓的库存,或许自动同步库房库存。而前台则需求用户确认自己地点的城市或收货区域,以用来查询上架 SKU
的库存状况,确认是否能参加购物车或是下单。
- 是否有产品具有特殊的配送规模
比方,分仓惯例产品能够配送北上广。可是澳洲龙虾的生命力不如波士顿龙虾,只能在分仓同城配送。这种状况下,配送规模就不能跟着库房走,而应该跟着产品走。产品能够默认配送规模便是分仓的配送规模,可是也能够完全自定义。
- 实践运营事务中针对分仓的产品售卖是否会有价格差异。
比方波士顿龙虾的货物到岗清关是在上海,而针对波龙的出售除了江浙沪外,还有珠三角的事务,这时分需求将在上海清关的波龙在通过冷链干线运送到珠三角的水产仓/放养池。
那这部分珠三角和长三角的本钱差异天然也会提现在最终售价里,然后变为相同的 SKU
因为出售城市的不同售价不同的状况。假如出现这种状况,而运营又对精细化操控有要求的话,或许 SKU
的售价操控,就需求准确到市了。
咱们展现产品是展现sku仍是spu?
咱们能够看到京东或许淘宝的产品,京东和淘宝的展现的产品还不太相同,他们的展现方法都有不同的原因,咱们来分析一下:
- 第一点:京东的产品以展现单品为主,而淘宝以展现店肆为主。
- 第二点:京东前台以
SKU
为主,淘宝前台是以SPU
为主。 - 第三点:京东标题讲究精准查找,淘宝标题则更多人挑选的是关键词堆积用满30个字
所以咱们需求展现 sku
仍是 spu
,能够依据咱们产品的方向进行挑选,不必盲目的进行仿照。