商品是电商系统中最重要的业务模型，某种程度上说，电商就是围绕于商品进行的，不管在电商供应链、电商营销、还是推荐，商品都有其非常重要的地位。
本文将为你介绍在电商系统中如何从概念到应用搭建一套商品及类目体系，进而完善整个商品系统。
什么是商品？
在电商系统这个语境之下，商品是一堆相同业务属性的集合，这种属性集合映射的是现实中的实物，我们通过建模将现实中的物品抽象，形成一个数字化的商品概念，在交易流程中通过商品进行串联。
刚才说了电商系统中的商品是对于现实世界中实物的数字化抽象，那么我们先了解下现实中一个实物物品的交付流程。
上图简单展示了一个通用商品在真实世界流通过程。
那么再看下一个商品在电商系统上的流通过程是什么样的。
围绕于商品的流转主要有两个链路，一个是围绕于商品的售卖的交易链路，一个是围绕于商品供给与调配的供给链路。针对于这两个链路上商品流转的模型是有比较大的区别的，因为所承载的核心属性与信息不同，所以我们抽象出了两个模型，一个是商品模型服务于交易链路，一个是货品模型服务于供给链路，为实现扩展性，我们引入了属性、类目的概念，后续的很多设计其实是围绕于如何搞好属性和类目来的。
通用的商品模型包括商品、SPU、SKU，关系与结构如下：
SKU
商品模型中通过SKU和库存实现了线上商品和线下实物商品的对应，每个商品对应一个线下商品、每个商品可以有多重颜色、尺码、款式等销售属性，也就是SKU。
很多人对于产品和商品比较混淆，举个例子，我们买手机，比如小米11是一款产品，但是不同颜色的小米11就是一个个商品，SPU是产品主要属性的集合，SKU是销售主要的商品属性。
SKU一般称为库存单位，也就是对于库存进出计量的单位，可以以件、盒等度量单位售卖。
SPU
在设计商品模型时，除了SKU之外还有一个非常重要的概念就是类目。比如服装属于一级类目，男装/女装属于二级类目，类目可以方便我们对于庞杂的商品信息进行组织和维护。回到手机那个例子，手机有多个品牌，我们是否可以在手机类目下再区分什么小米类目、华为类目、苹果类目吗？显然不需要，不然类目的维护就会异常冗余与复杂，所以我们一般会提出一个SPU的概念，实现对商品约束进一步的细化，以平衡一些需求。
SPU一般称为标准产品单元，实现对某一类标准产品的共同特征属性收敛描述，是对商品信息共有属性的一种提取，SPU一般是由后台类目+一组关键属性唯一确定的。
所以SPU是介于类目叶子节点和商品之间的概念，是对于类目属性的细化，也是实现对商品标准化运营的基础。
比如在一些电商系统中，相似推荐功能的实现就是基于用户购物车中的SPU的关联商品实现的。
还有一些比价网站，其比较的核心就是围绕于SPU进行比价。
CSPU
CSPU是淘宝提出的一个概念，C是Child的意思，就是标准化产品子单元，是对SPU的细分，实现更细粒度的产品标识。
叶子类目+关键属性+销售属性是确定一个细粒度CSPU的关键。
比如手机类目下，品牌、型号这两个属性可以确定一个SPU，但是不是一个CSPU，需要额外增加一个销售属性来确定，比如颜色、存储大小。
我们一般通过SPU和CSPU对商家发布的商品进行强管控，同时对于商家的SPU和CSPU属性进行填充实现对于基础属性和基础属性值库的丰富，在运营审核过程中，将这些基础属性添加到标准属性和对应的类目属性下。
刚才我们聊得是商品模型，同时也多次提到了类目体系，类目是商品的坐标，通过类目定位到具体的商品。
什么是类目
类目是商品所属的分类，类目决定了商品的归属，类目有层次之分，一级类目、二级类目等，类目之间有集成关系，一般以树的形式展示，最下一层类目是叶子类目，只有叶子类目下可以挂商品。
一般我们会对类目进一步划分，分成前台类目和后台类目。前台类目主要是给用户展示的，便于选品，后台类目主要是给商家用的，便于管理商品。
后台类目
后台类目主要关注于管理的标准化，后台类目一般是商品实际归属的类目，商家在发布商品时，将商品发布到指定的后台类目下，在淘宝中类目最多分成4层，类目层级太深会影响商家商品发布的体验。
前台类目
前台类目专注于导航、导购、推荐、营销、搜索等，目的是帮助用户快速选择商品，或是进行营销推荐。前台类目中保存的实际是对后台类目、属性的筛选条件，也就是通过前台类目会触发相关后台类目与属性的查询聚合，如果前台类目过长会导致转化率下降，一般来说前台类目不超过3层。
类目属性
类目属性是类目下的商品所具有的共同特征定义，关联了叶子类目和属性，比如手机类目有品牌、型号、颜色、网络属性等。相对应的还有类目属性值，用来表示类目下商品所具有的某一特性的值。
属性用于描述商品，便于对商品更好的描述，对类目属性进一步分层抽象，就形成了类目属性分类，比如关键属性、绑定属性、销售属性、商品属性等。
其实在商品管理体系中，类目与属性的建设是非常重要的，商品系统复杂也就体现在这里，属性用于描述商品本身，但是只有属性还不具有描述能力，还需要有属性值。其实属性值在商品系统里面一般会归类于元数据体系，也就是用于提供商品描述的基础数据。
我们通过一幅图了解下属性库建设的必要性：
在大型电商系统中，属性库数量级别都是百亿级的，那么这么多属性是怎么录入的呢？
靠人工录入显然不现实，对于平台型电商来说，属性库的数据一般来源于几个行业标准化协会，比如服装标准化委员会、家电标准化委员会、剩下的一些才靠人工录入。
如果商家录入了一个属性库不存在的属性，就会触发审核机制，审核通过后，就变成了属性库的一员了。
标准属性和基础属性
属性库分为标准属性库和基础属性库，是两套数据表，基础属性库和属性值来自于商家发布商品时录入，类目运营通过人工审核、机器审核等方式，把部分属性添加到标准属性库里。
所以标准属性库是经过审核的，类目上可以直接使用。而基础属性库则来自于商家在发布商品和SPU时录入的。经过运营审核、机器审核、清洗数据等流程后，基础属性数据会流入到标准属性库中，变为整个平台属性库的扩充，其他商家再录入商品时，就可以直接选择使用了，实现了属性的复用。
如何维护属性
属性库维护不是简单的k-v那么简单，还需要很多规则进行约束。比如有的属性是可枚举的，有的只能输入了，比如产地。但如果重叠了，可以通过枚举方式表示。一般来说，属性可以分为枚举、枚举可输入、可输入三种，某些复杂的类目下还有属性模板的定义，用于某些无法提取枚举的子属性填充。
部分属性还有子属性的概念，比如一些品牌还有自己的系列，这些系列就隶属于这个品牌属性。如果单纯通过笛卡尔积标识，在发布商品时就会出现太多的属性值并列，无法筛选的情况，引入多级属性可以解决这个问题。
上面的很多概念还是围绕于商品的交易链路展开的，那么商品的供给链路是什么样的呢？
前台商品与后台商品
之前提到过类目分为前台类目和后台类目，很多电商系统同时会将商品进一步分为前台商品和后台商品。
前台商品关注于销售链路，包括交易、订单等，后台商品关注于供应链，包括仓库、采购等。
比如空调本身分为室内主机和外机，内机和外机在仓库本身是分开的。所以我们可以将前台商品售卖的空调和后台商品的内机、外机关联起来，在最后计算库存时，使用的是内机库存和外机库存。
组合商品
在商品售卖时，我们经常会遇到很多商品组合促销的情况，类似于手机套餐，包含短信、流量、电话流量等。
基于全文我们对于电商系统中商品模型进行了简单的拆解，商品模型主要包含商品、类目、属性库。在电商系统中我们抽象商品模型的目的在于解决标准化问题和导购营销问题，这些扩展需求都离不开对于商品模型友好的设计。
其实商品本身是非常复杂的一个电商子域，还有很多内容没有展开，比如非标品商品、虚拟商品、商品库存、商品知识图谱、甚至商品系统的架构等。那么我们如何破解这么复杂的一套系统模型呢？
简单来说就是回归简单，寻找那些本质的要素，进行组合和包装，商品模型本质上是反映的真实世界中商品的交付，掌握了对于模型的抽象与组织，就可以轻松应对上层的业务变化。
京公网安备 11010802041100号 | 京ICP备19059560号-4 | PHP1.CN 第一PHP社区 版权所有 