(文章始发个人公众号：川术；欢迎关注)
你有没有遇到过这样的情况：不同的数据报告或产品中，相同的指标名称，却对应着不同的数字和不同的计算口径？相信大部分人会点头。我所在的环境中，这个问题已然成为顽疾，我们正在努力！解决该问题的关键点之一，便是：指标命名。
在简单的业务场景中，抓住以下几点，指标的命名一般不成问题：
- 指标名称“名副其实”和“简洁易懂”
- 遵照一定的行业惯例或者规范（如财务指标、电商经营指标）
当业务规模大，相似的职能线多，相似的部门多了后，数据对齐的难度陡增（这一定程度上也会是组织架构的不合理的体现，但本文不对此展开讨论）。如何让指标命名规范，变成为了一个大问题。我们分两步来解决这个问题。
一、解析一个指标的天然构造
如上图，每个数据指标，其实都可以分解为“业务主题+限制条件+计算维度+指标名称”的结构。
业务主题，可理解为指标应用的业务范围。这里可以是具体某个业务部门，比如市场部；某个项目，比如客户留存提升；某种职能，比如质控、KPI、数据研发等；甚至是某个分析师名字，比如404。业务主题，理应能帮助指标阅读者迅速理解这个指标的来源。
限制条件，即是指标计算时需要处理的某些必要条件（不做处理指标会脱离业务意义）。对于分析师来说，更直观的理解是SQL里面的WHERE条件。比如，app活跃用户计算时只计算登陆时间在1分钟以上的用户数；网站注册转化率计算时剔除爬虫访问；电商客单价计算时剔除大促订单；外卖单量计算时限制即时单等。
计算维度，即指标做某种维度切分后进行的汇总。比如城市、时段、区域等。这点是可选项。限制条件实质上也是某种维度，但我建议分开理解。限制条件是每个指标计算时必须要考虑的，而维度并不是。
最后是指标名称，要求名副其实且简洁易懂。
二、由构造形成命名
认识到指标名称的构造，命名也就不难了。将各个结构进行罗列并用某种字符连接后，就是一个清晰的指标名称。我个人就比较习惯用“-”，如“数据研发-去爬虫-上海-独立访客数”。
另外，每部分结构中，有时会同时出现多个条件，若是交集，建议用“-”符号连接，若是并集，用“&”符号连接。
但是问题来了，每个指标名称，都要覆盖4个结构，名称就会很长，应用起来不方便。所以，我的建议是，除了业务主题外，其他结构都是可以设置默认值，进而在名称中隐去，使得指标名称形成“主题-名称”的简写形式。当然，默认值的说明一定要清晰。
当某些场景下（数据产品开发、可视化呈现等），业务主题加名称的形式已然过长，可只保留名称，而将业务主题变成注释形式另外展示。
总结一下，指标名称，本质上有全称和简称两种形式，普遍应用简称，而使用者心里需明白全称。
补充一点：“限制条件”、“计算维度”的默认值，应当取最普遍的情况，让数据使用者的理解成本降到最低。比如，活跃访客数的计算，大家普遍认知是剔除了爬虫访问，那么限制条件隐去的默认值便设置为此。当然，一定的宣导不能忽略。
给一个我们现实业务的样例：
全称，质控-全国-直营-平台单-即时单&预订单-组织运力&众包运力-全标品-全维度-有效完成率；
简称，质控-有效完成率。
本文所提出的命名方式，正在试验阶段，大规模应用能否实现，还需要验证。希望这样的思路能给你带来一些启发，也许就能设计出一套更合理的方案。