如何进行商品分类,用户才会买单?

去年底寻空在虎嗅网发布了一篇文章《同样是商品分类,京东和淘宝有什么不同?》,相信这篇文章让大家对X型分类(依据商品自身属性进行的分类)和Y型分类(依据用户标签进行的分类)记忆深刻。作为对京东所展示的分类进行用户体验评估的人员,在看完这篇文章后,脑海中立马闪现出千万个疑问: 哪些用户会使用分类? 什么样的分类才能满足用户的查找需求? X型分类真的已经不再适用于目前信息爆炸和用户消费升级的时代? Y型分类真的可以辅助用户的商品查找? …… 当然,核心问题在于如何进行商品分类,用户才会买单? 带着这些问号,我们与分类产品的用户进行了一次“亲密接触”。 以下是寻空文章中X型分类和Y型分类的示例:   用户查找商品的途径 诚然,在解答这诸多疑问之前,有一个首当其冲的问题便是分类的使用率,这需要从用户查找商品的途径谈起。   随着用户网购经验日趋丰富以及电商网站商品丰富度的提升,用户对购物效率的关注度逐步提高,搜索和个性化推荐日益成为用户查找商品的主要途径,相应地对分类的使用则越来越少(这一点从分类产品的流量数据分析也可以验证)。基于此,分类产品从用户的需求变化出发进行产品功能和运营优化至关重要。 从用户使用场景出发进行商品分类 目前,用户使用分类导航的场景可以分为以下三种类型(此项发现是基于我们的用户使用分类导航的行为,与其他平台的用户使用行为可能存在差异): 场景1-模糊挑选 这种场景下,用户更多通过分类导航来查找一些自己不太熟悉的品类商品,如女性用户对于电脑办公、3C类商品不熟悉,会更多通过分类来查找;或者查找一些对于品牌/型号没有特定要求的商品,如生活日用类商品。此时用户的核心诉求在于快速定位到自己想要找的商品品类,之后进行进一步的筛选和决策。明确的X型分类结合适量的Y型分类可以辅助用户在这一场景下的商品查找。 场景2-精准查找 京东的老用户更多有这种使用场景,对京东的分类较为熟悉,加之遇到过搜索结果与实际不符的情况,所以使用分类来查找商品成为一种习惯。这种场景下用户对于分类维度设置及分类所覆盖的商品范围的精准度要求较高。明确的X型分类和精准的后台SKU存储类目路径将提升用户在这一场景下的查找体验。 场景3-随意浏览 这种场景下用户没有明确的购买目的,随意浏览来打发无聊的时间,通过“逛”分类来发现一些可以买的东西或者可以参加的促销活动。此时X型分类对用户而言并没有吸引力,Y型分类便可以“趁虚而入”了。 综上,基于用户的使用场景,将X型分类和Y型分类相结合进行商品分类,满足用户在不同场景下的查找需求。当然,在进行类目设置时,要考虑品类间的差异性,标品需要清晰的X型分类导航,非标品则要更多考虑Y型分类的运营。因“品类”制宜,方能迎合用户需求。 一些关于类目运营的迷思 在进行类目运营时,我们需要考虑诸多因素: 用户侧:用户对品类的认知架构、购物行为习惯 业务侧:品类的发展现状及规划、行业环境、市场发展潜力 平台侧:整体品类的发展现状及战略规划 因此,品类架构及其展示是基于这多方因素综合考虑和权衡之后所诞生的一个“产品”,在进行类目维度设置及品类曝光的决策时,这诸多因素或多或少都会让我们有些“头疼”。以下是我们在对分类进行用户体验评估时经常遇到的一些“迷思”,这些迷思并没有标准的答案,仅在此呈现个人的分析思路。 1. 品类曝光:展示全品类 VS 包装爆品 这个问题业务同事和做类目运营的同事都会遇到,平台有形形色色的品类,但是分类导航处的空间是有限的。这有限的空间应该用来展示所有的商品品类还是对某几个品类进行深度运营,包装爆品? 对于这个问题,我们需要因“时”制宜:对品类进行深度运营的前提是已经建立了品类用户对于品类的基本认知,所以在平台或者品类发展初期,我们需要展示全品类,培养用户认知,引导用户购买;在业务进一步发展之后进行深度运营,包装爆品。类目运营需要契合品类所处的发展阶段及用户对品类的认知水平。 2. 类目维度设置:求全 VS求优 当然,后台SKU存储的类目架构一定是求全的,此处所讨论的类目维度设置是指在展示给用户的商品分类中,类目维度应该是求全还是求优。 以下是对于“地方特产”品类的两种类目维度划分,你认为以哪种维度进行展示更好呢? 维度1中,以“大区”维度进行展示,每个分类下可以展示更多的商品,保证商品种类的丰富性;维度2中,展示“热门省市/地区”,虽然展示的省市/地区数量有限,但更能激发用户的浏览意愿,毕竟在用户的认知中,特产与所处的省市/地区联系更为紧密,而不是所处的大区。在后期的数据验证中,维度2的类目引流效果也更好。 综上,类目维度设置不能一味求全,要从品类自身出发,适度“求优”,契合品类用户的浏览和查找习惯。 3. 虚拟业务运营思维:品类思维 VS 平台思维 从品类出发,可将业务划分为不同品类的业务类型;从平台出发,可将业务划分为两种形态-实物和虚拟。对于虚拟业务,应该如何进行运营呢? 从品类思维出发,虚拟业务与相应的实物业务关联性强(如体育用品和体育服务),联合运营更能促进用户转化及关联购买;从平台思维出发,将不同类型的虚拟业务进行统一整合,更能增强用户对虚拟业务类目的整体感知。基于此,在对虚拟业务进行运营时,需要将品类思维和平台思维相结合。具体到商品分类中,则是在实物分类和虚拟业务分类中对相应的品类进行双显,满足用户不同路径下的查找需求。 提升类目运营效果的方法/技巧 诚然,类目运营对于品类的发展至关重要。那么如何提升类目运营的效果呢?以下是一些实战经验。 1. 年度/季度品类规划,及时调整运营策略 需要制定年度/季度品类规划,对整体品类进行盘点,明确优势品类、弱势品类、高潜品类等,针对不同的品类制定相应的运营策略,同时结合业务的实际发展进行及时调整。 2. A/B测试,确定类目划分维度 […]

