Imagine asking about your own data the way you'd ask a colleague. “Why did ROAS in Poland drop last week?", “How much did we really make on Black Friday after returns?", “Do customers from this promotion come back?" And you get the answer during the meeting — not in a ticket to your analyst with a due date the day after tomorrow.

Technically this is possible today, and it's called MCP: a standard that lets you connect the AI model your team already uses — ChatGPT, Claude or Gemini — to external data sources. It sounds like the whole problem solved, which is exactly why the catch is worth naming right away. Connecting AI to your data isn't the same as making it understand your data. This article is about that difference — and about what you have to add so that connecting it produces something you can base a decision on.

One clarification up front, so there's no misunderstanding: we're not talking about another chat window bolted onto a dashboard. We're talking about the model you already use, connected to your warehouse through a layer that knows what your numbers mean.

Connecting AI to data isn't the same as making it understand data

Companies trying to analyze data with AI today usually do it one of three ways. It's worth going through them one by one, because each fails at a different point.

• A screenshot or a data export pasted into a chat. The model will calculate exactly what it was given — a slice, with no way to check anything deeper. Every follow-up question means another export, and every “break that down by market too" means going back to the dashboard. It works for one question; it doesn't work as a way of working.
• AI connected directly to source systems — GA4, Meta, the store. The data there is raw and scattered, so the model queries six sources, pulls thousands of rows of products and transactions into context, confuses spend with cost, and simply chokes on larger volumes. It looks great in a demo. At real volume, it answers slowly, expensively and unreliably. We went into this at length in the piece on a single source of truth — it also shows how much of that work can be done once, instead of from scratch at every question.
• AI on your own warehouse, but without documentation. This approach looks the most serious, which is exactly why it's the most deceptive. The data is already in one place, the model has access to the tables — nobody just told it what those tables mean. Your order-status column might have seven values, two of which mean “returned," one means “cash on delivery, not yet paid," and one is left over from a store migration and no longer means anything. The model doesn't know that and has no way to find out, so it counts revenue from everything and hands back a number that sounds credible. Because AI fills gaps in documentation with its most plausible guess — and “plausible" and “true" are two different things in analytics.

The model doesn't have a problem with counting. It has a problem with nobody telling it what your numbers mean. And the one that's guessing sounds exactly as confident as the one that knows.

That's the entire difference between “we connected AI to our data" and “we have an assistant a decision can be based on."

What the AI assistant in WitCloud is

The AI assistant is our module built on WitCloud MCP — a layer that sits between the model you use and your data in your own BigQuery. We're not taking you to yet another chat panel: you connect your assistant to your data and work where you already largely work.

This layer does three things — and they're what accounts for the difference described above.

• It points the model only at ready-made datasets. The assistant works on the All In One tables and on our solutions' tables — LTV and customer segmentation, the KPI tree, monitoring, product analysis — never on raw data. The heaviest work — joining, cleaning and aggregating millions of rows — has already been done earlier, in the warehouse, on Google Cloud's compute power. The model doesn't grind through raw tables: it asks for a ready, lightweight dataset and gets an answer immediately.
• Documentation first, then the query. Every project carries its own documentation: what it contains, what each column means, which query a given analysis is calculated with. The assistant reads it before calculating anything — and uses the rules described in the documentation instead of building its own queries from scratch. This is the one rule whose absence turns the previous scenario into a generator of confident-sounding nonsense.
• It starts by establishing what you're working on. You pick a project, the assistant pulls in its contents — data sources, business contexts, channel and market groupings — and asks about two things: what you want to analyze, and what form you want the answer in — a table, a summary, chart-ready data, or a mix of both. Only then does it go down to the data, and it sticks to the agreed format for the rest of the session.

And if a project doesn't have anything to analyze yet — because Google Cloud isn't connected, or the first connector hasn't delivered data yet — the assistant recognizes that and walks you through what's missing, instead of searching for data that isn't there.

Three things that turn a correct answer into a useful one

A correct answer is one where the numbers add up. A useful one is one you can bring to a meeting and make a decision on. Between the two stand three things you describe once, and the assistant reads at every analysis.

Business context — what your company actually is

Your own description: what you sell and to whom, which markets you operate in, how your industry behaves, what “new customer" means for you, where you have margin and where it's just turnover. You keep it as text in WitCloud or in your own Google Docs, which WitCloud reads at every analysis — so you update it wherever you already work.

A project can have several contexts: a separate one per brand, a separate one per market. An analysis is always read against the one you specify — the assistant doesn't choose it for you. That's deliberate: automatically picking “the first one on the list" is the simplest way to get an accurate-sounding answer about the wrong business.

