CDP标签体系三层分类法，给你一个马上能用的框架

 

标签建了两三百个，业务说一个都用不上。问题不在标签少，在标签乱。这篇给你一个三层分类框架，照着搭，不跑偏。

做CDP的客户十个有九个上来就问，标签体系怎么建。我说你先别急着建，先回答我一个问题，你现在有多少标签，业务用过几个。

答案几乎一模一样。标签建了两三百个，真正被业务用起来的不到二十个。剩下的全在那儿吃灰，占着计算资源，还没人敢删。

C企CDP项目里我花了大半年搞标签体系，踩了一堆坑之后总结出一套三层分类法。不是什么高深理论，就是让你建标签之前先想清楚，这个标签属于哪一层，用什么方式建，谁来维护，什么时候该下线。想明白这几件事，标签体系就不会乱。

---

标签体系的通病

先说说我见过的几种典型翻车场景。

第一种，一锅炖。不分层不分类，想到什么建什么。市场部说要个「高价值客户」标签，售后部说要个「活跃维修客户」标签，运营部说要个「流失风险客户」标签。建完往那儿一扔，没人管数据来源是什么，计算逻辑是什么，更新频率是多少。三个月后回头看，发现「高价值客户」和「活跃维修客户」的底层逻辑高度重叠，圈出来的人群有70%是一样的。

第二种，照搬别人家的。有客户拿来一份同行的标签清单，说人家有三百多个标签，我们也照着建。我问你了解他们的业务场景吗，了解他们的数据源吗，了解他们的标签计算逻辑吗。都不了解，就想把名字搬过来。搬过来的标签没有数据支撑，算不出值，上线第一天就是空壳。

第三种，只建不管。标签上线了就完事，没有生命周期管理。半年后业务需求变了，标签逻辑过时了，但没人下线，还在那儿跑计算任务。有些标签的数据源早就改了字段名，计算直接报错，也没人发现。标签系统变成了一个垃圾场。

这三种病的根子是一样的，建标签之前没想清楚分类和规范。三层分类法就是治这个病的。

---

三层分类法

我把标签分成三层，基础属性层、行为特征层、预测模型层。每一层的定位、数据来源、计算方式、维护频率都不一样，搞混了就出问题。

第一层 基础属性标签

这一层回答一个问题，这个人是谁。

数据直接从业务系统映射过来，不加工不算，原样取值。性别、年龄、手机号归属地、车型、购车时间、会员等级，这些属于基础属性。

在C企CDP项目里，我们把这层标签叫做事实类标签。创建方式用的是值映射，说白了就是把数据源的某个字段直接映射成标签。比如数据源里有个「客户性别」字段，值映射过来就是「性别」标签，男就是男，女就是女。

这层标签看起来简单，但最容易出问题的地方也在这儿。同一个属性可能来自多个数据源，销售系统的手机号和售后系统的手机号不一样，取哪个。我们的做法是用优先级规则，设定数据源优先级，优先取销售系统的值，如果为空再取售后的。C企项目里手机号标签就是这么建的，优先取会员系统的手机号，为空则取CRM系统的，再为空取DCS系统的。

基础属性层有一个特点，更新频率不高。性别、车型这些东西不会天天变，按天更新甚至按周更新就够了。别搞实时，没必要，浪费资源。

第二层 行为特征标签

这一层回答一个问题，这个人做了什么。

不是直接取值，是基于用户的行为数据计算出来的。浏览了什么页面，留了几次资，进了几次站，维修花了多少钱，上一次活跃是什么时候。这些标签需要用到事件数据和规则计算。

C企项目里这层叫规则类标签，创建方式最灵活，有三种。

自定义规则，属性加事件加已有标签，任意组合。举个例子，「高意向客户」这个标签，条件是在DCS系统留过资、线索级别是A或H、且当前不是车主。三个条件组合起来，自定义规则一把就配出来了。业务人员自己就能操作，不用找开发。

运算规则，基于已有标签做四则运算。比如「维修消费能力」这个标签，拿维修金额合计除以进站次数，算出客单价，再按阈值分成低客单、中客单、高客单三档。这种标签需要一点数据思维，但不需要写代码。

SQL规则，直接写SQL查询。适合复杂逻辑，比如「首次进站时间」这种标签，需要关联多张表做时间排序取最早一条。SQL规则在C企项目里是受权限控制的，只有授权人员才能用，因为SQL写错了可能拖垮整个计算集群。

行为特征层的更新频率比基础属性层高，因为行为数据天天在变。我们一般按天更新，高频标签按小时更新。具体看业务需求，没有统一标准。

第三层 预测模型标签

这一层回答一个问题，这个人接下来会做什么。

不是统计已有行为，是基于算法模型预测未来行为。流失概率、购买意向分、生命周期价值（LTV）、推荐倾向分，这些属于预测模型标签。

C企项目里这层叫模型类标签。说实话，这层标签在大部分企业里用得不多，原因很现实，数据量不够，算法能力不够，业务场景不够成熟。

