关于 kpi-dashboard-design
面向设计 KPI 仪表板的团队,涵盖指标选择、信息层级、展示实践,以及常见的数据和告警问题。
主要功能
- 01战略、战术和运营 KPI 框架
- 02SMART 指标选择
- 03仪表板层级与布局指导
- 04指标背景信息和下钻建议
- 05指标与告警问题排查
适用场景
- 01规划高管 KPI 仪表板
- 02选择部门级指标
- 03改进趋势不清晰的仪表板
- 04排查不一致或频繁触发的指标告警
安装
复制下面的命令,在终端中运行。
$
npx skills add https:/ / github.com/ wshobson/ agents --skill kpi-dashboard-design安装后在 Claude Code 中输入/kpi-dashboard-design确认已加载。
附带文件references/details.md
详细介绍
KPI 仪表盘设计
用于设计有效关键绩效指标 (KPI) 仪表盘、推动业务决策的全面模式。
何时使用此技能
- 设计高管仪表盘
- 选择有意义的 KPI
- 构建实时监控展示
- 创建部门专属指标视图
- 改进现有仪表盘布局
- 建立指标治理
核心概念
1. KPI 框架
| 层级 | 关注点 | 更新频率 | 受众 |
|---|---|---|---|
| 战略 | 长期目标 | 每月/每季度 | 高管 |
| 战术 | 部门目标 | 每周/每月 | 管理者 |
| 运营 | 日常工作 | 实时/每日 | 团队 |
2. SMART KPI
Specific: Clear definition
Measurable: Quantifiable
Achievable: Realistic targets
Relevant: Aligned to goals
Time-bound: Defined period
3. 仪表盘层级
├── Executive Summary (1 page)
│ ├── 4-6 headline KPIs
│ ├── Trend indicators
│ └── Key alerts
├── Department Views
│ ├── Sales Dashboard
│ ├── Marketing Dashboard
│ ├── Operations Dashboard
│ └── Finance Dashboard
└── Detailed Drilldowns
├── Individual metrics
└── Root cause analysis
详细示例与模式
详细章节(从 ## Common KPIs by Department 开始)位于 references/details.md。当上方的导航摘要不够充分时,请阅读该文件。
最佳实践
应该做的
- 限制为 5-7 个 KPI - 专注于重要事项
- 展示上下文 - 对比、趋势、目标
- 使用一致的颜色 - 红色=差,绿色=好
- 支持下钻 - 从汇总到明细
- 适当更新 - 匹配指标频率
不应该做的
- 不要展示虚荣指标 - 专注于可操作的数据
- 不要过度拥挤 - 留白有助于理解
- 不要使用 3D 图表 - 它们会扭曲感知
- 不要隐藏方法论 - 记录计算方法
- 不要忽视移动端 - 确保响应式设计
故障排除
仪表盘上显示的 MRR 与财务的数字矛盾
最常见的原因是对年度套餐的处理不一致。财务可能按日折算,而仪表盘则归一化为按月计算。统一采用单一公式,并直接记录在仪表盘卡片上:
-- Explicit formula shown in tooltip / data dictionary
-- Annual plans: divide total contract value by 12
-- Quarterly plans: divide by 3
-- Monthly plans: use as-is
CASE subscription_interval
WHEN 'monthly' THEN amount
WHEN 'quarterly' THEN amount / 3.0
WHEN 'yearly' THEN amount / 12.0
END AS normalized_mrr
仪表盘显示绿色,但产品团队报告用户抱怨
仪表盘很可能跟踪的是系统正常运行时间(一个滞后指标),而没有跟踪面向用户的质量指标。在基础设施指标之外,增加客户感知指标:
| 基础设施(绿色) | 用户感知(添加这些) |
|---|---|
| API 正常运行时间 99.9% | P95 页面加载时间 |
| 错误率 0.1% | 任务完成率 |
| 队列深度正常 | 支持工单量 |
留存同期群看起来持平——同期群之间没有差异
检查同期群查询是否正确按注册月份分区。一个常见缺陷是使用 created_at::date 而不是 DATE_TRUNC('month', created_at),这会按天分组并产生过小、无法显示趋势的同期群:
-- Wrong: too granular, cohorts are too small
DATE_TRUNC('day', created_at) AS cohort_date
-- Correct: monthly cohorts
DATE_TRUNC('month', created_at) AS cohort_month
实时仪表盘对数据库造成沉重压力
一个每 10 秒刷新一次、使用复杂同期群 SQL 的实时仪表盘会降低生产查询性能。通过定时任务将预聚合指标写入汇总表,将 OLAP 工作负载与 OLTP 分离,并让仪表盘从该表读取:
# Scheduled every 5 minutes via cron/Celery
def refresh_mrr_summary():
conn.execute("""
INSERT INTO kpi_snapshot (metric, value, snapshot_at)
SELECT 'mrr', SUM(...), NOW()
FROM subscriptions WHERE status = 'active'
ON CONFLICT (metric) DO UPDATE SET value = EXCLUDED.value
""")
告警阈值不断触发,团队对其置之不理
一次性设置且从不复查的静态阈值会导致告警疲劳。使用基于滚动平均值的动态阈值,使告警仅在指标显著偏离自身基线时触发:
# Alert if current value is > 2 standard deviations from 30-day rolling mean
def is_anomalous(current: float, history: list[float]) -> bool:
mean = statistics.mean(history)
stdev = statistics.stdev(history)
return abs(current - mean) > 2 * stdev
相关技能
data-storytelling- 将仪表盘的发现转化为推动高管决策的叙述
评论
支持 Markdown