第07期：电商产品商品管理怎么设计

更新于 2026-09-15

商品管理系统是电商的数据基础，订单、营销、支付、物流都依赖它；本期讲清商品管理的组成、目的与策略。

1 关于电商产品商品管理

1.1 什么是商品系统

商品管理系统，是整个电商系统的数据基础，用于记录与商品有关的数据，虽然系统逻辑不复杂，但是由于操作的数据比较多，需要掌控细节，订单，营销，支付，物流等环节都需要从商品中心获取数据。

1.2 商品管理组成

商品管理系统，是整个电商系统的数据基础，用于记录与商品有关的数据，虽然系统逻辑不复杂，但是由于操作的数据比较多，需要掌控细节，订单，营销，支付，物流等环节都需要从商品中心获取数据。商品管理系统主要包含以下几个部分：

  1. 分类管理：管理商品分类，主要起到对不同商品的归类和；
  2. 品牌管理：管理商品品牌，为不同的商品添加品牌；
  3. 规格管理：规格也可以叫属性，决定了SKU，SPU，是商品模块重要的部分；
  4. 参数管理：参数也叫非关键属性，与规格类似，但是不决定SKU，只起到展示的作用；
  5. 商品推荐：商品推荐分常规推荐和个性化推荐；
  6. 商品搜索：涉及商品搜索逻辑和之后的展示问题；
  7. 商品评论：关键词，敏感词汇的筛选，评论等级等；
  8. 商品管理 : 对商品的增删改查以及上下架等其他操作，比较重要。

1.3 目的

  • 能够让用户快速的找到商品（主要是通过关键词搜索与类目搜索，商品管理为其提供了基础）；
  • 为同类型产品提供标准的属性，属性值，便于统一产品，使用户得到决策必须的消息；
  • 为运营童鞋方便管理商品的上下架。

2 如何做？

2.1 方法

（1）类目设计怎么做？

对电商而言，商品是电商平台最核心的部分之一，商品管理系统属于电商平台的基础数据服务系统，与其他系统都有直接的关系，例如订单系统、库存系统、采购系统等。而类目又是商品管理系统的根基，所以说类目设计的好坏会对整个电商平台中其他系统有直接或者间接的影响，因此一个好的类目设计至关重要。

  1. 什么是类目？

首先我们先来了解下什么是类目，类目简单来说就是商品的分类和类别。对于用户来说，类目可以为用户缩短查找商品的时间，可以快速的找到自己心仪的商品；对于平台来说，可以高效的管理商品体系，为运营人员提供支持。

  1. 目管理

若平台初期商品数量和品类不多的情况下，运营人员管理起来相对容易些，但随着业务的扩展和商品数量的增多，而且前台用户还有可能随着营销方式的变化、季节的变化等（例如根据季节不同、当季流行），用户购物的需求也会发生变化，运营人员就要随着用户的需求频繁的调整类目，既要满足前台用户多变的购物需求，又要让运营人员高效管理海量商品，运营人员的压力是巨大的。参照线下实体类商品的管理模式（仓库中商品分类的摆放和面向用户的展示柜），所以电商衍生出来了基础数据类目（后台类目）、前台展示类目（前台类目）。运营人员可以随意调整前台的类目展示，通过映射的关系与后台类目关联。下图为前后台类目的映射关系图：

  1. 类目树

类目可以将海量的商品进行分类管理，但是随着商品的数量和品类的不断增加，单一的类目划分管理，类目的划分就会变得越来越多，用户查找起来依然会不方便。此时就需要多级类目来管理，类目树就诞生了。类目树可以在一定程度上解决商品分类的问题，平台管理类目的问题，还可以缩短用户查找商品的路径。类目逐级往下分，最底层称为叶子类目，商品被挂在叶子类目下面，叶子类目的基本原则就是互相之间不能有交集、不能重复。类目的层级一般为3到4级，一般不能超过4级。

  1. 后台类目

