数据中台：标签体系建设方法与实践

01 标签是数据最细粒度的划分

通过下图一个小例子我们先感受一下标签，一个数据项可以加工出很多标签，同时一个标签也可以由很多数据项共同加工而成。

从数据查询的角度来看，最原始的数据查询方式是关键字段查询，后来演化为基于元数据的自定义查询，再到现在的标签化查询，数据的粒度是在逐步深化的，所以讲标签是数据最细粒度的划分。

从技术性能角度来看，标签是把复杂的业务逻辑转化为提前T+1跑批了。例如“是否7天内理财到期客户”，一个客户可能持有多款理财产品，这个标签如果不提前跑批会涉及多表关联以及复杂的业务逻辑判断，查询性能响应自然是吃不消的。

从不同的角度看两种方式各有千秋，前者面向技术，成本低弹性大，后者面向终端用户，业务响应快，体验好。因此标签管理的方式和程度必须以公司业务情况而定。

如果公司对于标签数据的需求不大，标签数据量也就十几个、几十个，那么暂时通过表的管理是完全可以的。
 

如果公司进入到精细化运营的阶段，那就需要大量的用户标签支撑各类业务的发展，标签的数量可能几百、上千个，这时，就一定会衍生出大量的标签搜索、详情查看、甚至逻辑修改、创建标签、标签调用等等的需求场景，这时，产品化的标签管理就是必须的了。

标签的管理，具体都是有哪些内容需要管理呢？主要包括以下两个方面：标签分类体系和标签内容信息。

标签分类是为了从海量的标签中找到想要的标签，使得所有的标签形成有机整体。标签内容信息是为了将单个标签的重要内容无遗漏地呈现，以更好地使用标签。
 

1、用户自己填写的数据生成的标签

这部分标签是用户在注册产品或者在各个模块自行填写的信息。一般就是【性别】、【生日】、【真实姓名】、【居住地】、【身份证】等。

2、通过统计用户行为，生成的统计标签

常见的做法是，基于用户在平台中的交互行为，通过对埋点收集到的数据进行各维度的统计加工。

3、通过算法生成的标签

基于历史数据训练机器学习模型得到的标签，常用的如营销响应率、产品响应率。
 

4、通过第三方采购、积累的

比如蚂蚁评分、电信数据等等。

二、按照业务场景分类

这种方式根据各自业务特点不同、业务复杂度不同，所采取的分类层级和分类也不尽相同。

这个分类，主要是用于标签系统的标签管理，按照业务方式进行组织标签类别，有助于用户的便捷使用。以下为几个参考案例：

阿里达摩盘的标签分类：

某司内部的标签分类：

某电商平台用户标签分类：

三、按照数据类型分类

1、数值型标签

如【用户最近7天购买金额】、【用户近1天浏览天数】等，这些标签都是按照一定的规则统计生成的，均是数值型标签。

组成公式是：【时间范围】+【行为方式】+【统计方式】。

下图是达摩盘标签中的部分统计标签：

2、单值型枚举标签

这类标签的最大特征，就是一个用户在这个标签中，只能有一个选项值。而且，和数值型标签的区别在于，单选型标签的选项值是可穷举的，是离散的。

例如：【用户的生命周期】，用户肯定是处于【成长期】、【成熟期】、【衰退期】、【沉睡期】其中的一个，不可能属于两个或者多个。

3、多值型枚举标签

4、文本型标签

这类标签最大的特征，是不连续、且不可穷举。

例如，【用户常用热搜词】，每个用户都可以有自己的常用热搜词，但热搜词的数量是巨大的，不能像单选型标签或者复选型标签那样，几个、甚至最多几十个选项，就能覆盖所有。为啥要进行这个分类呢？

05 标签建设的整体架构

一个完整的标签建设项目包括标签加工、标签装载、标签管理、标签服务四个环节的，如下图所示：
 

标签加工：很多客户问我标签加工是放在大数据平台，还是传统数据平台中？其实放在哪里都可以，如果你的基础数据已经落地在HDFS了，那建议你在大数据平台中做，毕竟分布式架构的加工跑批速度会有优势，另外对于算法挖掘和文本挖掘类的标签传统数据仓库技术也无法支撑。

标签装载：标签装载层是标签对外提供服务的物理存储层，这里面数据库选型尤为重要，后面有专门的章节分析。数据建模方面，宽表是标签数据模型的金标准。有很多客户问我，宽表中的字段数有没有限制？一张宽表字段数如果太多可不可以按主题拆表做join？标签所有场景的性能响应要求都是秒级的，任何数据库表关联都会大大降低查询效率，所以数据库选型要充分考虑这些因素。

