标签类目体系设计方法论

标签类目体系的设计方法基于“树形结构的标签树”第一性原理，通过识别对象、同一对象数据打通、数据化的事物表达、构建数据类目体系、构建标签类目体系、前后台标签类目体系等步骤实现完整的数据资产构建过程。

一

识别对象

标签类目体系方法并不着急设计标签，而是先研究对象：因为只有确定清楚对象，才是抓住了问题本质。

数字映射可以将现实世界中的一切事物归属为对象。对象分为“人”、“物”、“关系”三大类型。其中“人”包括自然人、自然人群体、法人、法人群体等，例如消费者、消费者协会、电商企业、电商企业联合会，是会主动发起行为的主体；“物”包括物品、物体、物品集合等，例如商品、仓库等，是行为中的被施与对象；关系指的是人和物，或人和人，物和物等在某时某刻发生的某种连接，包括行为关系、归属关系、思维关系等各种强、弱关系；例如购物、运货、聊天、监管等。因此可以采用这种对象识别方法，将现实世界中的一切事物、关系通过这种方式一一对应到相应的对象分类中。

二

同一对象数据打通

由于同一个对象在多处系统留存有按不同ID组织的信息记录，因此需要进行多种ID间的同一对象识别打通。

例如某一个自然人，公安系统用身份证进行唯一识别；但在看病时，需要使用医疗系统给予的医保账号进行挂号缴费；缴纳生活费用时，又对应有不同的水表账号、电表账号、天然气账号；购买了手机会有手机的设备账号；上网购物会有电商账号，上网聊天会有社交账号…… 不同的账号下都记录了大量的历史行为记录。要对现实世界的事物进行完整的数字转录，采用数据技术对研究对象进行深入的洞察分析，就必须先将多方数据进行ID打通。

大数据领域中的ID-Mapping技术就是用来解决某一对象多源数据打通的问题。输入两两ID关系对，采用机器学习算法进行概率匹配计算，构建ID关系网络。可以确立一个核心ID，例如AID、ONEID、XID（业内各种叫法不一）作为某对象的唯一识别码，将其他ID信息通过ID关系网络与之关联匹配。

三

数据化的事物表达

数据思维要求我们能将现实世界进行快速的数据映射：将所有事物映射为“人”“物”“关系”三类，系统性的向下梳理各对象全维度属性，各属性下有具体属性值，如下图所示。在同一类群体中，属性具有一定的通用性，而属性值则体现了个体差异。

以“爱读书的我今天在微信上花了半小时读了一篇很有意思的科技文章”这个事件举例：可以抽象出“读者（人）”、 “文章（物）”，“阅读（关系）”三个对象。

继续对“读者（人）“对象梳理出“阅读偏好度”和“今日阅读时长”等属性。在“我”这个具体读者实例中，“阅读偏好度”属性的属性值是“爱读书”；“今日阅读时长”属性的属性值是“半小时”。

在“文章（物）”对象下梳理出“有趣度”“文章阅读渠道”“文章类型”等属性。在“XXX文章”这个具体文章实例中，“有趣度”属性的属性值是“很有意思”；“文章阅读渠道”属性的属性值是“微信App”；“文章类型”属性的属性值是“科技”。

在“阅读（关系）”对象下梳理出“阅读渠道”“阅读时长”等属性。在“某次阅读”这个具体阅读记录实例中，“阅读渠道”属性的属性值是“微信App”；“阅读时长”属性的属性值是“半小时”。

四

构建数据类目体系

数据映射完成后，梳理出的数据类型会非常多：对象多，属性多，属性值也很多。因此需要一套系统的数据资产梳理方法，体系化地对“对象、属性、属性值”进行统一梳理和体系化梳理。

例如构建某服装企业的数据类目体系，需要先抽象出交易（流程）、库存（流程）、要货（流程）等业务流程的对象目录；同时将这些业务流程中所涉及的加盟商（人）、员工（人）、消费者（人）等人的对象目录构建出来；将这些业务流程中所涉及的门店（物）、商品（物）、仓库（物）等物的对象目录也同样抽取出来，如下图所示。

对象目录确定后，需要进行对象下数据类目的展开。

（1）首先梳理“流程”对象的数据类目。

流程类的数据类目往往可以按照业务归属、业务存储库、业务表等方式对数据进行分类。例如市场销售这一类业务部门，细分零售交易业务线和批发交易业务线；零售交易业务线的数据库中又将数据按照交易人数据库、交易物数据库、交易记录数据库分库存储；交易记录数据库中又按照明细交易、日统计交易、月统计交易、历史统计交易等多表存储，交易明细表中除了交易记录ID，还有交易时间、交易渠道、交易金额等字段信息。

