电商产品设计三大年夜核心模块（一）商品分类体系

半年前由于机缘巧合，笔者有机会从零开始设计一个电商产品。

由于本身不是做电商出身，没有什么电商产品设计履历，以是只能边学边做。

这半年来，我看了大量的书本、视频和文章，也和许多同行的前辈互换过，再加上自己在实践中的打磨，现在大体上能够说出个一二来了。
趁着最近有些韶光，我琢磨着把这半年来的履历总结一下，和同行小伙伴一起互换互换吧。

做电商的都知道，电商产品核心模块就三大块：信息流、资金流、物流。

由于本人做的是虚拟物品交易，没有涉及物流模块，因此不谈论物流干系内容。
而信息流细分开来，可以分为商品信息流和订单信息流（订单流是由信息流和资金流组成的）。
因此，我将会分三个部分来阐释：

商品信息流；订单信息流；资金流。

这篇文章先来讲讲商品信息流吧。

“商品信息流”，听起来很抽象，先不管名词怎么定义，我们先来想一下：浩瀚的商品，从它们被卖家摆到网站上展示，到买家看到这些商品，然后进行选购，全体过程产品经理关注的核心是什么？我想该当因此下两点：

如何让卖家分门别类地把这些商品上传到后台商品库；如何让清晰地向买家展示浩瀚类别的商品，并进行导购；

要回答这些问题，就要从全体商品体系的设计和搭建提及。

一、 无分类

当你的产品量级非常小的时候，所有商品直接摆出来展示就好了，不须要分类。
比如03年淘宝刚上线的时候，便是没有分类的，所有商品直接摆出来展示。

二、 一级类目

当商品越来越多，用户查找开始未便利了，就须要有分类了。
在电商领域我们把这种分类叫做类目，最大略的是一级类目，比如小米商城：https://www.mi.com/。

小米商城首页类目

从上图你可以看到，每一种商品就一个分类（一级类目），没有子分类，这个分类下挂靠了该类眼前的所有商品。

三、 多级类目

当商品的数量再往上走，达到千位级、万位级，乃至更多的时候，一级类目就知足不了需求了，这个时候就涌现了多级类目的观点，也便是我们所说的“ 类目树 ”。

类目树一样平常三级旁边为宜，只管即便不要超过五级。
由于电商有一个公认的铁定律叫“漏斗模型”，也便是层级越深，流失落量越大，就像漏斗一样，越往下口越小，以是类目层级不能太深。

三级类目（图片来源百度）

上图便是一个三级类目的例子。
卖家在上传商品的时候，须要一级一级往下选择，直至确定叶子类目。

四、 类目+属性

当商品的量级达到百万级、千万级乃至亿级的时候，新的问题又涌现了。
比如服装可以分为男装和女装，男装、女装下面又分为T恤、裤子等，而T恤又分很多品牌，裤子按照是非又可以分为九分裤、七分裤等等，这样的类目树一贯分下去，交叉和重合是不可避免的，这就变成了一个很难管理的网。

以是当商品越来越多，分类越来越细，用户搜索越来越个性化，纯挚靠类目树已经不能知足商品管理的需求了。
这个时候就涌现了其余一个维度的分类方法，叫 “ 属性 ”。

“ 属性 ” 怎么理解呢，先看看下面这张图：

属性

这是对付“裤子”这种商品的描述，我们可以用左侧这些形容词去描述它，这个便是我们平时说的标签。
但标签分类太细，数量多了的时候不好管理，当我们把标签按右侧的办法进行归类的时候，这些种别号称就成了我们说的“属性”，左侧的标签便是我们说的“属性值”。

举个普通的例子，我们平时用的微信，通讯录联系人按照26个英笔墨母归类排序，这就好比我们上面说过的类目，然后我们根据联系人的不同特色，给他们进行归类，比如“家人”、“高中同学”、“大学同学”等等，你喜好的话划分个“前男友”或者“前女友”也是可以的。

