前言

电商商品系统，是电商基础系统之一，承载了商品在电商系统中的生命周期管理。本篇我们来简单拆解一下电商商品系统应该有哪些模块。

整体概述

一个商品如何从出现在电商系统里，然后能够让用户看到并下单？

电商交易过程

而这些都需要起源于一个信息的录入。此时信息的录入包含几个关键点：商品信息、价格信息、库存信息等。对于一些商家系统来说，库存和价格是直接在商品输入的时候会有一个录入。而对于一些系统来说，可能会分的更加的精细。商品系统只负责商品信息的管理，价格由专门的价格系统管理，而库存则是在采购入库上架后进行更新，此时会有至少三个系统来负责管理商品、价格和库存。

我们本篇主要说明的是商品信息管理系统。先来上图。商品系统需要实现数据生产，数据治理和数据应用。

数据生产：满足多角色，多场景，多业务的数据生产要求；

数据治理：对生产的数据进行规范，必要的时候用下架、删除、商家扣分等方式去解决；

数据应用：将生产的商品数据以服务形式对外输出，让需要的流程能获取商品信息；

商品系统功能拆解

数据生产

一个完整的商品信息需要包含什么数据？先来个大致概览。

商品字段信息

其中蓝色底标示的是商家品需要相较于自营品多填写的内容。

决定商品信息的因素有什么？

（1）商品本身的属性信息，就像冰箱要写能耗，空调要写匹数这些基本信息；

（2）商品的经营信息，比如是不是支持价保，支持7天无理由退换货等；

（3）对服务方的支持信息。商品系统要服务很多系统，要考虑下游的服务系统，比如物流运输需要考虑这个商品是不是危险品，是不是易碎品。

而这些决定信息中，商品本身的属性，依赖于类目的选择。所以目前很多商品创建的时候都需要先选择类目，然后由类目来决定商品需要填写的字段。此时就需要单独维护一套属性，然后将属性和类目做关联。如果属性比较多，可以将不同的属性打包成一个属性组。此时简单说明一下属性和属性值的区别。

属性：颜色

属性值：红色

而电商的类目一般分为前台类目和后台类目。后台类目是依据商品的基本特征为分类原则，一般为3～5级；前台分类一般只做展示用，可以随时根据最近的经营分类进行调整，通过与后台分类的对应关系关联到商品。其对应关系如下。

分类和商品对照关系

而这些属性中，又有一种特殊的属性，销售规格，这些将同一spu下的多个sku区别开来。此时来强调一下spu和sku的概念。

SPU = Standard Product Unit （标准化产品单元），是商品信息聚合的最小单位，是一组可复用、易检索的标准化信息的集合。

SKU=stock keeping unit(库存量单位)，库存保有单位或者说库存进出计量的单位。

说到spu和sku，不得不提到的是淘宝和京东对于spu和sku的定位。首先来说两家定位并没有本质的区别，区别在于京东把部分属性做到了sku维度，而淘宝则是把除销售规格外的所有属性都做到了spu维度。另外就是在搜索和详情展示方向也有差异，京东会默认一个sku展示，淘宝则不会默认指定到sku，而是默认展示的spu。两者都各有利弊，没有比对方有明显的优势。比如京东会有一个明显的切换时的刷新，而淘宝则是sku作弊非常严重，许多百货类商家会填写一个不存在的规则写下很便宜的价格吸引用户点击。如果新搭建一个商品系统建议还是先选择京东模式，因为在初期，基本没有太多的人力去做商品治理，如果采用淘宝的模式会比较危险。

京东的属性有spu和sku的区别 淘宝则是做到spu维度

而除了sku和spu的概念，目前还有标品和非标品的概念。现在各大电商也在努力打造标品库。此时再引入一些概念：

UPC最早大规模应用的条码，其特性是一种长度固定、连续性的条码，目前主要在美国和加拿大使用；

EAN：主要EAN码是国际物品编码协会制定的一种商品用条码，通用于全世界。因为我国的前两位是69，所以有时候也会称之为69码；

