指标字典写完没人管，三个月就成了第二套口径

去年三月我们花两周建了一份指标字典，四十七个指标，每个写清了定义、口径、数据源、负责人。建完那天我很满意，觉得口径这件事算是解决了。

七月做季度复盘，发现同一个「在库天数」在三张报表里是三个算法。字典还在，没人改过，也没人按它做。

字典腐化的三个信号

第一个信号是「新人不知道字典在哪」。新人上手用的是老人给的表，那张表比字典还老。

第二个信号是「有人在群里问这个数怎么算」。这个问题只要被问出来，说明字典里那条要么写得不清楚，要么已经和实际用法脱节。问一次是偶发，一个月问三次就是腐化。

第三个信号是「新报表绕开字典建指标」。建新表的时候没人去查字典里有没有同名指标，直接按自己的理解写了一个 SQL。三个月后你会发现字典里有「毛利率」，业务表里也有「毛利率」，两个差三个百分点。

维护责任人要是使用者，不是写作者

字典维护的闭环，与三个腐化信号出现的位置

我们第一版字典的负责人是建它的那位数据同事。他不负责业务决策，也就感受不到口径不一致带来的痛。他维护字典的动力来自我的催促，我不催就不动。

改成使用者负责之后情况变了。现在每个指标挂的是最常用它的那个业务岗位，数据侧只做技术复核。使用者自己承担口径错乱的后果，他会主动来提修改。

配套改的一条是：字典里每条指标必须写最后复核日期。超过复核周期没更新的条目，在报表里显示为「口径未复核」，逼着使用者来处理。

复核周期按变化频率定

统一按季度复核是最省事的做法，也是最没用的做法。平台原生指标一年可能都不动，自定义业务指标一个月就能变两次。周期定长了自定义那批一直错，定短了没人有空复核全部。

改一条定义要留下三样东西

改定义必须同时写：改前的口径、改后的口径、切换日期。少了切换日期，历史数据就没法比。

我见过最糟的一次是有人在六月把「活跃 ASIN」的定义从「30 天有单」改成「90 天有单」，没有留切换日期。八月看趋势图，活跃数掉了三成，全团队以为业务出问题，查了两天才发现是定义变了。

留了切换日期还有一个用处：老报表可以继续用老口径跑一段时间，两条线并行一个周期再切换。直接切，历史对比就断。

字典里该删的条目比该加的多

四十七条建到七月变成六十三条，加了十六条，其中十一条只有一个人用过一次。这种「一次性指标」留在字典里是负担，后来者不知道它的可信度，会当成常用指标引用。

现在每季度清一次：过去两个季度内被引用少于三次的指标，从正式字典移到备用区。移到备用区的条目仍然保留，只是不参与默认展示。清过两轮之后，正式字典稳定在三十八条左右，这个数量用的人真的会去翻。