3. 冲突分类与分级：先分轻重，再定策略
指标口径冲突，不是所有问题都值得你拍桌子。我见过不少团队，一发现口径对不上就全员拉会，结果吵了半天，发现只是个无伤大雅的维度别名问题。说白了，你得先给冲突「定个性」，才知道该花多少力气去解决。
这一章，我们就来聊聊怎么给冲突分类和分级。我个人习惯把这件事分成两个维度：按严重程度分级，决定响应速度；按类型分类，决定解决路径。两条线一交叉，处理策略就清晰了。
核心原则：致命级冲突必须当天解决，提示级冲突可以攒到周会统一过。别拿大炮打蚊子，也别把小火苗拖成火灾。
3.1 按严重程度分级：四档定乾坤
分级这件事，我踩过不少坑。早期做数据治理时，我把所有冲突都当成大事，结果团队疲于奔命，反而漏掉了真正要命的。后来我总结了一套四档分级法，用了五六年，基本没出过岔子。
| 级别 | 判定标准 | 响应时效 | 处理方式 |
|---|---|---|---|
| 致命 | 数据差异 > 5%，或直接影响财报、监管报送、核心KPI | 2小时内 | 立即拉群，暂停相关数据发布，定位根因 |
| 严重 | 数据差异 1%-5%，或影响部门级业务决策 | 1个工作日内 | 指定负责人，24小时内出修复方案 |
| 一般 | 数据差异 < 1%，或口径描述不一致但数值接近 | 3个工作日内 | 纳入迭代排期，随版本修复 |
| 提示 | 命名差异、别名不同、文档描述不统一，数值无差异 | 周会统一过 | 记录到口径知识库，定期清理 |
注意：致命级冲突不要试图自己扛。我曾经有一次发现营收数据差了6%，想着先查清楚再上报，结果拖了半天，被老板直接点名。正确的做法是：发现致命冲突，先拉群同步风险，再并行排查。信息透明比完美答案更重要。
3.2 按类型分类：四种冲突，四种解法
分级告诉你「多紧急」，分类告诉你「怎么修」。我习惯把冲突分成四类，每一类的根因和解决套路都不一样。
3.2.1 计算逻辑冲突
这是最常见、也最头疼的一类。说白了，就是两个指标名字一样，但背后的计算公式不一样。
典型场景：
- 一个用「SUM」，一个用「COUNT」
- 一个算「平均值」，一个算「中位数」
- 一个先过滤后聚合，一个先聚合后过滤
怎么治？
我个人习惯的做法是：把两个口径的SQL或伪代码贴到一起，逐行对比。别信文档，文档经常是过时的。我在项目中遇到过，文档写的是「去重用户数」，实际代码跑的是「全量用户数」，差了整整一倍。
小技巧：对比计算逻辑时，重点关注三个地方——聚合函数、过滤条件、计算顺序。这三个点出问题的概率占80%以上。
3.2.2 数据范围冲突
这个好理解。同一个指标，你取的是全量数据，我取的是部分数据，那结果肯定对不上。
典型场景：
- 包含/排除测试数据、内部测试账号
- 数据源不同：一个从数仓取，一个从业务库直接拉
- 数据版本不同：一个用T-1全量，一个用实时增量
怎么治？
嗯，这里要注意。数据范围冲突的根因往往是「默认规则」没对齐。你觉得应该排除测试数据，我觉得应该包含，两边都没错，但结果就是不一样。解决方法是：把数据范围的边界条件写进口径定义里，白纸黑字。
3.2.3 时间周期冲突
时间周期冲突，说白了就是「时间窗口」没对齐。你想想看，一个指标用自然月，一个用财务月，能一样才怪。
典型场景：
- 自然月 vs 财务月（比如财务月从26号开始）
- T+1 vs 实时 vs 小时级
- 滚动12个月 vs 自然年
怎么治？
我建议在指标元数据里，把时间周期单独拎出来作为一个字段。这样每次对比指标时，第一眼就能看到时间周期是否一致。我曾经因为没注意这个，被业务方追着问了一个下午——两个报表的「本月销售额」差了30%，最后发现一个算的是1号到30号，一个算的是1号到31号。
3.2.4 维度定义冲突
这类冲突最隐蔽。数值对得上，但维度对不上，导致汇总结果天差地别。
典型场景：
- 「一线城市」的定义不同：北上广深 vs 北上广深+新一线
- 「新客」的定义不同：首单用户 vs 注册30天内首单用户
- 维度层级不同：三级类目 vs 二级类目
怎么治？
维度定义冲突，说白了就是「同一个词，不同理解」。解决方法是建立统一的维度字典，把每个维度的成员、层级、映射关系都写清楚。别嫌麻烦，这个投入值得。
3.3 分类分级的交叉矩阵
把分级和分类放在一起看，处理策略就更清晰了。我整理了一个矩阵，平时排查冲突时直接对着看。
| 类型 \ 级别 | 致命 | 严重 | 一般 | 提示 |
|---|---|---|---|---|
| 计算逻辑 | 立即停用，拉通评审 | 指定责任人，出修复方案 | 纳入迭代排期 | 记录知识库 |
| 数据范围 | 暂停数据发布，核对数据源 | 明确包含/排除规则 | 补充数据范围说明 | 更新文档 |
| 时间周期 | 立即对齐时间窗口 | 统一时间口径定义 | 标注时间周期差异 | 补充时间说明 |
| 维度定义 | 暂停使用该维度 | 统一维度字典 | 补充维度映射关系 | 记录别名差异 |
实战建议：我建议每个团队都维护一张类似的矩阵表，贴在指标管理平台的首页。每次发现冲突，先对照矩阵定级定类，再分配处理资源。这样能避免「所有冲突都紧急」的混乱局面。
3.4 避坑指南：我踩过的几个坑
做指标治理这些年，我在分类分级上栽过不少跟头。挑几个典型的说说，你们遇到了可以绕开走。
- 坑一：只看数值差异，不看类型。我曾经遇到一个冲突，数值只差了0.3%，按分级算「一般」。但仔细一查，是计算逻辑冲突——一个用了加权平均，一个用了简单平均。虽然数值差异小，但逻辑错了，后续所有衍生指标都会错。所以，分级要看数值，但分类不能只看数值。
- 坑二：把「提示级」冲突不当回事。提示级冲突虽然不影响数值，但积累多了，口径知识库就变成了一团乱麻。我建议每两周花半小时，集中清理一次提示级冲突，保持知识库的整洁。
- 坑三：分级标准太死板。5%的阈值不是金科玉律。如果某个指标虽然差异只有2%，但它是老板每天看的核心指标，那也得按「致命」处理。分级标准要结合业务场景灵活调整。
我的习惯：每次处理完一个冲突，我都会在口径知识库里加一条备注，记录「当初为什么这么分级分类」。时间久了，这些备注就成了团队最宝贵的经验库。