zoukankan      html  css  js  c++  java
  • 从商品类目到属性

    转自:http://www.3lian.com/edu/2013/07-04/78349.html

    产品经理必须是分类控,而商品管理的核心,或者说基础就是“分类”,“分类”方法的变迁是整个商品系统变迁的核心。

      文/苏杰

    从商品类目到属性:产品经理必须是分类控 三联
     

      你应该在淘宝上买过东西,我们来说说最常见的购物过程:

      从某个入口类页面(或广义到产品)开始,经过某种导购过程,到达需要你做交易决策的页面,之后进入交易过程。

      入口,最典型的是淘宝首页或某个活动页面,当然,对于一些资深的淘宝买家,他的入口也可能是“我的淘宝”、某个“垂直市场首页”、收藏的某个“店铺首页”,甚至是某些有SNS属性的页面,比如淘宝内部的论坛、帮派,或外部的蘑菇街、美丽说。

      然后,从这个入口到一个具体的商品详情页面,也叫商品detail页的过程,都可以视为广义的导购过程。淘宝可以根据买家是否有明确的购物需求,用不同的产品来导购。

      因此,在设计导购路径的时候,对有明确购物目标(比如说要买一双Nike鞋,连货号都知道了)的买家,提供搜索、搜索结果页;对只有模糊购物目标 (比如想买几件T恤、一个路由器)的买家,则提供类目导航、各种频道页导航;对于没有购物目标(很像线下逛街的女生,随便看看,看到好的就买)的买家,可以提供各种促销活动信息。

      导购的过程页面,经常是一个列表,所以也叫list页。

      随着购物诉求越来越多样,近年来淘宝开始尝试通过购物的心理诉求来分类导购,比如求新、求便宜(对list页按照价格排序就是很典型的对应功能)、求实惠、求品质、从众(按销量排序)、追星等等,或者是场景化的导购,比如对装修,可以按照水电阶段、泥瓦阶段、木工阶段、油漆阶段、软装阶段等引导买家。这里面的学问很多,靠的是对行业和用户的理解。

      这个环节背后,还有一些买家不太能感受到的产品,也发挥着不可或缺的作用,比如营销体系、会员体系、广告系统等,有时候出现在你面前的宝贝,可能是根据你的会员信息,通过营销或广告系统里某个强大的算法算出来的。

      接下来,你到了商品detail页,在页面上浏览各种信息,做出购买决策,可以不买,可以“立刻购买”,也可以再考虑考虑,把宝贝放进“收藏夹”或“加入购物车”,还可以通过阿里旺旺和卖家沟通。

      之后就进入交易过程,从付款到卖家发货到买家确认收货、评价。当然,还有可能存在逆向流程,比如退款、退货。

      产品经理必须是分类控

      从2003年到2013年,淘宝从零开始,发展非常快,做到了一年上万亿的规模。2012年双十一,淘宝的峰值交易额是191亿,天猫做了132亿,集市做了59亿。

      要把这些需求支撑起来,技术当然很重要,但从产品的角度来看,这就是一个系统,根据需求的变化,从简单逐渐变得复杂的现实案例。接下来,我们将以淘宝上最最核心的一个对象——商品,也叫宝贝为例,来说说系统的变迁。

      我觉得,产品经理必须是分类控,恨不得把家里的各种东西都归类放进对应的盒子里,然后盒子上都贴上标签,再盒子套盒子……而商品管理的核心,或者说基础就是“分类”。

      2003年5月,淘宝刚上线的时候,只有几个商品,可以想象,很容易管,根本不需要分类,无非就是把几个商品铺开来给用户选就行了。随着商品多起来以后,才牵扯到分类。因为我们有了很多商品以后,就需要管理,首先需要梳理清楚,分清楚才能去管,不能10亿商品一个个管,没有意义,“分类”方法的变迁是整个商品系统变迁的核心。

      刚开始分类很简单叫类目,类目就是一个纯粹的分类,像服装、电器、手机等这样分下去。我们拿服装来做例子,当所有商品到100多个的时候,服装有20个,不需要再分了;到了1000个的时候,服装有400个,不分也可以,但已经不太好选了,如果40个商品一页的话,就要翻10页,用户翻页的耐心最多就3页,第3页以后的商品,点击非常低。

      到了10000个商品的时候,你不分就傻了,是一种浪费。因为我们发现,在商品数量比较少的时候,总交易额和商品数量强烈正相关,而这里的商品数量,是能被买家看到的有效数量。于是当商品数越来越多,到10万、100万、1000万的时候,我们就需要把类目分得更细,但是不可能全部平铺。想象一下,一下子展现给买家1000个类目让他筛选,是没有意义的。所以出现了多级类目的概念,就是一棵类目树。

      可问题是:商品越来越多,类目树就会越来越深,这是问题的本质,整整困扰淘宝4年时间。

      为什么?正常的用户购物路径,从服装到男装到T恤,每一次点击,用户都会有一定比例的流失,大概超过50%,这样你可以算一下,0.5×0.5×0.5,这样再下去就没几个用户进来了。但另一方面,商品太多,你又必须得这么分,有很多品牌,比如说杰克琼斯、美特斯邦威、耐克,不分出来,那在T恤上找,也是很费力的。

      再者,这样分下去,我们的小二也会比较累,很乱。我们发现,除了男装,女装下面也是有T恤的,T恤下面也是有品牌的,美特斯邦威、耐克……这样的树分下去以后,交叉和重合不可避免,变成了一个很难管理的网。

      这两个问题怎么解决?直到2006年,淘宝才引入了“属性”的概念。这是一个革命性变化。为什么这么久?一方面,淘宝小二对业务的理解有一个过程。商品管理的本质是分类,今天很多小二都能回答出来,但当初能够回答出来的很少;另一方面,商品数量是逐步增长的,这个问题到2006年才变成一个会死人的问题。对产品经理来说,问题总是太多,资源总是太少,什么问题是会死人的才优先解决。在2004、2005年用类目分下去还不会死人,到2006年商品数量已经破千万了,意味着这样分下去就没办法分了。

      这个时候,淘宝有一个传奇的产品经理——一灯,提出了属性的概念,属性很好地解决了上一段提到的两个问题。与类目相比,属性更离散、更灵活,类似tag。

      品牌是一个属性,性别、颜色、尺寸、材质也是属性。属性下面会有值,即属性值,比如品牌下面有杰克琼斯、耐克、诺基亚、苹果,所以属性的本质还是为了分类。

      其实,最早有属性的类目是食品。淘宝上卖食品,食品监管部门说食品有些标准化信息必须有,比如批文、生产日期、健字号。于是淘宝对食品类目做了十几个属性定义,每个商品有不同的属性、不同的属性值。最早这个属性只是用来描述的,而不是用来分类的。淘宝的很多产品,都是灰度发布的,比如先用个别类目做属性的试点就是一个例子。

      回到属性,我们讲到类目之外又有了属性,属性下面有属性值,其实有的属性值还会变成子属性。子属性是为了更好地分类,比如品牌和子品牌(或系列)。品牌是属性,阿迪、耐克、匡威是属性值,同时阿迪又会是一个子属性,它的子属性值为“Performance系列(三条纹),Originals系列(三叶草)和style系列(圆球型LOGO)”。如果没有子属性的概念,那又会出现没有子类目一样的情况,太多的属性值并列,导致无法筛选。

      品牌和系列,在现实中也是有从属关系的,比较适合把系列挂在品牌下面,这样一个品牌有相应的系列,另外一个品牌有另外相应的系列,本质上是为了更好地分类。所以说,属性和类目一样,也是一棵树——属性树,并且也有级数的控制。

      我们再来看看属性值的管理。大家有没有发现属性值和属性值其实是不同的?有的比较简单,属性值是离散的,比如性别只有两类——男、女,最多加上“中性”。有的稍微复杂一点,比如手机的品牌下面有苹果、诺基亚、三星等,服装的品牌有杰克琼斯、耐克等,但小二很难列全,因为这个东西是不断变化的。还有的更复杂一点,比如重量,它是一个连续的值,没有办法全列出来。用一个表格简单地表示一下上述三种属性值,如下表所示。

      属性值在客观上的不同,导致了产品上的一些区别,这三种从上到下,有两点值得说说。

      第一,管控的尺度是越来越松的,这比较容易理解。枚举不可输入——性别,是人都能列全,我们直接定了。枚举可输入——品牌,我们设想一下,如果品牌不能由卖家输入,卖家发布商品的时候就可能找不到自己的品牌。这时候怎么办?大家很容易想到解决方案——增加“其他”。但这样会使得我们永远不知道某些品牌,所以,可输入起到一个信息采集的作用,因为正常的属性值小二是不可提前预知的。系统通过用户输入的行为进行一个排序,比较重要的就跳出来,小二把它加到可选范围里面去,这样属性值就更完善了。而不可枚举,是放开让卖家自己玩的。(是否可枚举是指平台是否可枚举)

      第二,分类的功能是越来越小的。一般来说不可枚举的东西,是不可以分类的,这意味着这个值是描述性的。比如说尺寸、体积、重量,这种是不可枚举的,因为这种东西直接拿这个值做分类是没有意义的,但是有些时候可能会按区间来做分类。比如颜色,它某种程度上跟价格是一样的,因为颜色稍微变一点,就可以分出来,但是有谁能够说出20种以上的颜色?很难,如果你把几万种颜色描述出来,那对用户没有意义。所以产品经理就在做简化的动作,我们归归类好了,比如说红色、蓝色、灰色,再细一点,天蓝色、天青色,再加个“其他”,这样来分,把一个不可枚举的属性变成了可枚举的区间。

      有了这些属性以后,怎么跟类目搭上关系?

      首先,属性只能挂在叶子类目下面。非叶子类目其实也有对属性的需求,但那是通过另外的方式来实现的,谈到公共属性的时候,会说到这个问题。

      其次,类目和属性是有关联关系的。举个例子,对于T恤这个类目来说,品牌这个属性肯定是需要的,材质也是必须的,性别不需要,假设T恤的父类目是男装,颜色也是需要的,尺码也是需要的……我们发现,有些属性适合放在这个类目,有些属性不适合放在这个类目,所以,我们建立了一个很重要的关系,就是类目属性。这是淘宝的专有词汇,类目与属性是有关联关系的,每个类目都有自己特有的属性。

      那么,类目和属性怎么跟商品关联上?其实很简单,卖家发布商品的时候,先从根目录选到叶子类目,再选择这个叶子类目对应的类目属性的各种属性值。

      至此,我们对整个商品的描述很完整,也很完美,有了属性以后,我们分1亿商品都能轻松搞定。但是,接下来新出现的问题才是更严重的。

      产品经理需要解决问题,而不是优化产品

      我们继续以品牌这个属性举例。作为淘宝的小二,每个人能说出来的品牌非常有限,一般只有几十个,能说出几百个已经是行业专家了,但是整个中国乃至世界汇集的品牌至少几万个,怎么办?让消费者怎么选?意味着品牌这个属性的属性值一定要再想办法细分。小二当然也很聪明,就搞出了“男装品牌”、“女装品牌”、“手机品牌”等等不同的属性。

      那么,男装品牌T恤挂在男装的叶子类目T恤下面,女装品牌T恤挂在女装的叶子类目T恤下面。不同类目的运营小二因为分工的关系,各自维护各自类目的品牌属性值,这样就带来几个问题。

      第一,不同类目下都有品牌这个属性,但数据库里的ID不一致。

      第二,品牌之下的属性值不唯一。比如,男装的“耐克”在数据库里面有一个单独的值,女装的“耐克”在数据库里面又有另外一个值,属性值不归一了。这样就很乱,本来都是耐克,但是男装耐克和女装耐克是没有关系的,对前台导购来说,这是非常怪异的事情。

      第三,同样一个“阿迪达斯”,不同小二定义的格式不一样,可以是阿迪达斯、阿迪、adidas、Adidas等等。

      如果放任上述问题存在,基于品牌的管理是没办法做的,所以,我们做了“属性归一”的事情。这个事情又要分两块来看,一是历史的问题,一是将来的问题。

      先说历史问题。当时我们把某些需要归一的属性列出来,比如“品牌”,通过这个关键字找,然后看一下所有属性里面是“品牌”意思的属性,把这些属性合并掉,并在一个ID下,再把下面的属性值也做合并,解决上述后两个问题。你可以想象,我们先要考虑“哪些属性需要做归一、哪些属性值要做归一”,然后再一步步操作,这是一个非常庞大的人肉工作。

      更悲惨的是,这只能解决历史问题,没有办法解决将来。

      当我们把“品牌”人肉完了以后,截止那一刻,品牌和品牌值都是很“干净”的,而且为了避免第三个问题,对品牌值我们还做了一个规范,英文在前面,中文在后面,然后用反斜杠隔开。但是,品牌下面的属性值还是有几万个,让小二在几万个属性值里面挑出来,他会嫌烦,所以很多小二还是“违规”操作,他可能直接输入一个,按照自己意愿,比如说“Nokia/诺基亚”已经有了,他会直接输入一个诺基亚,然后把这个值挂到他自己的类目属性里面去。这也就是说,又有两个诺基亚了,于是我们只能定期去清理。

      这个问题很难用产品来彻底解决,原因有很多,比如说品牌的复杂性,可能有的品牌并没有英文或者是中文。所以,我们后来用了一个看起来很傻的方案——整个淘宝品牌管理里面,允许品牌输入的只有唯一一位小二(截至2012年初)。现在是谁?有几个人?或者有什么更好的办法?过几年再和大家分享。从这些例子里我们看到,在特定的场景下,一个问题不一定要用传统意义上的“开发产品功能”来解决,产品经理的责任从根本上来说是解决问题,而不是做产品。

      但,有了这个专职的小二以后,还是需要定期清理,为什么?因为由小二添加品牌是相对可以做得规范一点,但还有大量的品牌是通过枚举可输入的方式进来的,这也是为了丰富我们的品牌库。一旦这些卖家输入的品牌下面的商品数量达到一定程度,我们又需要把这些品牌进行归一,整理到小二认可的品牌值里面,所以这个清理是一个持续的动作,直到2012年还在做。

      品牌这个属性比较关键,还可能人肉做,而其他的一些属性,很多就乱着放在那里。当然,将来我们希望有产品经理能够通过系统的方式彻底解决掉这个问题。

      (原载于《天下网商·经理人》六月刊)

  • 相关阅读:
    WPF中DataGrid控件的数据绑定与显示数组
    WPF中添加个简单的显示当前系统时间的示例
    WPF中往ComboBox里添加选项并指定默认选项
    WPF中Button的四种状态
    Web安全新变化 智能手机是下一个进攻点 狼人:
    卡巴斯基重拳组合 高效应对高考网站挂马 狼人:
    DNS规模故障追踪:由24岁站长引发的蝴蝶效应 狼人:
    追踪多省网络故障:域名解析瘫痪后的连锁反应 狼人:
    化解SaaS安全问题的三大措施 狼人:
    报道称黑客利用微软IIS安全漏洞 入侵大学服务器 狼人:
  • 原文地址:https://www.cnblogs.com/panning/p/5925967.html
Copyright © 2011-2022 走看看