对应于数据类目体系的梳理：就可以在交易（流程）对象下，设置两个一级类目：分别是【零售交易】和【批发交易】。【零售交易】一级类目下可以分为【交易人】、【交易物】、【交易记录】等三个二级类目。【交易记录】二级类目下可以分为【明细交易】、【日统计交易】、【月统计交易】、【历史统计交易】等四个三级类目。在【明细交易】三级类目下，可以挂有“交易记录ID”“交易时间”“交易渠道”“交易金额”等字段，如下图所示。

（2）其次梳理“人”“物”等实体对象的类目。

信息化建设比较成熟的企业，已经专门梳理有“人”“物”实体对象的数据库。例如商品数据库中，会有商品的基本信息表，服装属性表；也有来自业务流程中抽取出来的以商品为主键的交易统计表、商品库存统计表等。商品的基本信息表中有“商品ID”“商品名称”“商品类型”等字段；商品交易统计表中有“商品ID”“商品历史总交易量”“商品平均交易单价”等字段。因此在数据类目体系中，可以构建商品（物）对象目录，在商品对象下，设置有【基本信息】、【服装属性】、【交易售卖】、【库存流通】、【要货供应】等五个一级类目。在【基本信息】一级类目下挂有“商品ID”“商品名称”“商品类型”等字段，在【交易售卖】一级类目下挂有“商品ID”“商品历史总交易量”“商品平均交易单价”等字段，如下图所示。

信息化建设比较落后的企业，可能只有按流程组织的数据，并没有单独梳理按“消费者”“商品”等实体数据库，那么数据类目体系中，就可以不用单独设列“消费者”“商品”等对象目录。

数据类数据类目体系反映了构建者对企业原生数据的理解，现实中数据库、数据表、数据字段是如何组织的，就相应转化为数据类目，不需要过分发散。当原生数据按照数据类目体系进行归整处理后，不管前端业务对数据采集的形式、周期、传输方式等发生了何种变化，传递到数据类目体系后都是稳定不变的。原生数据的管理即数据类目体系不会随着业务形式、经营活动方案等上层形态变化而经常发生底层结构改动。

五

构建标签类目体系

梳理完企业原始积累的数据类目体系后，需要根据业务场景需要，设计标签及标签类目体系。标签类目体系的设计过程，比数据类目体系更为复杂。

首先我们需要明确定义“标签”这一概念：从原始数据清洗加工而来，能够为业务所使用产生价值的数据资源称为标签。一般都需要结构化到字段粒度，保障服务化使用。它面向数据应用端，解答的是“数据怎么用”“数据的价值是什么”的问题。

1、标签设计的两大前提

标签不能凭空设计，必须考虑标签开发落地的数据可行性；同时标签也必须是业务上需要的，能够帮助业务人员作出业务判断、支撑、帮助的数据项。在当前业务中，它经常也被称呼为：属性、特征、指标、参数等，如下图所示。

2、标签设计的五种思路

标签的设计一般来自业务诉求的梳理抽象。简单而言，将业务痛点拆解成应对的数据方案，数据方案中的数据资源拆解到字段粒度，就是标签的设计过程。

在更发散的场景中，例如数据资产的整体规划，或为业务部门想象数据空间；而非根据已知的业务需求仅仅完成数据执行的场合，可以有更多的标签设计、发散思路，如下图所示。

思路一：从核心词属性角度发散，例如需要设计“品牌偏好”类标签，可以思考品牌有哪些属性？品牌有国别属性、有档次属性、有风格属性，因此可以设计出“品牌国别偏好”、“品牌档次偏好”、“品牌风格偏好”等标签。

思路二：从包含、拥有角度发散，例如需要设计“生理参数”类标签，可以思考生理参数包含哪些具体的特征信息？很容易联想到身高、体重、血型、三围、尺码等生理信息，因此可以设计出“身高”“体重”“血型”“胸围”“脚码”等标签。

思路三：从详细内容角度思考，例如需要设计“推荐方案”类标签，可以思考一个推荐方案往往会由哪些内容要素组成？进而可以设计出“推荐时间”“推荐渠道”“推荐逻辑”“推荐对象ID”“推荐商品ID”等标签。

思路四：从发展过程角度思考，例如需要设计“浏览行为”类标签，可以思考浏览行为的完整发展过程中所涉及的各项信息，进而可以设计出“浏览来源”“浏览路径”“浏览商品ID”“浏览是否转化”等标签。

