标签生命周期管理：从创建到归档的完整旅程
标签不是一成不变的。它像软件代码一样，有自己的生命周期。我见过太多团队，标签建了一堆，最后没人敢用、没人敢删，整个标签体系变成了一锅粥。
这一章，我们就聊聊标签从生到死的完整流程。说白了，就是一套治理规则。你想想看，如果没有这套规则，标签库会变成什么样？
1. 标签创建：不是拍脑袋的事
创建标签，看起来最简单。填个名字，选个类型，完事。但我在项目中遇到过，有人把「用户活跃度」和「用户活跃天数」当成两个标签来建。结果呢？数据冗余，查询混乱。
我个人习惯，创建标签前先问三个问题：
- 这个标签解决什么问题？ 业务场景必须明确。
- 有没有已有标签可以复用？ 避免重复建设。
- 数据源是否稳定？ 别建一个标签，数据源三天两头断。
标签的元数据结构，我建议至少包含以下字段：
| 字段 | 说明 | 示例 |
|---|---|---|
| 标签名称 | 唯一标识，遵循命名规范 | user_active_level |
| 显示名称 | 业务可读的名称 | 用户活跃等级 |
| 数据类型 | string / int / boolean 等 | string |
| 业务域 | 所属业务领域 | 用户运营 |
| 数据源 | 标签值从哪里来 | dwd_user_behavior_di |
| 负责人 | 谁对这个标签负责 | 张三 |
2. 标签审核：把问题扼杀在摇篮里
审核这一步，很多团队会跳过。觉得「建个标签而已，审什么审」。嗯，这里要注意，跳过审核的代价，往往是后面花十倍的时间去擦屁股。
我曾经接手过一个项目，标签库里有 3000 多个标签。其中「高价值用户」这个标签，居然有 7 个不同的版本。有的按消费金额算，有的按登录频次算，有的按客单价算。你说，报表出来能信吗？
审核主要看三点：
- 命名规范检查：是否遵循了团队约定的命名规则。比如统一用下划线分隔，禁止中文混用。
- 语义冲突检查：新标签是否与已有标签含义重叠或矛盾。
- 数据可行性检查：数据源是否存在，计算逻辑是否合理。
3. 标签发布：让数据真正流动起来
审核通过后，标签进入发布阶段。发布不是简单地把标签状态改成「已上线」。它涉及几个动作：
- 元数据同步：把标签定义推送到数据目录、数据地图等系统。
- 数据管道激活：如果标签需要定时计算，启动对应的 ETL 任务。
- 权限配置：谁可以读、谁可以写、谁可以管理。
- 通知相关方：告诉业务团队，有新标签可以用了。
我个人习惯，发布时做一个「标签上线检查清单」。逐项打勾，避免遗漏。比如：
标签上线检查清单示例：
□ 标签元数据已录入数据目录
□ 数据源表权限已开通
□ 计算任务已配置调度
□ 标签值抽样验证通过
□ 业务方已确认样例数据
□ 监控告警已配置4. 标签废弃：体面地退出
标签用了一段时间，可能业务变了，或者有更好的替代方案。这时候就需要废弃。但废弃不是直接删除。你想想看，如果直接删了，历史报表怎么办？历史分析怎么办？
我建议的废弃流程：
- 标记为「待废弃」：给标签一个缓冲期，比如 30 天。期间标签仍然可用，但会提示「即将废弃」。
- 通知所有使用者：发邮件、发群消息，告诉业务方这个标签要废弃了，请尽快迁移。
- 观察使用情况：如果缓冲期内还有人在用，可以主动沟通，了解原因。
- 正式废弃：缓冲期结束，将标签状态改为「已废弃」。数据不再更新，但历史数据保留。
5. 标签归档：给标签一个安息之地
归档是生命周期的最后一站。标签废弃后，数据不再更新，但元数据还在。归档的目的，是让这些「死标签」不再干扰日常使用，但又能被追溯。
归档后的标签，默认不出现在搜索和推荐结果中。但如果你知道它的名字，还是可以查到。这就像图书馆里的「闭架书库」——书还在，但需要专门申请才能调阅。
归档的保留期限，我建议至少 1 年。1 年后，如果确认没有任何引用，可以彻底删除。但说实话，我一般不建议彻底删除。硬盘不贵，但数据丢失的代价可能很高。