惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

人人都是产品经理
人人都是产品经理
Apple Machine Learning Research
Apple Machine Learning Research
云风的 BLOG
云风的 BLOG
罗磊的独立博客
博客园 - 三生石上(FineUI控件)
量子位
GbyAI
GbyAI
腾讯CDC
T
Tailwind CSS Blog
博客园 - Franky
奇客Solidot–传递最新科技情报
奇客Solidot–传递最新科技情报
D
Docker
G
Google Developers Blog
aimingoo的专栏
aimingoo的专栏
The GitHub Blog
The GitHub Blog
Microsoft Security Blog
Microsoft Security Blog
Stack Overflow Blog
Stack Overflow Blog
Hugging Face - Blog
Hugging Face - Blog
小众软件
小众软件
Cyber Security Advisories - MS-ISAC
Cyber Security Advisories - MS-ISAC
N
Netflix TechBlog - Medium
Jina AI
Jina AI
IT之家
IT之家
Y
Y Combinator Blog

人人都是产品经理

为什么你的产品找不到差异化?90%的失败都卡在第一步上(下) – 人人都是产品经理, 3年从30万到1300万用户、获2200万美元融资,这个AI教育产品用“抽卡”破解了获客难题 – 人人都是产品经理, 园区招商系统怎么做才能真正帮到去化?我加了这一个功能,推广链接转发400次阅读过万 – 人人都是产品经理, AI大事件:OpenAI发完网络安全模型又搞药物研发,小鹏汽车要抓”DeepSeek时刻” – 人人都是产品经理, 电商不是卖货,是一场更残酷的产品经理实战 – 人人都是产品经理, 没想到,活动营销又回来了! – 人人都是产品经理, 为何All-in海外KOC:一场关于AI时代窗口期的豪赌 – 人人都是产品经理, 重新理解企业的内部协作 – 人人都是产品经理, 苹果的 AI 战略到底是什么? – 人人都是产品经理, 医疗智能体·第2讲——合规护城河:等保、PIPL与HIPAA的架构实战 – 人人都是产品经理, 向量知识库五步法:从“答非所问”到“精准回复” – 人人都是产品经理, 鸿蒙PC三方库构建总指挥HPKBUILD(sha)库为例 – 人人都是产品经理, 何时该用LLM?AI产品经理的LLM设计指南 – 人人都是产品经理, 医疗信息领域的需求方、决策方、准入方以及关注点(二) – 人人都是产品经理, 即梦涨价:一场被误读的「傲慢」 – 人人都是产品经理, 面试AI PM必答题:Hermes和OpenClaw的区别,如何讲清楚业务价值 – 人人都是产品经理, AI的下一张船票:世界模型——AI产品经理必须理解的技术拐点 – 人人都是产品经理, 小红书做GEO,怎么让AI信你?记住这 3 个重要信息 – 人人都是产品经理, 5 家印度 AI 初创公司,看看印度 AI 再做什么 – 人人都是产品经理, AI项目跨团队协作:产品技术业务如何不打架 – 人人都是产品经理, Agentic Workflow(智能体工作流):让AI从”答案生成器”变成”数字员工” – 人人都是产品经理, lycium_plusplus 项目全景解读:OpenHarmony 三方库构建的“大管家” – 人人都是产品经理, 从爆单救火到前置履约:两套预采策略,把生鲜大促履约效率拉满 – 人人都是产品经理, 什么时候该补货?我用一轮数据做了一个决定 – 人人都是产品经理, 从“机械兜底”到“动态分流”:AI客服重复进线治理的4大底层逻辑 – 人人都是产品经理, 抖音拼效率,红书拼洞察 – 人人都是产品经理, 全民狂欢与退潮——为什么龙虾这波热潮冷却得如此之快? – 人人都是产品经理, Stripe押注!MPP重塑全球支付 – 人人都是产品经理, 小红书GEO:AI引用你的内容,不是因为你对,而是因为你看起来可信 – 人人都是产品经理, 前百度副总裁押注办公Agent,日韩付费爆发,Manus迎来强劲对手 – 人人都是产品经理,
商品中心:如何做好类目管理?
誓博 · 2023-04-20 · via 人人都是产品经理

如今我们使用的电商APP中,都可以看到商品分类,用户通过该功能,快速找到想要购买的商品。为什么要做类目管理,又要如何做好呢?本文作者对此进行了分析,一起来看一下吧。

