#原文笔记

序一

将数据进行标签化的思路就像微积分。微积分是两个概念的组合，先微分，再积分。微分是把一个大的东西切分成足够微小的部分；积分是把切分后的微小部分组织合成。标签的设计过程就是把各种对象充分“微分”的过程，解析和拆分得足够精细；而标签的使用过程就是将场景中涉及的对象标签拼装在一起使用，是一个“积分”的过程。

但是在同一份数据的跨业务领域使用或跨时间先后使用的场景中，经常存在复用困难的问题。

标签化的数据处理则意味着数据需要经过标准化组织后规模复用。

这种将经常用到的信息、技术、功能进行标准化封装以供业务端不同场景复用、拼装的做法就是中台模式。

到底选择传统数据模式还是标签化数据模式，本质而言是效率问题和商业问题，也许“慢就是快”的长线思维和“成本降低，收入增加”的财务公式能让大家聚焦问题本质。

序二

资产的严格定义是：资产指由企业过去的交易或事项形成的、由企业拥有或控制的、预期会给企业带来经济利益的资源

2020年4月9日，中共中央、国务院发布《关于构建更加完善的要素市场化配置体制机制的意见》，首次将数据列为除土地、劳动力、资本、技术之外的第五大生产要素。

数字经济的基本特征是，以数据资源为重要生产要素，以现代信息网络为主要载体，以信息通信技术融合应用，以全要素数字化转型为推动力，促进公平与效率更加统一。

最后，数据带来了新的伦理和法律问题

数据中台包含两层含义：第一层是打通数据，就像建电网；第二层是让数据好用，就是把数据技术装备化，甚至“傻瓜化”，让所有业务人员都可以轻松自如地使用数据，发挥“数据能”的威力

因为有梦，所以出发；既已出发，使命必达。

前言

但以技术来驱动数据中台建设也许从方向上就错了！

中台的核心本质是将可复用的能力、技术和工具汇聚在一起，帮助前端业务快速响应变化。

到了2.0时代，中台应该是一个智能操作系统，能让业务人员以可理解、易操作的方式创建服务接口或应用系统，让数据“用”起来。

现状是，很多企业还停留在数据梳理、治理、数仓建设阶段，业内研究较多的仍然是如何制定标准、推动标准治理落地。

有了标签对物理数据的逻辑映射，数据对于业务人员来说就不再是无法碰触的数据虚体，而是鲜活生动的数据产品，具有标签名、标签定义、标签逻辑、标签取值、标签适用场景、标签调用量、标签质量、标签价值等使用属性。标签化使得业务人员看数据就像逛淘宝，选数据就像加购物车，用数据就像下单购买一样简单。

建设数据资产的3点必要性：资产可复用、业务可理解、价值可衡量。

由来篇 因何产生，为何需要

标签类目体系是一门面向业务的数据资产设计方法学

第1章 因：6大数据困局

图1-1　6大数据困局

1.1 数据孤岛，无法打通

1.1　数据孤岛，无法打通

基于异构数据源、异构厂商集群、时效性和技术栈等因素考虑，当前业内一般采用离线数据同步和实时数据同步两种技术方式来进行数据迁移打通。

数据使用1.0：自生自用，即部门、企业的数据自己生产加工，自己使用。数据使用2.0：自生他用，即部门、企业的数据自己生产、加工、授权后供他人使用。数据使用3.0：共生共用，即多部门或多企业将数据进行融合再加工，授权后供多部门、企业共同使用。

各部门对自身数据进行加工处理并形成分析报告，查找原因以进行针对性改进，实现了业务数据化→数据业务化的小循环过程。

数据是一种特别的资源，它可再生，融合价值大于原有价值之和，越用越有价值。因此只有把数据汇聚在一起，才能实现数据世界的完整复刻

共生共用意味着数据的接入、生产、使用、管理进入系统化阶段：所有数据的来源、现状、去向都清晰可查，生命周期都得到有效管理，使用都有章可循。这种数据观的构建往往需要3～5年持续不断的耕耘建设，甚至需要融入企业的文化建设中。

首先，塑造企业的数据认知。

