即便在ChatGPT出现的今天，指标管理模型的思想依然受用，它是指标建设的基础。文章约12000字，比较长，如果你遇到指标口径管理混乱，怎么都对不齐，数据不一致，指标繁多不清晰，这篇文章或许对你有帮助。
在数据这行工作的都知道，简单难做的两件事：“埋点”+“指标”。简单是因为不论是从技术方案、个人使用、产品使用每个单项来看都不是很复杂的。例如埋点，一个点击事件、曝光事件，非常好理解；指标的话，DAU，销售额，公司每个人都会关注使用，没有理解成本。
但是我经历过的公司中，这两块都普遍存在着很多的问题。一方面是“简单”造成的，生产者的角度来讲，浸在里面拔不出来，个人成长性不足。另一方面从度来看，有一种花费大量人力物力只是产出了这么一点点内容还做不好的感觉。
我们先来看看指标从生产到使用参与的角色：
以大公司的标准来看，每个角色都有足够的人力，全角色参与，那么一个指标从设计到生产到应用的过程（从无到有）大致是这样的：
定义指标->数据采集->数据加工分析->开发指标->应用指标
其中又涉及的角色包括：【指标设计者】【数据产品】【业务研发】【数据研发】【数据分析师】5个角色
我们做两个假设：
1）如果不考虑指标需求满足的时长、并且长期有足够的资源（人力资源、机器资源），指标的开发与使用或许也不会有什么太大的问题。我是用户，我想看DAU，我去找研发帮我算个数，等1，2天没什么问题。我是研发，需求也比较多，要DAU的人也很多，把珍藏许久的祖传SQL跑一遍，工作量还好。
2）如果看指标的只有一个人，生产指标的也只有一个人，1对1定向服务。
以上这两个假设如果成立，在指标建设和应用这里，不会出现什么问题。
但是现实情况不是这样的。事实是：
可以说，不论指标的使用方，还是开发方，都会感受到上面的问题，用户觉得指标时常不准，同样名称的指标和别人手上的数据不一样，紧急时刻需要查看指标的时候总是—显示。生产方同样面临生产压力与指标准确性的质疑等问题。
其实主要的原因，在于指标的设计、生产，绝大多数情况发生在局部范围，并非一个指标从生产到使用都走上面的全流程，且各自所在的部门有自己的生产体系。在一个公司内，指标的生产建设就像是一个联邦共和国，这样做的原因是为了确保指标需要的时效性，用户选择最近距离索取原则，第一时间拿到指标数据。
例如深圳分公司的负责人想要深圳地区近一个月的销售额，难不成还要去问北京总部的分析师吗？另外就是在数据平台、数据工具体系建设不是很完善的情况下，稍微大一点的部门或者业务，都会专门设有专职来为业务提供指标数据的开发，确保数据提供的及时性。再有，如果所有人的数据需求都统一到一个部门，部门的承接能力也会受到挑战，一个需求动辄等上一周，这个对于业务、用户来说是不可能接受的，所以长期下来，就近索取原则必然发生。
我们经常会在同一场合下对一个指标的数据报出来两个不同的值。最常见的场景：两个人在茶余饭后聊天，聊到了公司的某个指标，发现数据对不上，例如我们公司到底有多少销售？有多少门店？；经营大会上披露的数据和自己统计的数据不同，业绩比自己的低5%；自己在邮件中看到的dau和手机中《北极星小程序》的dau不一样，也和某个报表中的dau不一样。
综合来看，造成数据不一样的情况有很多种，主要归位以下5种情况：
综合来看，前三个情况，是人们在使用指标过程遇到的绝大多数情况。指标的供给者太多，导致一个独立的个人，在多处都可以收到各种指标体系。数据平台工具、定制化的数据产品需要简单的学习成本，导致用户在使用的过程中容易造成“自我失误”，可能一个老鸟在经过数月的时间里才会对数据的及时性、稳定性、波动了然于心。数据链路的稳定性、产品的易用性、需要一个复杂的体系和庞大的团队维持才可以持续精进，稍有差池都会对数据的使用者造成一定的影响，“自我失误”也就会经常出现了。
再有就是口径对不齐了，时常是不同的部门不同的业务在对一个指标展开舌战。有的时候大家都不知道为什么去核对指标口径，以至于在这里浪费了大量的时间。
很多时候，指标口径就不用对齐，因为不会产生对不齐的场景。为了对齐而对齐，减少很多不必要的解释使我们多数核对口径的出发点。
几乎所有的问题提出是没有成本的，你发现了数据有比较大的波动时，如果你明确这种问题可以去提问，并熟知提问方式，你一定会问问今天的数据是不是出错了。之所以倾向于凡事遇到问题都去”oncall”，一是用户没有全方位的手段来排查判断自己发现的问题，二是提问后可以直接等结果，相比自己来判断，省去了很多麻烦和成本。
oncall在系统服务过程中本就是天经地义的存在，在这里想表达的是，没有成本的提问会导致数据服务体系“敏感”。不论数据波动是真的业务导致，还是数据系统出错，对双方来说都会很敏感。
以我个人的历史经历来看，10次数据波动问题，10次数据团队会介入排查，业务本身导致波动的情况有8次。8次业务波动带来的问题实质上是反馈了业务对数据的信赖程度。可信赖的数据是数据团队工作的底线，守住这个底线需要花费大量的精力，咨询、服务、值班这些都是要做的。但是守住底线不是单向的，需要双向达成共识。
使用指标的用户的直接体感是“指标数据对不齐”，“及时性不足”，“数据常出错”，他们期望的是“准确可靠的数据”，“易于理解的数据”。同样，数据团队的直接体感是“做不完的指标”，“没完没了的对数”，“压力山大”；他们期望的是“高效的数据开发”，“数据口径明晰不混乱”，“自信”。双方在指标数据的使用与提供上都有各自的期待。
我们时常寄希望于某一个系统、流程、或者规则努力来实现上面的期望。通过多年的指标建设，我发现指标建设是个体系、生态。组织，流程、产品通力合作才可以提升各自的体感。这里至关重要的是“统一思想”。一般我们用到的产品都不会把核心运行逻辑暴露给用户，例如汽车、手机，很少有人知道cpu里面是如何运行的，发动机的核心原理是什么。但是指标的建设就需要设计与用户“同心”了。生产者知道怎么生产，使用者也需要知道怎么使用。并且也需要知道怎么生产的。
“寻求共识”就变的非常有必要了。
首先就需要共识的就是指标的管理模型与指标要素。
其实对于指标的管理与应用思想很早之前就已经出现了，例如olap联机分析、多维立方体、cube等名词绝大部分人也都耳熟能详。我相信绝大部分人都是一知半解。去网上获取这些名词的解释不难，能够理解它并加以应用又是另一个情况。
今天我想通过解决上述指标问题、建设一个指标生态（建设方、使用方、平台、流程、辐射的系统统称为指标生态）需要的核心指导思想来解释“指标管理模型”这个概念。它贯穿整个指标的建设、应用、与服务，是指标生态的底层基础。需要让指标生态的所有建设方与使用方都通透的理解这个概念。
讲指标这个概念必须要明确两个最重要的概念，【度量】和【维度】。
一个正确的指标必须包括度量和维度。
“性别”是维度，“男性数量”，“女性数量”，“男性占比”，“女性占比”是度量。
“城市”是维度，“一线城市占比”，“省会城市数量”，“GDP大于1万亿的城市数量”是包含了维度和度量的指标。
指标都是汇总计算出来的，有聚合过程。
例如单笔订单的金额不能是一个指标，统计一天的订单金额才是指标。
指标需要维度进行多方面的描述分析，维度可以根据需要可以无限扩展。
例如，月汽车销量，可以增加城市维度、品牌维度、是否贷款维度等等，就可以变成：城市月汽车销量，大众汽车城市月销量、有贷款的大众汽车城市月销量。
1）一维表格
不存在单维表格，单一的值不能是指标，例如：
因为上面的表格没有描述是谁的成交金额，单独的一个值，无法描述这个值代表的什么事务、动作，以及在什么时间周期范围内产生的这个聚合度量。如果真的出现了这样的表，那么一定只有你自己知道是什么意思。
2）二维表格，时间周期
任何指标统计都离不开时间周期，可以说所有的指标都会涉及时间。对在一个时间段内发生的业务进行统计。例如过去24小时，一个自然日、自然周，这一年，从月初到现在，往前推30天等等，都是时间周期。
如果在表格中描述指标，则一定且必须最少是一个二维表格（至少有两列），我们在表格中加入时间周期，就得到了这样的结果：
上面这个表可以明确的表达了指标的两个基本要素【度量+维度】，度量是成交金额、维度是时间。但是这里还缺少对于业务本身的描述，仅表达了在某个时间周期内发生的度量。如果表名称是特斯拉股票成交金额，就可以用这种方式来表达了，因为数据内容已经限定在这个业务范围【特斯拉股票】内了。
3）业务范围
如果确定了业务范围，例如业务范围=【短视频】，度量是播放次数，并且把播放VV这个度量的时间范围确定在天这个范围内。
那么该指标表的展示如下：
业务这一列用于描述这个度量的业务范围，一般称它为业务修饰词，但通常在表格中，我们不会这么存放，第二列造成了冗余，一般都简化掉这一列，收敛成两列的形式，把业务范围和度量合并：
业务范围和维度的区别：
业务范围也是维度，只不过我们在指标计算的过程中，会从最宏观的一面开始，习惯性的会定义一个范围，要统计哪个业务的数据？
你有4家水果店，别人要问你，你的日销售额是什么？那你可能会问，是哪家门店？或者是我所有的门店？（相当于我自己的生意范围）它本身就是一个维度（视角）来统计的。但我们把它抽离出来，是方便于我们对指标的管理与认知。公司大了，有很多分支业务的时候，你问DAU是多少，肯定会带上业务前缀的。
4）业务范围的收敛意义
业务范围的核心意义在于确定范围。
指标都是作用于某一个业务范围的，业务范围在公司内也有层级关系，例如视频业务会划分短视频、长视频；金融业务会划分贷款业务、存款业务、证券业务；
它们代表了一个业务的父子板块关系。可以看下图来理解视频业务的逐层缩减：
我们把指标体系限定在不同的业务域内，就是业务限定。业务限定很好的帮助我们对数据进行切割，把业务原子化，访问次数、播放量、订单金额这些原子指标都是在具体的业务限定内来完成的，先把数据进行业务划分，能够提高开发效率(因为要处理的数据变少了）
5）多维表格
业务对指标的使用会随着需求逐步加深分析维度。
如果二维表格是最小集，那么加入更多的维度和度量，这个表格就变成多维表格。
例如，修饰词=【短视频】，加入维度=【终端】和【是否会员】则多维表格是这样的：
也可以在此基础之上，增加度量，例如增加度量【播放时长】。
多维表格的表头样式就是这样的：【维度1】【维度2】【维度3】【维度n…】【度量1】【度量2】【度量3】【度量n…】。
6）每一行的维度+单一度量都是一个指标
这里有一个很重要的思想统一，上面的多维表中每一行都是一个指标，每一行形成了指标的基本要求【维度】+【度量】。
经常会有一种情况，用户在相互沟通指标时，没有按照每一行是一个独立指标来看待。
例如，会员在ios端的播放vv和会员在安卓端播放的vv是两个不同的指标，很多人会认为指标是播放vv，会员、终端都是描述指标的维度。这样理解没问题。因为视角不同。”指标是播放vv，会员、终端都是描述指标的维度“是典型的管理视角，我们下文会展开讲到。一行一个指标是应用视角，我们在描述指标的时候，就是确定在这一行的这个数字上，如果按照管理视角来看，那么指标就会有很多行。
如果多个人有多个理解方式，就一定会产生沟通成本。
7）条件限定
上面的多维表是正确表达指标的一种理想状态，每一行都是一个可以解释的指标。但实际使用情况不单单是用【维度】+【时间周期】+【度量】就可以完成指标的描述的。
用户会随着业务的需求，有很多临时分析需要，随时对指标进行条件的设定。
例如上面的表中，指标【短视频播放时长】，需要对用户做分类，就会有一定的条件限制：播放时长大于1小时的用户，非会员且播放时长大于1小时的用户。
这个例子中，我们把指标【短视频播放时长】以及维度【是否会员】做了条件限制，用于描述指标【短视频用户数】。
这种情况非常常见，例如大于18岁的用户，本科及以上学历，用户登录次数大于3等等。度量、维度值，都可以当做条件作用于其他指标。
以上情况统称为条件限定，条件限定扩大了指标的灵活性，可以基于实际的业务需要对指标进行数据剪裁。
条件限定和维度值的区别：
例如像IOS端，是一个维度值，单独来看IOS端的短视频用户数，IOS端可以表达维度，也可以用于条件限定，但是维度值是确定且单一的，它不能组合。
条件限定是灵活的，它可以用度量来限制、也可以组合各种维度值，例如渠道包括：1，系统直播 2，线下门店 3，淘宝 4、外部直播 5、分销商，每一个数值都代表一个维度值，他是确定的观察视角。条件限定可以是他们中任何数字的组合，比如 1和2，2和3，1或者2，2或者3，不是1和2 等等，它是灵活多变的。
用一张图来总结上面的内容：
原子指标是指数据分析中最小的可度量单元，通常是一个数值或一个计数。原子指标是数据分析的基础，它们可以用来描述某个特定的事件、行为或状态，如销售额、访问量、转化率等。原子指标通常是不可再分的，因为它们已经是最小的可度量单元了。按照上面的例子来说，原子指标可以理解为是度量，例如【销售金额】【播放VV】【播放时长】【访问次数】等等，这些度量是不可拆解的。
原子指标用于明确业务的统计口径及计算逻辑。具备以下特性：
派生指标在业务限定的范围内，由原子指标、时间周期、维度三大要素构成，用于统计目标指标在具体时间、维度、业务条件下的数值表现，反映企业某一业务活动的业务状况。
例如上面讲到的多维表中的每一行都是一个派生指标，也就是说，业务中用到的指标都是派生指标。
不同的派生指标可能具有相同的原子指标，这样派生指标就定义了一种等价关系，而属于相同的原子指标就构成了一个对指标体系的划分。在每一个划分中，存在一个可以派生出其他指标的最小派生指标，即最细粒度。
派生指标的另一个类型是复合指标，如果把它单独独立出来也可以，如果把它归类为原子指标也可以，取决于我们如何做数据的开发以及应用。先来看几个复合指标的例子：
上面三个例子都是在原子指标间进行计算的原子级复合指标。
也可以通过两个派生指标来计算复合指标，例如派生指标是：近七天北京地区IPAD的平均销售价格=近七天北京地区IPAD的销售额/近七天北京地区IPAD的销售量。
也就是说，可以通过结果来进行计算，平均销售价格并不会在数据加工中直接计算。
上面介绍了很多的概念，其实核心思想是统一对指标的认知和理解，每一个概念单独去理解可能无法有一个整体的感受。可以看下图，来完成对指标的整体理解：
我们把【原子指标】【时间周期】【业务范围】【维度】【条件限定】统称为指标要素，他们是指标的实体组织。
其中：
上图列举的三个指标：【长视频当日下单人数】，【最近7天游戏大于18岁的客单价】，【最近1天电影老会员退款金额】都是基于这些指标要素组合起来的。
基于指标要素，我们可以把它和SQL关联起来理解。便于我们了解数据的加工和实现过程,有益于我们从技术的视角理解指标要素。
1）先了解SQL的大结构
SQL的核心作用就是从数据表中提取数据。操作对象是表，所以可以理解为：【去哪张表里，以什么样的条件，取哪些数据，要以什么样的方法进行数据计算】。
SQL的基本操作逻辑：
select “选取哪些字段” 在这里提供字段的各种计算方式，例如SUM，MIX，MIN，IF, ELSE等，对这一列数据进行操作。
FROM “从哪张表取” 在这里提供单表、多表关联（JOIN,不同表提取多列合并成一张表)、多表合并UNION（不同表，但表结构相同，上下对齐成一张表）。
WHERE“以什么样的条件” 在这里和SELECT 一样提供字段的各种计算方式，来限制取值范围。
GROUP BY,ORDER BY 组合与排序。
2）【原子指标】对应select
原子指标是度量，它确定了统计目标和聚合方法，在SQL中，它作用于SELECT范围内。可以这么理解，SELECT范围内的内容就是【原子指标】。
例如：
selectcount(order_ID)—>计算订单数
selectsum(order_amount)->计算订单金额
3）【业务范围】对应from
数据来源于哪张表，一定是确定了业务范围，在数仓中，一般会对表进行分类，分类的规则会基于业务来进行，便于管理。
例如：
selectcount(order_ID) fromdwd.orderlist 在订单明细表中计算订单数
4）【条件限定】对应where
条件限定，一般体现在where条件语句中，表达以什么样的条件来看指标。
例如：
select
count(order_ID)
from dwd.orderlist
where order_amount>100
在订单明细表中计算订单金额大于100的订单数
【时间周期】也会当做限定条件出现在where条件中。
where order_amount>100 AND order_date=‘2023-05-20′
在订单明细表中计算2023年5月20日订单金额大于100的订单数
【维度值】也会当做条件出现在where条件中
whereorder_amount>100 AND order_date=‘2023-05-20’ AND CITY_NAME=“北京“
在订单明细表中计算2023年5月20日订单金额大于100且在北京发生的订单数。
5）【维度】对应group by
维度会参与select过程和group by过程。groupby 的目的是分组，分组就是为了以不同的视角去看数据。
count(order_ID),city_name
from dwd.orderlist
where order_amount>100 AND order_date=‘2023-05-20’ groupby city_name
在订单明细表中计算2023年5月20日订单金额大于100的订单数,按城市分组
6）综合来看：
知晓指标要素与SQL语句的对应关系，能够对指标的实现过程有更深层次的理解。这里最重要的意义在于用户对指标的定义能够映射到技术方案上。能够基于这层关系，对数据进行合理的建模、开发与使用。
上面把指标抽象成指标要素便于我们统一对指标的理解，其实更重要的目的是便于使用与管理。管理上的意义在于能够做到指标开发使用从无边界到有边界的过程，逐步收敛覆盖，另一层面能够做好统一的标准，最后由此做基础，向上放射到不同的系统、环境中去，形成整体的生态。
先看这张图：
根据派生指标的概念，通过【原子指标】+【维度】+【时间周期】+【条件限定】组成了一个派生指标，当每一个指标元素出现大于1的情况时，就会出现多个派生指标，计算方法是它们的乘积。
例如上面的情况，3个【原子指标】*4个【维度值】*3个【时间周期】*2个【条件限定】=72个派生指标。
指标在使用的过程中，不论是口头交谈还是系统展示，都会以上图右边的形式来体现，【视频业务日销售额】谁都可以读懂。没有哪个用户去把指标拆解成这些要素来沟通，除非出现数据问题。所以我们在报表、汇报、业务沟通的过程中，都是如【视频业务日销售额】的指标形式体现出来的。
这样对于管理有一个非常大的好处，可以基于指标要素的组合进行最大可能的使用覆盖。
根据业务的实际诉求，完成分析体系的建设：确定分析框架，确定分析类别，确定分析场景等等，例如用户行为分析、业绩分析、经营分析、安全性分析、竞对分析、财务分析..等多个场景。基于这些分析框架，可以逐步的抽象出指标要素，确定有多少个【原子指标】+【维度】，然后就可以大致的得出，我们能够覆盖”多少个“指标了。
这样做的好处在于，业务用到的绝大多数指标，都是可以覆盖在指标要素组成的这些结果之内的，指标管理者、开发者只需要关注指标要素的增减即可，不用根据具体的需求CASE BY CASE 的去完成任务，大大减少了管理和开发成本，从而实现了“收敛” 。
如果已经确定好指标要素【原子指标】+【维度】+【时间周期】+【条件限定】，这些指标就可以提前进行计算：
把指标要素组合的指标，提前进行预算，因为是结果集，即便是组合再多，也能控制在百万、千万级别，或者是分块、分组来存储，这样就有数据量级小的特性，我们可以把结果存入到响应速度更快的内存数据库中，完成“空间换时间”，解决大多数人无法等待超长时间的计算过程。
即便大数据技术发展到今天，如SPARK、clickhouse等大规模秒级响应的查询技术已经很成熟了，这种空间换时间的方式依然非常受用。从成本的角度来讲，非常划算。
如果使用指标要素的管理理念来生产、管理指标，在用户使用指标的时候，可以做到指标名称的统一性。
回顾来看，所有应用的指标都可以认为是派生指标，派生指标的指标元素中，有哪些可以参与命名，哪些不用参与命名：
指标的命名规范性，直接影响使用者对指标的理解，并能够影响到整个指标使用的效果，如果命名不规范，会导致大家认知出现偏差，经常会出现不同名称同一指标，甚至还有同一指标不同名称的情况，增加大家的沟通对齐成本。
指标命名的基本原则：简短易懂，便于传播，不易出现理解偏差。
【时间周期】必须参与命名，累计、昨日、月度、周；时间周期最直接的圈定了统计的范围，需要明确的展示在指标名称上，简单直接，避免不同人的理解歧义，减少错误发生的几率。
【原子指标】必须参与命名，指标的核心。
【业务范围】可参与命名，如果在系统、使用场景流程做的比较的情况下，可不用参与命名。
例如，进入到”视频业务“的专属分析系统中，系统对业务有明确的划分板块，例如进入”电影“板块，指标名称就无需带上【电影】这个业务范围了，比如昨日电影播放量就可以直接写成播放量即可。
【条件限定】不参与命名。条件限定有量个非常重要的特性，就是很容易变长，二是它出现在指标建立之后的灵活应用上，是临时性效果。
例如【昨日播放量】这个条件是：大于18岁，中国地区，IOS端，会员，近30天未登录的，如果参与命名的话就是：
【会员IOS端中国区大于18岁其近30天未登录的昨日播放量】这样读起来就非常别扭。而且组合条件还需要考虑语言的通顺性，例如这样组合
【大于18岁中国区IOS端近30天未登录会员昨日播放量】读起来就会拗口。
另外，很多条件限定都是临时性提出的，例如年龄大于18岁，但是有可能随时调整到16岁，如果按照人的年龄分布来讲，我们可以从1岁到100岁这100个数字都当做限定条件，这样指标就会无限增多膨胀，增大开发、管理、使用成本。
【维度】不参与指标命名，维度与条件限定相同，它具有无限扩展的情况，并且无法从语言上让指标变得易于理解。
例如【昨日播放量】支持维度：销售渠道、城市、端、业务类型，加入维度后的命名是【昨日播放量销售渠道城市端业务类型】这样指标就变的不可读。
实际情况是维度在分析过程中参与GROUP BY 过程，例如表格中的分组，报表中的下钻过程，实际上指标命名带上维度没有意义，可以在应用的过程中，告知用户支持什么维度。
运用指标要素的指标管理模型，本质上是抽象+收敛的过程，确定少量的指标要素，覆盖大多数的使用指标，减少开发、运维、管理和认知成本。一致性问题同样可以在这个模型中被解决。
业务基于这个模型思路，去构建自己的指标模型，并用系统加以管理，当做整个生态的底层基础。
建立在这个模型之上，可以对接更上层的应用系统，例如报表工具，业务分析系统，用户管理系统，经营分析系统等设计到指标应用的场景中，从而让整个业务、数据分析系统生态中都利用起这个模型的思想。
NLPto指标：
指标数据最理想的使用场景就是，想要就有，数据准确，可视化展示。用户期望能够随时查看自己想要的业务指标数据，绝大多数人都有自己的使用指标的渠道和方法，我们现在一般都会提供几种方式例如：
以上的指标使用场景，需要用户熟悉系统的操作、数据内容可能会根据需求提前预设好，如果是问指标的话，就依赖被询问者的时间了。虽然每个人都各显其通能够拿到数据，但于用户体验来说，还是需要有操作和时间成本。
智能化的指标应用可以大幅提高数据指标的用户体验和效率。我们希望的场景是，用户对着手机：“告诉我昨天的DAU、用户客单价和销售额”，系统就能快速的反馈给用户这三个指标的结果，并且是准确的。
指标的加工处理到使用中间有很多过程，从数据采集->数仓加工->口径定义->报表->系统->用户，中间流程最直接的方式就是自然语言直接对接到数据。
在ChatGPT出现之前，我们的做法是基于指标要素生产出指标的模型（提前预算好所有的可能），通过NLP技术，将自然语言转译成SQL，直接读取指标模型，大概的技术思路如下：
这里不展开讲解技术细节，总之我们希望通过技术的加持，打造用户在灵活搜索指标的时候能够快速反馈给用户正确的指标的体验。
用户的需求是灵活多变的，如果想完成上面对着手机说话就能反馈指标结果的场景，我们核心要做的事情就聚焦在两点：
ChatGPT的出现，让这个事情变得更容易。
ChatGPT生成式AI非常符合上面的理解自然语言，并准确的把它转换成可执行的SQL这个能力的需要，现在我们可以把指标管理模型的定义、指标要素等元数据信息送给ChatGPT当做prompt进行指标搜索与生成。
这里做的比较的一家国外产品：thoughtspot，建立在用户搜索、找数据的场景中，去建立智能化分析搜索引擎。感兴趣的可以去看看。
上面讲方案是理想的，真正能不能应用起来，是另一回事，现实是，一个小小的指标，可能经历多个团队，多年，多次治理，都达不到好的效果。我认为，核心原因有几点：
上面4点是相互关联的。主要是组织的设定与运转，业务部门在数据、指标的建设上是门外汉，他们最希望的是想要的时候有，不希望要个数据特别困难，还有部门墙的存在，所以最适应于这种诉求的组织方式就是自给自足，逐步的指标就变成了开头说的那种情况。
数据、指标是一个需要认准一个解决方案（流程、标准、组织）就需要长期持续做下去的事情。如果出现中断或者反复，沉淀的经验不能继承，则很难达到指标准确、及时好用的状态。
学习成本以及运营同样是一个非常重要的因素。再简单的指标，也需要读懂口径、也需要明确指标在哪里看到的最准，数据出现了问题要找谁，用户处于这个系统的时候，脑子里是没有明确的说明书的，需要他逐步的探索，探索的过程因司而异。不同的公司有不同的组织协同和方法以及平台系统来支持。所以一个完善的指标（数据）服务团队是非常有必要的，这个团队与平台、产品、数据团队合力完成整体服务体系的建设。
但现实是上面4点难以有公司能够做到。我认为核心的问题在于，这套体系在公司的决策层没有概念，或者是ROI很低。
上面第一点说到，需要强权部门或者人来统领建设，一般公司决定权的人很少有数据建设科班出身的人，这个ROI评估，是需要对上面的内容非常懂的情况下才能评估。公司老板想看到数据非常容易，他们的体感会特别好，有专人服务，很多有“北极星”的数据产品，能够达到快速、准确的数据使用标准。
基层人员就不同了，需要看到的数据颗粒度更细，分析整合的细节更多，并且服务的团队更公共化。所以，在公司内产生了两极现象，决策者使用数据舒服，但是他们总能听到数据不好用的投诉或者声音，感觉非常诧异。
基层使用者就没那么幸运，上述种种让数据服务、指标体系建设变得很难。直白点说，服务老板的资源和服务基层一线人员的资源完全不对等。所以，从体感上来讲，决策层是没有”怎么连个DAU“都算不清楚的感受的。
方案容易，理解思想简单，但是能不能真正落地，真的是看公司是否有决心能够下决心去做这个事情。还有一点最不能忽视的是，我们是否真正有足够的时间和耐心等待这个体系的成长带来的收获。
作者：勍爷小箴，微信公众账号：数据产品设计 datadesign
本文由 @勍爷小箴 原创发布于人人都是产品经理。未经许可，禁止转载。
该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。
关注微信