后台类目是前台类目的搭建基础，后台类目是按照商品本身而进行物理的分类，相对固定，一旦确定不可轻易变更或者删除。后台类目主要面对的是商家和平台运营，平台运营负责搭建管理类目，商家在发布商品时，必须选择对应的类目才能发布商品。商品被挂载在叶子类目上，选择完叶子类目后，需要填写商品的属性等信息（属性挂载在类目上），关于属性本篇文章暂不展开说明，下篇文章再做详细讲解。下图为淘宝的后台类目：

  1. 前台类目

前台类目是按照业务场景和用户购物角度的分类，可根据运营需求灵活多变，可重复、可删除。前台类目架构是引用后台各个叶子类目，再进行排序或组合而得到，前台类目不挂载属性，继承后台的叶子类目或者叶子类目集合的公共属性。前台类目主要面对的是前台用户，前台类目灵活多变可有效的缩短用户查找商品的路径，方便用户筛选出心仪的商品。下图为京东的前台类目：

  1. 前台类目和后台类目的映射关系

由于前后台类目的分离，需要通过映射的关系，将前台类目和后台类目进行关联，常见的映射关系有以下几种。

  1. 一对一关系类目

这种映射关系适合电商平台初期，以及商品品类不多的情况下使用。后台类目与前台类目是一对一的关系，前台类目直接将后台类目映射过来，在前台呈现。例如：后台类目叫平底鞋，前台类目也叫平底鞋。一对一映射如下图：

  1. 多对一关系类目

后台多个类目下的商品有相同的属性，前台类目通过聚合的方式，将后台类目中具有相同属性的类目聚合映射成一个类目。例如前台类目中的流行女鞋，后台类目中的圆头鞋、平底鞋、帆布鞋、水晶鞋都具有流行的属性，通过“流行”这个属性就可以将多个类目聚合映射成一个类目。多对一映射如下图：

  1. 关键词类目

输入关键词搜索或者点击文字链接，直接搜索出系统中与关键词有关的类目商品。下图为淘宝的关键词类目。4） 链接类目通过某种链接的方式，用户直接点击后会直接到达某一相关链接的页面。下图上方和右侧为京东的链接类目。

  1. 小结

类目设计是电商平台的起点，一个好的类目设计会影响整个电商平台的搭建。类目的搭建并不复杂，复杂的是类目实际场景的应用，只要能掌握最本质的核心，万变不离其宗，根据实际的业务场景就能找到适合自己产品的类目设计，希望以上笔者的分享能够在工作中帮助大家。

（2）属性库搭建

当公司的业务不断扩张，商品的数量和种类数据量规模逐步增多，达到一定量级的时候，类目数就会变的越来越庞大，对于运营来说管理起来极其困难，对用户来说想要快速查找心仪的商品，也是非常不方便的。为了方便商品的管理，因此就有了属性的诞生。属性不仅可以更方便的管理商品，还可以为搜索、索引、筛选提供支持，前台用户不仅可以通过类目来查找商品，还可以通过商品的属性查找商品。例如，某些商品都有同一属性，可以直接通过属性找到它们。

  1. 什么是属性

作为类目的“家属”，类目和属性是“共生”的关系，属性被挂靠在类目下，那么属性到底是什么呢？属性：用来描述商品的特征信息，例如颜色、尺码、材质等。属性由“属性名称和属性值”组成，例如颜色是属性名称，红、白、黑是属性值。有时候同一种属性可以用于描述多种商品，但描述商品时的叫法可能不一样，所以同一种属性可以定义多个属性别名。例如：颜色、色彩等；都是同一种属性，属性值也都一样。但在商品描述时，可能使用的属性名不一样。如下图示例添加属性页面；下图为前台看到的属性和属性值，红色框线内的为属性，绿色框线内的为属性值。

  1. 属性库（池）管理

对于小型平台来说，商品量不大时，可不用属性池管理的方法，直接在叶子类目下设置相应属性即可。但对于中大型平台来说，商品量过于庞大，属性量也会过于庞大，管理起来非常困难。有些不同的商品还可能会有同样的属性，为避免重复性创建属性，方便管理属性，一般平台的做法会建立一个属性库，来统一管理属性。如下图：

  1. 属性的分类