1.2 烟囱式建设，重复造轮子

1. 烟囱越建越高，难以支撑

在开发过程中，也缺乏数据逻辑和建模分层上的思考和指导。一切都以业务为导向，为了及时产出最终的数据结果，中间步骤是否合规合理、代码程序是否稳健正确都可能会被忽略。这样进行的数据建设极容易倾斜倒塌。

3. 重复投入容易造成资源浪费

底层原始层数据、中间明细层数据，乃至上层应用层数据都可能存在大量重复

业务部门通常并不会基于企业过去积累的全部数据建设成果来规划完整的企业数据建设计划，而只是按照部门的当前需求进行规划。

企业总部缺乏整体性的数据建设规划

1.3 各说各话，没有统一口径

如果每个部门都按照自己对业务逻辑的理解进行数据开发，会导致同一个指标具有不同的计算口径，最终的计算结果当然也不相同。

分析原因后会发现，原始数据的清洗方式、中间数据的统计逻辑、结果数据的汇总差异都会影响最终的数据结果。

核心问题在于每个指标都需要有准确名称和精准定义，能向其读者解释清楚指标的加工逻辑

1. 形成数据工作的标准流程与规范

数据部门应该尽可能多地为业务提供可选的指标信息以支撑业务发展，而不是替业务做决定

3. 授权数据部门对指标进行统一定义

1.4 鸡同鸭讲，无法穿透业务层

如何向业务人员解释清楚数据是什么？当前有哪些数据？数据可以为业务做什么？

数据迁移、数据标准化、数据建模、数据开发、数据治理

形成数据共知是双方共同努力的结果，需要业务人员与数据人员在三方面将认知拉齐

首先，要在企业内树立统一正确的数据观，这是第一要务。

其次，学习模式和背景不同的文、理科人才都需要掌握将感性思维和理性思维结合运用的能力。

在企业实际运转过程中，因为业务价值比较容易凸显，业务部门往往比较强势。一般建议由数据部门人员主动向业务侧靠拢，将数据技术转化为业务工具，为业务部门赋能。

大型企业中往往设有商业分析师这一岗位，其职责是实现数据端和业务端的打通和连接。

我们需要找到一种能自我说明的数据方法，让数据资产自己将自己说明白：它是什么，它从哪里来，可以怎么用。

1.5 数据人员的梦魇，数据治理永远没有尽头

传统的数据治理通常包括数据标准管理、元数据管理、数据质量管理、数据安全管理、数据生命周期管理等内容。在数据治理领域比较著名的理论有以下几个。

数据治理的5大典型困难

1. 传统数据治理的专业门槛较高

2. 传统数据治理涉及的板块多，周期长

3. 治理工作一遍又一遍，治理不完

4. 治理工作难以对外扩展，获得配合

5. 治理难度太大，是一项系统工程

人性是趋利的，要么让业务人员真正懂数据，会用数据，要么就向其展示、证明数据对业务场景的显著提升作用，这样才能拉动业务侧一起积极配合、共同治理。

可以从业务出发，找到数据核心价值，以价值来联动数据与业务两个部门，共同完成数据资产设计、数据资产治理、数据资产使用等过程，将数据以资产的形式高效运营起来。

1.6 数据部门的尴尬，被命运扼住咽喉的成本中心

数据部门势弱，主要原因在于业务部门势强

业务部门是利润中心，数据部门是成本中心

数据部门的KPI设定往往是自我建设和对外赋能：完成企业数据架构设计，完成数据平台底座建设，完成数据资产目录梳理，完成数据产品系统开发；支撑业务部门对数据的规模调用，支撑数据赋能下的业务持续增长，支撑企业经营管理中的数据呈现和数据决策，支撑企业数字化转型战略

不依赖领导的站台背书、政策制度的强制、兄弟部门的同情与共情，而是依靠自己的武器—数据价值去扭转局面，跳脱出成本中心的桎梏，努力将自己打造成利润中心