在线下商店购物时,我们会发现商品被商家分门别类地放在特定的区域和货架上。比如超市分为食品、生活用品、办公用品、电器、服装家纺等区域,书店分为热销新书、经管、政治、经济、历史、哲学、心理学、小说等书架。

随着电商的发展,这种对商品进行分类的设计,也被产品经理搬迁到了电商系统中。如今,我们使用的电商App中,都可以看到商品分类(也称商品类目),用户通过该功能,快速找到想要购买的商品。

那么,为什么要做类目管理?如何做好类目管理呢?这篇文章就来详细分析一下。

一、为什么要做类目管理?

类目管理的用户价值是帮助用户快速找到目标商品,产品价值是方便运营维护商品信息、为其他功能提供基础支撑。

1. 帮助用户快速找到目标商品

当用户想要购买一款商品时,用户的诉求是快速找到想要购买的商品。为了达到该目标,用户通常会使用搜索功能,通过关键词来查找目标商品。

但是,搜索关键词并不能准确地描述一款商品。一个关键词可能指向多种完全不同的商品,也可能指向的是相似商品,但过于宽泛,不能准确定位一种商品。

“笔记本”既可以指便携式电脑,也可以指用于写字记录的小册子,“充电器”既可以指手机充电器,也可以指电动汽车充电器。

有了商品类目,就能在搜索结果的基础上做类目筛选,进一步明确搜索目标,帮助用户更快找到想要的商品。

除了搜索功能,通过商品类目逐级筛选,也能帮助用户更快找到目标商品。用户通过合理编排的多层类目,逐级缩小查找范围,相对于从全部商品中查找目标商品,效率大幅度提升。

2. 方便维护商品信息

电商是一个信息与实物商品分离的交易模式。用户在线上购物时,不能接触到真实的商品,只能通过查看商家填写的商品信息来对商品做出判断。因此,在电商中,商家需要将用户关注的商品信息展示给线上的用户。

不同类目的商品,用户关注的商品信息不同,商家需要维护的商品信息(如商品属性、商品品牌)也就不同,这些信息跟商品类目关联最紧密。

对于手机,用户关注CPU型号、内存大小、屏幕尺寸等商品信息;对于手机充电器,用户关注充电功率、接口类型等商品信息。

有了类目管理,就能把该类目的商品需要维护的商品信息,与商品类目关联起来。运营人员在录入对应类目的商品时,只需要按照设定好的商品信息清单逐个录入,不需要思考应该录入哪些商品信息,再录入具体的内容,大大提高了维护商品信息的效率。

3. 为其他功能提供基础支撑

在电商系统中,有很多其他功能都会依赖类目功能,最常见的有品牌关联商品类目、仓库分类目存储商品、汇总类目相关数据。

①品牌关联商品类目:在上一篇文章中,我们有介绍到品牌信息与类目关联:一个品牌涉足的商品品类有限,为了剔除掉跟类目不相关的品牌选项,提高运营人员上传商品时选择品牌的效率、提高用户筛选品牌的效率,需要将品牌与类目做关联。商品类目功能是品牌关联类目的基础。有了商品类目,才能将品牌关联到类目。

②仓库分区存储:存储在仓库中的商品,需要根据商品类目分区存储。如果不按类目分区仓储,把所有的商品都随意堆放,仓储人员在做商品入库、分拣出库时,就必须要在海量的商品中寻找目标商品的存放位置,如同大海捞针,效率极其低下。商品类目功能是仓库分区存储商品的基础。将商品类目与仓库库位关联,仓库管理人员就能根据商品所属类目,快速找到存储改商品的库位。

③汇总类目相关数据:无论是公司内部还是整个行业,都需要对同一类商品的相关数据做汇总统计,如销量、消费结果、客单价、毛利率等等,形成有参考价值的品类数据分析报告。没有商品类目,就无法对商品的相关数据做聚合。

二、如何设计类目管理?

类目功能的使用对象包括普通消费者,即前端用户,和负责运营管理的商家。对于前者,他们通过前端产品使用类目功能,如电商App、小程序;对于后者,他们通过后端产品使用类目功能,即电商后台系统。

1. 后端商家对类目的需求

商家是商品管理方面的专业人士,包括运营、仓储、采购等多个角色。为了方便他们的日常操作和互相之间的配合,需要采用一套客观、统一的分类标准。由于这套分类方法在后端产品中使用,也称为“后端类目”。有以下特点:

1)类目数量多

商品数越多,单个类目要归集的商品数也越多,在单个类目下查找商品的操作成本也就越大。随着电商的快速发展,大部分商品都被搬上了线上来销售,导致后端类目数量也越来越多了。

