一、数据标签的结构

1. 业务域

比数据域更高维度的业务划分方法，适用于特别庞大的业务系统，且业务板块之间的指标或业务重叠性较小。例如用车业务板块包含乘客端、司机端，电商业务板块包含商城、返利模块。

2. 业务过程

业务过程可以概括为一个个不可拆分的行为事件，如下单、支付、评价等业务过程/事件。

看到这一系列的名词，很多人可能就开始懵逼了，业务域倒还能理解，简单来说就是对不同业务的分类；业务过程也容易理解，相当于画业务流程图呗。

那数据域又是何方神圣？

3. 数据域

是联系较为紧密的数据主题的集合，是对业务对象高度概括的概念层归类，目的是便于数据管理与应用。

简而言之，数据域就类似于我们电脑桌面要建立不同的文件夹来存储数据，这些个文件夹名就是数据域。

维度、维度属性、修饰这些怎么理解？有什么用途？

4. 维度

是度量的环境，用来反映业务的一类属性，这类属性的集合构成一个维度，可以从who-where-when-what层面来看。

5. 维度属性

维度属性隶属于维度，相当于维度的具体说明，如用户维度中性别为男、女。

6. 修饰词

指除了统计维度以外指标的业务场景。

7. 修饰类型

对修饰词的抽象划分。

简而言之，维度和修饰都可以理解为原子指标的一些限定条件，懂sql的会更好理解一些，一般是写sql时，放在where语句后边的。

8. 度量/原子指标

原子指标和度量含义相同，某一业务行为事件下的度量，是业务定义中不可拆分的指标，如注册数。

9. 时间周期

用来明确数据统计的时间范围或是时间点，如最近30天、自然周、截至当日等。

10. 指标类型

包含原子指标、派生指标。

原子指标= 行为事件+度量

派生指标= 一个原子指标+多个修饰词+时间周期

例如：原子指标=完单量，派生指标=近一周iOS乘客完单量，包含时间周期=近一周，修饰词=iOS，维度=乘客，原子指标=完单量。

二、数据标签开发中常见问题与解决方法

问题1：指标定义不够清晰明确，两个页面上的指标定义其实是不同的，但是展示给商家看到的可能是同一个中文名称。又或者同样一个含义的指标在不同的界面上展示的名称却不相同，让人产生歧义。

问题2：一个指标因为由不同的数据开发同学来制作，可能会被重复开发，不但造成资源浪费，还会造成维护困难。

问题3：对于需要新开发的指标，不仅缺少开发工具简化开发流程，甚至该使用哪些表，不该使用哪些表很大程度上都要凭借数据开发同学与数仓同学的经验。如果稍微马虎一点或者缺乏经验，比如使用了某些业务域下特有的表或者不是由数仓提供的统一中间层的表就可能会使用错误的数据，造成后期返工等情况。

为了解决上述问题，指标库应运而生。

指标库中指标数据的来源一般都是从DW 库，数仓统一中间层的表中通过计算得来。指标库最基础的元数据，比如维度信息，原子指标信息等都是使用数仓统一中间层。

第一步：数仓先确定业务域并导入DW 库统一中间层的表。

要录入的维度指标属于哪个域先确定下来，例如店铺属于店铺域，订单支付金额属于交易域。只要数仓内部自己有统一的规划即可。然后就可以导入中间层的表到指标库。

第二步：数仓定义原子指标，维度，修饰词。

如果之前没有定义过，就新建维度指标等，并关联到正确的表字段上，在第一步导入表的过程中也可以快速关联到已经存在的维度指标。

第三步：生成派生指标。

有了维度，原子指标等元数据，就可以定义派生指标了。利用指标库的SQL 生成功能可以快速生成技术口径。同时在指标库上可以快速创建单个派生指标的数据开发平台调度任务。

第四步：应用派生指标

选择需要的多个派生指标后可以通过指标库快速创建多个派生指标的数据开发平台调度任务和统一数据服务的在线API。至此就可以在线上查询一批指标的数据了。当然指标库上也支持临时查询指标的数据。

标签库的特性：

（1）检索：标签多意味着检索效率低，大多业务人员习惯于就访问自己关注的那几个标签，因此需要设立业务专区，根据自身企业的业务分类将标签分门别类，但无论哪种分类都解决不了一线灵活管理的要求，因此还需要提供自定义目录能力，共性的标签确保权威性，个性的标签确保灵活性。

（2）实时：可以将整个场景(LBS)封装成一个动态标签，然后再配置一个触发规则；

（3）簇群：每个用户都处于一个特定群体中，需要结合业务实际突破了原有以用户为核心的标签管理方式，打造簇群这种新的标签体系，这样可以大幅提升客群管理效率和生成效率，比如营销家庭产品肯定更关注户主，因此就需要家庭标签，而不是个人标签。

（4）性能：标签库特别关注两种性能，一个是实时计算能力，一种是实时查询能力，前者解决标签组合计算生成客户群的效率问题，比如10个标签组合关联得到目标用户群，你得在极短的时间生成，后者解决的是实时统计的问题，因为业务人员需要基于实际数据量调整策略。

（5）聚合标签：比如原来有四个工作地位置标签，分别是用户工作地归属地市【日】、用户工作地归属区县【日】、用户工作地归属乡镇【日】、用户工作地XXXX【日】等等，但你会发现用户在使用的时候往往无法一步到位选择到自己所需的标签，因为选择太多、粒度太细，而这种现象普遍存在。因此新增了聚合标签这个概念，就是做一次封装，最后面向用户展示的标签被整合成一个，即用户工作地归属行政区域【日】，而更细粒度的标签就定义为子标签，这是一种自顶向下的设计方法。

三、标签在营销中的应用

标签库与营销平台的衔接流程：营销平台使用的客户群全部来自标签库，用户在营销平台发起的投放流程应该最为便捷的选择到自己在标签库创建的客户群，反之，在标签库也应该最为方便的将客户群推送到营销等外部平台。

我们现在都在提中台，标签也是中台，而数据中台最核心的工作，不是建什么功能，而是持续的提升模型和标签质量，让这些数据持续的产生价值。

需要建立标签效果的反馈机制，比如依据营销的成功率进行标签的评估，你起码得知道哪个标签跟哪个营销活动有关，你才能从营销的成功情况评判标签的价值。