2. 标签体系设计原则：维度建模、多级分类、可扩展性设计
做标签体系的人，最怕什么？最怕刚到新公司，发现之前同事留了一堆“民间标签”——有的叫高消费，有的叫消费能力A，还有的叫大客户。三个标签描述的是同一件事，但口径全不一样。你说这数据还能用吗？
所以我要跟你聊清楚，一套能落地的标签体系到底该怎么搭。核心就三个原则：维度建模、多级分类、可扩展性设计。
一句话总结：标签体系不是贴上去的，是长出来的。它必须能撑住业务增长的快，也要经得起数据治理的挑。
2.1 维度建模：把标签拆成可衡量的颗粒
我记得第一次给人做标签规划时，业务方直接说：“你帮我打几个标签就行，比如‘有钱’、‘活跃’、‘喜欢买鞋’。”我一听就意识到——这种直觉式定义，十个项目得有九个翻车。
维度建模说白了，就是把业务语义翻译成可计算的维度+度量结构。举个例子：
- 业务语义：“有钱的客户” → 需要拆成“过去12个月累计消费金额”这个度量；
- 维度：时间维度（近12个月）、客户维度（每人一条）、金额维度（大于某个阈值）。
我在项目中遇到过最典型的教训是：业务方要求打“高价值用户”，但不给任何阈值。等我用RFM模型算完后，他们说“不对，我心目中的高价值是客单500以上，并且月购2次以上”。你看，维度不明确，标签就变成了橡皮泥——谁都能捏，但谁都不认。
那么维度建模具体怎么落地？我建议用这张对照表来梳理：
| 标签示例 | 隐含维度 | 建议度量 / 阈值 |
|---|---|---|
| 高净值客户 | 资产、时间 | 近90天日均资产 ≥ 50万 |
| 流失预警 | 登录行为、交易行为 | 连续30天无登录 & 无订单 |
| 品类偏好 | 品类、时间、频次 | 近180天某品类购买次数占比 > 40% |
| 新客 | 注册时间、首单时间 | 注册且首单在7天内 |
小技巧：我习惯用“实体+时间+行为+阈值”四段式来定义标签名。例如：用户_近30天_购买_次数≥3。这样写出来的标签，后期ETL映射几乎零歧义。
维度建模还有个坑：维度爆炸。你想想看，如果把时间维度拆成“近1天、近3天、近7天……”每段都配一个标签，最后光时间维组合就会超过50个。怎么办？用参数化标签，把时间窗口和阈值做成变量，同一套计算逻辑，换参数即可。
2.2 多级分类：让标签自己形成树
公司大了，标签会从几十个迅速膨胀到上千个。我有一个前同事的公司，最后标签到了3000个，业务方根本不知道有什么标签可用，只能一遍遍来问数据团队。这就是没有多级分类的问题。
我建议分类至少分三层：
- 主题域（第一级）：比如“用户基础”、“消费行为”、“营销响应”、“风险等级”。
- 类别（第二级）：在主题域下细分，比如“消费行为”下再拆“消费频次”、“消费金额”、“品类偏好”。
- 具体标签（第三级）：就是最终可落地的标签，比如“高消费频次_周均≥2次”。
实际操作时，我建议一开始就建个标签目录表，每次新建标签先看能不能挂到现有分类下。如果挂不了，再考虑是否要新开主题域。这样做能避免把“标签管理”变成“标签混乱”。
避坑：我曾经因为觉得“才50个标签没必要分级”，三个月后标签冲到200个，想重新分类，得一个个通知下游业务方改映射表，那叫一个痛苦。所以不管现在多少标签，先搭框架，哪怕只有两层。
多级分类还有一个隐形好处：权限管控方便。比如风控团队只能查看“风险等级”主题域，而运营团队只能看“消费行为”和“营销响应”。按分类切权限，比按标签一个个配置要省事得多。
2.3 可扩展性设计：给未来留接口
这是最容易被忽略的一环。我见过太多团队在最初只设计2个标签属性：标签名、逻辑描述。等后面要加标签有效期、加绑定维度、加置信度时，发现数据库表要重建，代码要重写。
可扩展性设计，说白了就是在标签元数据层面，预留未来可能会用到的字段。我给你列几个我踩坑后保留下来的“必留字段”：
| 字段名 | 类型 | 说明 | 为什么重要 |
|---|---|---|---|
tag_id |
字符串 | 唯一键，建议用UUID或编码 | 方便后续迁移，不怕ID冲突 |
version |
整数 | 标签逻辑版本号 | 业务规则变更时，旧标签还能回溯 |
valid_from / valid_to |
datetime | 有效期起止 | 支持标签的下线与替换 |
dimension_json |
text | JSON存储维度组合 | 后续扩展维度时无需改表 |
置信度_pct |
decimal | 标签打标准确率或置信度 | 用于A/B实验和标签质量监控 |
再举一个我遇到的真实案例：业务方要求在现有“高价值”标签上，增加一个“近30天是否有客服投诉”的排除条件。如果我们当初没有预留dimension_json，那就得改ETL、改存储过程、改下游视图。而有了可扩展字段，我直接在配置表里加一条维度规则就行，一行代码都不用改。
核心方法论：先定义元数据模型，再写计算逻辑。元数据模型决定了你的标签体系能走多远。
说到这里，你应该能感受到，这三条原则其实是环环相扣的：维度建模决定了标签的精确性；多级分类决定了标签的可管理性；可扩展性决定了标签体系的生命周期。缺一个，后面就有数不完的黑夜。
下面这张图把三条原则的关系串起来了，你可以在课后对照着梳理自己的标签体系：
画外音：这个图你可以在标签平台做决策时直接截图用。三个原则就像三根柱子，缺一根体系就歪。
好了，标签体系设计原则就聊到这里。你回到自己的业务场景，可以试着做三件事：
1. 拿出一张纸，把现有标签按“维度”、“分类”、“扩展字段”过一遍；
2. 找到至少3个维度定义不清的标签，重新写它的度量逻辑；
3. 检查标签元数据表，看看缺了哪些我提到的预留字段（valid_from、dimension_json等），能补先补上。
下一站，我们将进入标签的元数据管理——这部分我有很多踩坑实录，到时候再跟你细聊。