Querying analytics data with AI: no report needed

The web coordinator of a province called me last year after a busy information evening. Something had gone wrong with the registration page, but he did not know exactly what. When did the traffic drop, which page stopped visitors, had the campaign anything to do with it? To answer those three questions he needed three separate reports. By the time they were ready, the event was long over.

That situation is recognisable for anyone who uses analytics but is not an analyst. You know what you want to know. You do not know how to configure the tool for it.

The AI assistant solves that. You ask the question in plain language. The agent decides how to reach an answer, retrieves the right data, and returns it as text, chart, or table, directly in the chat.

Your dashboard context is already loaded

Every chat starts with the context of the dashboard you are looking at right now: the selected period, the active metric, and the filters you have applied. That information travels with your question to the agent, so you do not have to explain what you are looking at.

That is why even a short question works. Ask “How is the website doing?” and the agent already knows you are looking at visitors over the last 28 days, pulls the trend, and summarises what stands out.

The context is not a hidden setting. You can see exactly what was sent to the agent at any time. Change the dashboard, and a new session picks up the current state in one click.

Two paths to the answer

The agent has two ways to reach your data, depending on what the question requires.

Via the reporting API. The same API that powers the dashboards. For questions about trends, comparisons and breakdowns, the agent calls it the way any other client would. “Take last week’s sessions and compare them with the week before” returns one chart and a day-by-day table.

Via direct read-only database queries. For questions no ready-made report covers, the agent writes its own SQL against the same tables your BI tools may use. Think of a custom funnel from a single event parameter, or a comparison combining two reporting periods and a segment. The agent inspects the schema, writes its own read-only query, and reports the result.

This works because of an architectural choice made long before the agent existed: the data warehouse schema is flat, documented, and designed to be queried by humans and BI tools alike. What is easy for an analyst to query turns out to be easy for a language model to query too. Clean, documented data is what “AI-ready” actually means.

Built within the [gov] standard

Giving a language model direct access to your analytics data is the point at which most organisations rightly become critical. The AI assistant was therefore built within the [gov] standard from the first line, not alongside it.

One property per session. Each session has access to exactly one property. There is no path to other tenants or other properties. That separation does not live in a prompt politely asking the model to behave: it lives below the model, in the access layer.

Read-only, by construction. The agent’s database access is read-only. It can query your data, but it cannot modify, delete, or export it anywhere.

Inspectable context. What the agent receives is shown in the session’s context view. Not hidden in a prompt you cannot see.

The boundaries live in the architecture, not in the contract. The orchestration, the data access, and the isolation live in the core of the platform, not in the language model. The model is a swappable component. The read-only access and the per-property separation apply regardless of which model you choose.

EU language models by default

By default, the agent uses EU-based language models. The default model is fully open source and runs on EU infrastructure. Your questions, your dashboard context, and the query results the agent reads do not leave the EU.

If you chose Govanalytics because you want to know where your data is, an AI feature that quietly sends your analytics data to a US inference endpoint would undo that choice. That is not how this works.

Your own model if you prefer

The intelligence of the agent does not depend on one specific model. The orchestration, the data access, and the security boundaries live in the core of Govanalytics. The LLM API is a swappable component managed by the core.

That has a practical consequence: organisations with an existing agreement with a model provider, or with their own inference, can connect the AI assistant to it.

Any model that scores sufficiently on standard benchmarks works well with our setup. That means you can freely trade off cost, speed, and provider choice without losing the feature itself.

Start with a question you half already know

Open a dashboard, start a chat, and ask the question you would normally turn into a report request.

Start with something you half already know the answer to. Watching the agent pull the same numbers you would have pulled, only faster, is the quickest way to build trust in the answers you did not predict.

Book an intro chat →