[ Guides ]
7 min read
How AI analytics works with dbt metrics
At 9:07 on a Monday morning, a sales leader asks an AI analyst a simple question: How much enterprise revenue did we close last quarter?
The answer arrives before the coffee does. There is a chart, a percentage change, and a neat paragraph explaining that enterprise revenue grew 14%. It looks polished enough to paste into the weekly leadership update.
Then Finance replies with a different number.
Nothing is obviously broken. The SQL ran. The warehouse returned rows. The chart is mathematically correct. The problem is that the AI used booked contract value, while Finance reports recognized revenue after credits and currency adjustments. Both calculations are defensible. Only one is the company metric.
This is the central problem with AI analytics: generating a query is easy. Knowing which version of the business to query is hard.
AI can write SQL. It cannot invent agreement.
Natural-language analytics removes a real bottleneck. People no longer need to know table names, SQL syntax, or which date function works in the warehouse. They can ask a question in the language they already use at work.
But natural language is full of compressed assumptions. Revenue, active user, qualified lead, retained customer, and conversion are not columns waiting to be selected. They are agreements. Each one contains decisions about filters, time windows, joins, exclusions, and grain.
An AI model presented with raw tables has to reconstruct those agreements from clues. It can inspect column names, documentation, and past queries. It can make a plausible guess. Plausibility is useful for exploration. It is dangerous when the answer is presented as a governed fact.
dbt metrics change the problem. Instead of asking the model to rediscover the company every time, they give it a governed definition it can reuse.
What a dbt metric gives the AI system
A dbt metric is more than a formula. In a semantic model, the metric sits alongside the entities, dimensions, measures, and time grains that describe how it can be queried. That context constrains the space of valid answers.
For an AI analytics system, this creates four important advantages:
A canonical calculation: the system does not invent a new revenue formula for each prompt.
Valid dimensions and joins: it knows how the metric can be broken down without changing its grain.
Consistent time logic: week, month, quarter, and fiscal periods resolve through approved definitions.
Explainable context: the answer can identify the metric, filters, and models it used.
The result is not that the AI becomes incapable of making mistakes. The result is that a large class of avoidable mistakes—wrong table, wrong join, wrong aggregation, wrong date—becomes much less likely.
From a question to a governed answer
Consider a product manager asking: Why did activation drop for enterprise accounts last week? A raw-table agent might search for columns containing activation, enterprise, and account, then assemble a query. A governed system follows a different path.
Interpret the business terms. The system maps activation to the approved activation metric and enterprise account to a governed account segment.
Resolve the metric graph. It identifies the semantic model, entities, dimensions, measures, and valid joins needed for the question.
Apply the user’s context. Permissions, default filters, timezone, and the requested comparison period are added before execution.
Generate and run the query. SQL becomes an implementation detail produced from governed definitions rather than raw-table guesswork.
Validate the result. Freshness, missing data, unusual distributions, and important caveats are checked before the answer is presented.
Explain the answer. The response shows the metric definition, filters, period, sources, and follow-up paths.
That workflow feels slightly less magical than asking an unconstrained model to search the entire warehouse. It is also far more useful. Production analytics should optimize for repeatable trust, not demo-day surprise.
The metric layer does not remove exploration
Governance is often described as the opposite of curiosity: approved dashboards on one side, free exploration on the other. That is a false choice.
A governed metric can be the starting point for exploration. The user can compare segments, change time ranges, investigate drivers, and ask follow-up questions. What stays stable is the meaning of the metric itself.
Think of it like a map. A map does not decide where you must go. It gives you a shared coordinate system so that north does not change halfway through the journey.
This distinction matters for AI because conversational interfaces encourage iteration. One question becomes five. The user asks why revenue changed, then which segment moved, then whether the shift came from volume, price, churn, or currency. If every follow-up silently changes definitions, the conversation becomes an increasingly confident work of fiction.
Where AI analytics still breaks
A metrics layer solves definition drift. It does not solve every reliability problem. The cleanest semantic model in the world can still produce a bad answer if the data underneath it is stale, incomplete, or unexpectedly changed.
The source is late
The metric is correct, but yesterday’s billing data has not arrived. The system should say the result is incomplete rather than confidently comparing partial revenue with a complete prior period.
The schema changed
A source field was renamed or a model changed grain. The metric may still compile while producing a different result. Contracts, tests, lineage, and change-impact checks are still required.
The entity is wrong
Customer, account, workspace, and subscription are not interchangeable. An AI system needs explicit entities and relationships or it can answer the right question at the wrong grain.
The user lacks context
A correct number without its definition can still be misunderstood. The response needs enough context for the reader to know what was counted, what was excluded, and whether the answer fits the decision.
What a trustworthy AI answer should show
Most AI interfaces optimize for a clean final answer. Analytics interfaces should expose a little productive friction. The user should be able to inspect the reasoning without reading generated SQL line by line.
The metric name and plain-language definition
The dimensions, filters, and comparison period
The source semantic models or governed datasets
The latest trustworthy data timestamp
Warnings about missing data, unusual changes, or assumptions
A link to lineage, ownership, or the underlying analysis
These details are not decorative transparency. They teach the user how the business defines the metric. Over time, the interface becomes a way to distribute institutional knowledge, not merely query results.
How to implement AI analytics with dbt metrics
Teams often begin by connecting a model to the warehouse and hoping better prompts will produce better answers. A more durable rollout starts with the questions the business asks repeatedly.
Choose a small set of decision-critical metrics. Revenue, activation, pipeline, retention, and churn are common starting points.
Define the metrics and semantic models in dbt. Make entities, dimensions, measures, time grains, and ownership explicit.
Test the assumptions that can change the meaning. Validate uniqueness, accepted values, relationships, and model contracts.
Connect the AI layer to governed metric APIs or metadata instead of exposing raw warehouse tables as the default context.
Return explanations with every answer. Include definitions, filters, freshness, and lineage.
Review real questions. Use failed or ambiguous prompts to improve metric definitions and semantic documentation.
The final step is easy to underestimate. Real user questions reveal gaps no architecture diagram will show. Someone will ask for expansion revenue when only total revenue exists. Someone will use customer to mean account. Someone will ask for last quarter while thinking in the company’s fiscal calendar.
Those are not prompt failures. They are opportunities to make the organization’s definitions clearer.
What this changes for the data team
AI analytics does not eliminate analytics engineering. It changes where the leverage sits.
Instead of writing every query, data teams design the trusted paths through which many questions can be answered. They invest in semantic models, metric definitions, documentation, contracts, lineage, and evaluation. They monitor which questions recur and which answers produce confusion.
The work becomes less about translating each request and more about building a system that translates the business consistently.
That is a meaningful shift. It moves the data team from queue manager to product steward.
Frequently asked questions
Can an AI analyst use dbt metrics directly?
Yes. The implementation varies, but the AI layer can use metric definitions, semantic metadata, or a semantic-layer query interface to resolve business questions into governed metrics and dimensions.
Do dbt metrics guarantee correct AI answers?
No. They reduce ambiguity in business logic, but correctness still depends on source quality, freshness, permissions, entity relationships, tests, and how faithfully the AI system uses the governed context.
Why not let the model learn from existing dashboards?
Dashboards are useful context, but they often contain duplicated or local calculations. Learning from them can reproduce the inconsistency the semantic layer is meant to remove. Certified dashboards can help, but governed definitions should remain the source of truth.
Is a semantic layer necessary for natural-language analytics?
It is possible to generate answers without one, especially for exploratory work. As usage grows, a semantic layer becomes increasingly important for consistent metrics, valid joins, permissions, and explanations.
The real product is not the chatbot
The visible product may be a conversational interface. The durable product is the agreement underneath it: which metrics matter, what they mean, how they can be sliced, who can see them, and how the organization knows when they are unsafe.
dbt metrics give AI analytics a foundation that raw-table prompting cannot. They turn natural language from a shortcut around governance into an interface for governance.
That is the difference between an AI system that can produce a chart and one that can participate in a real business decision.