与JDReact的第一次亲密接触 ——加油卡项目总结

JDReact 平台是在 Facebook ReactNative 开源框架基础上,进行了深度二次开发和功能扩展。不仅打通了 Android/iOS/Web 三端平台,而且对京东移动端基础业务能力进行了 SDK 级别的封装,提供了统一、易于开发的 API 。基于以上种种优势,加油卡壳牌业务决定使用 JDReact 技术进行开发。 由于这是我们团队首次使用 JDReact ,在开发过程中遇到了很多问题:不熟悉 JDReact 提供的 API 、如何调用后台数据接口?怎样切换测试、预发环境?开发完后怎样打包?如何上线?等等每个流程都不熟悉。因此,在完成项目之后,很想做一个总结,从前期准备到最终项目上线的整个流程做一个分享,希望能为初次使用 JDReact 的同事有所帮助!如有错误,还请多多指教! 1 前期准备 1.1 项目背景 加油卡壳牌业务是京东APP中的一个项目,可以从首页的「充值缴费」入口进去,如下视频演示: 1.2 项目环境配置 1.2.1 开发分支以及文件结构 初始项目中只包含一个 dev 分支,最后打包 APP 时会从该分支中抽取代码,所以我们新建了一个 trunk 分支,平时在该分支上进行开发,最后打包 APP 的时候再切换到 dev 分支,合并代码。 对于文件结构,如上图所示,其中 Navigation.js 设置页面路由信息,以及打开项目时进入的默认页面;pages 文件夹下存放项目的每个页面代码;images 存放项目开发中使用到的图片;components 文件夹下存放页面中用到的各个组件。 1.2.2 安装依赖环境 按照 JDReact 团队给出的安装依赖环境的步骤,当执行 npm start […]

“猜你喜欢”设计总结