属性通常分为关键属性、销售属性、商品属性、普通属性这四种。为方便理解，笔者以手机为例为大家解释这几种属性之间的区别。关键属性：一个或者多个关键属性可以确定一个SPU（Standard Product Unit，标准化产品单元），通过关键属性能够确定某类商品（某一类商品的集合），但不是具体的某一款商品。例如：苹果手机、iPhone X（品牌+型号）可以确定这一类商品。销售属性：也称为规格属性，一个或者多个销售属性能够确定一个SKU（Standard Product Unit，库存量单位），通过销售属性能够确定具体的某一款商品。例如：苹果手机、iphone X、黑色、128G。简单的可以理解为，用户在商品详情页，只有选择了机身颜色和内存，才会显示价格和库存量。商品属性：一般是指商品特有的属性特征，如手机的屏幕尺寸、分辨率等。普通属性：除关键属性、销售属性、商品属性外的其他属性，该属性一般用来作为商品属性的补充说明，非必填项。如当季流行、适用人群（老年机、商务机、音乐手机…）等，与商家的销售场景有关。上架商品时，填写的商品属性模板通常就是根据以上属性来定义的。当然根据自己公司的实际业务，还可以进行其他属性的分类，例如特殊属性、绑定属性等，特殊属性仅在特殊业务场景下使用，如生鲜类商品需要冷藏，在生成订单时会自动打上生鲜的标签；绑定属性可以理解几种属性之间有强关联的关系，如手机有“型号”的属性，那么屏幕尺寸、电池容量、分辨率等也会被连带一起确定。

  1. 属性组管理

属性的产生解决了类目冗杂的问题，却会衍生出新的问题，属性库中的属性不断增多，变的越来越庞大，管理起来也变得越来越困难。为了解决这一难题，引入属性分组的概念。在商品和属性的量不是特别大的时候，可以不使用属性分组。属性分组的目的就是将同一类特征的多个属性归属到同一属性组中，方便对属性库的维护和管理。在添加属性的时候，可以选择是否将属性关联到属性组中。类目也可以直接调用整个属性组中的属性。下图为后台属性组维护界面；下图为前台商品展示的属性页面；最左侧一列为属性组，中间一列为属性，最后侧一列为属性值。

  1. 属性与类目的挂靠关系

类目的层级一般为3到4级，商品被挂靠在最后一层级（叶子类目）上，每种商品的属性有很多种，每种商品之间有可能存在相同的属性。为减少在录入商品时添加属性的工作量，可将同一层级下所有商品的共有属性，挂靠在同一层级类目上，每一层级的类目会继承父级类目的属性，最终叶子类目会继承类目路径上的所有属性。商家在发布商品时，需要选择对应的叶子类目，此时会相应的加载出来叶子类目上的所有属性（对应商品的属性模板）。如下图：

  1. 品牌管理

品牌是比较特殊的商品属性，需要单独进行管理。品牌不仅会影响商品的发布，还会影响前台商品的曝光度，用户通过品牌对商品的认可、通过品牌来搜索商品等，品牌与商品是多对一的关系，一个品牌会对应多个商品。例如iphone 11、ipad Air、AirPods三种商品对应的品牌都是苹果。电商平台发展初期，品牌都是由商家自行填写的，不免会出现同一种品牌有多种叫法。例如“苹果”这个品牌，有的商家填写“苹果”，有的商家填写“apple”。为避免品牌数据的杂乱、冗余，需要将品牌进行标准化管理，整个管理的流程为品牌申请、品牌审核、品牌使用。品牌申请：若商家或者平台发布新的商品时无对应的品牌，需要进行品牌申请，申请通过后方可使用。申请品牌时一般包括中文品牌名、英文品牌名、LOGO、产地等信息。如下图：品牌审核：商家或者平台内部发起品牌申请后，由专门的品牌管理运营人员进行审核通过/驳回。品牌使用：品牌申请通过，状态为“启用”后，发布商品时可选择对应品牌。品牌的使用一般有2种方式，第一种是将品牌挂在类目的叶子类目下进行选择，在填写属性模板时展示出来。第二种直接在填写商品属性模板时进行选择。

  1. 小结

属性和类目一样对商品的统一管理意义重大，它不仅影响后台商品的管理，对前台商品的搜索、曝光度、用户对商品的认可度，都起到决定的作用。希望本篇文章能够帮助大家对商品管理系统属性库的搭建有个全面的认识和了解，对大家有所帮助。