这些人为的分类便是标签，把相同性子的标签归类成标签组便是属性（比如把“高中同学”和“大学同学”归类为“同学”）。
这里只是举个例子，微信只支持标签，不支持标签组。

有一点须要把稳的是，后台录入商品时，属性必须挂靠在叶子类眼前面。
比如服装——女装——超短裙，超短裙是叶子类目，它下面可以挂靠属性，比如赤色，这样搜索赤色超短裙就能直达商品。
但如果你想把属性挂靠到服装——女装时，女装下面还可以细分很多类目，女装直接挂靠赤色就没故意义了。

类目+属性：找钢网

上图的“找钢网”（http://www.zhaogang.com/）便是范例的“类目+属性”的例子，钢材按照品名、材质、规格、钢厂等进行类目划分，然后通过品牌等进行属性划分。

五、 前台类目+后台类目+属性

那是不是用“类目+属性”就能办理所有商品分类的问题了呢？

答案当然是不能。
先来看看一个很常见的场景：

网站运营职员为了导购，须要常常调度类目属性；但是卖家为了商品稳定，减少不必要的韶光耗费，不肯望调度。
这里就涌现了抵牾。

抵牾的根源其实在于买家和卖家之间的需求差异，运营职员就会旁边难堪，一方面导购是为了给买家更好的体验，另一方面也不肯望卖家常常被折腾。

这里的实质就在于，一个产品，一套逻辑，没办法很好地知足两个截然不同的用户群体。
那怎么办呢？

最早想到办理方案的是08年那时淘宝的一位产品经理，有一次他去逛沃尔玛，他仔细不雅观察了传统超市的商品分类逻辑：

大超市里的商品，在货架上的陈设办法都是常常变来变去的，随着时令、分外节日、发卖状况等成分的变革，商品的陈设办法也会常常做出调度。

但大超市还有一个地方是仓库，仓库里的商品摆放是相对固定的，食品就在食品区，洗护就在洗护区。
以是说，超市里的商品实在是放在两个地方——后台仓库和前台货架，利用的分类方法也是截然不同的。

从这里他受到启示，想出了“前台类目+后台类目”的架构设计方案——把一个产品一分为二，一个知足买家，一个知足卖家，也便是：

卖家通过后台类目发布商品，买家通过前台类目选购商品。

原来的类目变成了后台类目树，其余再建一个前台类目树，然后把前台类目树的叶子类目去和后台类目通过映射关系关联起来。
任何一个前台类目的叶子类目，都可以对应任何一个或多个后台类目，且不一定是后台叶子类目。

举个例子：

比如iPhone X卖得好，那运营职员就可以建立一个“iPhone X”的前台类目，然后把后台的类目【数码产品——手机】和属性【品牌=iPhone & 型号=X】挂到这个前台类眼前，如下图：

前台类目对应后台类目

再来看个实际场景的例子，大家最常用的淘宝网（https://www.taobao.com/）：

淘宝首页前台类目

上图中红圈部分便是范例的运营职员为了运营需求而展示出来的前台类目，其映射的是后台某些类目或属性下的详细商品。

这种设计奠定了我们现在大部分电商产品的商品分类体系模型：前台类目+后台类目+前后台映射管理+属性

回过分来总结一下，从03年我国第一家电商网站淘宝上线，到如今电商网站百花齐放，商品分类体系的演化路径可以归纳为五步，如下图：

商品分类体系的演化

至此，我想和大家分享的第一个知识点——商品分类体系 就已经讲完了。
鉴于本人履历有限，可能还有很多地方理解不到位，或者某些地方表述不清楚的，欢迎拍砖~

期待你我诚挚的互换能碰撞出聪慧的火花 ~ ^ _ ^ ~

本文由@Haby 原创发布于大家都是产品经理。
未经容许，禁止转载

题图来自Unsplash，基于CC0协议