BigQuery measures is now GA, unifying BI metrics and knowledge graphs for AI accuracy

Google Cloud announced that BigQuery measures, a feature built on BigQuery Graph that defines BI metric definitions directly on knowledge-graph entities, is now generally available. Google Cloud says the unified model lets dashboards and AI agents retrieve both a governed metric and the relational context behind it from a single schema without data movement, addressing agent hallucination caused by metrics and relationships living in separate BI and graph stacks. Woolworths NZ Head of Data Enablement Amanda Reelick said defining measures natively in BigQuery "ensures Looker Dashboards, Conversational Agents and our Data team queries operate on identical logic.

To answer a complex business question, an AI agent must understand two things: what happened, and why. The what is a governed metric, like revenue at risk; the why is the network of relationships that produced it. Because metric definitions, a.k.a. measures, traditionally live in business intelligence BI platforms while relationships live in knowledge graphs, an AI agent only ever sees half the picture. It guesses the rest, leading to confident but sometimes wrong answers. To solve this hallucination problem, we introduced measures in BigQuery https://cloud.google.com/blog/products/data-analytics/bigquery-graphs-with-measures-for-trusted-agentic-workloads , which are now generally available. Historically, organizations needing both BI and knowledge graphs had to run two siloed technology stacks: one to calculate reliable metrics, the other to map out entity relationships. Bridging them entailed brittle data pipelines and runtime reconciliation by analysts and AI agents, who held the connections in their heads or in sprawling prompts. This patchwork approach wasn't just slow and expensive — it’s where data governance broke down, as every analyst and prompt may define joins and metrics differently. To replace manual reconciliation, you need a single model that understands both the structure of your business and the math that measures it. BigQuery measures builds directly on BigQuery Graph https://cloud.google.com/blog/products/data-analytics/bigquery-graph-connecting-data-and-ai-at-scale to deliver that unified foundation. By defining measures directly on the graph entities they describe, your BI dashboards and AI agents don't just get a number they can trust — they get the relational context behind it. Finally, they can reliably answer both the what and the why. "With BigQuery measures, we can now deliver self-documenting data products. Defining measures natively in BigQuery ensures Looker Dashboards, Conversational Agents and our Data team queries operate on identical logic, guaranteeing metric alignment across leadership and significantly reducing data team maintenance overhead." - Amanda Reelick, Head of Data Enablement, Woolworths NZ Let's walk through an example. Suppose your retail bank's risk analytics team spots a sudden spike in transaction activity in the Prague district. You need to know whether this represents healthy customer growth or concentrated risk exposure. Answering requires two pieces of evidence: how much money actually moved the what , and which specific accounts it flowed through the why . At most banks, getting that answer takes two teams, two tools, and two numbers that are rarely reconciled. With BigQuery, your underlying data is already in place — whether in native tables or in a borderless Lakehouse https://docs.cloud.google.com/lakehouse/docs/introduction . With a single schema, you can define a semantic model directly over your existing transaction, account, and district tables — with no data movement and no secondary system: To determine whether the Prague spike reflects broad growth or concentrated exposure, your team checks whether the transaction volume is spread across many accounts or driven by just a few. Using GRAPH EXPAND , you flatten the graph and roll up both measures with the AGG function: You can ensure accurate reporting by using measures that have been “grain-locked” — where a fixed level of granularity has been assigned to how facts and dimensions are modeled. Because a single account can have thousands of transactions, joining the two tables can duplicate account rows. A standard SQL COUNT account id would overcount those accounts, leaving your risk and finance teams with conflicting numbers. BigQuery measures preserve the native grain of each entity, counting every account only once regardless of how the tables are joined. The second half of the investigation is about connectivity: Which accounts are driving the Prague activity? You can answer that with a traversal in GQL the ISO-standard Graph Query Language over the exact same model: Neither query requires a separate system, and both evaluate against the same governed definitions. While the preview introduced grain-locked measures tightly integrated with BigQuery Graph, real-world production analytics demand more than basic sums — and enterprise AI agents need programmatic ways to discover and interpret those metrics. The GA of BigQuery measures focuses on two key areas: richer modeling and visualization for complex business logic, and native semantic discovery for the agentic ecosystem. To enable more expressive and flexible measure definitions, MEASURE supports both composite expressions and derived measures; this capability is GA. Rather than repeating conditional logic across queries, you can define baseline aggregates once and compose them into higher-order calculations on the same table using AGG . BigQuery validates these formula dependencies at schema compilation time to catch circular references or invalid aggregations early. Downstream dashboards and AI agents can then query complex ratios and net metrics at any dimensionality with consistent accuracy. For example, on your Trans node, you can define settled volume alongside total volume, and then derive unsettled volume and unsettled percentage directly from those building blocks: Query across multiple fact tables Enterprise data models routinely span multiple business processes. Joining separate fact tables that share a common dimension — such as transactions and credit cards linked to the same bank account — traditionally causes a "chasm trap," where cross-fact multiplication inflates both metrics. The new start node argument in GRAPH EXPAND solves this by isolating each fact table into its own expansion tree. BigQuery evaluates each measure at its native grain before joining the results on the shared entity: By expanding each fact table from its own root Trans and Card , each branch maintains its exact grain — even for accounts with transactions but no issued cards. Visualize in Data Studio With the updated BigQuery connector in Data Studio https://cloud.google.com/data-studio , you can now connect directly to BigQuery graphs and build interactive visualizations powered by native measures. Data Studio honors the aggregation logic defined in your graph model, keeping complex calculations consistent across charts while preventing accidental client-side re-aggregations. Attach business meaning to your measures In a large enterprise schema, it’s nice to be able to attach business meaning to your measures, as multiple metrics often share similar names. In our banking model alone, total trans amount , settled volume , and unsettled volume could all casually be called "volume" by a business user. That ambiguity can trip up both analysts building reports and AI agents translating natural-language prompts into SQL. With the GA, you can embed rich semantic metadata directly into each measure definition using the OPTIONS clause, including plain-language description strings, domain synonyms, and custom key-value extensions: Because this business context lives inside the schema alongside the SQL formula, your semantic definitions travel wherever the metric is queried. BigQuery directly integrates with Knowledge Catalog to create a unified discovery and consumption loop for both people and machines: Enterprise-wide context discovery in Knowledge Catalog: BigQuery Graph and measures metadata is automatically ingested and searchable in Knowledge Catalog as a native resource alongside tables, views, and routines. Data stewards, analysts, and AI agents can search across the catalog using business synonyms or descriptions, inspect governance tags, and view the underlying measure’s SQL definitions such as SUM CASE WHEN is settled = TRUE... to verify how each metric is calculated before using it. In Knowledge Catalog, you can also enrich graph metadata with business glossaries and stewardship context, uniting asset discovery, business meaning, and mathematical measures in a single pane so users and agents can work from the same context. Runtime schema introspection in BigQuery: Calling BQ.SHOW GRAPH EXPAND SCHEMA returns an expanded graph's schema as JSON without scanning underlying tables, flagging metrics with "is measure": true alongside their descriptions and synonyms. Passing flatten results = FALSE preserves your entity hierarchy as nested ROW STRUCT types, letting agents inspect the relational tree and query paths like Account.District.city directly. Connect across your data and AI ecosystem Finally, BigQuery measures integrates across the Google Cloud data and AI stack so you can author, reuse, and query semantics in the tools you already use: Author with AI: Use the graph skills in Data Agent Kit https://docs.cloud.google.com/data-agent-kit to scaffold, author, and validate BigQuery measure definitions using natural-language prompts in your preferred AI coding environment. Reuse existing LookML models: If you already model business metrics in Looker, you can model once using LookML-based derived analytic models https://docs.cloud.google.com/looker/docs/reference/param-view-derived-analytic-model lookml-based-derived-analytic-models to compile Explores, joins, and measures directly into native BigQuery Graph models. Query with natural language: Unified graph and measure definitions are supported out-of-the-box in Conversational Analytics https://docs.cloud.google.com/bigquery/docs/conversational-analytics , enabling business users and AI agents to ask complex questions against governed metrics in plain natural language. The primary advantage of this unified model is that you can build from the foundation you already have. If you already run a BI semantic layer, take a governed metric and define it directly on the entity it describes; if your foundation is a knowledge graph, attach a unified measure to your most frequent traversal. Whichever side you start from, you are building a single source of truth for both your BI dashboards and your AI agents. To see unified semantics in action, watch the BigQuery measures introduction video https://www.youtube.com/watch?v=CEtOL6yDmMc , or dive into the BigQuery measures documentation https://docs.cloud.google.com/bigquery/docs/graph-measures and BigQuery Graph overview https://docs.cloud.google.com/bigquery/docs/graph-overview . When you are ready to build hands-on, try our step-by-step codelabs for music streaming analytics https://codelabs.developers.google.com/codelabs/bq-graph-measures/instructions 0 .