但如果你要做，有几个要点。

第一，模型标签的输入特征来自前两层的标签。基础属性和行为特征标签建好了，模型标签才有原料。前两层没建好就想跳到第三层，等于盖楼不打地基。

第二，模型标签一定要有业务解释性。不能丢一个黑盒模型上去，输出一个分数，业务问你这个分怎么来的，你说算法算的。这种标签没人敢用。C企项目里我们做流失预测模型，输出的是一个0到100的分值，但同时还输出影响这个分值的前三个因素，比如「近30天未登录」「维修频次下降50%」「最近一次到店超过6个月」。业务拿到这个标签，不仅知道谁可能流失，还知道为什么可能流失，运营动作才做得出来。

第三，模型标签需要持续验证和迭代。模型上线不是终点，是起点。预测准确率要定期回测，发现衰减了就要重新训练。C企项目里我们的流失模型，上线第一个月准确率85%，三个月后掉到72%，数据分布变了模型就过时了。如果不持续迭代，模型标签比规则标签更危险，因为业务会基于错误预测做决策。

---

五种创建方式怎么选

把三层分类和五种创建方式对应一下，你就知道该怎么选了。

标签层级	标签类型	推荐创建方式	适用场景
基础属性层	事实类	值映射、优先级规则	直接取值、多源取优
行为特征层	规则类	自定义规则、运算规则、SQL规则	组合条件、数值计算、复杂查询
预测模型层	模型类	值映射（模型结果映射）	算法输出结果入库后映射为标签

有个原则，能用简单的就不用复杂的。值映射能搞定的事别用SQL，自定义规则能配出来的别写代码。标签越简单，后续维护成本越低，出错的概率越小。

---

标签命名规范

标签建多了，命名不规范就是灾难。C企项目早期没有命名规范，大家各起各的名字。市场部建了个「高价值客户」，售后部建了个「高价值车主」，运营部建了个「VIP客户」，三个标签的底层逻辑几乎一样，名字不同，谁也搞不清区别。

后来我们定了规范，标签名称不超过15个中文字符，不能纯数字或特殊符号，不能重名。但这还不够，我建议再加上一条，标签名称要能看出层级和归属。

命名格式我推荐这样的结构，[对象][维度][标签名]。比如「客户-消费-维修消费能力」「客户-行为-高意向度」「客户-预测-流失概率」。一看名字就知道这个标签打在什么对象上，属于什么维度，是什么类型。

有人觉得这个格式太死板，不好看。但你建到两百个标签的时候就知道，规范比好看重要。

---

标签生命周期管理

标签不是建完就完事的，它有自己的生命周期。上线、运行、变更、下线，每个阶段都要有人管。

C企项目里我们设计了四个状态。

上线，标签通过计算验证，数据正常，正式投入使用。上线之前要走审批，标签创建人提交，数据管理员审核，确认标签逻辑正确、命名规范、数据来源可靠。

变更，标签的计算逻辑或数据源发生变化。比如「高意向客户」标签原来只看DCS留资，现在要加上官网留资。变更要走流程，变更记录要留痕，因为标签逻辑变了，历史人群包的圈选结果可能会变。

下线，标签不再使用。两种情况，一种是业务需求没了，标签没用了。另一种是标签逻辑过时了，数据源变了字段或者业务规则调整了，标签计算出来的值不对了。下线不等于删除，标签数据保留，但不再参与计算和圈选。

停用，临时停止使用。比如发现标签数据异常，先停用排查，问题修复后再恢复。

C企项目里我们还做了标签使用分析，每周出一份报告，哪些标签被用得多，哪些没人用。连续四周使用次数为零的标签，触发下线预警，通知标签创建人确认是否下线。这个机制跑起来之后，标签总数从三百多精简到一百出头，留下的都是真正有业务价值的。

---

写在最后

标签体系不是技术问题，是业务问题。技术能帮你把标签建出来，但标签有没有用、该不该建、什么时候下线，这些问题技术回答不了。

三层分类法的价值在于，它逼着你在建标签之前先想清楚三件事。这个标签回答什么问题，用什么方式算，谁来维护。想清楚这三件事，标签体系就不会乱。

如果你正在做CDP或者标签系统，我建议从第一层开始，把基础属性标签建扎实，再去碰第二层的行为特征标签。第三层预测模型标签别急着上，等前两层跑顺了、数据量够了、业务场景成熟了再考虑。我见过太多团队一上来就想搞AI模型标签，结果基础标签没建好，模型没有输入特征，做出来的东西业务不认。

说白了一句话，标签体系这件事，慢就是快。先把地基打好，后面盖楼才稳。

---

作者，凌波，18年汽车行业数字化老兵，CDGP数据治理专家。从DMS运维到数据中台架构，干过甲方也干过乙方。

博客园「凌波微数」，持续分享数据治理、数据架构、企业数字化的实战经验。如果对你有用，点个推荐吧~~