（3）商品管理

  1. SPU与SKU定义

电商产品中不得不了解的两个名词，SPU和SKU。SPU（Standard Product Unit）：标准化产品单元，是商品信息聚合的最小单位，是一组可复用、易检索的标准化信息的集合，该集合描述了一个“产品”的特性。通俗点讲，属性值、特性相同的商品就可以称为一个SPU。前面文章提到过，类目系统中的关键属性能够确定一个SPU，它可以确定某一类商品，但不能确定具体的某一个商品。例如：苹果手机+Iphone X（品牌+型号）能够确定一个SPU。SKU（Standard Keeping Unit）：库存量单位，即库存进出计量的基本单元，也可以说SKU就是库存的最小单位（个、件、盒、托盘等）。每个SKU都拥有不同的编码。前面文章同样提到过，类目系统的销售属性能够确定一个SKU，它可以确定具体的某一个商品。例如：苹果手机+Iphone X+12G+黑色，能够确定一个SKU。简单的可以理解为，用户在商品详情页，只有选择了具体的商品规格信息，才能够显示出价格和库存量。SPU、SKU、商品的关系SPU与SKU的关系一般是一对多或者一对一的关系，SPU包含多个SKU，SKU是SPU的子集，而商品是SKU的具象化实物。例如：森马+工装男鞋，可以代表一个SPU；再加上颜色和尺码，森马+工装男鞋+黄色+41码，可以代表一个SKU。有些特殊情况下，一个SKU也可能对应多个SPU，不过此种情况比较少见。例如：某家店铺中同样的一款鞋子，当作两种商品上架在商店中，起了两个名字（森马工装男鞋、森马复古休闲男鞋），此时在前台展示的是两种商品，而后台系统中对应的是一款商品（一个SKU编码对应两个SPU编码）。为方便理解，笔者简单绘制了SPU、SKU、商品的关系。除了以上情况之外，根据卖家实际业务场景不同，商品系统中还有一种商品类型叫做商品套装或者组合商品，此种业务场景相对比较复杂。例如运动健身衣套装（两件套、三件套、四件套…）在前台用户购买下单的时候是一个商品，而后台的处理逻辑是将n个SKU组合关联成一个虚拟的SKU，下发到仓库后将虚拟SKU拆解，按照实际的SKU扣减库存，在发货的时候将n个SKU对应的商品打包成一个包裹送到用户手中。

  1. 什么是商品系统

商品管理系统属于电商产品中最基础、最核心的系统，是支撑整个电商产品的核心，基本上所有的系统都离不开商品数据，商品贯穿整个电商平台。从商品的采购、到达仓库、商品上架、前台的展示、下单、物流配送、收货、售后服务等，整个流程都离不开商品。后台商品系统一般分为，类目管理、属性库、品牌管理、商品管理（发布商品、编辑商品、商品上下架、审核、价格库存设置、运费模板设置等），本篇文章主要和大家分享后台商品管理。

  1. 商品管理

前面一系列的准备工作都是为了商品的管理，包括类目、属性库的设计，以及本篇文章提到的SPU和SKU，只有把这些全部搞清楚了，才能了解商品管理系统是怎么“玩”的，才能真正读懂电商平台的核心系统——商品管理。商品管理其实说白了就是对商品的维护管理工作，包括发布（新增）商品、商品的上下架、商品修改、商品的查询、设置运费模板等。如下图是商品管理的界面；

  1. 发布（新增）商品

商品的创建或者发布之前，应先选择挂靠类目，商品调用类目中挂载的属性，生成对应的属性模板，通过关键属性和销售属性（规格属性）去关联SPU和SKU，同一SPU在前台显示可共用同一商品详情，但需要通过销售属性（规格属性）映射到具体的SKU。京东是以SKU维度进行管理的，淘宝和天猫是以SPU维度进行管理的。（京东切换商品规格时标题和商品详情改变，淘宝和天猫切换商品规格时标题及商品详情不变）为了保证新发布的商品信息正确性，降低发布违规商品的风险，因此需要平台运营人员进行审核，才能保证平台发布商品的质量，审核通后方可正常上下架商品。一般常见的审核流程如下图（仅供参考）；发布（新增）商品时，商品信息一般有商品基本信息、商品属性、商品图文描述、支付信息、物流信息、售后服务等部分组成。

  • 商品基本信息

