博客 AI 时代,为什么指标平台还需要明细查询?

AI 时代,为什么指标平台还需要明细查询?

   数栈君   发表于 8 小时前  11  0

作者:大舟

在企业的数据分析里,我们经常会遇到一个很熟悉的场景。

早会上,业务负责人打开销售看板,发现上周某个区域的销售额下降了 15%。图表很清楚,趋势也很明显:销售额下滑、转化率下降、部分商品动销异常。

但此时,真正的对齐才刚刚开始。老板或者业务负责人接下来会追问:

  • “这个数是哪些订单算出来的?”
  • “是不是某几个门店拖了后腿?”
  • “有没有异常客户或者异常商品?”
  • “这个下降,是整体都在降,还是某一类明细数据出了问题?”

看上去,这些问题都是在追原因。但在数据团队的视角里,这意味着新的取数工作又要开始了:截图发群、SQL 查数、导出 Excel、按区域、门店、商品分组。一套弄完,突然发现口径还和看板上的不一致,又要再回头确认指标定义、时间范围和过滤条件。

https://assets.dtstack.com/2021bbs/files_user1/article/64cb61a78df42f894bd2b2131e1e1c3c..png

一个指标表达出来的“异常”,往往会演变成数据团队里的多轮协作。而另一边,业务负责人只能焦急地等待。

这个现象的本质不是企业没有指标,也不是看板没有呈现异常,而是业务无法拿到真正核验指标的路径。


痛点解析:业务看指标从来都不只是看汇总

传统的 BI 数据看板和可视化报表,擅长把结果表达出来,主要解决的是企业经营状态的聚焦展示。

比如运营团队关注的是,销售额是多少、环比下降多少、周转率是多少、履约时长有没有变长。这些指标可以帮助企业快速看到当前的经营状态,也能让管理层第一时间发现问题。

但在真实的数据业务场景里,看到问题只是第一步,后续分析还有三个新的断点。

第一,结论和证据断开。

看板告诉我们销售额下降了,但没有告诉我们这个下降由哪些订单、哪些客户、哪些商品构成。业务只能看到结论,却缺少继续核对的证据。

第二,业务和数据断开。

业务人员想继续追问,数据团队就要临时补链路。一次排查,就会变成多轮取数、导表、筛选和确认口径。指标已经展示出来了,但业务的数据消费根本没有真正闭环。

第三,人工分析和 AI 分析断开。

如果未来借助 AI 帮助分析指标异常,AI 也不能单纯从一个汇总结果就开始解释。没有指标口径、查询条件和相关明细数据作为上下文,AI 很容易停留在“看图说话”,而不是基于数据链路做判断。

https://assets.dtstack.com/2021bbs/files_user1/article/b631e82e468dc0b0b4a9b4f5c4afbf7f..png

只看汇总指标,容易留下结论和证据、业务和数据、人工分析和 AI 分析之间的断点。


能力补位:明细查询补上的是指标消费的证据链

这也是为什么,在指标平台里,明细查询并不是一个可有可无的功能。它补上的,是指标结果背后的核验路径。

指标查询更像是在回答:

“这个业务结果是多少?”

而明细查询回答的是:

“这个结果是由哪些数据构成的?”

在数栈智能指标中,明细查询是让用户可以围绕一个已授权数据模型,继续完成一条结构化的核验链路:

https://assets.dtstack.com/2021bbs/files_user1/article/e51102fc4c318b34469aa12d0c9d4c1b..png

  • 先选择模型,确认本次查询的数据来源。
  • 再选择字段,确认需要查看哪些明细。
  • 继续配置筛选条件和排序规则,把查询范围收窄到当前问题。
  • 执行查询后,先预览明细结果。
  • 必要时查看 SQL、下载结果,或保存为取数模板,方便下次复用。
  • https://assets.dtstack.com/2021bbs/files_user1/article/0533671c7b5963b7694e7cfa3e5a5dfd..png


这样一来,从汇总指标到明细记录,中间就有了一条连续的使用路径——从指标追到模型,从模型追到明细。

而且,明细查询对不同角色的价值并不相同。

对业务负责人来说,它解决的是“继续追问”的问题。

当一个指标出现异常时,业务不需要只停留在一张看板上,也不必每次都等数据团队重新取数。通过明细查询,用户可以继续查看指标背后的相关明细,按区域、门店、商品、客户等维度进行筛选,收集异常的特征,看看是否集中在某类具体的对象上。

对数据团队和产品负责人来说,它解决的是“重复协作”的问题。

很多企业并不是没有指标体系,正好相反,由于复杂,指标不同口径建了 N 多个,并且指标消费链路还不够闭环。指标定义好不容易完成后,在使用过程还要面临产生大量临时取数和口径解释。但如果常见的、需要高频的明细核验路径可以沉淀在平台里,数据团队就不必每次都从头开始响应核数问题。

尤其是当查询结果支持查看 SQL、下载结果、保存为取数模板时,一次核验就不只是临时的动作,也可以是后续可复用的查询配置。


未来展望:从“可见”到“可信”,再到“可智能分析”

目前,明细查询主要还在解决人工核数和明细追溯的问题。但如果再往 AI 分析场景靠,它的价值会进一步放大。

当业务问“为什么这个指标下降了”,更理想的情况不是让 AI 只基于一个汇总数字直接生成解释,而是让 AI 能够在指标口径、查询条件和明细数据的基础上继续分析。

也就是说,要做可信的指标分析,不能只理解指标口径和图表结果,还需要接触到指标背后的证据链。

好的指标平台,不只是把指标算出来、展示出来。更重要的是,当业务看到一个结果后,还能继续往下确认、核对、解释和复用。

明细查询看似是一个小功能,但它解决的是企业指标消费里的一个关键断点:

业务看到了结论,还需要继续核验的路径,乃至基于明细继续定位到问题。

而目前,数栈智能指标中的明细查询,正是围绕这个问题补足能力。它能让业务人员从指标结果继续追到明细数据,也能让数据团队把常见排查路径沉淀到平台中。

这一步,是指标平台从“可见”走向“可信”,并进一步走向“可被智能分析”的必经之路。

0条评论
社区公告
  • 大数据领域最专业的产品&技术交流社区,专注于探讨与分享大数据领域有趣又火热的信息,专业又专注的数据人园地

最新活动更多
微信扫码获取数字化转型资料