‘猜你喜欢’当然它还有很多词汇可以形容,比如:为您推荐、为您精选…;经常在移动端购物的剁手一族们肯定都不会陌生;它似乎无孔不入般的存在于我们浏览的各种页面中作为长尾内容进行向用户补充推荐。我们在浏览时可能并不会细想其背后的逻辑是什么?这样设计的原因是什么?但仔细观察就会发现,虽然它们都有共同的名字‘猜你喜欢’,但在不同的运用场景下,其设计与推荐逻辑存在很大的差异化。 本文将从设计师的角度出发,全面而细致的介绍‘猜你喜欢’内容设计的思考与总结。首先,先来介绍一下什么是长尾 一、什么是长尾: 长尾(The Long Tail)这一概念是由Chris Anderson在2004年十月的“长尾” 一文中最早提出,用来描述诸如亚马逊和Netflix之类网站的商业和经济模式。 长尾理论是网络时代兴起的一种新理论,当商品的销售成本急剧降低时,几乎任何以前看似需求极低的产品,只要有卖,都会有人买。这些需求和销量不高的产品所占据的共同市场份额,可以和主流产品的市场份额相比,甚至更大 二、设计‘猜你喜欢’的原因: 简单了解长尾的含义后,可以清晰的知道移动电商在页面中要加入长尾设计(猜你喜欢)的原因:利用互联网移动端页面无限长的框架进行更多货品的曝光来留住剩余未跳转流量进行商品售卖来实现价值最大化 三、‘猜你喜欢’常见的内容形式: 猜你喜欢的推荐逻辑多以用户历史浏览记录或已购买记录进行推荐,而单品推荐更加贴近触达用户;因此,单品是经常运用到的展示形式,后续讲到的关于如何设计猜你喜欢也是以单品为例。同时,随着推荐逻辑的逐渐完善,为了丰富产品内容以及满足用户多维度需求,逐渐增加了关键词、促销活动、品牌、资讯等内容形式,通常以穿插的形式展示在单品列表中 四、如何设计‘猜你喜欢’: ‘猜你喜欢’涉及的后台技术为BI推荐(实现模型),即将现有的用户数据进行有效整合,快速准确的提供决策依据,帮助产品做出明智的内容呈现,这里将不在多做介绍延展;主要从界面设计(表现模型)、及用户分析(心理模型)这两方面出发进行分析。 在移动端购物APP界面中,运用猜你喜欢的场景大致有如下页面:首页、搜索结果页、商品详情页、购物车页、个人中心页、购买成功页、订单详情页、物流详情页、大促页面等场景。接下来,将分场景介绍在不同页面下如何设计‘猜你喜欢’。 4.1首页: 是最重要的运用场景,如京东、淘宝、严选等的首页都是以猜你喜欢作为长尾展示。用户在浏览首页时,多以无目的闲逛为主,当用户未在重点活动或栏目入口处点击跳走,此时进入长尾内容区‘猜你喜欢’,如何留住用户的脚步是其重点;因此首页‘猜你喜欢’的推荐逻辑多以用户历史浏览记录来向用户推荐,以此来激发用户的潜在遗忘需求。 随着首页猜你喜欢运用场景的完善,后续可以单品推荐为主,增加关键词、品牌、促销活动、内容资讯、店铺等内容的穿插,既能丰富内容推荐维度,又能满足不同维度偏好的用户在闲逛时激发其潜在需求 在设计首页猜你喜欢单品样式时,也从最初由图片、标题、价格三种元素组成的基础样式,逐渐演变新增了功能按钮:看相似/不喜欢/加车、推荐理由、标签、标识等的展示。对于这方面的具体设计将在后面详细讲到 4.2搜索结果页: 搜索是用户在移动端购物使用的重要场景,此时用户目的明确,但不排除所输入词汇系统不可整体识别而出现缺省页的情况;或者,筛选出的结果太少等情况的发生。为避免这两种情况的发生,往往会通过猜你喜欢的形式,识别用户所输词汇的部分字段进行推荐,或者历史浏览记录向用户进行推荐。 4.3商品详情页: 用户在浏览商详页时,此时目的较为明确:对此商品有较高兴趣或需求;在此场景下,若用户未能进行直接购买的行为,如何让用户在此场景需求下继续逛下去是其重点;因此商详页‘猜你喜欢’的推荐逻辑多以相似商品或排行榜形式来向用户推荐,以此来补充用户对比较、筛选场景的需求。 商品详情页包含商品基础信息介绍(图片/价格/促销/店家等)、评价、图文详情等,页面篇幅较长;此时,很难像首页一样把猜你喜欢作为长尾进行展示处理。原因有两点:1.在海量商品面前,用户更多是通过基础信息项来锁定商品,在多数情况下很难浏览到页面靠下的位置,若还作为长尾展示,很难进行模块的曝光;2.此场景下的猜你喜欢满足了用户对此类商品比较筛选的需求,在初期商品筛选中,与图文详情相比对用户意义更大。 因此,对商详页猜你喜欢的设计,往往会固定模块高度放在商品基础信息(图片/价格/促销/店家等)之后,图文详情之前进行展示。常用形式为:一排三个展示两排,可滑动拓展的形式解决因限制模块高度而造成的商品曝光数量受限的问题。这里的单品样式较为简单,多以图片、标题、价格三种元素组合而成。 4.4购物车页: 购物车页属于功能型页面,用户多数是查看已加车商品或选择商品进行支付,是进行支付环节的前一步,以目的性浏览为主;如何提升下单率是其重点;因此购物车‘猜你喜欢’的推荐逻辑多以加车记录来向用户推荐,以此来满足用户对比筛选的需求。表现形式如:购物车有XXX的人还在对比;购买XXX商品的人还买了。 4.4个人中心页: 与购物车页一样属于功能型页面,是用户相关信息整合页,以目的性浏览为主。此页面‘猜你喜欢’的作用是以补充内容,长尾展示为用户曝光商品为主,推荐逻辑多以用户历史浏览记录来向用户推荐。 4.6售后环节:购买完成页、订单详情页、物流详情页 售后环节的购买成功页/订单详情页/物流详情页与个人中心页面一样,是用户相关信息整合页,以目的性浏览为主。其猜你喜欢的作用是:补充内容,长尾展示为用户曝光商品;推荐逻辑可以此订单商品的连带商品向用户推荐,挖掘其潜在需求。 4.7大促页面:主会场、分会场等 大促页面是猜你喜欢运用的另一重要场景;因大促页面内容较多,页面篇幅也较长,猜你喜欢主要作为补充内容进行长尾展示;推荐逻辑多以用户历史浏览记录+会场属性来向用户推荐。因本身大促页面设计及促销信息繁杂,此时猜你喜欢的样式设计趋向简单更容易释放用户的浏览压力,因此样式多以图片、标题、价格、看相似等基础元素组合而成,以一排两个或三个的形式进行展示。 五、‘猜你喜欢’组件化设计: 在众多场景中都有猜你喜欢的涉及,为了提高设计、开发的工作效率,以及用户体验的一致性,规范猜你喜欢单品样式,进行组件化设计是一个很好的方法。目前猜你喜欢的单品模块可以归纳为七个组件,分别为: 1.商品图片:占据最大位置的组件,也是用户关注的首要元素 2.商品标题:有一行两行标题的区别,但猜你喜欢通常使用两行标题来展示更多的信息 3.商品价格:核心组件,有单价格和双价格展示之分 4.标签:分为大促标签、腰带标签、日常促销标签三种样式,一个单品可同时出现这三种标签,因此信息传递的层次性是设计的关注重点 5.标识:如自营、全球购、沃尔玛、京东精选等表明商品从属的标识,一般只展示一种标识 6.操作功能区:如看相似、加车功能按钮等 7.业务拓展区:如推荐理由的文案描述,同时支持链接填写 当一个单品同时出现上述七个组件时,如何使信息传递具有层次性,是设计重点;同时也要考虑不同单品展示不同组件对页面框架造成的影响:如图片、商品标题、商品价格组成基础单品架构,而其余组件的设计应该在不改变单品基础架构的前提下进行设计,这样才能使样式更具有普适性。 六、思考:猜你喜欢是否能够作为独立的产品进行展示? 讲到此刻,相信大家都有个疑问:猜你喜欢是否能够作为独立的页面场景进行展示呢?天猫APP2017年6月发布新版,可以清楚的看到首页框架发生了极大的改变:除保留一排icon、banner、两个品牌入口外,其余内容以猜你喜欢单品的形式进行承载,频道/活动入口穿插至单品中;可以看出此次改版以简化框架,重猜你喜欢的形式进行展示为主。但在不久的10月发布了与6月相比变化较大的首页改版:前两屏不仅增加了有关天猫直营的天猫超市/生鲜、进口、魅力惠等频道入口,还增加了品牌维度的入口曝光,最大的改动是猜你喜欢变成了切类目TAB的形式展示,默认TAB为精选(原猜你喜欢的内容) 我们无法拿到6月改版后的数据变化,但可以大胆猜测10月改版的原因:1.6月轻入口重猜你喜欢的形式,无法使重点栏目得到充分的流量曝光;2.由于各电商平台的数据壁垒,无法精确推测用户行为,使猜你喜欢的内容推荐无法精准的集中用户     笔者认为:就目前的市场环境与技术发展,猜你喜欢并不适合作为独立的页面场景进行展示 写在最后的话: 以上都是关于猜你喜欢的个人设计思考与总结,希望能帮到看完全文的你;可能会有一些缺点和不足,欢迎一起讨论,互相学习,共同进步。

