[认识龙井茶分类]
[推荐性国家标准 地理标志产品 龙井茶]
【物流强国】
[视频]-日日顺仓库
[思考与讨论]
随着仓库的智能化，还有没有必要对仓库储存商品进行分类管理？为什么？
【零售企业商品分类管理目的探讨】
[案例分析] 啤酒为什么会和尿不湿放一起?
这个现象最开始是在美国的沃尔玛超市当中出现的。
他们超市的管理人员分析销售数据时发现了一个令人难以理解的现象:在某些特定的情况下，“啤酒”与“尿布湿”这两件看上去毫无关系的商品会经常出现在同一个购物篮中。
这种独特的销售现象引起了管理人员的注意，经过后续调查他们发现，这种现象大多出现在年轻的父亲身上。
在有婴儿的美国家庭中，一般是母亲在家中照看婴儿，年轻的父亲前去超市购买尿布湿。父亲在购买尿布湿的同时，往往会顺便为自己购买啤酒，这就出现了啤酒与尿布湿这两件看上去不相干的商品经常被放入同一个购物篮的现象。
如果这个年轻的父亲在卖场只能买到上述两件商品中的一件，则他很有可能会放弃购物而到另一家商店，直到可以一次同时买到啤酒与尿布湿为止。
沃尔玛超市发现了这一独特的现象，开始在卖场尝试将啤酒与尿布湿摆放在相同的区域，让年轻的父亲可以同时找到这两件商品，并很快地完成购物。
而沃尔玛超市也因为让这些客户一次性购买两件商品而不是一件，从而获得了很好的商品销售收入。
当然“啤酒与尿布湿”的故事最终也是有理论依据:1993年美国学者Agrawal通过分析购物篮中的商品集合，从而找出商品之间关联关系的算法，并根据商品之间的关系，找出客户的购买行为。
以上资料，来源于网络资料
[任务]
[视频]-国家相册
[任务]这段视频中茶的分类标志是什么？
电子商务商品分类管理目的探讨
分享一篇文章 转载自微信公众号 淼凡大叔
淼凡大叔 gh_87b2af481a0f 2019-02-14
众所周知的电商商品分类已成为电商人不可回避的话题，贝索斯的飞轮效应中的第一个杀手锏就是品类效应。
电商有三大核心商品模块：物流、信息流、资金流，本文大家详细介绍商品信息流模块是如何构建的。
半年前由于机缘巧合，有机会设计一个电商产品。因为本身不是做电商出身，没有什么电商产品设计经验，所以只能边学边做。
这半年来，我看了大量的书籍、视频和文章，也和许多同行的前辈交流过，再加上自己在实践中的打磨，现在大体上能够说出个一二来了。趁着最近有些时间，我琢磨着把这半年来的经验总结一下，和同行小伙伴一起交流交流吧。
做电商的都知道，电商产品核心模块就三大块：
信息流、资金流、物流。
由于本人做的是虚拟物品交易，没有涉及物流模块，因此不讨论物流相关内容。而信息流细分开来，可以分为商品信息流和订单信息流（订单流是由信息流和资金流组成的）。因此，我将会分三个部分来阐释：
商品信息流；
订单信息流；
资金流。
这篇文章先来讲讲商品信息流吧。
“商品信息流”，听起来很抽象，先不管名词怎么定义，我们先来想一下：众多的商品，从它们被卖家摆到网站上展示，到买家看到这些商品，然后进行选购，整个过程产品经理关注的核心是什么？我想应该是以下两点：
如何让卖家分门别类地把这些商品上传到后台商品库；
如何让清晰地向买家展示众多类别的商品，并进行导购；
要回答这些问题，就要从整个商品体系的设计和搭建说起。
一、 无分类
当你的产品量级非常小的时候，所有商品直接摆出来展示就好了，不需要分类。比如03年淘宝刚上线的时候，就是没有分类的，所有商品直接摆出来展示。
二、 一级类目
当商品越来越多，用户查找开始不方便了，就需要有分类了。在电商领域我们把这种分类叫做类目，最简单的是一级类目，比如小米商城
小米商城首页类目
从上图你可以看到，每一种商品就一个分类（一级类目），没有子分类，这个分类下挂靠了该类目下的所有商品。
三、 多级类目
当商品的数量再往上走，达到千位级、万位级，甚至更多的时候，一级类目就满足不了需求了，这个时候就出现了多级类目的概念，也就是我们所说的 “ 类目树 ”。
类目树一般三级左右为宜，尽量不要超过五级。因为电商有一个公认的铁定律叫“漏斗模型”，也就是层级越深，流失量越大，就像漏斗一样，越往下口越小，所以类目层级不能太深。
三级类目（图片来源百度）
上图就是一个三级类目的例子。卖家在上传商品的时候，需要一级一级往下选择，直至确定叶子类目。
四、 类目+属性
当商品的量级达到百万级、千万级甚至亿级的时候，新的问题又出现了。比如服装可以分为男装和女装，男装、女装下面又分为T恤、裤子等，而T恤又分很多品牌，裤子按照长短又可以分为九分裤、七分裤等等，这样的类目树一直分下去，交叉和重合是不可避免的，这就变成了一个很难管理的网。
所以当商品越来越多，分类越来越细，用户搜索越来越个性化，单纯靠类目树已经不能满足商品管理的需求了。这个时候就出现了另外一个维度的分类方法，叫 “ 属性 ”。
“ 属性 ” 怎么理解呢，先看看下面这张图：
属性
这是对于“裤子”这种商品的描述，我们可以用左侧这些形容词去描述它，这个就是我们平时说的标签。但标签分类太细，数量多了的时候不好管理，当我们把标签按右侧的方式进行归类的时候，这些类别名称就成了我们说的“属性”，左侧的标签就是我们说的“属性值”。
举个通俗的例子，我们平时用的微信，通讯录联系人按照26个英文字母归类排序，这就好比我们上面说过的类目，然后我们根据联系人的不同特征，给他们进行归类，比如“家人”、“高中同学”、“大学同学”等等，你喜欢的话划分个“前男友”或者“前女友”也是可以的。
这些人为的分类就是标签，把相同性质的标签归类成标签组就是属性（比如把“高中同学”和“大学同学”归类为“同学”）。这里只是举个例子，微信只支持标签，不支持标签组。
有一点需要注意的是，后台录入商品时，属性必须挂靠在叶子类目下面。比如服装——女装——超短裙，超短裙是叶子类目，它下面可以挂靠属性，比如红色，这样搜索红色超短裙就能直达商品。但如果你想把属性挂靠到服装——女装时，女装下面还可以细分很多类目，女装直接挂靠红色就没有意义了。
类目+属性：找钢网
上图的“找钢网”（http://www.zhaogang.com/）就是典型的“类目+属性”的例子，钢材按照品名、材质、规格、钢厂等进行类目划分，然后通过品牌等进行属性划分。
五、 前台类目+后台类目+属性
那是不是用“类目+属性”就能解决所有商品分类的问题了呢？
答案当然是不能。先来看看一个很常见的场景：
网站运营人员为了导购，需要经常调整类目属性；但是卖家为了商品稳定，减少不必要的时间耗费，不希望调整。这里就出现了矛盾。
矛盾的根源其实在于买家和卖家之间的需求差异，运营人员就会左右为难，一方面导购是为了给买家更好的体验，另一方面也不希望卖家经常被折腾。
这里的本质就在于，一个产品，一套逻辑，没办法很好地满足两个截然不同的用户群体。那怎么办呢？
最早想到解决方案的是08年那时淘宝的一位产品经理，有一次他去逛沃尔玛，他仔细观察了传统超市的商品分类逻辑：
大超市里的商品，在货架上的陈列方式都是经常变来变去的，随着季节、特殊节日、销售状况等因素的变化，商品的陈列方式也会经常做出调整。
但大超市还有一个地方是仓库，仓库里的商品摆放是相对固定的，食品就在食品区，洗护就在洗护区。所以说，超市里的商品其实是放在两个地方——后台仓库和前台货架，使用的分类方法也是截然不同的。
从这里他受到启发，想出了“前台类目+后台类目”的架构设计方案——把一个产品一分为二，一个满足买家，一个满足卖家，也就是：
卖家通过后台类目发布商品，买家通过前台类目选购商品。
原来的类目变成了后台类目树，另外再建一个前台类目树，然后把前台类目树的叶子类目去和后台类目通过映射关系关联起来。任何一个前台类目的叶子类目，都可以对应任何一个或多个后台类目，且不一定是后台叶子类目。
举个例子：
比如iPhone X卖得好，那运营人员就可以建立一个“iPhone X”的前台类目，然后把后台的类目【数码产品——手机】和属性【品牌=iPhone & 型号=X】挂到这个前台类目下，如下图：
前台类目对应后台类目
再来看个实际场景的例子，大家最常用的淘宝网：
淘宝首页前台类目
上图中红圈部分就是典型的运营人员为了运营需求而展示出来的前台类目，其映射的是后台某些类目或属性下的具体商品。
这种设计奠定了我们现在大部分电商产品的商品分类体系模型：前台类目+后台类目+前后台映射管理+属性
回过头来总结一下，从03年我国第一家电商网站淘宝上线，到如今电商网站百花齐放，商品分类体系的演变路径可以归纳为五步，如下图：