在企业内，可以尝试着将数据部门作为一家数据公司看待，其所采购的服务器、数据源、工具平台等可看作成本支出，其所产出的数据服务、数据应用可看作定价售卖的数据产品，各业务部门需要为数据价值进行收益上的定量拨付或财务核算，这就是数据部门的利润收入。

2.1 数据资产发展的4个阶段

数据资产1.0：构建消费者信息库

1. 数据侧与业务侧的初次接触

每个数据产品经理都会先研读完《消费者心理学》和《消费者行为学》这两本书

在数据价值尚未探明时期，数据部门的姿态往往是很低的

数据侧为业务侧打造的第一个数据解决方案一定要成功，必须在首次合作中为业务人员把数据项、数据加工逻辑、数据使用方式、数据赋能效果等全链路内容设计到位，保障业务人员低门槛地使用数据方案。得到业务的初步认可后，数据合作的第一步就完成了。

2. 激发业务人员使用数据的兴趣

营销业内一般将个体的属性特征统称为“标签”。一开始，为业务人员设计的标签大多为原始类标签，即现有数据库表中的字段经过清洗登记后即可提供给业务人员使用。

数据产品经理开始给业务人员设计一些更具有业务气息的统计类标签

只有价值线和数据线同频共振，互相迭代，企业的数据资产体系才能真正构建起来。

后台回流数据表明，对数据敏感的品牌运营团队可以将ROI（投入产出比）提高到4，乃至8以上，而同时段普通通投广告的平均ROI一般在1.4～1.8。

精准营销的广告收入超出无差异广告投放的部分就可以简单视为数据资产的价值增益。

无线端兴起后，Cookie技术不再适用，在无线日志中能获取到的是无线设备码Device-ID，例如IMEI、IMSI、IDFA、MAC等。

只有完成了多渠道ID的识别打通，才能实现跨屏联动、多屏影响的广告策略

从此精准营销确立了从数据接入→客户识别→人群圈选→透视分析→定向投放→回流优化的完整闭环链路

此时，数据事业部开始制定数据资产使用的共享原则：加入数据联盟的生态伙伴在获得其他伙伴数据资源的同时，需要贡献其自身业务板块的数据资源，即“用给同频”的合作模式。

数据部门做好数据资源的统一管理和调用性能的稳定保障，而业务部门则可以专注于业务场景优化和打磨数据创新应用。

向O2O部门开放所有可用标签，让对方业务人员可以自由查看、使用消费者标签库中的标签资产，并安排数据产品经理向对方业务人员提供数据使用上的贴身服务。

金融数据在安全脱敏后进入数据中心，数据资产保障金融业务平稳使用

各部门年终考核项中都需要考核其数据化运营程度，最基本的判断方式为接入使用标签资产库的程度。

消费者标签库所包含的主要属性维度

数据资产4.0：更广泛领域的数据实践

将这种数据使用的能力、经验带给外部企业，特别是传统企业，他们更需要数据的唤醒与赋能。

在对保险行业进行全面的业务梳理后发现，至少需要构建“保险人”“代理人”“保险产品”“保单”“购买”“回访”“理赔”“保全”8个对象的标签库

因此不能用单一领域数据推测其某一通用维度的标签取值，而需要将标签按照场景拆细，尽量客观地反映场景情况。

标签设计工作也一样，应该仔细推敲，增加标签的场景、时空维度，使标签能真实还原出任意场景中的立体对象，或该对象身上任意切片的全光谱信息。

2.2 方法论抽象的2个阶段

从历史积累的工作流程中抽象出通用的资产设计方法，经历了方法梳理和原理研究两阶段。

设计标签的能力可不可以产品化？产品经理的使命是将社会问题通过可复制的产品能力来解决，而不是单点单次地重复。”

1. 先梳理标签还是对象

如果将这些指标一一摊开、仔细检查，会发现一个很大的问题：指标这么多，很可能并不指向同一对象

因此在梳理数据资产设计方法论的过程中，第一件事情并不是直接关注“标签”，而是把注意力放到标签的核心本质——“对象”身上。只有把一家企业经营流程中涉及的所有对象都整理和筛选出来，才算确立了标签生长的根基。