Event log — why the numbers did what they did

A calendar of what happened at your company: a promotion, a change to the free-shipping threshold, a stockout, a store migration, entering a new market, a rebrand. A simple spreadsheet — date, category, description.

This is what turns “traffic grew 40%" into “traffic grew 40% because a campaign launched on the 12th," and protects you from the most common excuse in analytics — blaming seasonality for anything we can't explain another way. The assistant reads this log during analysis and can add to it: you tell it in conversation that a delivery fell through last week, and it adds an entry. A month later, no one will be wondering what happened there.

Channel and market grouping — so both are named the way your company names them

Traffic and cost arrive labeled as a mess: google / cpc, newsletter_2024, fb-ig, twenty UTM variants. Channel grouping is your set of rules that reduces this to the channels your team actually talks about in a meeting.

The same module handles a second dimension that gets discussed far less often and, with more than one market, decides everything: market grouping. Because a market arrives in several versions at once too — GA4 talks about the country of the session, the store about the shipping country, the ad account about targeting, and a single campaign can serve three countries at the same time. On top of that, “market" in your company rarely means exactly “country": DACH is often one market, the rest of the EU one bucket, and the marketplace its own entity even when it sells in the same country as the store. Market grouping is the same set of rules, just on that dimension — reducing every variant to the split you actually manage.

And this is the dimension it's easiest to trip on, because the error doesn't look like an error. “Is Germany behaving today the way Poland did a year ago?" or “which market are we losing money on shipping in" are questions where the whole difficulty sits not in the arithmetic, but in whether Germany means the same thing on both sides of the comparison. The path you walk when diagnosing — market → channel → campaign — starts on exactly this dimension: if the first step is out of alignment, the rest of the drilldown leads somewhere wrong, just in great detail.

The quality of both groupings decides how trustworthy every channel report and every cross-market comparison is, so it's worth reviewing — and that's a job perfectly suited to the assistant. It will calculate, on your own data, how much cost and traffic lands in “other," which rules no longer catch anything, what the biggest unassigned sources are, and where markets drift apart between systems. It will propose fixes. And if the new rules are meant to cover historical data too, it shows you the cost estimate first — recalculating history is the only operation in this module that actually costs something, and nothing starts without your explicit approval.

Numbers tell you what happened. Context tells you why — and only that decides whether an answer is fit for a decision.

Four things people do with the assistant most often

1. A weekly health check. Instead of opening five reports: “go through the whole KPI tree, every metric in its own comparison window, and tell me what needs my attention." If the tree is defined in WitCloud — with metrics linked and the right window on every branch — the assistant has something to work down through, and it comes back with one coherent overview: from the top of the tree down to the levers you'd end up drilling into by hand anyway. Without a tree it will still answer, just a narrower question: about a specific metric, not about your overall health.
2. Diagnosis when something deviates from the norm. An alert says ROAS in Poland dropped 22%. You ask “why" directly, and the assistant follows the same path you'd take in a report: market → channel → campaign, and then it breaks down the metric itself — cost or revenue, CPC or click count. It just goes deeper, and doesn't get tired by the tenth branch in the middle of the day.
3. Customer questions. How much a customer from Google Ads is worth compared to one from a newsletter. How many months it takes to recover acquisition cost in the March cohort. Which channels bring in valuable customers, and which just bring in cheap ones. Which products acquire customers, and which build loyalty. How segments shift from month to month.
4. Product questions. What sells versus what makes money. Where variants are eroding and which campaigns are already feeling it. What a new arrival delivered in its last test window. Which products are running out of stock while their budget is still switched on.

On top of that comes a category you can't plan for: one-off questions. “Do customers from this promotion come back?", “How much did we really make on Black Friday after returns?", “Is Germany behaving today the way Poland did a year ago?" Before, each of these was a ticket that went into a queue. Now it's a question asked mid-conversation — and that's the change people feel the most.

It works inside the tool your team already uses

We're not building our own chat, because your team already has one. You connect WitCloud to ChatGPT, Claude, or Gemini — we have a step-by-step guide for each. You log in with your own WitCloud account, by email and password or through Google, and access is per user, not one shared key for the whole company.

Data never leaves your Google Cloud. The model gets a query result — only as much as it needs for the answer — not a copy of the warehouse. Everything the assistant reads is read-only; it only changes the three things you explicitly ask it to: business context, the event log, and channel and market grouping.