商品的基本信息是对商品的基本描述，一般是指用户浏览商品时第一眼看到的信息，根据平台的业务不同该部分会有略微的区别，但一般都主要是商品的所属类目信息、商品标题（商品名称）、品牌信息、商品编码（也叫69码）、商品属性、广告语等信息。

  • 商品属性

商品属性通常包括关键属性、销售属性、商品属性、普通属性这四种，根据自己公司的实际业务，还可以进行其他属性的分类，例如特殊属性、绑定属性等。笔者在属性库搭建一篇文章中有详细讲解关于商品的属性，如何从零到一搭建属性库，属性又是如何与商品类目关联的。感兴趣的同学可前去阅读，商品管理系统设计（二）：属性库搭建

  • 商品图文描述

包括商品图和商品描述，商品图片一般包括，商品主图、商品轮播图，以及商品活动图；商品描述是针对图片附加的文字说明，可填可不填。

  • 库存设置

库存设置是针对商品的销售属性（规格属性），即商品的SKU，设置对应价格和库存，不同规格的商品对应不同的价格和库存，当商品库存销售为0时会自动下架。一般SKU库存同步WMS系统中库存，即实物库存，或者人工设置活动库存。商品库存数量与库存系统、WMS系统之间进行数据交互，在前台显示。关于库存系统，后面更新文章笔者会专门分享。

  • 支付信息

一般是指用户在拍下商品时的付款方式和拍下商品时的库存计数方式。付款方式分为一口价（普通交易模式）、预售模式、货到付款等。一口价是指提交订单时一次付清；预售模式是指先付一部分定金，等到商品开始售卖时，将尾款付清。货到付款比较容易理解，就是用户确认收货后再支付。库存计数分为拍下减库存和付款减库存。拍下减库存会存在用户恶意拍单，而不买的风险；付款减库存会存在平台或商家超卖的风险。两种方式各有利弊。如下图是淘宝发布商品页中的支付信息。

  • 物流信息

主要是根据商品具体情况选择提前设置好的运费模板，若没有符合要求的运费模板，可前往物流系统进行设置后再使用。

  • 售后服务

一般是商品售后对用户的承诺，例如，退换货承诺（7天无理由退换货等）、假一赔十…根据商品不同售后服务不同。如下图是淘宝发布商品页中售后服务。

  1. 商品上下架

商品管理中的商品分为在售商品（上架中的商品）和待售商品（下架中的商品），发布商品时也可以设置自动下架或者定时上架规则。将商品分为在售商品和代售商品两个模块，只要便于平台运营人员或者商家管理商品。在日上运营过程中，商品下架的原因有很多，对应的处理方式也不同，例如系统自动下架、商家自主下架等。系统下架的场景一般有违规、品牌到期、店铺迁移等，对应常见的原因有风控系统管控下架、店铺迁移或者关闭、类目变更、平台运营操作等。在设计产品时要尽可能罗列出有关系统下架的场景和原因，以供运营人员通过下架原因告知商家进行整改。

  1. 商品编辑

商品编辑同发布商品（新增商品）的功能一样，是对已经发布的商品的信息进行修改，修改过后系统会判定是否新增的商品，若是新增的商品上架时要走审核流。

  1. 商品删除

商品删除是对不在进行销售的商品删除，上架状态的商品不可删除。

  1. 设置运费模板

在商品管理模块中有设置运费的入口，直接进入到物流系统设置运费模板，设置好运费模板之后，在发布（新增）商品时直接使用。订单处理会根据物流信息计算运费，计价方式一般分为按件计算、按重量计算、按体积计算，如图运费模板是按件数计价。关于物流系统，后面更新文章笔者会专门分享。

  1. 商品状态流转

