Conversational Agents on GA4 BigQuery Exports

Every analytics team gets the same message on a Monday morning: "Quick one, how many demo requests came from paid social last week?" It is never quick. Someone opens the BigQuery console, finds the right daily tables, unnests event_params, and checks whether the intraday table is included. Then they explain why the number does not match the GA4 interface. An hour later, the stakeholder has their answer and a new question.

This is the problem conversational agents on top of a data warehouse are meant to solve. A stakeholder asks in plain English. The agent writes the SQL, runs it, and answers with the result and the query behind it. The idea is not new. What has changed is how little setup it takes to try. That makes it worth asking what you actually need in place before you let one loose on your marketing data.

Lower setup is real, and that changes who tries this

A recent release of datasette-llm 0.1a9, the plugin that Datasette Agent builds on, now uses the default model already set in LLM. That means you can start using Datasette Agent without explicitly configuring a default model first. It is a tiny user experience improvement, with bigger upgrades to Datasette Agent still to come.

A small change, but it points in a clear direction. Asking an LLM questions about a database is becoming something you set up in minutes, not a project. Datasette works with SQLite files, not BigQuery. The pattern carries over, though: a model, a description of your tables, and a tool that lets the model run queries and read the results.

For marketing teams, the friction never really sat in the agent. It sits in the data, and in the guardrails that make an agent safe to hand to someone who does not read SQL. That is where we spend our time when we build these.

Why GA4 exports trip up a naive agent

If you point a general-purpose model at a raw GA4 BigQuery export and ask "how many sessions did we get from organic search last month?", you will usually get SQL that runs. You will not always get SQL that is right. The export has quirks that catch humans out, and models are no exception:

• Sharded daily tables. Events land in events_YYYYMMDD tables, plus events_intraday_ tables if streaming export is enabled. An agent that queries one table, or double-counts intraday and daily data, gives you a confident wrong number.
• Nested parameters. Most of what matters (page location, session ID, form names, custom parameters) lives inside the repeated event_params record. Getting it out needs UNNEST and the right value type, and the type is not always the one you expect.
• Sessions are not a column. There is no ready-made session count. You build it from user_pseudo_id and the ga_session_id parameter, and you need to decide how to handle edge cases.
• Attribution differs from the interface. Traffic source fields in the export do not behave like the reports stakeholders see in GA4, so "why doesn't this match?" will come up.

None of this is exotic. It is the same knowledge your analyst carries in their head. The job is to get that knowledge out of their head and into something the agent can read.

It also assumes the data is trustworthy at source. If your tagging is inconsistent, an agent will simply answer faster with bad data. If your containers have drifted, it is worth working through what to audit in your GTM containers before you put a natural-language layer on top.

The architecture we recommend

The shape is simple and it stays the same whichever client or model you use:

1. A model that does the reasoning and writes SQL.
2. A query tool the model can call. In our setups this is usually an MCP server, which gives the model a defined set of actions such as listing tables, reading schema and running a query. We have written about the same pattern for a different job in running SE Ranking through an MCP server.
3. A curated layer of views in BigQuery that does the hard GA4 work once: unnested parameters, a sessions view, a conversions view with your definitions baked in.
4. Documentation the agent reads before it writes anything.
5. A log of every question and every query.

The curated layer does most of the work. Ask an agent to rebuild sessionisation logic from scratch every time and it will drift. Give it a sessions view and a conversions view and it mostly has to filter and group. Models are reliably good at that.

Guardrail 1: read-only, by construction

The agent should be physically unable to change anything. Do not rely on a line in the prompt saying "never run DELETE". Prompts are instructions, not permissions.

In practice:

• Create a dedicated service account for the agent. Never reuse an analyst's credentials or a pipeline account.
• Grant it read access only to the curated dataset of views, not to the raw export or anything else in the project.
• Give it the minimum role needed to run query jobs, and nothing that lets it create, modify or delete tables.
• Set a maximum bytes billed limit on the queries it runs, so one badly formed question cannot scan your entire event history.

This also settles the data protection question early. If the curated views exclude fields you would not want surfaced in a chat window, the agent cannot surface them, however the question is phrased.

Guardrail 2: schema docs that carry business meaning

Column names tell a model what a field is called. They do not tell it what your business means by it. Good schema documentation does both, and it is the single biggest lever on answer quality.

We write three layers:

• Column descriptions in BigQuery itself, so they travel with the table and any tool can read them.
• A glossary of business definitions. What counts as a lead? Is a demo request the form submit event or the thank-you page view? Which channels are "paid social"? This is where most wrong answers come from, because the model will otherwise guess.
• Worked example queries for the questions people actually ask. A handful of correct, commented queries teaches the model your conventions faster than any amount of prose.

Add known caveats too: when tracking changed, which date ranges are incomplete, why the export will not match the interface. An agent that can say "note: form tracking changed on this date, so earlier figures are not comparable" earns more trust than one that is merely fluent.

Guardrail 3: log every question and every query

If a stakeholder quotes a number from the agent in a board deck, you need to be able to reconstruct where it came from. Logging makes that possible, and it is also how you improve the system.

For each interaction, record:

• the question as asked
• the SQL the agent ran
• bytes processed
• a short summary of the answer given
• who asked, and when

BigQuery already keeps job history, which you can query through INFORMATION_SCHEMA views, so the SQL and bytes side is partly covered once the agent has its own service account. Pair that with a simple log on the conversation side and you have an audit trail. Review it weekly. Questions the agent got wrong tell you which definitions are missing from the glossary. Questions that come up repeatedly are candidates for a proper dashboard.

Guardrail 4: always show the working

Make it a rule that every answer includes the query that produced it, or at least a plain-language description of the filters applied. "312 demo requests" is a claim. "312 demo requests, counting form submit events with form name demo, last calendar week, channel grouped as paid social" is a claim someone can check and challenge.

This matters most for the people who cannot read SQL. They can still read the assumptions.

Choosing a model and keeping costs sane

This kind of agent has an unusual cost profile. Most questions are short and repetitive, but a few need real reasoning about tricky joins. It is often sensible to route routine lookups to a smaller, faster model and escalate to a stronger one when a question needs it. We looked at that trade-off in how Claude Haiku 5.5 changes the math on high-volume marketing agents.

Whichever model you use, the warehouse side of the bill is the one to watch. The byte limit from guardrail 1 and the curated views from the architecture section do more for cost control than model choice does. Narrow views mean smaller scans.

Where this works, and where it does not

Conversational agents on marketing data are good at:

• quick factual lookups with clear definitions
• "compare this to that" questions across defined periods
• first-pass exploration before someone commits to building a report

They are weak at:

• questions where the definition itself is contested, such as attribution debates
• anything that needs data you have not modelled into the curated layer
• replacing judgement about what a number means for the business

The aim is not to replace your analyst. It is to stop your analyst being a human SQL endpoint, so they can spend their time on the questions an agent should not answer alone.

A starting checklist

If you want to try this on your own GA4 export:

1. Confirm your tracking is clean at source.
2. Build a small curated dataset: sessions, conversions, and one or two unnested event views.
3. Create a dedicated read-only service account scoped to that dataset, with a byte limit.
4. Write column descriptions, a glossary and a few example queries.
5. Connect a model through an MCP server or similar query tool.
6. Log everything, and require every answer to show its working.
7. Pilot with one team and review the log every week.

Talk to us

If you want a conversational layer on your GA4 and BigQuery data that stakeholders can actually trust, we can help. We set up the MCP connections, the curated views, the documentation and the guardrails. Get in touch with Bitegrico to talk through your analytics and MCP implementation.