2)类目分层,且层级深

当类目数量很多时,不能把所有类目平铺,为了提高类目的使用效率,必须对类目再做分类,这样就形成了多层类目。通常来说,后端类目有3~5层,如下图:

商品中心:类目管理

3)相对固定,不轻易变更和删除

后端类目跟品牌、属性都做了关联,且已经创建对应的商品后,就不能轻易变更和删除,否则会导致数据错乱。

4)名称客观、统一

为了让商家内部不同角色的人更好地辨别类目,后端类目的命名必须要客观、统一。客观是为了准确表达商品的本质属性,而不是受人的主观影响,统一为了建立在不同角色的人之间建立沟通的标准,不至于各说各话,互相之间无法沟通。

基于以上特点,在定义后端类目时,通常要参考一些科学的分类标准,如《国标统计用产品分类目录》。

2. 前端用户对类目的需求

作为普通消费者,前端用户对商品分类的认知来自常识和生活经验。由于这套分类方法在被应用在前端产品中,也称为“前端类目”。有以下特点:

1)命名通俗易懂

前端用户的专业知识有限,因此类目名称不能使用过于复杂的专用名词,而后端类目的命名可能会使用一些专用名词。淘宝的“家用光伏集成热水系统”,在前端中会命名为“太阳能热水器”,如下图:

商品中心:类目管理

2)类目数量少、层级浅

通过减少类目数量和类目层级,合并对前端用户来说不必要的子类目,缩短用户查找路径,让用户更快找到想要购买的商品。如前端只有婴儿奶粉一个类目,而后端有很多个相关的类目,前端类目只有3层,后端类目达到了5层,如下图:

商品中心:类目管理

3)灵活多变

前端类目不仅要满足用户查找商品的需求,还要承载运营人员的运营诉求。用户的需求会随着时令节日变化,运营人员也会根据各方面因素制定不同的运营目标,因此展示给前端用户的商品类目也会随时发生变化。

夏天来临,朴朴超市增加了“清凉季”类目,海鲜水产下有“今日推荐”、“3件8折”等带运营目标的商品类目,如下图:

商品中心:类目管理

3. 前后端类目分离

如前文所述,前端类目和后端类目的使用对象不同,设计目标也不同,不能使用同样的方案。让前端用户使用后端类目,会导致用户无法快速找到自己想购买商品,前端类目也不能满足后端各角色的管理要求。

后端类目按客观、统一的原则对商品进行分类,一旦确定之后,长期保持固定,不轻易变更和删除。同时,将商品属性、品牌都与后端类目做关联。原型参考下图:

商品中心:类目管理

前端类目使用用户能理解的分类方式,从用户的视角来对商品进行分类,可灵活编辑、可重叠、可删除、可随时变动,甚至定时生效。原型参考下图:

商品中心:类目管理

4. 前端类目映射商品

运营在维护商品时,不能直接把商品添加到某个前端类目下,因为前端类目灵活多遍,随时会添加和删除。而应该添加到长期稳定不变的后端类目下,再根据客户需求或运营目的,创建前端类目,并选择要关联的商品。

前端类目关联商品通常有多种方式,最常用的是前端类目直接关联多个后端类目,被关联的多个后端类目下的商品就被归集到该前端类目下。也可以将前端类目关联后端类目和商品属性,甚至可以通过一些个性化推荐和聚焦运营目标的方式关联商品,最大限度缩短用户的查找路径,提高运营效果。

淘宝将前端类目“猜你喜欢”通过个性化推荐算法,关联当前用户最近感兴趣的后端类目或商品,并直接放在最靠前的位置。朴朴超市将前端类目“今日推荐”直接关联运营重点推荐的商品。如下图:

商品中心:类目管理

三、总结

类目管理可以帮助用户快速找到想要购买的商品、提高商品管理效率,并为其他相关功能提供基础支撑。

由于前端用户和后端商家对类目的需求不同,前端类目命名通俗易懂、类目数量少层级浅、灵活多变,而后端类目数量多、层级深、不轻易变更和删除、命名客观统一,在设计产品方案时,需要采用前端类目和后端类目分离、前端类目关联商品的方法。

专栏作家

誓博,微信公众号:产品慎思录。人人都是产品经理专栏作家。7年产品经验,专注电商交易系统方向。

本文原创发布于人人都是产品经理,未经作者许可,禁止转载。

题图来自 Unsplash,基于 CC0 协议。

该文观点仅代表作者本人,人人都是产品经理平台仅提供信息存储空间服务。