《京保养》基于Vue+Vuex的单页面应用实践

接到《京保养》项目需求,了解到是移动端项目,运用于微信公众号及京东 APP 。通过与后端研发沟通,后端将提供所有的数据展示接口,这样最终商定使用前后端分离技术,而作为前端这边就非常适合选择基于 webpack + Vue 的单页面应用来实现。 前期组内也有基于单页面应用的项目总结,他们的总结的确让我在本项目中少走了很多弯路,但是不同的项目又遇到了不同的新问题,本文将会介绍我所遇到的新问题及解决方案。 感兴趣的同学可以通过以下两个入口先去体验下京保养应用,然后回来接着看文章: 微信公众号搜索“京东汽车用品” – 关注公众号 – 菜单栏“京保养”,见图1; 京东 APP – 我的 – 我的爱车 – 京保养,见图2。 图1 图2 如果你在 APP 中找不到“我的爱车”入口,你得先在京东 APP – 我的 – 设置 – 添加档案 – 我的爱车 – 绑定自己的爱车,然后才会有入口。 为什么要使用 Vuex 初拟技术选型,项目开始了,而开发过程中发现,项目中有不同的表单视图需要大量数据的共享。而仅使用单页面的路由来传参并不能满足需求,因为数据量过大,导致路由传参过于复杂。如此,项目中引进 Vuex 技术来实现数据共享。 拿项目中需要数据共享的地方举例 —— 绑定车辆模块。先来看下该模块的操作流程: 绑定车辆页面填写车牌号码; 填写车系,包含选择品牌、选择车系、选择年款; 回到了绑定车辆页面继续填写车辆绑定信息。 如果上字描述还不清楚,我也录了个小视频,点击查看交互流程: 可以看到这几个步骤中已经有多个视图的跳转了,但最终目的是将绑定车辆的信息填写完整。每一次跳转都需要将已经操作过的页面交互数据(比如:车牌号、车系信息、电话号码等)记录下来,最后回填到绑定车辆页面。这些数据如果没有一个可以由多个视图都能取得的地方存储,绑定车辆的信息永远也填写不完整,此时 Vuex 就可以派上了用场。 Vuex 的使用 Vuex 的具体使用,有几个核心概念: state —— 定义存储状态; getter —— 对数据进行过滤; mutation —— 更改 Vuex 的 […]

