如何搭建数据仪表盘:数据源、关键指标、图表与权限
要搭建仪表盘,首先要从它必须回答的问题和读者出发,精确定义一小组指标,连接这些指标所依赖的数据,并为每个指标选择简单的图表。然后决定谁可以看到哪些数字。AI 应用构建工具可以在几分钟内生成一个精美的仪表盘;真正困难的部分,也是决定人们是否信任它的部分,是把数据和定义做对。
从问题出发,而不是从图表出发
一个试图展示所有内容的仪表盘,通常只会被打开一次。在考虑图表之前,先回答以下问题:
- 它是给谁用的? 创始人、销售团队、运营、投资者,还是你的客户?
- 它支持哪些决策? “我们是否需要再招一名客服?”是仪表盘能回答的问题。“给我看看我们的数据”则不是。
- 他们多久看一次? 日常运营仪表盘需要新鲜的数据和提醒;月度董事会视图则不需要。
写下三到五个问题。每个问题对应一到两个指标。
精确定义每个指标
大多数关于仪表盘的争论,实际上都是关于定义的争论。为每个数字写一段简短的定义:
| 指标 | 模糊的说法 | 精确的定义 |
|---|---|---|
| 收入 | “我们赚到的钱” | 按发票日期统计的已付款发票总额之和,不含税,以美元计 |
| 活跃用户 | “正在使用的人” | 过去 30 天内至少登录过一次的不重复用户数 |
| 流失率 | “离开的人” | 月初的付费客户中,在当月取消订阅的人数,除以月初的客户总数 |
| 响应时间 | “支持团队有多快” | 从工单创建到人工首次回复的中位数小时数,仅计工作日 |
把这些定义粘贴到你的提示词中。否则 AI 会选择一种听起来合理、但可能与你的业务计算方式不一致的计算方法。
数据从哪里来
| 数据源 | 仪表盘如何读取 | 注意事项 |
|---|---|---|
| 你应用自身的数据库 | 直接查询 | 繁重的查询可能拖慢主应用;必要时添加汇总表 |
| 电子表格 | 以 CSV 导入,或通过 API 读取 | 手动编辑会破坏格式;合计行和合并单元格 |
| SaaS 工具(Stripe、HubSpot、Shopify、Google Analytics) | 使用你的 API 密钥调用其 API | 速率限制、分页,以及每个工具对指标的定义各不相同 |
| 数据仓库(BigQuery、Snowflake、Postgres) | 通过服务器端连接执行 SQL | 凭据和查询成本 |
以下两条原则适用于所有情况:
- 密钥只放在服务器端。 API 密钥和数据库密码应保存在应用的环境变量中,绝不能出现在浏览器代码里。
- 确定数据的新鲜度。 每次打开页面都从多个 API 拉取数据,速度慢,还可能触发速率限制。对大多数业务仪表盘来说,每小时或每晚同步到你自己的数据库,并在页面上显示“最后更新”时间,更简单也更可靠。
如果你对 API 还不熟悉,什么是 API 和 什么是数据库 会解释基础知识。
选择合适的图表
- 带变化的单一数字(“$42k,较上月增长 8%”):指标卡片。它是大多数仪表盘上最有用的元素。
- 随时间变化的趋势:折线图。柱状图只适用于周期数较少的情况。
- 比较不同类别:按数值排序的水平柱状图。
- 部分与整体:堆叠柱状图。饼图只适合两到三个扇区的情况。
- 细节与异常:带排序、搜索和筛选的表格。通常比任何图表都更有用。
保持颜色一致:“当前周期”用一种颜色,“对比”用一种低调的颜色,只有需要关注的内容才使用红色。
谁能看到什么
在搭建之前就要确定访问权限:
- 内部使用,所有人看到所有内容:最简单。如果包含业务数据,仍然需要登录。
- 基于角色:销售看销售数据,财务看利润率,经理只看自己团队的数据。
- 面向客户:每个客户只能看到自己的数据。每条查询都必须在服务器端按客户账户进行过滤。用两个不同的客户账户登录来测试。
把收入或客户数据放在没有登录保护的公开网址上,就等于留下了一个等待被发现的数据泄露隐患。
一个有效的初始提示词
为一家 10 人的 B2B 软件公司搭建一个销售仪表盘。受众:创始人和销售负责人,每周一查看。概览页面:指标卡片,显示本月新增 MRR、总 MRR、本月新客户数、本月流失客户数和商机金额,每项都附上与上月的变化;一张展示过去 12 个月 MRR 的折线图;一张按来源统计新商机的柱状图。商机页面:可搜索、可排序的表格(公司、负责人、金额、阶段、成交日期),并可按负责人和阶段筛选。指标定义:MRR 为活跃月度订阅金额之和,年付套餐除以 12;流失率统计本月订阅结束的客户。目前使用数据库中的真实感示例数据,之后再连接 Stripe。显示“最后更新”时间。需要登录。清晰的侧边栏布局。
这个提示词写明了受众、每个指标的定义、图表以及数据方案,并且一开始就使用示例数据,这样你可以在连接真实数据源之前先就设计达成一致。
构建步骤
- 使用示例数据搭建布局。 在数据是假的、修改成本低的时候,就指标和图表达成一致。
- 连接一个真实数据源。 逐一手动将每个数字与源系统核对。如果 MRR 与 Stripe 显示的不一致,先弄清楚原因再继续。
- 逐个添加其他数据源,每添加一个都要核对。
- 定时刷新或在加载时查询,并附上“最后更新”标签。
- 筛选器:先做日期范围,再做人们经常要求的一两个其他筛选条件。
- 登录与角色。
- 空状态和错误状态:当某个数据源不可用或筛选结果为空时,页面显示什么。
- 与受众分享,然后删除一个月后仍无人查看的内容。
让它更快
仪表盘一旦变慢,就会被更少的人查看。对计算成本高的总计进行预计算(使用每日汇总表,而不是扫描每一笔订单),对大型表格进行分页,并优先加载核心指标卡片,让页面在图表加载完成之前就已经有用。如果某个数字计算耗时很长,就显示它最后一次计算的时间,而不是每次访问都重新计算。
常见错误
- 图表太多。 如果所有内容都被高亮,那就什么都没有被突出。
- 指标未定义。 两个人看同一个仪表盘,应该得出相同的结论。
- 从不与源数据核对。 一个错误的数字就会让人们开始怀疑整个仪表盘。
- 每次页面加载都查询每个 API。 速度慢、不稳定,有时还很昂贵。
- 缺少日期背景。 始终显示统计周期和对比周期。
- 前端暴露密钥。 浏览器中可见的 API 密钥,任何打开页面的人都可以复制。
什么时候 BI 工具是更好的选择
如果你的数据已经存放在数据库或数据仓库中,而主要用户是希望探索数据、切片分析并自行制作图表的分析师,那么 BI 工具(Looker Studio、Power BI、Metabase 等)比自建方案更适合他们。许多 SaaS 工具也内置了不错的报表,在重新开发之前先检查一下它们。当仪表盘面向客户或非分析师,需要 BI 工具无法表达的逻辑或权限,需要以你的业务特有方式组合数据源,或者它属于你已经运营的产品的一部分时,自建仪表盘才更有优势。
如果你的工作更多是修改记录而不是查看数字,那么你需要的是管理后台或内部工具,参见如何搭建内部工具。如果你的数字目前保存在电子表格中,如何把电子表格变成应用是很好的下一步阅读材料。
使用 Mythex 搭建
在 Mythex 中,你描述仪表盘,代理会在实时预览中构建页面和图表,起初使用真实感的示例数据,当数字需要持久保存时再迁移到专用的 Postgres 数据库。文档中的仪表盘用例提供了起始提示词。如果你的数据存放在 Google Sheets 之类的工具中,可以通过 Connectors 连接该账户,并让代理读取数据并据此构建仪表盘。
应用本身没有内置的数据仓库连接器。对于 BigQuery、Snowflake、Stripe 等服务,应用需要调用它们的 API,并使用你保存为项目机密的密钥。查看仪表盘的人员的登录和角色,是你所搭建应用的一部分。若想从提示词开始,可以浏览仪表盘模板,例如指标仪表盘。
常见问题
如何搭建仪表盘?
先确定仪表盘面向谁、必须回答哪些问题,挑选少量指标并给出精确定义,连接数据源,然后为每个指标选择图表。一旦你明确了这些,AI 应用构建工具就可以根据描述生成页面和图表。
仪表盘应该有多少个关键指标?
数量要少到人们能一眼看完,主视图通常五到七个即可。详细数据放在单独的页面上,当某个核心数字看起来不对时,人们再去打开。
应该自建仪表盘还是使用 BI 工具?
当你的数据已经存放在受支持的数据库或数据仓库中,并且由分析师自行探索时,使用 Looker Studio、Power BI 或 Metabase 等 BI 工具。当仪表盘面向客户或非分析师、需要你自己的业务逻辑或权限,或者需要嵌入你已有的应用中时,才自建。
仪表盘可以显示实时数据吗?
可以,只要它在页面加载时或按刷新间隔从数据库或 API 读取数据。对于许多业务仪表盘来说,每小时或每天刷新一次的数据就已经足够,而且更简单、运行成本更低。