The assistant itself doesn't touch your campaigns — and that's a choice, not a gap. But MCP is a standard, so ours doesn't have to be the only one in the chat: you plug the Google Ads MCP in next to it and have both in the same conversation. Ours supplies the knowledge — what's happening, in which market and why — and that one does the work, on its own permissions, which you grant separately. Let them talk to each other. The decision is still yours; you just don't have to click it through three panels any more.

You don't need to know SQL, and you don't need to know what the tables are called. You need to know what to ask — and that's a skill your team already has. The analyst doesn't disappear in this either: they stop stitching together reports for questions that a ready-made dataset can already answer, and focus on the ones that genuinely need an analyst.

Billing runs per active user per month and is tiered: you only pay for people who actually asked something that month, and the more of them there are, the lower the rate on the next tiers. You'll find the current tiers in the module's documentation.

The more you have in place, the more the assistant gets out of it

The assistant works from day one — a warehouse with data flowing into it and a business context on one page is enough. But it doesn't invent analyses out of thin air: it reaches for what you already have computed. So every additional module you switch on doesn't give it a new feature — it gives it new questions it can answer. And that's probably the nicest part of this puzzle, because it works without any extra effort on your side.

• All In One supplies the common language: spend and cost stop being two different things, and the assistant can answer about sales, costs, channels and ROI in one number instead of five.
• The data quality audit decides whether that number can be trusted. The assistant will count exactly what it's given — so the fewer holes at the source, the fewer confidently delivered mistakes.
• The KPI tree with monitoring turns “how are we doing?" into a concrete path. The assistant doesn't have to guess what to look at: it has defined metrics, comparison windows and branches to walk down.
• LTV and customer segmentation open a whole block of customer questions — cohorts, payback on acquisition, customer value per channel — without computing it from scratch at every question.
• Product analysis does the same for your assortment: margin, turnover, stock and variant erosion are already computed, so “what earns versus what merely sells" gets an answer rather than another query.

And it works both ways. The assistant is also the fastest way to review and maintain those modules: it will check channel and market grouping, point out rules that no longer catch anything, add to the event log what you tell it in conversation. The more you have in place, the more you get out of it — and the more often you use it, the better organized what you have stays.

You don't need all of it to start. It's just worth knowing there's no dead end here: every piece you add simply widens the range of questions you'll get a sensible answer to.

What the assistant won't do

Being upfront about the limits, because they decide whether this works for you.

• It won't fix your data quality. If half your transactions never make it to analytics because the purchase tag doesn't fire after returning from the payment gateway, the assistant will calculate exactly what's there — and say it confidently. That's why it runs on a guarded source rather than raw systems. If you want to know what specifically tends to break along the way and how to catch it, we wrote it up in the marketing data audit.
• It won't replace a report. Some teams simply prefer to click through a ready-made All In One report — and that's fine. Both stand on the same source, so either path leads to the same number.
• It doesn't know your business out of thin air. Without context and without the event log, it will explain as seasonality what was actually a promotion. These two things are the only “homework" in this module — and it takes a page, not a book.
• It won't answer questions about data you don't collect. A missing integration won't turn into an answer. It'll turn into information about what's missing — which is useful too, but it's a different answer than the one you're counting on.
• Fresh data is still fresh. Yesterday is usually closed out, today isn't, and conversions keep arriving for a few more days. The assistant accounts for this, but doesn't override it.

Getting started

On the data side the minimum is shorter than it looks: a working All In One with data flowing into it, reviewed channel and market grouping, and a business context that fits on one page. That's enough to ask the first questions worth asking — the rest arrives along the way, at whatever pace you set.

On the team side: one person who starts, and one rhythm. A weekly meeting with five standing questions works best — what changed, what's off from normal, where we're losing, what came through, what we do next — one where nobody prepares materials in advance, because the answers are pulled live. Once that rhythm holds, you extend access to the rest of the team.

Organized data finally starts paying for itself

No MCP will take the job of organizing your data off your hands, and nobody should honestly promise that. What it does instead is visible from the first week: that order starts paying off daily, rather than once a quarter, when someone finally gets around to building a report on it.

AI connected to a mess speeds up exactly one thing: how fast you make the wrong call. Connected to an organized, documented source, with your business context on hand, it shortens the path from question to action from days to minutes — and it does that for the whole team, not just for the person who knows SQL.

That's why the assistant is worth switching on last, even though it looks the most impressive of the lot. The warehouse, the audit, the KPI tree, the segmentation — all that work only stops sitting in panels nobody opens more than once a month once the assistant is there.

Instead of asking about your data once a month — talk to it every day.