而“场景”应该是“人”“物”“关系”概念之上更高一层的概念：某一场景中至少包含一种“人”、一种“物”、一种“关系”。

当标签达到一定的数量时，就需要有一种标签的分类管理方法，即合理设置的标签体系。

而找寻逻辑奇点不要用归纳法，而应该用纯逻辑，因为归纳是基于现象的总结，而对现象的观察容易受到当前思维认识的局限而变形。要用纯逻辑，则需要熟练掌握逻辑知识、现象发生过程，在脑中进行上百次的推演论证，直到某天“牛顿的苹果”砸下。

在具体行动之前，要先了解清楚定义和基本原理，这非常重要。

2. 以树为原型的理论框架

2.3 标签在数据系统中的定位

标签是面向业务的数据资产组织方式，因此标签在数据系统中处于核心位置。

标签是具有业务含义或对业务有指导意义的数据定义

从广义上讲，企业拥有的所有数据资源，包括原始数据、中间数据、临时数据、数据类目体系、标签类目体系、标签、标签类目体系方法论等都是数据资产。

从精准定义上讲，数据资产是指由企业拥有或控制的、能够直接为企业带来经济利益的数据资源。以标签形式组织的数据资源就是数据资产的最佳呈现方式。

数据管理部门负责将标签商品上架展示，业务部门作为消费方可以在标签集市中搜索、查看、收藏、下单。申请审核通过后，业务部门就可以在服务管理中导入、配置标签的使用方式，最终创建完成一个数据服务接口或数据应用系统。

标签创新了一种数据使用模式：将数据打散到最小粒度单元，每次使用时，以搭积木的方式灵活选取所需零件，通过工具或平台支撑快速完成某一数据服务或数据应用的装配。

数据资产有采集、生产、管理、运营等成本，数据资产的使用方需要为数据资产的使用“记账”或“买单”，同时数据管理方必须从价值的考量出发，不断优化和更新数据资产的最佳配置。

业内已有非常多的成熟工具可以对标签进行基本的管理控制，例如阿里云的DataQuotient、数澜的标签中心、百分点的用户标签管理、神策的用户画像、易观的方舟智能画像、个推的个像等。

从架构角度看，数据中台上承业务数据积累，通过自己的数据平台工具，将原始数据加工成数据资产，并通过数据资产服务化下启数据应用场景，帮助业务端或管理端降本增效。

在数据中台内部，具体又细分出开发工具层、数据资产层、资产管理层、数据服务层、数据运营体系、数据安全体系等模块

2.4 关键术语的定义和解释

由企业拥有或控制的，能够直接为企业带来经济利益的数据资源。通常需要有较好的组织形式，数据资产才可以被编目、被管理、被高效使用。

数据中台是一套可持续“让企业数据用起来”的机制。数据中台是依据企业特有的业务模式和组织架构，以有形的产品和实施方法论为支撑，构建的一套持续不断把数据变成资产并服务于业务的机制。

根据加工方式的不同，标签可以分成基础类标签、统计类标签和算法类标签。

元标签是标签的标签，即对标签的属性信息（特别是业务化属性信息）梳理。通过元标签，业务人员可以快速理解标签定义，获取标签设计、加工、管理、使用等相关信息。

数据类目体系是将企业原始拥有的数据字段，采用类目体系的方式进行梳理所形成的目录结构。

标签类目体系是将企业业务上所需的标签，采用类目体系的方式进行梳理所形成的目录结构。

标签类目体系方法论中的场景指某环境下，具体对象（人、物、关系）在时空中的表现。

前台标签类目体系中的场景往往指的是前台业务使用数据资产服务解决自身业务问题、提升业务效率的数据应用场景。

前台类目与后台类目仅存在映射关联，并不直接挪动标签的物理位置，因而前后台是相互隔离的。因此前台类目可以灵活多变，并不影响后台类目的稳定统一。

3.1 数据资产可复用

中台最核心的目的就是完成前台业务对后台资源的快速调用、快速试错

既然数据中台的第一要义是把常用的数据资源沉淀下来供前台业务快速调用，那么标签作为可复用的数据资源的最佳载体，自然就是数据中台理念的落地核心了。