思路五：有一种特别的标签设计思路，来自相同类型事物的统一抽象。例如提到兴趣爱好，大家一下子就会想到：吃货、购物达人、运动健将、音乐发烧友、户外一族、追星深粉、阅读者等，但是这些名词都属于标签值范畴。在这种情况下建议设计一个“兴趣爱好”标签，将这些具体的兴趣取值作为这个标签的标签值。如果需要突出兴趣类型，也可以通过将取值转化为标签的方式处理：对标签各取值加上“是否”前缀或 “程度/指数”后缀，例如“是否吃货”，“吃货程度”，“吃货指数”，这样处理后标签值就转变成了标签。将这些同类型的兴趣爱好取值都做相同处理，就变成了一批兴趣爱好类的标签，这些标签都可以放到【兴趣爱好】的类目下。

3、标签类目体系的设计思路

按照数据映射原理可以预估，企业或企业业务线，其沉淀下来的数据项、业务需要使用的标签项将会非常多。当标签量越来越多时，查找、管理、使用标签就会变得比较低效。一般当标签量超过50个，业务人员要查找或使用标签就有麻烦，数据管理员要管理数据、标签也会存在障碍。因此需要一种分类机制来对标签进行系统分类。

标签类目体系由根目录、类目体系、属性标签组成。类目体系是一种树状结构：从根目录上长出的第一级分支，称为一级类目；从第一级分支中长出的第二级分支，称为二级类目；从第二级分支中长出的第三级分支，称为三级类目…，类目结构的分层设定根据企业自身需求而定，没有强制规定。没有上一级类目的类目称为一级类目，没有下一级分类的类目称为叶子类目，挂在叶子类目上的具体叶子就是标签。有下级类目的类目是下级类目的父类目、有上级类目的类目是上级类目的子类目，如下图所示。

类目体系的层级结构以用户容易理解的分类方式展开，其存在的核心意义即为用户快速查找、管理目标对象使用。因此数据类目体系建议按照数据采集、存储、管理等系统原有体系去进行划分，这样可以帮助数据管理者、数据开发者以他们的思维认知方式去匹配类目找到所需数据。而标签类目体系则建议按照对象理解、价值场景等数据应用的角度去进行划分，因为标签类目体系是供业务人员、产品经理等数据资产使用者理解、查找、探索业务上所需标签，发挥数据资产价值。必须转变传统技术视角，切换为业务人员能理解的业务视角去组织标签。

需要正确认知到不存在一套通用的、统一的标签类目体系结果能满足所有企业、机构、政府在各种业务、管理场景中的数据需求。不变的只有按照真实业务、管理需求来构建标签类目体系的思路方法。

六

前后台标签类目体系

在构建完企业完整的标签类目体系后，需要将标签类目体系进一步加工为前后台类目。

1、什么是前后台类目

根据前文各步骤构建出的是企业后台标签类目体系：数据资产的全集，即所有需沉淀可复用有价值的标签池。数据资产设计师或管理员可以创建、维护后台标签类目体系，其他人员可以查看类目体系，但不能随意修改。后台标签类目体系比较稳定，是对人、物、关系各类对象的本质描述及描述属性的普适分类。与业务场景松耦合，保持对人、物、关系各类对象的全局、稳定的标签定义。

前台标签类目体系侧重于对业务场景的响应，根据业务需求来汇集所需的标签集合，并根据业务的理解对标签进行分类，以供业务系统或数据应用调用。因此前台标签类目体系会随着业务场景变化而变化，是灵活可配的。当业务场景的参与人、业务流程、影响范围等发生变化时、所涉及的标签也会随之发生变化。业务场景本身也可能是短暂的，快速产生快速关闭，或者演变成另一种业务场景，那么其所关联的前台标签类目也会随之新增、删除或演化。因此前台标签类目体系是场景化的、不稳定的、更贴近业务需求。

2、前后台类目的联系与区别

前台标签类目一般按照大场景/子场景/数据服务等层级展开。在大场景/子场景/数据服务下先抽象出所涉及的对象，再去后台标签类目体系该对象下的标签总集中找到该数据服务所需的标签添加到这个前台类目对象下。如果数据服务中某对象下标签多于10个，就可以设计一级、二级等多级类目，将众多标签分别挂入不同的前台类目中。因此可以认为某一个数据场景的前台标签类目是后台标签类目的一个标签子集，如下图所示。前台类目会随着企业对数据资产的广泛使用而越来越复杂，生命周期也会随着业务快速发展而发生短平快的改变：包括前台类目结构的变化，类目下所含标签的变化等。

3、区分前后台类目的意义

为什么要区分前台类目和后台类目？因为业务需要与技术管理存在矛盾：业务是灵活的，变化的，它对数据需求是高响应和灵活可调，因此针对某个场景的标签组织方式应该是自由可配置的。但是另一方面，从技术视角管理标签时又希望标签的组织方式是较为稳定的，同时业务人员来标签门户看、选标签时，也希望标签组织方式是较为稳定的，因此我们区分了前台类目和后台类目：前台类目映射灵活多变的前台业务数据服务需求；后台类目适配稳定统一的后台资产组织管理需求。