
Author: Johan Peen, COO · Last updated: September 2026
Connecting an LLM like Claude directly to your ad platforms or raw data warehouse produces fast answers, but unreliable numbers.
In our client work at s360, reliable AI-assisted reporting has one consistent prerequisite: a governed semantic layer between the model and the data, so the AI queries certified metric definitions instead of guessing at raw tables.
Almost every team we talk to travels the same road to that conclusion. It has four stages, and each one fails predictably. Knowing them in advance can save you months.
The journey usually starts with a shortcut: someone installs a community-built connector for Google Ads or Meta in Claude, asks a few questions, and gets impressive answers in seconds. Two weeks later, the reports that went up the chain turn out to be full of silent errors.
The errors are not random. They come from the model working on raw API data with no shared definitions. Ad platforms disagree by design. Meta’s default attribution window is 7-day click and 1-day view, while Google Ads defaults to data-driven attribution, so their “conversions” were never the same number to begin with. Add accounts running in different currencies that get summed without conversion, and micro-conversions counted alongside primary leads, and you get ROAS figures that match no platform dashboard anywhere.
There is also a governance problem hiding under the convenience. There is no native Google Ads connector in Claude’s directory. Google’s official Google Ads MCP server, open-sourced in October 2025, is a self-hosted, read-only developer tool. Most directory connectors are community-built wrappers that route your ad data through a third party’s infrastructure, with no metric definitions and no contract about where the data goes.
The predictable outcome: the numbers get challenged once, trust evaporates, and the experiment gets scrapped.
The usual second stage is a managed aggregator such as Supermetrics. This is a real improvement: these platforms normalize API schemas, convert currencies, and blend channels into clean, consistent reporting. For cross-channel spend and performance dashboards, they do exactly what they promise.
What they cannot do is speak your business language. The semantics are generic, and the vendor’s definitions of a conversion, a lead, or revenue, not yours. And marketing questions stop being platform questions quickly: the moment leadership asks about CAC against unit economics, pipeline contribution, or pacing against budget targets, you need ad data joined with CRM records and finance data. That data lives in your warehouse – for most mature teams, BigQuery or Snowflake.
This is the pivotal stage, because the idea sounds so reasonable: the data is already centralized, and Claude writes excellent SQL. But direct text-to-SQL over raw tables is where an experienced data team starts asking uncomfortable questions, and each one points at a real architectural gap.
The summary answer: Claude will happily write syntactically perfect SQL on top of raw tables, but access to data is not the same as understanding data logic.
A semantic layer is a governed translation layer that sits on top of the data warehouse and defines, in one version-controlled place, what your business metrics mean: how revenue is calculated, which conversions count, how tables join, and who may see what. Tools in this category include the dbt Semantic Layer (powered by MetricFlow), Cube, and Looker’s LookML.
For AI analytics, the semantic layer changes the model’s job completely. An LLM writing raw SQL is doing probabilistic generation: predicting plausible queries, inventing join paths and metric formulas as it goes. An LLM in front of a semantic layer only maps a natural-language question to certified metrics and dimensions; the layer then compiles the query deterministically, with correct joins, partition filters, and access policies applied before any SQL runs. Same question, same answer, every time. And when a question falls outside the modeled scope, the system can say so instead of hallucinating a number.
The connection between the two is increasingly standardized through the Model Context Protocol (MCP), the open standard that lets Claude and other LLMs discover and query governed tools rather than raw database catalogs.
The setups that actually work don’t let agents trawl raw tables. Getting there is a data project before it is an AI project:
| Approach | Answer reliability | Cost risk | Governance | Maintenance burden |
| Community connector on ad platforms | Low – no shared definitions | Low | Weak – third-party data flow | None (and it shows) |
| Managed aggregator | Good within its scope | Low | Vendor-defined semantics | Low |
| LLM direct on raw warehouse | Unpredictable | High – unbounded scans | Depends on auth model | High – breaks with schema drift |
| Semantic layer + MCP | High within modeled scope; refuses out-of-scope | Controlled | Central RLS/CLS before queries run | Real but owned and versioned |
Yes, but not through an official one-click connector. Google’s official Google Ads MCP server (open-sourced October 2025) is read-only and self-hosted, requiring your own developer token. The connectors in Claude’s directory are third-party or community-built, which means your data routes through their infrastructure. Either way, you get raw API access, not governed reporting.
Because the model is aggregating raw data without your definitions. Different attribution windows (Meta’s 7-day click/1-day view vs. Google’s data-driven attribution), unconverted currencies, and micro-conversions mixed into primary conversions each produce numbers no platform dashboard will confirm. The fix is normalized data and shared metric definitions, not a better prompt.
Only with the right authentication architecture. Warehouse security policies apply to the connecting account – an agent using one shared service account bypasses per-user row-level security in practice. Safe setups use per-user credentials or a semantic layer that enforces access policies before queries are compiled, plus logging of every query the agent runs.
For cross-platform questions, effectively yes. An LLM on top of individual ad platforms inherits each platform’s incompatible definitions. Combining ad data with CRM, revenue, and budget data requires a central store – BigQuery or Snowflake in most stacks – and a modeled layer on top that defines how it all joins.
The main options are the dbt Semantic Layer (powered by MetricFlow), Cube, and Looker’s LookML – all of which expose governed metrics that LLMs can query, increasingly over MCP. The right choice depends on your existing stack; the principle matters more than the tool: the AI should query certified definitions, not raw tables.
We help marketing and data teams get from stage one to stage four: the warehouse foundation, the semantic layer, the MCP integration, and the evaluation setup that makes AI-assisted reporting trustworthy enough to send up the chain. If you’re exploring AI-assisted dashboards or analytics agents, or you’ve already been burned by the quick version, contact us to talk about how to structure this for your stack.