标签管理：标签管理是指平台应用的管理端，管理端是面向内部用户使用的，服务端是面向客户服务的。管理端包括数据代理、标签库管理、标签元数据管理、标签审批、标签上下架、标签应用效果评估、衍生标签配置、客群提取、客群洞察等标签全生命周期管理功能。

标签服务：标签服务是指平台应用的服务端，管理端和服务端要做微服务切割，目的是解耦并建议分开部署，隔离不同渠道调用所占用的资源，例如内部筛选客群负载过大时，不能影响手机银行标签API调用服务，服务之间要做隔离。服务端设计要在网关层面充分考虑负载并发的压力，做分布式部署，保证并发性能的瓶颈不出现java进程这一端。

06 标签全生命周期运营管理体系

标签是打通数据后台与渠道系统之间的重要载体，标签系统上线后会迅速过渡到跨部门、跨系统的标签运营管理阶段，所以做好标签的创建、审批、开发、上线、应用、评估、共享、变更、下线等全生命周期流程管理规范是一项非常重要的工作。
 

在标签运营管理阶段，对于新增标签需求的评估和设计是重中之重。下图是我们做过的一个案例，电子银行部想在手机银行中针对“是否30天内APP新注册未绑卡”的客群展开营销活动。最简单粗暴的方式就是直接将这个布尔型标签提给数据加工团队，这么做就没有考虑标签的复用。

好的设计是尽可能将一个复杂的标签拆解成若干基础标签，基础标签是可以复用的。例如可以将这个标签拆成“是否30天内APP新注册客户”和“是否绑卡客户”两个标签，两者and衍生成目标标签。当然这里有个30天的参数是容易变的，更好的设计是将“是否30天内APP新注册客户”进一步转化为“APP注册天数”的设计，然后通过衍生标签配置满足业务需求。

当然，这么做的劣势就是查询性能的损耗，过去没有大数据技术的支撑这种设计显然是不合理的，现在技术突破了，业务创新就可以有更多更合理的选择。

07 银行业标签应用场景

标签在银行业的应用场景非常广泛，我们常讲的标签很多人会默认为客户标签，其实贴标签的对象不仅仅可以是客户，还可以是账户、产品、机构、员工、渠道等等，例如我们可以给员工贴标签，譬如通过历史数据观察员工最擅长销售哪类金融产品、员工月均访客次数、员工绩效等等。
 

在规划标签的应用路径时，建议大家先搞清楚标签的服务对象，是针对内部员工的还是直接对客服务的。例如淘宝中的猜你喜欢就是标签直接服务于客户，同理如果标签服务于手机银行、网银、STM等自助渠道就属于对客应用。如果标签服务于CRM、营销平台、柜面等员工渠道就属于内部员工类应用。

08 客户标签、客户画像与客户360°视图

客户标签、客户画像、客户360°视图三者之间的关系很多人搞得云里雾里的，其实从字面意思上就容易理解它们的含义。

我请一位画家帮我画一幅画像，那么这幅画像首先是静态的，只反映我当下的样子。画家动笔时当然需要仔细观察我的特点，比如眼睛、鼻子、嘴的特征是什么样的，这些特征就是标签，它也是静态的。画像只反映当下的我，如果要研究我的全貌就需要了解我的历史，我的家庭成员都有谁，我的朋友圈都有谁等等，这就是客户360°视图。

所以，客户标签是客户画像的组成元素，客户画像是轻量级的客户360°视图，这是我的理解。
 

客户画像相对于客户360°视图来说，虽然不能完整地刻画客户全貌，但是它也具备三个优点。

关于于标签管理的产品化，主要产品模块包括标签列表及标签详情页。其实主要就是针对标签的分类及标签的内容信息。

1、标签列表

标签列表页，主要涉及的功能模块有：

标签目录检索。即将标签体系作为检索条件，检索标签

标签关键词搜索。支持用户通过搜索的方式直接找到标签

标签列表。呈现检索或者搜索后的标签列表，列表可呈现必要标签信息

标签排序。按照关键数据进行标签的排序

2、标签详情页

标签详情页，主要涉及的功能模块有：

标签基本信息

标签的应用信息

标签的数据表信息

标签的加工信息

标签的质量信息