2）前台业务调用数据资源时中台能快速响应、无缝连接。

前台业务通过选取标签、配置所需的数据服务，将数据资产转化为对前台业务赋能的数据应用。

标签和标签类目体系主要关注的是哪些数据可复用，因此它们一定不是用来解决单一场景问题的。

数据资产化的最终目的就是让业务人员也能阅读、理解、方便地使用数据，因此将数据资产转化为可阅读、易理解的载体就是把数据资源标签化

3.2 面向业务可理解

数据资产之所以称为资产，是因为它是从价值出发，经整理、管理、优化，对业务真正有帮助、能带来效益的数据资源

业务人员可以通过标签的定义、逻辑、值字典、常见应用类型、使用效果等维度来全面简单地理解数据资产。

好的数据资产设计办法是桥接数据和业务的中间逻辑层，让数据变得可阅读、易理解

好的数据资产设计办法是一种统一的对象数据描述办法，应该把个体刻画升级为群体刻画

所谓业务导向，并不是说要听业务专家的意见，而是要听业务流程、业务人员、业务数据所表达出来的意见。

真正持久的数据资产建设一定不是从治理出发，干的都是苦活累活但是效果却不显著，业务并不为苦劳埋单，而要从价值倒推，让业务部门通过收获数据红利来反向促动数据部门治理和优化数据，并按需主动提供新的数据源。

当前业内提到的数据资产构建方法其实有两大派系：一种是技术派系，类似数仓建模理论、数据治理方法等，目的是使海量数据能够稳定、高效地运转，属于技术半程范畴；而另一种就是本书所倡导的以标签作为数据资产价值载体的标签类目体系方法论，其目的是激发业务诉求，寻找并发挥数据价值，是面向业务半程的。

3.3 数据价值可衡量

企业迫切需要一种数据转化方式将设备中的信号、数据库中的字段、业务人员口中的指标等，映射和封装成一种可确权、可交易、可持续、可衡量的数据商品

标签对数据的业务导向封装正好匹配了数据商品化的思路：将数据拆解成最小粒度单元，既具备某一对象的共有属性，又有丰富的多样性。通过标签这种组织方式，可以实现对数据资产的管理、使用、衡量的全链路闭环，因此标签完全符合数据商品化的载体要求。

数据商品在参与价值分配时，不能直接对数据本身定价或分配价值，只能对带有具体数据的数据服务形态定价或分配价值

数据商品中的数据本身根据不同的颗粒度可以分为对象层、表层、字段层、字段取值层。

在标签类目体系方法论中，对象对应于根目录，多种表对应于多级类目，属性/字段对应于标签，属性/字段值对应于标签值

通过服务化的工具，可以将选中的标签集合快速配置成数据服务或数据应用（真正的数据商品形态），供业务部门使用。

4.1 为什么要先讲道

不要用有限的生命去无规则地学习无限的点状知识。建议先建立成熟的思维认知，用武装好的大脑去学习最核心的原理性知识、方法论。在现实社会中遇到具体问题或对某方面知识产生兴趣时，再有针对性地补充点状知识。

人们总结出了两种理性思维：归纳法和演绎法

掌握这种能力的人就是市场上最缺乏的既懂数据、又懂业务、还会方法论的人。

采用习以为常的归纳法去认知世界，容易形成对世界的错误认知，这是对人类认知的最大限制：以为的快反而变成了一种遥不可及的慢。

4.3 根、枝干、叶/花

“对象”分两大类型：实体对象（人、物）和关系对象（强关系、弱关系）。因此存在两大类的标签类目树：实体树和关系树。

类目是对“标签”的分类，而非对“对象”的分类。

树的叶/花部分对应的就是对象的各种属性，即标签

动、静标签的区别在于某一对象个体在该标签下的标签取值是否会经常变化

由大量动态标签的取值可以推测和演算出静态标签的取值

标签类目体系实质上是对对象属性的模式设计

某一对象是否需要持续细分出不同的细根，取决于待细分对象的“树形轮廓”是否发生了质的变化。就像基因片段发生一定量变后会造成物种隔离，形成一个新物种，当量变引起质变时，就需要梳理一个新的根目录对象。