京东火车票项目思考总结

京东火车票项目是一个不断迭代优化的项目。一想到要参与一个 GMV 很大的项目,内心抑制不住的兴奋。随着业务和需求的深入,兴奋感渐渐转变为压力。因为一直忙于完成业务需求,也就没有认真总结和反思存在的问题。借着写博客的机会,对项目进行简单的回顾和总结。 一开始接触项目是对当时存在的一些 bug 进行集中处理优化,对原有组件进行版本更新。然后到车次列表页进行前后端分离的尝试,还有对退改签业务的更新和重构。还有后来的学生票、儿童票丰富了火车票的业务场景。在这个过程中,遇到了形形色色的问题。有的问题很快解决了,有的就会耗费较多的时间精力。我遇到的问题有的是个例的,小概率的,有的可能是很多人都会犯的错误。我希望将一些自己认为有用的东西写出来。 学生票的特殊业务及其带来的问题 1、学生乘车时间为每年的6月1日到9月30日及每年的12月1日到第二年3月31日,可提前30天购买学生票,不能购买学生票的时候,学生票勾选不能点击。 看上去很简单的业务,做起来的时候发现还是不那么简单。因为它并不是简单的数字的比较。首先,要找出学生票可点击的区间范围,具体时间节点及范围如下: 1月1日到3月31日 6月1日到9月30日 12月1日到12月31日 然后,重点来了,出发日期日历范围的控制。正常推算,这个范围就是从当天到30天后结束嘛,但是细想一下,这30天的区间跨度可能会包含了某个时间节点,就是说有可能30天后,学生票不在可购买的范围内。那么,日历的可勾选范围就并不是简单的从当天到30天后,就出现以下如图所示的几种特殊情况。 思路理清晰了,转换为如下代码即可。