商品状态分为新增、待审核、审核通过、审核未通过、已上架、已下架、失效、有效待审核共8个状态，笔者为大家梳理了一张商品在整个流程中的状态流转图（仅供参考）。平台运营或者商家在发布（新增）商品时，若无对应的商品需要走审核流，若有对应的商品无需审核，发布（新增）商品成功后，方可直接操作商品的上下架。

  1. 总结

商品管理系统是电商平台的基础，是其他系统所依赖的基础数据系统，在建立电商平台初期就要规划好系统的每个模块，需要考虑每个模块的可扩展性，减少耦合性。避免后期产品扩展时遇到瓶颈，后期若再进行系统规划调整，会产生巨大的成本。因此打好基础，对电商平台后续业务规模的发展起到至关重要的作用。

2.2 策略

如何将数以万计的商品管理好，实现线上无人介绍的情况下，用户能看懂、商家说得清、平台管得住，作为电商公司，需要采取适当的策略，才能实现上述目标。

（1）商品管理策略体系

一般地，主流电商平台采取的策略包括如下。

  1. 规范化

由行业专家制定规范，对品类规划涉及的类目——属性——属性值（CPV）和商品涉及的标题、卖点、标签、图片、详情、视频等进行规范。对于规范性策略，从实践落地的效果看，尽量制定系统能够量化理解的，这样能够通过算法实现系统管控；不要制定定性描述性的，系统无法通过算法来执行，描述性的规范只是在传播上有价值，在管控上无法通过系统自动管控，发挥不了多大作用。拿一个具体的案例来说，比如我们规定每个商品标题至少包含一个商品的功能属性，这样的规范需要进一步细致到每个品类的功能属性项和属性值分别是什么，这样才能有系统识别出标题是否包含至少一个属性项中的属性值，这样才具备规范的落地意义，而不是通过人工来判断这个标题是否包含功能属性。

  1. 标准化

将非标品类比如生鲜、服务项目标准化。标准化实现了电商平台业务范围的扩大，并且标准化后，数据的流转分析更加精准，在各个角色（用户、商户、平台）之间的沟通成本更低。

  1. 平台化

大量商家涉及相同的工作提炼到平台，进行平台化共享共治，节约社会资源，降低商家成本，产品信息库就是具体的应用示例。在电商平台上，大量商家都在卖相同的货，对于标品（家电3C等）半标品（快消品、美妆等）尤其如此，品牌集中度非常高，卖相同商品的商家也非常多。比如卖手机商家中，30%的商家都在卖苹果手机，这些商家都需要进行商品的信息发布。在发布过程中，商品的物理属性是完全相同的，如果电商平台将这些信息进行平台化，其他商家都可以直接调用，这样商家不需要填写，而且数据的一致性和准确性也大为提升。规范化、标准化、平台化实现商家低成本高效率运营，也是电商平台高效商品流转的基础。

（2）商品治理策略体系

在电商平台，一个个商品就像社会上一个个人，有好人，也有坏人。在电商平台，有好商品，也有坏商品。形成坏商品背后的动机也各不相同，有商家小二不懂平台规则、或者不懂电商相关法律法规形成；也有商家出于利益动机故意的，比如平台上每个类目的佣金扣点不同，一些商家为了少交佣金，将商品发布在低佣金扣点的类目。有的商家为了营销的需要，在商品标题卖点中增加国家广告法所不允许的“全国第一”、“世界驰名”等词汇。面对数以亿计的商品，如何管理好这些商品，提升用户体验，降低平台经营风险，是商品治理需要考虑的事情。从成功的业务实践上看，商品治理需要采用闭环治理和综合治理两套组合拳策略，互不隶属，互不偏颇。

  1. 闭环治理

闭环治理主要是指商品流转闭环和处理流程闭环，前者在增量商品入库和入库后形成存量两个环节都要治理，后者是指问题商品的处理上也要闭环。1）增量入库问题&风险前置识别，增量违规实时提示纠正，访问问题商品如平台。2）存量商品定期扫描存量商品，违规实时推送督促商家整改，并打上风险标签帮助后续的处理闭环。比如打上风险标签后，流量分发（搜索、推荐、广告）环节根据风险等级决定流量分配是否应该是彻底关闭流量、流量降权。3）处理流程闭环问题诊断、仲裁、奖惩、整改、恢复。规范性要求平台治理有法可依，增量和存量识别是有法必依，处理闭环策略原则是违法必究，同时给予被冤枉的商家申诉仲裁的机会，对于确认是违规的，进行量刑适当的惩罚，如果商户积极配合整改，在处罚完毕后，给予恢复的机会。

  1. 综合治理

