商品spu是什么意思-商品sku和spu的区别

编辑导语：SPU和SKU是电商后台和ERP后台的重要单元。SPU即标准化产品单元，SKU即最小库存单元。而电商后台系统设计与ERP系统设计有所不同，单纯地借助电商后台管理系统设计，将| K N x g `导致ERP设计上有所误差。本文作者结合其工作经验对ERP系统设计中的SPU和SKU设置进行阐述，一起来看一下。

一、SPU和{ c ZSKU的关系

关于SPU和SKU的基础概念. @ # j &的了解，建议大家还是看看一些关于电商的书籍介绍，在此我\ # t g a S Z : 1就不做过多的整理，直接从《电商产品经理兵法：基于SaaS的电商系统设& 3 L g # F q计与实% – R w s K践》此书中搬运一些基础概念过来。

1. 什么是SPU？

SPU即标准化产品单元，是一组可复用、易检索I @ } % ( $ c X y的标准化信息的集合。该集合描述了一个“产品”的特性。\ ^ \ L G M v ^ b

通俗来说，属性值、特性相同的商品就可以称为一个SPU。也可以说，SPU是一个抽象出来的模板。

一般来说，类目系统中的关键属性（品牌、货号等）能够确定一个SPU，例如，iPhone 6就是一个SPU，诺基亚N97也是一个SPU，这与商家无关，与颜色、款式、套餐也无关。

SPU的属性是分类属性的子集。只要用户在SPU中定义了l M t A . [属性，那么用户在录入商品时，就不( & U # j /需要再次录入，也不可以更改。

摘自《电商产品经理兵法：基于t I XSaaS的电商系统设计与实践》

2. 什么是SKU？

SKU即单品/最小Z [ a @ Q 4 [库存单元。目前，SKU在各M { _ A ) g . +种零售商品中应用得非常普遍。例如，某款衣服是一件w ( # ~ g : 9 =商品，不同颜色、不同* 9 S Q I 0 : R A尺码的该款衣服，对应不同的SKU。SKU比较简单，就是把销$ N ` X 2 W ?售的值组合存放，再加上库存、价格。例如，该款r e |衣服的黑色大号共有5件，每件20元；红色小号共有3件，每件21元。

摘自《电商产品经& E } u 3 w理兵法：基于SaaS的电商系统设计与实践》

3. 电商后台0 f # F e ` `与ERP的商品管理差别

电商H $ +后台往往不会直接有SKU层面的管理，都是在「商品管理」中处理，也就是在SPU层面来管理。主要涉及的操作有商品发布B ~ Z c + q B、编辑/修改、商品上/下架、提交商品审核等。

而ERP中，往往是在SKU层面进行管理的，例如发起g 0 e 8 } k采购、创建订单、查看库存、出入库单据等，都是关联的SPU。

所以在设计E– * ^ 7 8RP的商品管理功能的时候，如果只是单纯地参考电商后^ s 2 ^ a – F L 1台的管理，很容易踩坑，也很不太能理解背后是怎么运作、怎么管理的。

前段时间我W T Q刚好在调研这一块的业6 h W o h u 0 g务，既调研了电商后台商品管理的一些逻辑，也上手试用了好几款ERP的商品管理，有一些疑惑已经解开，同时也有一些踩下的坑v h j 9 ! 9 @让我记忆犹新。

所以此文就来谈谈前段时间我是怎么被SPU和SKUV 7 y E s g z +这两个东西折磨的，还有踩过的坑分别有哪些。

二、SPU删除规格之后怎么处理？

基于电商后台的规则，SKU是通过SPU的多规格来生成的，例如在创建SPU的时候，选择不同的规格，然后不同的规格就会通过笛卡尔乘积，生成不同的SKU。

在梳理8 | d l ; L T这一块的逻辑的时候我就发现了一个l E P g O w w问题：如果一个SPU的规格属性有两种「颜色」和「尺码」，然后在「颜色」中有“红色”、“蓝色\ * c J b v * | B”，在「尺码」中有“S”和“M”，则意味着一共是会生成四个SKU。

但是如果允许后期修改规格（修改规格属性或者修改规格值）的, b N a – z v q内容的话，会重新生成SKU，同时老的SKU在这里就无法体现了（因为规格不存在或者属性不存在）。