2、购买学生票填单页面需要输入学校和优惠区间城市,页面引入了学校和优惠区间城市的相应数据文件,但是学校和城市数据 JS 太大,导致页面第一次加载完成时间超级长,甚至加载到最后,直接失败,整个页面功能基本不能用。 解决方案: 因文件过大而导致的页面加载失败,最直接的解决方案就是缩小文件。 优化第一步:改变数据格式,删除冗余字段名,减小文件大小。具体修改如下图,改完后文件大小缩小了大概300多KB。 本以为这样就万事大吉了, BUT 问题来了,文件还有400多KB,网速稍稍不好的时候,刚进入页面时依旧会加载失败,导致页面功能无法使用。 优化第二步:按需加载。具体方式是,鼠标移动到需要该数据的区域时再请求数据。 这么做表面上看上去是解决问题了,初次进入页面超级快。BUT问题又来了,当鼠标移动到要操作的区域的时候,数据还没加载完了,用户就要操作了,来不及啊! 优化第三步:延时加载。具体操作办法是等待页面其他资源全部加载完毕,再加载学校的数据文件,这样利用用户在做不需要此数据的操作时,加载学校数据文件。如此,来不及加载数据的问题得到缓解,不浪费任何时间加载数据,同时也不影响用户的其他操作。 按照以上三不优化做完后,页面加载过慢问题有了很大的改善。 车次列表页前后端分离重构 起初是后端将数据直接输出到页面,可是有一个很奇葩的问题。就是在IE9下 table 代码段不能有换行,否则页面就会错乱掉。解决方法简单粗暴,后端将页面的换行回车都去掉。这样看似解决了问题,但引发了新的问题。就是 HTML 文件是一大坨难以名状的怪物,维护起来简直想去死。于是提出了前后端分离的实现思路。 后端只输出数据,渲染页面由前端处理。我使用的是 art-template 来进行数据渲染。 当时普通车次列表页和改签车次列表页同时开发。我对接了两个不同的开发同学,他们对业务有不同的理解,于是给出不同的数据结构。可是两个列表页只是业务场景不同, View 层的展示大同小异。最简单的解决方法就是开发同学统一数据结构,那我就只需要维护一套模板来渲染数据了。要不我维护两套渲染模板,这样带来的问题就是之后的维护成本会很高。就在前两种都不满足的情况下,想出了如下图新的解决方案。 数据处理函数,对不同的入口数据进行处理,输出需要的目标数据,我称之为是一种中间件模式。经过这层处理之后,对于后期开发同学数据结构需要变化的情况,只需要对数据处理函数进行修改,确保始终维护一份渲染模板代码。这样代码的稳健性和可维护性就提高了很多。 列表页会有很多个数据接口,有的是基本不会变动的,有的是需要开发人员更新的。将公用并且基本不会变动的接口放在公共接口对象里(前端控制)。可配置接口及可能变化的接口放在页面里,后台开发同学只需要将 HTML 本地开发的文件注释掉就可以了。 在使用 art-template 时出现一个问题,如何循环一个数字长度来显示大量重复控件。需要实现的效果图如下: 对应的数据结构如下图 需要实现的是根据 star 的不同数字展示不同的效果,10、20、30、40、50展示不同数目的星号,25、35、45展示对应的文字信息。

边界容错(undefined、try catch) 一开始约定好,拿到服务器返回的数据,返回了个 […]

© 2018 JDC. All Rights Reserved.