口语中的“标签”并不等同于标签类目体系方法论中的“标签”，而应该等同于其中的“标签值”

标签体系设计是一种对对象统一进行本质刻画的数据描述办法：把个体观察升级为群体观察，而非过去对个体现象的归纳，更具有面向未来的场景化适应能力。

4.4 能量、养分和凋零

业务使用是对标签树的养分供给，业务调用量大的标签会生长茂盛，没有业务使用的标签会凋零下架，这是标签的生命规律。

如果要将交易关系的标签“交易金额”转化为消费者实体的标签，建议转化为“最近一次交易金额”“第一次交易金额”“历史交易总金额”“平均交易金额”“交易消费等级”“偏好的交易金额分段”等统计类或算法类标签。这些标签不再指向某一次具体的交易，而是被提炼为一种可复用的、带有“业务意义”的标签，化零为整。

将没有复用价值的标签下架是必须考虑的标签生命周期过程，否则企业很容易面临数据资产爆炸的风险，即数据项越来越多，管理运营成本巨大。

对于企业来说，需要重点维护的就是使用频繁、具有复用价值的实体树，因为业务关系是现象，而实体则往往是商业本质。

4.6 资产树使用模式推演

每个标签就像一片独特的叶子，拥有独立的ID、名称、逻辑、类型、值字典等元标签取值

元标签中涉及业务元标签部分的，应该以业务人员日常沟通交流的方式进行描述，例如标签名、标签业务逻辑、标签场景示例、标签价值等都属于业务元标签范畴；涉及技术元标签部分的，应该以技术人员日常工作沟通的方式进行刻画，例如标签血缘、标签开发逻辑、标签源表、标签物理存储方式、标签映射字段等都属于技术元标签范畴。

资产实体指的是在设计好的标签类目树模式下的具体个体实例，即每个对象个体。

种树和用树要分开，即种即用的情况也会有，但是仅适用于小园子；

• 不考虑种树，直接奔着用树去的时候，会手忙脚乱且容易一叶障目；

• 找到一种高效办法串联好种的树（资产）和用的树（服务）。

第5章 法：完整的设计方法

这种通过数字化方式将现实世界事物映射到数据世界对象的过程也称为数字孪生。

5.1 3个构建前提

三大构建前提包括统一的数据思维、充分的前期调研、正确的落地思路

数据认知三大问题数据在哪？数据价值在哪？数据怎么用？

在数据架构中，最底层是各业务系统通过业务流程或有目标的数据留存所产生的信息系统数据。利用采集、交换等方面的工具，技术人员可以将各业务系统中的数据进行清洗、交换、汇总，形成企业的数据中心。这一过程完成了业务数据化。

图5-3　企业数据构架示意图

哪个业务环节上存在哪些痛点？这些痛点发生的原因是什么？这些痛点的严重程度如何，会产生如何严重的后果？因此产生了怎样的需求？

痛点不等同于需求，需求不等同于功能

5.2 6个设计步骤

数字映射可以将现实世界中的一切事物归属为对象。对象分为“人”“物”“关系”三大类型

流程类的数据类目往往可以按照业务归属、业务存储库、业务表等对数据进行分类。

数据类目体系反映了构建者对企业原始数据的理解，现实中数据库、数据表、数据字段是如何组织的，就相应转化为数据类目，不需要过于发散。

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

“标签”则是指从原始数据清洗加工而来，能够为业务所用并产生价值的数据资源，一般都需要结构化到字段粒度，保障服务化使用。它面向数据应用端，解答的是“数据怎么用”“数据的价值是什么”的问题。

标签是对某一对象的属性刻画，是结构化到字段粒度的数据资源

标签和标签值是不同颗粒度层级的数据资源，所指向的概念层级也不一样，需要加以区分和加强理解。

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

思路一：从核心词属性角度发散

1）标签类目体系可以实现标签管理的快速规整。

2）标签类目体系可以对标签设计进行系统性的规划。

2）当前暂时未用到，但是将来可能会用到的标签是否需要设计？