例如{ ^ 7 v U : v /下图，如果将“蓝色”改@ * = |成“绿色”，那么应该i L T重新生成SKU，但是原来的“蓝色”规格的SKU就“消失”了。还有如果一S A P s *些创建商品的时, 4 P候没有选择规格，然后只是生成了一个SKU，后续如果要增加规格的时候，那么原来的商品也不能和后续多规格衍生的SKU形成相同的结构（规格结构不一样）。

如果Q 6 Z rSKU编码BS和H * s o YBM是在库的、有库存的，那么直接删除这两个SKU显然是{ O { ; U A !不合理的，但是由于电商的管理应该大多数是基于SPU层面，所以如果修改了规格属性（电商也叫销B d ( ^ W { ; d售属性），那么被更改了的那个应该不能再出现了，类似于此款停G ^ & t Y F产或者不再售卖了。

下图是淘宝的千牛后台，发布商品的时候先选择对应的类目后，会给出对应的销售属性，而且是都必填，所以不存在中途增y $ a加和修改销售规格的情况出现。

但是ERP系统就不会有这么严谨的x z 4 d B w p逻辑，而且也没有对应的类目信息。

所以这一块如果限制死了，不允许客户添加规格，那么就可能会满足不了一些多规格的商品的信息维护；如果放开了限制，那么用户就可以随意调整对应的规格信息，那么生成的SK+ S w i +U可能就会和原SPU断开关联。

千牛后台截图

基v J M W ` .于上述的情况，我查了很多资料，也问了一些朋友之后发现，如果是单纯地参考电商平台的后台处理逻辑，那么很难兼容各行各业的商家的产品N Q $ d。

于是我开始找了另一类竞品：电商l \ ^ / j (ERP，主要还是= ? ]跨境类的，例如店小秘、马帮、? 4 ^ g 3 r n )通途等。

结果发现它们的处理方式很巧妙，在创建商品的时候可以选择类型：

• 单规格产品，也可以称为无规格产品；
• 多规格产品，可以自由添加规格进行变换。

单规格产品不能转为多规格H y j ^ b $ o s，如果需要增加规格，则需要重新创建SPU再生成SKU；多规格产品也不能转为单规格产品S ] n (，多规格产品一定y c ` / [ K E要选择至少一项规格属性。这样一分类，就将很多复杂的场景给隔离开了，只需要重点关{ l r i O f注多规格产品的管理即可。

三、无规格的产品怎么创建SKU？

在没有仔细地调研跨境ERP的做E + 2法的时候，关于无规格的产品怎么创建SKU的问题，我们内部讨论了两种方案。

1. 直接创建SPU的时候，不填写规Z k 6格信息，当没有规格信息的时候，0 o * ( A A默认SPU对应一个SKU，即一对` = Q – q 2 a一的关系b V 5 7；
2. 创建SPU的时候，填写一个规格，例如衣服就只有一个型号「白色t d C p 7的中码」，那么就是创建一j . ^ \ { ` n +个规格「White*M」。

后来调研了跨境ERP的做法之后，我发现这两种做法都不好，具体的理由和上面的是一样的。如果! 4 E F当前只有一个规格，后期多了规格需要拓展的时候，在此商品SPU的基础上拓展SKU，还是会踩坑。例如删除了“白色”这个规格，然后用了其他颜色，也删除了“M”这个尺码，那么之前的「White*M」就挂不在SPH U ; FU之下了。

所以我决定采用跨境ERP的做法，在创建SKU的时候要# ; & Q p ?先选择类型，到底是单规格产品还是多规格产品。如果是单规格产品，那么直接就{ 6 , t U M {生成SKt p 8 k ) CU，不能拓展所谓的规格属性；如果是多规格产品，则先生成& = j D d 5 2 `父级SPU，然后再通过多规格属性来拓展生成具体的SKU。

而且多规格* ? { H U # b 1的产品，不能添加&删除C ! r U 4原来的规格属性，只能追加对应的属性值。

例如一开始的规格属性是「颜色」和「尺码」，后续编辑的时候，只能继续追加「颜色」的属性值，或者追加「尺码」的属性值，而不能再删除「颜色」或者添加新的其他规格属性。同时也要限制不允许随意删除已生成的SKU（例如上面提到的BM和BS），要先判断SKU是否已被使用。

有赞后台截图

所以，最终我所选择的方案是：无规格的产品直接创建j } n L 4一个单品SKU，不需要和SPU关联；而有规格的产品则U X x \ i Z v先创建SPU之后，再通过规格来创建SKU。

当) u R x F (然还有更简单的办法就. P g $ n Q .是，ERP中不存在SPU的概念，直接全部创建的都k : % v Z @ u是SKU，用映射的方式来将电商平台的SPU下的SKU映射到系统中q 5 s。这种逻辑是最简单粗暴的，利弊都很明显，只是我们要支持的业务场景，不允许这样做……

四、供应商F o ) A w d ? –与SPU&SKU的关系

供应商是与SPU关联还是和SKU关联，这个也是J | 0 _ % h U我之前E ; O b q . Y一直很( ` 6 c纠结的一个问题。按理说，供应商提供的是具体的产品，那么自然而然应该是跟SKU关联。

但是有一部分的SKU是通过SPU的多规格属性演K ? ~化Q # C $ N而来的，如果供应商直接和SKU关联，那么则意味着创建好了SKU之后，还需要分别对同SPU但是不同SKU的产品一一设置供应商关系、供应商报价等。

从操作层面来说，用户要做多次重复的工作；从设计层面来说，有很多可复用的属性没有复用到……

创建多规格产品（SKU）的时候，将供应商信息挂在SPU维度上S ` v U，然后SKU继承这些信息，就避免了逐个SKU维护供应商的繁琐操作。^ 2 2 ; v ~ V

如果是创建单规格产品（B @ X p 5 T f F +SKU）的时候，将供应V r *商信息直接挂在SKU维度上，一个– T /SKU就维护一次。

通途ERP截图

通途ERP也是这样的做法，比较清晰明了。

五、SKU如何编辑？可以编辑哪些信息？

上面提到了，我们创建了SKU的时K + u } b v ^ 2候有两个入口，一个是创建单规格产y ) ( 5 s 0 O 3品，一个是创建多规格产品。所以对应的，我们编辑SKU的入口也有两个，一个是从SPU层面进入编辑，另外一个是从SKU的层面进入编辑。

期初我一直觉得既然创建好了SKU，那, R d么其实在ERP中，SPU基本上就没啥作用了，所以编辑只需要在SKU层面即可。

但是随着对业务的分析，以及对SPU和SKU的关系的进一步熟悉，我发现如果只是在SKU层编辑就会出现一些/ G ( L ) , ! w很奇怪的问题。

例如「iPhone 12 国行」可以算作是一个SPU，然后! S ` t B c“iPhF ^ Qone 12 国行 红色] \ f ) s @ 6 d 64G”（简称为：红色64G）和“iPhone 12 国( R \ $ !行 白色 128G”（简称为：白色128G）则是其所对应的SKU。

如果我将所有的编辑都z ^ Y放在SKU层面，那么我自然而然可以编辑一些“基础信息”、“非关键属性”、“销售信息”等。

如果只是编辑“销售信息”那么还没什么问题，因为不同的SL ^ y K 3KU就是因为销售属性不一样而做的区分。但是如果允许编辑一些“基础信息”，例如说“名称”、“描述”、“类目”等，那么可以将“iPhone 12 国行 红色 6x # %4G”改成“苹果12 中. J . , = 4 2 V国红 64G”，也可以改成“苹果11 白色 64G”等等，这样就会乱套了。

所以，SKU的编辑应该遵循和创建的逻辑相同，z \ 1 & S 1也要符合SPU和SKU的关系的定义。有两个入口创建，也就有两个入口编辑。同时，不同的入口可以编辑的信息是不一样的。

SPU维度编辑的“基础信息”等应该是复用在所有的SKU层面的，即改了SPU的信息则SKU的信息也要改；SKU维度的编辑，只能是一些自己独立的属性，例如“售价”、“库存信息”、“采购价格”等\ O o $ 2 W F。[ P o P ]

千牛后台截– Y . `图

六、一些参d | u D考资料

最V r ! p后分享F v \ ~ / D = q一些相关参考资料给大家，如果大家对电商后台或者ERP后台感兴趣的，可以根据下面的关键词进行搜索。有一些后台账号是需要申请5 [ a T w y试用的，找个小号去申请比较好，能避免后续很多的骚扰。

• 电商后台的竞品：千牛（淘宝商家后台）、刘志远——电商后台产品设计课程、相关图书（京东）、有赞。
• ERP的竞品：店小秘、马帮、金蝶星辰、聚水潭。

#专栏作家#

vitamin，微信公众号：皮酱叨逼叨。人人D D M * r (都是产品经理专栏作家，公众号运营小白，初+ ^ O |中级B端产品一枚（一年开发经验+三年产品经验）。主导过在线教育类产品，目前是跨境电商供应链仓储物流产品一^ : w } t c $ 4枚，欢迎勾搭，一同学习。