淘宝的商品中心和类目体系设计
商品作为电商体系中最重要的业务模型,不管是在电商供应链、电商营销,还是电商推荐中,都有很重要的应用。
这篇文章结合淘系的商品业务,从概念分析,到领域模型,再到上层应用,对电商的商品和类目体系进行拆解。
一、如何定义商品
在展开分析之前,先来思考一个问题,追根溯源,什么是商品?
1. 商品是货品的数字化
理解一个概念,不能离开上下文。
这篇文章描述的是电商领域中的商品,电商对应的是线下零售,在电商业务中,商品就是通过把不同的属性集合在一起,描述客观世界的实物。
为了更加真实和准确的反映实物,我们通过创建不同的模型,组合不同的属性去描述商品;也就是说,商品可以理解为线下实物商品的数字化。
商品连接交易,电商时代的特点是一切皆可交易,所以商品的概念也越来越宽泛。
4. CSPU
CSPU是淘宝特色的一个商品模型,这里的C是Child的意思,也就是子标准化产品单元,即SPU的细分,更细粒度的标识产品。
“类目+关键属性+销售属性”唯一确定一个的细粒度产品CSPU。
比如手机类型下,品牌和型号这两个属性可以确定一个SPU,但还不能标示一个CSPU,需要额外的销售属性来确定;
以苹果手机为例,品牌是IPhone,型号是12,颜色为深灰色,存储卡256G,两个关键属性是品牌和型号,两个销售属性为颜色和存储卡。
三、类目属性体系
类目属性体系和商品领域相辅相成,打个不恰当的比方,类目树是坐标轴,类目属性是坐标,商品就是其中的点。
1. 类目定义
类目是商品所属的分类,类目决定了商品的归属。
类目是有层次的,分为一级类目、二级类目等,之间有继承关系,通常是通过类目树来展现。
比如厨房电器这个一级类目下,有电磁炉,冰箱等二级类目,电磁炉下面还会有细分的三级类目,类目树的最下面一层类目是叶子类目;一般来说,只有叶子类目才可以下挂商品。
2. 前后台类目
通常来说,电商业务里有两大类型的类目体系,一种类型是后台类目,主要用于商家发布商品;另外一种类型是前台类目,主要用于前台商品导购。
1)后台类目,关注标准化管理
后台类目是商品的实际归属类目,卖家在发布商品时,将商品发布到指定的后台类目下;淘系定义的类目最多四层,类目层级太深会影响商家商品发布的体验。
2)前台类目,关注灵活的导购
前台类目用于在前台进行导航,展现,搜索定位用,前台类目中保存的,实际上是对后台类目/属性的筛选条件,即映射条件。
用户通过前台类目搜索到该类目所映射的后台类目下挂靠的商品,但是商品只归属于一个后台类目。
前台类目主要用来导购,导购路径过长会导致转化率下降,一般来说,前台类目不会超过3层。
在前端也有优化,比如上面淘宝的首页,实际上只有两层跳转。
3. 类目属性及分类
类目属性是类目下的商品所具有的共同特征定义,关联叶子类目和属性,比如手机类目具有品牌、型号、颜色、网络等属性。
和类目属性对应的是类目属性值,表示类目下的商品所具有的某一个特征的值。
属性是用来描述商品的,为了更好的对商品进行描述,对类目属性进行一层抽象,也就是类目属性分类。
一般的,类目属性可以进一步分为关键属性,绑定属性,销售属性,商品属性。
四、属性库建设
属性用于描述商品具有的特性,比如颜色、尺码,只靠属性不能描述商品,需要说明属性值才可以。
读到这里你肯定也意识到了,属性库其实类似元数据的概念,也就是「描述商品数据的数据」。
从这个角度来说,属性库,类目体系,SPU产品和商品,是一个类似金字塔的结构。
1. 属性数据从哪里来
属性库既然是元数据,就要支持大部分的商品描述,目前主流电商平台的属性库数量都是在百亿级别。
现在思考一个问题,那么这么多属性,都是靠运营手工录入的吗?
对于平台型电商来说,属性库的数据来源,一部分来自各个行业的标准化委员会,比如服装有全国服装标准化委员会,洗衣机有家电标准化委员会,然后运营去手工录入。
另外大部分数据,来自商家和平台的共建,也就是通过商家来输入。
这里又有一个问题,如果商家在发布商品时创建一个根本不存在的属性,比如上架一部手机,内存选择100TB,平台如何解决这种问题呢?
典型的解决方案,就是淘宝的商品审核机制。
以淘系为例,属性库分为标准属性库和基础属性库,其实就是对应两套数据表。
基础属性库和属性值来自商家发布商品时录入,类目运营通过人工审核、算法审核等方式,会把部分属性添加到标准属性库。
2. 标准属性和基础属性
标准属性库维护的是经过审核的,类目上直接可用的属性,而基础属性库,来自商家在发布商品和spu过程中直接录入的数据。
经过运营审核、机器审核、数据清洗等流程,基础属性数据会流入到标准属性,作为整个平台属性库的扩充,在其他商家录入商品时,可以直接依赖,实现属性的复用。
3. 属性如何管理
属性库不只有K-V结构这么简单,还需要一些别的规则来约束。
1)输入类型
属性有一个概念叫输入类型,因为不同的属性有的可以枚举,有的只能文本输入。
比如商品的产地,是固定的行政区域,但是如果是重量,就没办法通过枚举表示完全。
一般来说,属性可以分为枚举,枚举可输入,可输入三种,另外某些复杂类目下还有属性模板的定义,用于某些无法提前枚举的子属性填充。
2)多级属性
特别的,部分属性有子属性的概念,比如阿迪达斯的三叶草系列,就是隶属于阿迪达斯这个品牌属性值下边的。
如果没有子属性的概念,单纯通过笛卡尔积来表示,在发布商品时就会出现太多的属性值并列,导致无法筛选,并且出现很多不存在的属性组合,而多级属性,就可以解决这个问题。
五、供应链商品
上面的商品模型,都是偏向销售链路,在供应链路,商品模型又会有一切不同,简单列举几点。
1. 前后端商品
刚才说到,标准的电商类目体系会分为前台类目和后台类目,其实在商品模型中,也会分成前端商品和后端商品。
前端商品关注销售链路,包括交易,订单等,后端商品关注供应链路,包括仓储,采购等。
为什么要分前端商品和后端商品呢?
前端商品可以理解为分销商品,后端商品可以理解为供销商品。
举个例子,你在网上购买一个空调,实际上呢,这个空调分为室内主机和外机,内机和外机在仓储上和可能是分开的。
为了解决这种情况,就可以通过前后端商品模型,将前端的空调商品,与后端的空调内机和外机关联起来,最终计算库存时,是使用内机商品和外机商品的库存。
2. 组合商品
还记得啤酒与尿不湿的故事吗?
商品在销售过程中,常见的一个形式是组合商品,比如购买手机的电话卡套餐,双十一商家的套餐商品,都可以通过组合商品的方式来实现。
六、小结
这篇文章简单分析了商品、类目、属性库三层的业务模型;对于平台型电商来说,商品管理核心解决两个问题,一个是商品的标准化,另外一个是商品导购,而这些都离不开业务模型的支持。
模型的第一性:埃隆马斯克有个特别推崇的第一性原理,第一性原理要求我们回归本质,找寻最基本的要素,建立更简洁完整的架构体系。
商品模型的变化,都是为了更好的描述现实世界的实物商品,满足业务要求。
从这个角度看,电商业务中,商品模型就具有第一性,熟悉了底层商品模型,在面对上层的各种业务变化,就可以游刃有余。
本文作者 @邴越
版权声明
本文来自互联网用户投稿,文章观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符,请点击 举报 进行投诉反馈!