电商后台对大部分用户来说很陌生，平常几乎接触不到。后台与前端是相对的，对普通消费者来说，商家系统和平台管理系统都属于后台；对平台上的商家而言，商家系统就是后台系统；对平台来说，平台的管理系统属于后台，针对C端的APP、H5商城和针对B端的商家管理系统都属于用户端。电商后台系统，其实也不能叫做一个系统，可以称为后端支撑产品线，一些公司将其拆分为很多子系统，阿里更将其发展成了中台事业群（商品中心、搜索事业部、共享业务平台等）。后端一系列系统支撑着公司各种业务的进行和发展，当前端展示、业务处理（订单、售后）、库存变动等业务正在进行时，后端各系统间则互相调用接口进行数据更新。
年底了，最近做了个类新零售电商的数字化营销类型项目，在电商领域算是入了门，参考项目的实体拆分及所学总结，取其精华，弃其糟粕，总结一番学习到的电商业务知识。
首先是电商的几个核心领域，电商电商，第一当然是商品了。
商品中心
接触过电商的朋友都或多或少地接触一些术语，类似SKU、SPU、属性、类目等，如果你在做运营或者做开发，或者做产品，在实际工作中就会频繁被这些名词所包围。下面具体介绍一下电商的一些基本术语。
- SKU:（Stock Keeping Uint，即库存量单位），库存控制的最小可用单位。例如“iPhone 7Plus 128G银色”就是一个SKU，仓库管理、采购进货、库存管理都是以SKU为记录单元。
- SPU:（Standard Product Unit，即标准化产品单元），是一组标准化信息的集合，例如“iPhone 7 Plus”就是一个SPU。
- 类目：即分类树。电商常用的有两层类目：前台展示类目和后端商品类目。前台类目指的是展示给消费者看的类目，会根据季节、销售策略、活动进行变动；后台类目属于基础数据，不可随意变动，添加SKU时都需要选择后台类目，进行绑定。
- 属性：分为关键属性、销售属性、非关键属性。关键属性是指能够唯一确定产品的属性，是必填项，例如手机的屏幕尺寸、型号属于关键属性。销售属性是组成SKU的特殊属性，或称为“规格属性”，例如手机的“颜色”、“内存”。非关键属性指的是除关键属性、销售属性外的其他属性，如手机的手机接口类型。非关键属性不一定是非必填项，不过有时为了商品信息完整，也会设为必填项。
类目管理
如前文所说，商品类目分为两层：基础数据类目层（后台类目）、前台展示类目层（前台类目）。现在前、后台类目分离的理念已深入人心，那为什么要将前、后台类目分开管理，而不是前、后台共用一套类目呢？这就是业务驱动产品的一个实例。随着商品量的增多（京东的SKU达到数百万级，淘宝、天猫的SKU达到数亿级）、类目树的层级越来越深，一方面，如果买家直接使用后台类目，那么查找商品时将越来越难，另一方面，出于日常运营需要，运营人员在调整类目时，都需要去变更商品的类目，工作量巨大，而且随着节日、时令季节变化，运营会经常变更类目。在这样的情况下，将前、后台类目分离。后台类目面向商家或供应链人员，商品属性、销售属性及品牌等很多数据都是在基础类目上进行管理；前台类目面向用户，方便用户查找商品，还可以随着运营需要去调整。前、后台类目通过映射关联。
-
后台类目
后台类目主要面向平台商家，用于管理商品和属性。在添加和管理商品时，都是在基础数据类目层对商品进行管理。
-
前台类目
前台类目主要面向用户，方便用户筛选查找商品。前台类目可以根据运营需要，灵活多变。所以处理产品的前端类目时，就应该提供多样化的前端类目支持。
从用户渠道的纬度上讲：
（1）前台类目可支持不同客户端的设置。PC端、H5端、APP端等渠道由于用户群体有所差异，可分别设置前台类目，独立运营。例如京东的PC商城、APP、微信商城的分类就有所差异。
（2）支持平台商家自定义店铺前台类目。每个商家的产品和定位不同，有不同的类目运营需求。例如淘宝的每个店铺都可以自定义自己的前端类目。
从前台类目定义的维度上讲：
（1）前台类目对应后台类目，可一对一、一对多、多对多，自由组合，动态调整。现在大部分自营电商都是用的这种类型。
（2）前台类目直接对应品牌、商品，适合商品较少的小商家。这种情况主要是因为一些电商平台提供给平台上商家的类目服务，在添加商品时可以直接选择前台展示的类目。
（3）前台类目对应后台的叶子类目和某项属性的组合。例如分类时选择奶粉中的1段、2段、3段等属性组成类目。前台类目不同于固定的后台类目，编辑很灵活、可重叠、可删除、可随时变动，定时生效。
品牌管理
需要注意的是以下两点。
（1）新建品牌，其相关字段一般有：Logo、中文名、英文名、产地、备注、状态（可用、不可用）。
（2）将品牌关联到类目上，关系也是一对一、一对多、多对一。例如雀巢的产品有咖啡、奶粉、饮料等不同种类，这三类产品属于不同的叶子类目。
品牌关联类目的好处在于：提升发布商品的便捷性，避免出错；品牌管理标准化；在搜索筛选商品时更加快捷。当然品牌关联类目也会带来一定的管理难度。对于中小电商来说，当品牌数量并不是太多的时候，可以不做关联。
属性管理
属性是对产品性质的描述，是区分产品差异性的集合。在电商中，属性通常分为关键属性、销售属性、非关键属性、商品属性。
（1）关键属性：能够确认唯一“产品"的属性。关键属性可以是一个属性，也可以是多个属性的组合。例如：通过手机的“品牌”、“型号”两个属性组合就能确定唯一的产品，这两个就是关键属性；通过服装的“品牌”、“货号”两个属性组合能确定唯一的产品，所以这两个也是关键属性。
（2）销售属性：也称为规格属性。其是组成SKU的特殊属性，它会影响买家的购买和卖家的库存管理。例如服装的“颜色”、“套餐”和“尺码”，都是销售属性。
（3）非关键属性：除关键属性、销售属性外的其他属性。非关键属性不一定是非必填项，有时为了商品信息完整，也会被设为必填项。注意，产品的非关键属性并不包括商品属性。
（4）商品属性：表示商品的特有特征，比如新旧程度、保修方式等，不能作为产品的属性。属性的定义对于良好的消费体验有着至关重要的意义，对搜索、索引、筛选都能起到至关重要的作用。商品搜索能力，除了标题、类目，很大程度依赖于商品属性，条件筛选的基础数据也是商品属性和规格属性。完善商品属性对于实现良好用户体验至关重要。
属性包括属性名、属性值，一般都是挂在具体类目下，设置为必填或非必填。在设置属性值时，须保留一定的扩展性，部分允许自定义属性。商品属性管理要求强大的类目运营能力，在中小型电商平台一般会提供基础属性值，再开放自定义属性编辑，让用户来完善属性库数据。
【商品属性系统的设计】
为了方便商品管理，我们需要在系统中建立一套属性库，类目属性都是调取的属性库里的数据，而属性搭建的原则通常是从属性分类的纬度来搭建的，分别是关键属性、销售属性、非关键属性、商品属性。在定义一个属性时，需要挂载在类目下，区分属性分类（关键属性、销售属性、非关键属性、商品属性），并确定属性值、显示类型（单选、多选、可自定义）、是否必填以及属性分组。对属性的定义是为了在添加商品时，属性列有判断条件。在搜索筛选时，确定各属性字段的意义和权重。
1．属性分组
由于一个类目的属性有时会很多，可能几十个，甚至上百个，所以引入了属性分组的概念，把形容某一类特征的几个属性归属于一个组，这样在前端的规格参数里可以按后台设置的属性分组按序展示，也方便对属性进行管理。
2．属性继承
如果网站的商品分类为三个层级，每个商品由很多的商品属性构成，其中同一层级的商品属性可能有很多都是相同的属性，为了减少属性添加时的工作量，我们将这部分共用的属性归类后赋值在上一层级的分类中，依次操作，将归类后的属性分别赋值给上级的分类中。
SKU 与 SPU
SKU和SPU算是电商中最基础的概念，SKU是最小库存单元，SPU是标准化产品单元。很多电商从业者在入门的时候都会被这两个概念围绕。SPU与SKU的关系有许多种，可以一对多、一对示。绝大部分SPU与SKU都是一对一，多规格的SPU和SKU之间是通过规格属性来连接的。SPU的库存是由其对应的SKU库存共同决定的。
在日常运营中也很常见一个SKU对应多个SPU，比如图3-9中SKU2就对应SPU1和SPU2。例如在一家淘宝店中，同样的一件男裤，店家可以起两个不同的商品名称（“七分裤男夏季薄款纯棉运动休闲”、“7分男士短裤男夏天宽松大码小脚潮”），这时候在前台展示的是不同商品，系统中这两件商品编码（SPU编码）也不同，但是发货对应的是同一个SKU，库存也是共用。
商品管理
在商品上架发布之后，日常维护主要包括：上下架管理、价格管理、促销活动、商品标签、商家管理、销量、评论、库存、限购等管理。
（1）上下架管理：在商品管理中一般分为两个子菜单管理——在售商品管理（上架商品）和待售商品管理（下架商品）。管理功能包括：商品可进行批量上下架；可设置自动下架规则，在缺货（库存为0）时自动下架商品；新品上架可定时发布；活动商品定时上下架等。
（2）价格管理：商品价格管理的影响因素很多，对商品销售至关重要。市场价、平台价的设定，从单品促销活动中同步促销价。还有多规格商品的不同SKU的价格不一致。在价格管理时，有些电商还会去爬虫收集其他平台在相同商品的价格，以便于在调整价格时的参照。至于动态调价系统，需要制定调价规则，日常生活接触最多的应该是机票、酒店的售价。
（3）促销活动：同步商品参与的促销活动（满减、套装、优惠券等促销活动），在前端商品页面（分类搜索页、详情页）中显示促销的活动
（4）商品标签：包括活动标签、服务标签、性能标签等类型。诸如极速退款、门店自提、分期付款等是服务标签；热销、新品等是活动标签；正品等是性能标签。有的标签在商品编辑的时候添加；有的标签可以按品类、按店铺批量设置。有的标签需求在订单中体现，例如服务标签中的分期付款等。商品标签在前端或主图的角标上显示，或是在商品详情页中显示。
（5）商家管理：管理平台上各个商家的商品，例如违规下架。另外也负责对商家的商品进行审核。
（6）库存管理：同步仓库的实物库存或自设活动库存等。后面章节会详细讲解库存问题。
总结
对于电商后台，初创小公司用几十个开发人员就能满足需求开发，维持业务流转，大公司则需要几百甚至上千个开发人员来进行开发维护。这就涉及后台系统复杂度的问题，除了业务范围的区别，还有业务量的因素。
以商品模块为例，在业务量逐步增长时，为了高效便捷地服务用户，会慢慢拆分多个模块。如图上所示，在系统上线初期，整个后台系统融合在一起，商品部分只是后台系统的一个模块。随着业务量的增长，将商品中心独立为子系统；接着随着业务继续增长，库存模块从商品中心中独立出来，单独成为库存中心；再接着发展下来，价格模块从商品中心独立成价格系统；再后来，价格系统根据需要拆分为价格管理系统与价格监控系统。从这个例子中我们可以看到，系统都是从简单到复杂，随着业务慢慢迭代。
