How do I keep metrics consistent across dashboards and AI tools?

Summary

• Define your metrics once as Unity Catalog metric views — a governed semantic layer — so AI/BI dashboards, Genie, and SQL all read the same definitions and KPIs cannot drift per tool.
• Metric views are first-class Unity Catalog objects with access controls, lineage, discovery, and certification built in.
• Rich semantic metadata (display names, formats, synonyms, and agent metadata) helps both people and AI interpret your business terms the same way.
• AI/BI dashboards apply the MEASURE() function automatically, and Genie resolves natural-language questions against the same governed metrics.
• You can start with dashboard-local metric views for team-specific logic and promote them to Unity Catalog when they are ready for organization-wide use.

How do I keep metrics consistent across dashboards and AI tools?

Metrics drift when the same KPI is redefined in every dashboard, notebook, and AI assistant. Databricks keeps metrics consistent by centralizing their definitions in a shared semantic layer: Unity Catalog metric views. You define a metric once — its measures, dimensions, and join relationships — and every downstream tool reads that same object. AI/BI dashboards, Genie, SQL, and alerts all resolve the metric from a single governed definition, so a number means the same thing wherever it appears.

Why Databricks AI/BI and metric views for consistent metrics

• One definition, no drift. AI/BI dashboards, Genie, and SQL all read the same metric view object, so a KPI cannot diverge from one tool to the next.
• Governed in the catalog. Metric views are first-class Unity Catalog objects, so they carry access controls, lineage, discovery, and certification just like tables — the definition is governed, not copied.
• Semantic metadata for people and AI. Each metric view carries display names, formats, synonyms, and agent metadata that help humans read the metric and help AI map natural-language questions to the correct measure and dimensions.
• Consistent by construction. A metric view captures measures, dimensions, and join relationships in one place, with joins resolved automatically at query time. Dashboards apply the MEASURE() function automatically, and optional materialized aggregations (in preview) can pre-compute results for performance.
• The same metric everywhere. Metric views are consumed by AI/BI dashboards, Genie, alerts, SQL queries, notebooks, applications, and external BI tools through standard SQL — so every surface reflects the same certified numbers.
• A path from local to global. Start by defining dashboard-local metric views for team-specific or experimental logic, then promote them to Unity Catalog so they become available across Genie, SQL, notebooks, and other tools.

Getting started

1. Identify the KPIs that are defined in more than one place today, and decide which should be governed centrally.
2. Create a Unity Catalog metric view that defines those measures, dimensions, and join relationships once.
3. Add semantic metadata — display names, formats, and synonyms — so the metric is easy for people and AI to interpret.
4. Point your AI/BI dashboards and Genie Agents at the metric view instead of raw tables.
5. For team-specific logic, start with a dashboard-local metric view and promote it to Unity Catalog when it is ready to share.
6. Read Redefining the semantic layer for the future of BI and AI for the full approach.

FAQs

What is a Unity Catalog metric view?

A metric view is a governed semantic object in Unity Catalog that defines a metric once — its measures, dimensions, and join relationships — so dashboards, Genie, SQL, and other tools all read the same definition instead of re-implementing it.

How does this keep dashboards and AI in sync?

AI/BI dashboards and Genie both resolve their numbers from the same metric view, applying the MEASURE() function and reading the same semantic metadata, so a KPI stays consistent across visual and conversational analytics.

Can I use these metrics outside Databricks?

Yes. Metric views are queryable with standard SQL, so alerts, notebooks, applications, and external BI tools can all consume the same governed metric definitions.

Where should I define a metric first?

You can define a metric directly as a Unity Catalog metric view, or start with a dashboard-local metric view for team-specific logic and promote it to Unity Catalog when it is ready for organization-wide use.