综合治理是指商品管控要综合多角度多种力量进行治理，不是单纯地就事论事，处理商品就结束了，不仅仅是平台和商家的事情，也可以将全社会的力量都纳入进来。我们看来，综合治理至少包含如下几个方面内容。1）治理对象违规治理除了对问题商品自身进行处理，还要与店铺联动，避免店铺通过少数优质商品引进大量用户入店铺，但是其余大多数都是劣质商品，这些劣质商品影响店铺转化和用户体验。2）治理手段治理手段包括流控和准入。

  • 流控就是在商品的流量分发环节进行控制，在搜索、推荐、商业化推广等过程中，对于违规商品，不予分发流量，实现优质商品多流量奖励，劣质商品无流量，优胜劣汰。
  • 场景准入：一些场景对商品信息质量有最低要求，不达标无法参与，比如在首页猜你喜欢场景，商品必须是白底图或者场景图。
  • 活动门槛：一些活动，比如618大促，报名要求商品信息质量必须高于设置的水准，低于该水准的自动失去报名资格。 3）治理力量治理力量要开放协同，商家、平台、用户、培训机构、政府、媒体、行业机构多方资源参与。比如国家质量监督部门、每年的消费者保护日315就是很好的治理资源，国家行业协会制定的各类规范以及例行抽检会提供很好的违规来源，电商平台要学会利用这些资源通达平台商家，形成威慑力，让商家不敢违规。又比如疫情期间，对于积极组织生产质优价廉商品的商家，大力宣传形成社会正面力量，但是对于违规的商家，媒体也有极大的热情参与进来报道，淘汰负面商家。商品治理策略是实现用户良好体验的保障，合理的治理策略能实现事半功倍的效果，将多种力量纳入进来形成闭环治理和综合治理是电商平台比较成功的业务实践。面对平台上数以亿计商品，治理起来，我们在工作时间中，抓重点问题和主要矛盾，才能有的放矢。所以分层分级也是治理策略的一部分。分层分级主要包含：
  • 类目分层分级：类目治理遵循：“高GMV→高订单→腰部→尾部”顺序。
  • 商品分层分级：商品治理遵循：“动销→高热→温→冷”顺序。
  • 商家分层分级：商家治理遵循：“自营/KA大品牌→腰部商家→尾部商家“顺序。

分层分级是商家和平台根据二八原则分配资源，做最有价值工作的依据。

（3）总结

商品管理体系和商品治理体系是商品工作两个重要方面，前者涉及电商平台如何给商品定规矩，包括规范化、标准化和平台化；后者涉及如何按照规矩管理商品，包括闭环治理、综合治理和分层分级治理。二者相互配合，实现用户放心买、省心用；商家低成本高效率商品管理、平台高效率商品流转和有保障的风险管控。

2.3 注意事项

（1）商品管理的后台设计

后台设计大同小异，无非增删改查几个基本功能，有兴趣的话可以作部分探讨。但是在电商系统设计里，需要更加注意几（cai）个（guo）问（de）题（keng）：

  1. 数据唯一性（需要根据平台或店铺特点定制）：

包括但不仅限于：货号及UPC的全平台唯一、属性值的唯一性、类目值的唯一归属等等。

  1. 数据之间的调用关系：

商品是整个电商的最底层逻辑，会被各后台及系统反复调用，产品经理需要对商品的实现及各系统之间的调用要非常清楚。

（2）类目管理，越早越好

常规来讲，一个商品应该对应到唯一类目。类目的建立要考虑几个问题：

  1. 唯一性。唯一性指的是子类目下的名称不能与其他子类目下的名称重名。如在“鞋子”类目下如果有了“运动鞋”这个类目，那么“运动鞋”便不应该出现在“运动休闲”这个类目下。否则会在进行商品统计、数据分析、用户检索时傻傻分不清。
  2. 排他性。排他性是指商品仅挂落到一个类目树下，不重复。（多指后台系统）
  3. 前台类目与后台类目分别管理。前台类目的主要功能分为两个：方便用户进行检索、引导用户转化。后台类目功能有一个：将商品作聚类管理。