ISBN码：国际标准书号，是专门为识别图书等文献而设计的国际编号；

那标品是一定会拥有这样的编码。那之所以打造标品库，主要还是目前各大平台商品非常多，打造标品库能更好的应用。在标品库里存储的信息不包含商品的经营信息，都是其出厂携带信息。

除了类目之外，还有一个品牌的概念。品牌和类目是可以没有强绑定关系的，作为一个基础数据而存在。

基于以上信息，我们就需要有以下功能：

商品生产需要功能

还有个扩展小知识：商品除了直接利用表单进行录入外，还可以对接一些三方服务商直接导入，比如爱铺货，此时就需要商品系统能对外提供开放接口进行商品的导入。

数据治理

数据在生产完成后，需要对数据进行治理。

那对于自营平台，商品增速比较慢，可以由商品管理部进行审核，审核的依据可以根据商品的包装图进行审核。但对于有商家的平台型电商，商品增速则很快，依赖人来做审核显然是一个成本不高的方式。此时可以采用先发布后校验的方式或者先检验后发布的形式都可以，利用系统的校验规则对商品数据进行规范。

一.状态控制

商品可以通过“发布状态”和“上下架状态”两个字段来控制其展示。

发布状态根据商品信息在系统中的流转状态来控制，可以有 “新建-待审核-已审核-归档”的状态等，其中下市的商品可以置于归档的位置，不在进行销售；

而上下架状态指是否在前台展示，发布状态也会影响上下架状态。

二.敏感词系统。

敏感词系统可以采用三方服务+自有词库两种方式来实现成本和安全的平衡。采用三方服务的时候直接和服务商去了解使用方式即可，在做自有词库的时候考虑2个概念：敏感词以及敏感词白名单语意。

举个例子：王牌是规定的敏感词，但是出现在语意“《王牌对王牌》节目”中就是一个白名单语意，允许其出现。另外由于我们的商品中还有很多图片中也是带有文字的，也是需要进行敏感词的校验的。

三.数据规范治理

除了依据敏感词系统进行商品的校验，商品还有其它现象需要关注并治理。

1. 品牌不一致：名称中的品牌和实际参数中的品牌不一致；

2. 重复铺货：商家为了抢占流量，将同一商品创建多个，这对平台流量分发是一个问题；

3.sku作弊：做一个价格低但是不存在的sku，通过列表的低价格吸引用户点击。

4.品类错放：将不属于此品类的商品放到其它流量比较高的品类。

我们需要不断关注平台的商品问题，并针对问题不断优化系统鉴别策略，还需要辅助人工校验，再通过下架、删除，结合店铺评分工具对商家行为进行规范。

数据应用

商品数据应用于电商系统中的方方面面，从用户侧来说，主要是获取商品信息，从业务侧来说，是根据商品信息去更好的做经营管理。在做商品系统的时候，需要了解公司的经营模式，并规划好系统都需要提供哪些服务。接下来列举一些常见的商品服务功能。

商品服务

而在这些查询服务中我们需要注意区分前台服务和后台服务使用，最好做到前后端分离，保证服务的稳定。对于前台服务，需要注意调用方的流量情况，而对于后台系统，要注意批量调用。另外，除了通过接口的实时调用，后台服务还有对于数据存储的需求，比如搜索和大数据，需要将数据通过一定方式传输给其系统，比如MQ的方式，而不是完全通过调用方式来实现。

此处仅展示搜索结果页的分类查询项，根据搜索词匹配分类，并比对分类的属性及属性值进行展示。

而除了查询和分发服务外，我们还需要依据《电子商务法》要求： 电子商务平台经营者应当记录、保存平台上发布的商品和服务信息、交易信息，并确保信息的完整性、保密性、可用性。商品和服务信息、交易信息保存时间自交易完成之日起不少于三年；

作为平台方，需要保存交易快照。交易快照可以通过对数据的变更历史记录存储，通过交易时间比对历史的记录的时间来实现。

结语

本篇仅简单的对商品系统进行了拆解，后续待认知更清楚之后再与大家进行详细的分享讨论。