经标签类目体系使用场景的大量验证发现，三级分类结构，且每级分类不超过10个，即总类目数不超过1000个是比较合适的类目结构。

后台标签类目体系比较稳定，是对人、物、关系各类对象的本质描述及描述属性的普适分类。它与业务场景松耦合，保持对人、物、关系各类对象的全局、稳定的标签定义。

6.1 标签规范

标签化的核心是用数据思维去理解、抽象、提炼业务场景并解决业务问题。

在数据物理层面往往映射为某张大宽表中的主键，这张大宽表中的信息都是对该主键对象的详细刻画和数据记录：大宽表的列即映射为标签，大宽表的行记录则对应于具体的对象在各标签属性上的具体属性值记录。

多张主键相同但信息类型不同的数据表关联在一起就可以形成该主键对象下的大宽表。例如将消费者基本信息表、消费者地理位置表、消费者社交关系表按照消费者ID关联在一起，就可以形成一张消费者多维度信息宽表。

3. 标签是对象的属性，颗粒度到字段级

4. 标签值是对象属性的具体取值

标签值的取值类型可以是数值型、文本型、日期型、KV型，但主要为数值型。数值型中又分可枚举的离散值和不可枚举的连续值。

元标签主要有标签所属根目录、标签所属类目、标签名、标签描述、标签加工类型、标签逻辑、值字典、取值类型、示例、更新周期、安全等级、适用场景、当前调用量、质量分、价值分、表名、字段名、负责人、完成时间等

对于算法模型产出的标签，建议标签名称前增加“预测”二字，如“预测是否有房”“预测职业”“预测年龄”等

一般在有标签逻辑信息的情况下，标签描述可以不写，但是考虑到数据安全，有时标签逻辑信息不能完全对外展示，标签描述就成为唯一的对外解释窗口，就有存在的必要。

标签根据加工类型的不同可以分为原始类标签、统计类标签和算法类标签。

统计类标签：原始数据通过ETL加工，例如求和、平均、正则表达式、规则运算等简单数学函数运算，成为标签后被业务人员使用。

原始类标签往往是基础属性类标签

统计类标签往往是行为习惯类标签

在原子标签的基础上，增加维度信息去详细刻画或扩展某一类属性，即将【场景】+【时空修饰】+【计算方法】+【可选修饰】等信息联合作为修饰词。

算法类标签往往对应于兴趣爱好、性格思维、价值评估等高级抽象类标签

算法类标签逻辑一般需要定义清楚，需纳入算法模型处理的重要特征项、正负样本定义或学习样本逻辑、模型选型及模型结构（如有能力）、模型输出结果形式及阈值分段设定、希望的模型预测结果性能指标等。

建议构建1～4等级的安全定级（L1～L4），第一等级的标签（L1）是公开标签，可对外公开，是最为开放的数据标签，安全等级最低；第二等级的标签（L2）是内部标签，是在企业/机构内部跨部门可直接流通、申请、使用的数据标签，安全等级较低；第三等级的标签（L3）是保密标签，企业内部跨部门使用需要申请授权，批准后才能使用的标签，安全等级较高；第四等级的标签（L4）是机密标签，是企业/机构内部少数人才可以使用的标签，且不可传播，安全等级最高。

1）一个对象实例的某一标签取值只允许存在一条记录。

6.2 谈谈组合标签

2）找出两个对象的关联标签非常重要。

6.5 标签质量怎么看

标签的质量可以从三大维度上评估：数据来源、标签加工过程和标签使用过程。

6.8 标签方法论与数仓建模的异同

标签类目体系的建设思路是先构建标签资产，再构建数据服务化能力，组合式地满足业务端快速变化的场景化需求。

与数仓建模基于领域建模不同，标签方法论基于对象建模，描述的是对象本质信息。

7.1 标签工具

标签工具的核心模块包括：标签体系设计、标签同步加工、标签管理、标签门户、标签应用等

7.2 4个经典模板

用户标签类目体系结构图

9.1 7点价值总结

标签价值主要体现在：串联、业务友好、全息刻画、可复用、可管理、可运营、创新场景等7个方面