内容型产品中分类管理的分析与设计
编辑导语:当我们在图书馆想找到一本书时,面对偌大的图书馆,肯定不能一本一本去找,这时候就要用到图书馆里的搜索设备去找那本书或者那类书的大概位置;本文作者就详细介绍了内容型产品中的分类管理设计。
一、内容型产品的后台分类管理介绍
当用户想在某个图书APP中找到一本适合儿童听的有声书,但又没有具体目标时,他可以打开这个APP的分类页面,在Children’s Audiobooks这个分类下继续探索;这个页面中的分类像一个个文件夹一样结构清晰地划分了海量图书,让用户高效找到自己感兴趣的书籍。
这个线上图书馆里的图书是海量的,这么多书籍到底该如何存储和划分?这个线上图书馆还是不断变化的,新书来了怎么分类?儿童节到了是不是应该将儿童这个分类放在更加显眼的位置以促进消费?
这些问题都摆在了这个线上图书馆的图书管理员——运营人员面前;在这样的背景下,我们在后台开发了一个分类管理页面。
内容型产品管理后台中的分类管理功能,就是运营人员编排内容分类的功能,在运营归纳整理好之后,用户在APP上就看到了有结构的内容。
二、后台为什么要做分类管理功能
1. 结构化的内容方便查询
结构化的内容,就是内容经过分析后,分解成多个互相关联的组成部分,各组成部分之间有明确的层级结构;将内容整理成结构化的,就是让内容从无序变成有序的一个过程。
图书馆有海量的图书,通常我们是怎么找到自己需要的书籍的呢?
假设现在我想找一本学习少数民族语言的书籍,我会先找到“语言、文字”这个书架,然后再在这个书架中找到少数民族语言的片区,最后再选择具体想读的一本。
之所以能如此快速找到一本书,是因为图书管理员已经有结构地整理了这些书籍,把每一本书都放在了合适的分类书架上;如果所有的书籍都没有分类,所有的书架就都一样,也就不知道该去哪个书架哪个片区找到需要的书籍。
同样的,在有海量内容的产品中,也需要结构化地整理内容,来帮助用户快速找到自己需要的内容。
这里快速找到体现在,用户能通过有层级的分类导航来查找;而后台中的分类管理,就是运营人员分门别类整理内容的地方,通过分类管理,内容有结构有层次地展示给了用户。
如果没有分类管理这个功能,运营人员就无从整理这些内容,产品中的内容就杂乱无章;当用户找不到需要的内容,可能会觉得产品内容太少而不再愿意使用产品,由此影响产品的发展。
2. 相似推荐,提高曝光
采用内容过滤算法的相似推荐中,分类通常是计算内容相似度的一个维度。
后台的分类管理功能帮助运营人员给平台内容划分并标记正确的分类,从而在用户主动搜索或随意浏览的场景下,系统能为其匹配大量同类内容。
分类是自上而下的,先归纳特征形成一个类别后,这个分类中再有内容;以后一旦某个内容被归到这个分类,就表示内容具有这些特征,所以在计算内容相似度时会考虑内容的分类属性。
内容过滤算法的原理是:给用户推荐和他之前喜欢的物品相似的物品。
内容过滤算法利用物品的内容信息计算物品的相关表,并频繁地更新相关表;当新的物品加入时,或当用户的行为强烈受某一内容属性的影响时,内容过滤算法都有较高的精度;例如:图书类APP提供了一个较强的内容属性,图书的分类,爱读科幻小说的读者会经常关注科幻小说这个分类的图书。
分类管理是标记内容分类属性的工具,合理的分类才能提高相似推荐的精度并扩大内容曝光的范围;从而为用户提供更多的查找目标内容及其他感兴趣内容,给用户留下内容丰富且质量高的印象,提升了用户体验。
三、内容型产品中分类管理的特征
1. 两种分类逻辑相关联
先看看是哪两种分类:
- 第一种是前端分类,也就是用户在APP中看到的分类;
- 第二种是后端分类,是数据库存储的原始分类。
以书籍分类为例,某图书APP中用户看到的分类是这样的:
而数据库中存储的后端分类可能是这样的:
我们发现前后端分类不同,前端分类数量少层级浅,后端分类数量多层级深。
为什么要做这两种分类逻辑,前端和后端不能用一套分类逻辑吗?
前端的分类是给用户看的:为了让用户高效查找内容,在精细化分类的前提下,要求分类不能过多,层级不能太深;适量的分类个数和层级,能缩短用户的查找路径,从而提高查找效率。
后端的分类是给运营人员使用的:随着内容数量的增多,需要更多的分类和更深的层级才能归纳划分这些内容;这就要求后端分类的颗粒度需要足够细,精细颗粒度的分类,能更准确地归类内容,从而能通过聚类重组等运营操作,灵活地展示给用户。
以上图为例,说明如何聚类重组,运营人员可以将后端分类中的“小说/悬疑与侦探”以及“小说/惊悚片” 都添加到前端分类“悬疑与惊悚”下;将后端分类中的“小说/传记”添加到前端分类“传记和回忆录”中,从而实现聚类的效果。
可见,前后端使用分类的场景是不同的,采用两种逻辑并相互关联才能更好地服务于产品。
2. 前后端分类命名侧重点不同
前端分类是面向用户的,在命名时需要基于人们生活习惯上的理解,为内容划分一些通俗易懂的分类,这么做是为了让用户能准确地辨识分类和内容。
人们在感知任何事物时,总是根据已有的认知或经验来理解它,前端分类在命名时用一些符合用户习惯的通俗的分类名称,更有助于用户理解和辨识。
在理解分类方面,比如:一说分类“英语能力提升”,就知道这个分类下的书籍都是用来学习英语的;在理解内容方面,比如你可能不知道《走遍美国》是什么书,但是如果放在分类“英语能力提升”下,就知道是用来学习英语的内容,因为你对“英语能力提升”已经有了认知。
后端分类面向企业的运营以及其他合作公司的专业人员,为了方便管理和合作,要求分类命名客观、统一。
客观是相对主观来说的,客观的分类说明了内容的本质属性,和个人的想法没有关系,这让后续管理和合作时都能清晰辨识。
比如后端的分类会采用编码格式的分类,EDU005000代表“教育/双语教育”这个二级分类;每本书都被记录上一个编码,这个编码代表了书籍的本质属性,不会因为不再做节日促销或者时令更替等主观原因,这本书就不再是这个编码。
编码的客观性有利于运营的管理,比如可以轻松将EDU005000这样以EDU开头的编码书籍都聚类纳入前端分类“教育”中;在把版权出售给其他公司使用时,由于这些书籍都有客观的编码分类,合作方在编排时也会更方便。
统一就是与各个合作方尽量采用一致或类似的分类方法,当大家都采用一样的分类方法,我们拿到彼此的内容时就无需重新划分分类;比如《新概念英语》这本书,若各企业的分类编码都是EDU029080 ,表示“教育/教学方法和教材/语言”,这样在资源共享时,就没必要再重新编码划分。
这就是后端分类常常采用某个国际标准编码分类(如图书行业的BISAC Code)的原因,客观、统一、提高了管理和合作的效率。
四、内容型产品中分类管理的设计
前端和后端分类是面向不同人群的,所以设计时也有一些差别。
1. 层级确定
层级确定就是要定好分类需要几个级别。
由于前端分类是给用户看的,所以内容数量少可以只用一个层级;当相似内容数量多,相对粗略的一级分类无法划分全部内容时,就可以采用更精细的二级三级分类,但最好不能有更深的层级了。
尽量将内容归纳成较浅的层级,是为了缩短查找路径,提高查找效率。
后端分类通常不对层级的数量做要求,而是对划分的精细度有要求,要求尽可能细致地划分分类,方便后续对分类的管理。
2. 基本字段确定
1)前端分类字段
显示顺序:显示顺序是用户在APP中看到的分类排序,这个功能满足了运营人员的日常运营需要;例如儿童节,可能需要将儿童类的书籍放在最前面做促销打折活动。
分类名称:分类名称明确了当前分类是什么的问题,分类作为一种标记,必须要有分类名称让用户看到就能明白是什么;例如看到“儿童有声读物”,用户就明白如果需要找一本适合儿童听的有声书就可以在该分类下查找。
包含的后端分类:内容型产品的后台有前后端两种分类逻辑,这个字段说明了该前端分类与哪些后端分类有关联;假设该字段的值为“小说/悬疑与侦探,小说/惊悚”,那说明该前端分类是由“小说/悬疑与侦探”、“小说/惊悚”这两个后端分类组成。
包含内容的数量:包含内容数量说明了该分类下展示给用户的具体有多少内容,避免出现分类中数量过少不利于内容曝光的情况。
状态:状态的值通常有显示和隐藏,说明了该分类当前是否展示给用户;有些分类展示与否是和时间相关的,比如每季度的第二个周日是会员日,这一天就让“会员专享”这个分类显示,其他时间就隐藏不展示给用户。
2)后端分类字段
编码:后端分类通常采用编码并辅以备注名的方式,这里的编码唯一标识了该分类,明确说明了该分类是什么。
分类名称:分类名称帮助运营人员理解分类,编码确定了该条记录是什么分类的问题,但是还不够直观;假设运营人员需要聚类编排前端分类“英语能力提升”,却不知道后端分类编码代表的含义,但如果编码有辅助的分类名称叫做“英语口语教材”,这时就能轻松将这个编码纳入前端分类“英语能力提升”中了。
包含内容数量:说明该分类下有多少内容,方便在编排时确定数量。
3. 前后端分类关联性的设计
前后端分类的对应关系可以是一对一、一对多、多对多。
- 一对一表示一个前端分类和一个后端分类关联。
- 一对多表示一个前端分类和多个后端分类对应,因为前端分类数量少层级浅,而后端分类颗粒度很细,所以通常将多个后端分类纳入一个前端分类中;比如前端分类“小说”对应了很多个后端分类“小说/悬疑与侦探”、“小说/惊悚”、“小说/历史”等等。
- 多对多的关系是指,一个前端分类可以与多个后端分类关联,一个后端分类也可以与多个前端分类关联;比如一个前端分类“小说”对应了多个后端分类“小说/惊悚”、“小说/历史”,一个后端分类“小说/历史”又对应了多个前端分类“小说”、“历史”。
这种关联关系,可以通过设计前端分类管理页面中的功能来实现;通过编辑操作,在“包含的后端分类”这个字段中,添加需要聚类的后端分类。
在设计时,需要保证前台类目必须关联至少一个后台类目的逻辑,否则就会出现该分类下没有内容的情况。
五、总结
内容型产品管理后台中的分类管理功能,就是运营人员编排内容分类的功能,在运营归纳整理好之后,用户在APP上就看到了有结构的内容。
合理的分类设计能提高查询效率,并作为计算内容相似度的一个维度提升内容曝光。
结合前后端分类的场景和特征,我们设计了内容型产品管理后台中的分类管理功能,并在两套分类体系中做了不同逻辑处理。
本文由 @相与 原创发布于人人都是产品经理。未经许可,禁止转载
题图来自pexels,基于CC0协议
准确的说,包括现有的电商平台,应该这个逻辑:
一对一,一对多,单个后端分类允许重复分给前端。个人觉得这样好理解,多对多太多解释了