通常的情况是，每天的运营目标不同，除常规分类外还会配置运营分类。这里是非严格意义上的分类，更像是灵活配置的运营模块。比如今天iPhone X在电子产品的前台分类下，明天便可以放到开学神机这个分类下，但最终商品属性的后台类目是不变的。

（3）什么时候使用SKU，什么时候使用SPU？

总的一个原则：涉及到库存的部分使用SKU，涉及到展示的部分使用SPU。举个例子：每个SPU下，会同时存在多个SU信息，如阿迪达斯小绿尾会有36、37、38、39、40码。在运营模块、搜索结果中，只需要让用户知道小绿尾这个商品即可，所以用SPU信息（即货号信息）便足够。但是涉及到购买时，有的人需要36码，有的需要40码，这时便需要使用SKU信息对最小可操作单元进行管理。

（4）商品库存该如何管理？

库存是指该商品现有的数量，比如Adidas小绿尾36码有5个库存，那么可以售卖的库存数便是5。在电商系统里，一般会存在多层库存，包括但不限于：销售库存、中转库存、实物库存、良品库存、次品库存等等。较为简单的系统里仅有销售库存、实物库存两类，如果库存不一致时售卖便会有问题，当销售库存＞实物库存时便有可能出现超卖问题！（后续会继续介绍我在超卖问题上踩过的坑）那么，商品的库存会对用户侧有什么影响呢？——商品库存对售卖状态的影响。

  1. 销售库存=0时，一般为补货中或下架状态，具体如果变更状态及变更为什么状态，根据各司业务不同可自行定义。
  2. 销售库存＞0，实物库存=0的状态，一般是预售状态。预售状态尤其要注意的是卖出库存、剩余库存的处理关系。

（5）商品价格的管理？

一般讲，商品的价格系统由三部分构成：成本价、标牌价、现售价，活动期间还会有活动价格。踩过的坑主要是在活动价这一块。随着各种抢购活动的兴起，各种电商也开始了0点开抢大战。运营手动改库存或到点儿批量改库存肯定是受不了的，所以产品常会接到一个定时改价格的需求。在改价格的功能中，踩过了一些坑拿出来分享：

  1. 商品参加活动引发的价格优先级

商城的活动那么多，一个商品在同一时间可以参加几个活动呢？如果参加多个活动价格该如何计算呢？从销量角度来讲，是支持同一商品参加多场活动的；但是从复杂度来讲，限制了商品可以在同一时间段参加同一种类型的活动。比如同一件商品，可以同时参加大促、秒杀活动，但是不能参加同一时间的两场秒杀活动（不要问我为啥同一时间有两场秒杀，一切皆有可能！）。那么问题来了，A商品参加大促的价格是100元，参加秒杀的价格是200元，那么该显示哪一个价格呢？这时便需要根据自己平台特点和规则设计价格优先级。

  1. 品活动价格引发的对账问题

对账时，财务姐姐们不仅收到多少钱，还要精确到每一笔订单中的每一件商品要收多少钱。所以当商品的价格变更时一定要在报表中及时同步给对账的同学们展示清楚。参考文献：

  1. 电商后台：商品管理系统https://www.woshipm.com/pd/2879381.html
  2. 电商产品设计：后台商品管理设计https://www.woshipm.com/pd/4398392.html
  3. 商品管理系统设计（一）：类目设计怎么做？https://www.woshipm.com/pd/3593637.html
  4. 商品管理系统设计（二）：属性库搭建https://www.woshipm.com/pd/3664177.html
  5. 商品管理系统设计（三）：商品管理https://www.woshipm.com/pd/3810808.html
  6. 电商平台商品管理及治理的策略体系https://www.woshipm.com/operate/4707858.html
  7. 电商系统 | 后台设计 | 电商商品管理踩坑集合https://www.woshipm.com/pd/957417.html
→ 产品兵器库 · 第07期（原始飞书文档）