For most teams, the honest version of “we’re data-driven” is narrower than the phrase suggests: we look at the data, and then we decide roughly what we were going to decide anyway.
That isn’t cynicism, and it usually isn’t a skills problem either. The question that would genuinely settle an argument is almost always a week of somebody’s time, and no decision waits a week. So it gets made on experience, instinct, a read of the market and the dashboard arrives afterwards to confirm whichever part of that you were already leaning toward.
In this article, Ivan Burban, Head of Marketing at Coupler.io, explains how his team use AI analytics and data to support real business decisions: what context they had to capture first, how the workflow is set up, five decisions AI changed, and where it completely missed the mark.
Coupler.io is a data integration and AIanalytics platform that helps teams bring data from 400+ sources into one place. It lets users automate data collection, transformation, and reporting without relying heavily on engineering teams. Coupler.io also offers AI-powered analytics features that can help users explore data, spot trends, and get insights faster. The platform supports integrations with tools like Google Sheets, Excel, BigQuery, Snowflake, and Looker Studio. It’s designed for marketing, analytics, finance, and other teams that need reliable, up-to-date data for decision-making.
TL;DR
- We run plans, forecasts, and diagnostic questions through an AI agent with live, documented access to the warehouse, a practice usually called conversational analytics.
- AI can produce trustworthy answers with three context layers: data context, business context, and skills.
- Dashboards keep the work they are genuinely good at, including stable KPIs, budget, and anything that must be readable with nobody in the room to explain it.
- We have caught two disagreements between the dashboard and agent in three months.
- The compounding return is repeatability: because the method is written down and versioned, each month’s analysis starts from more than the last one did.
What can you miss when making decisions?
The problem with analytics isn’t always that you don’t have enough data. Sometimes, you have plenty of it, but not in a form that helps you answer the question in front of you.
Here is what that looked like for us. Our weekly demo calls fell by roughly half. The dashboard did exactly what it was built to do: it showed the drop immediately, and our CEO asked the obvious question: why?
We put the same question to the data. The agent queried the right dataset, calculated the change correctly, and came back with a sensible-sounding answer: demand may be weakening, so look at traffic quality, booking conversion, and friction in the demo funnel. Correct data. Correct SQL. Wrong business interpretation.
Then we looked at the outcome. Over the same period, sales-generated revenue had roughly doubled. So the same event could mean two opposite things: either we had a serious funnel problem, or we had stripped out low-value meetings and become far more efficient. More data exposed the contradiction. It still did not explain it.
What made this hard is that we spent the next stretch debating the wrong things. Was the model not good enough? Should we move from dashboards to a chat interface? Did we need a semantic layer instead of raw SQL?
Those are all real questions, and not one of them was our problem. A better model would not have known we changed lead qualification. A chat interface would not have known either. Even flawless SQL does not contain a decision taken in a sales meeting. We kept looking at the tooling, the model, and the query layer. Everything except the business context.
Three facts were missing, and none of them existed anywhere in the schema. We had introduced lead scoring. We had narrowed the ICP that sales would handle. And we had changed the demo booking flow, deliberately, to cut low-fit meetings. Those decisions lived in meetings, in Slack, and in people’s heads. That is why a perfectly correct query produced the wrong interpretation.
Once the business change was documented next to the dataset, the same model, on the same data, connected the lower call volume to the intended qualification change and the stronger revenue outcome: the decline is expected, and it indicates improved sales efficiency rather than weaker demand. We did not make the model smarter. We made the system around it complete. The part that matters is that the explanation is still there next Monday, not only in one corrected conversation.
That is the layer teams overlook most often, and the reason is that nothing about it looks missing. The data is complete. The query runs. The answer comes back fluent and confident. You only discover what was absent when the interpretation turns out to be wrong and by then somebody may already have acted on it.
Traditional analytics is good at answering questions that have already been defined. You build a dashboard to track channel performance, monitor revenue, understand user behavior, or follow a particular metric over time. Once it’s set up, you can return to the same questions again and again.
Yet, business decisions rarely arrive as answers to predefined questions..
That is the gap conversational analytics is designed to address: not replacing dashboards, but making it easier to explore the data beyond the questions your existing reports were designed to answer.
What conversational analytics actually means
Conversational analytics is a way of working with business data by asking questions in plain language instead of relying only on pre-built dashboards or writing SQL queries yourself.
For the answers to be useful, two things need to work together. First, the system needs access to current data, so it can query the actual dataset rather than rely on an old export or a manually prepared spreadsheet. Second, it needs context about that data: what each metric means, how it is calculated, what level of detail it represents, how it should be aggregated, and where there are known limitations.
That’s why much of the work behind conversational analytics involves making sure it understands the data well enough to answer the right question.
What context should be added?
Disappointing AI analytics is almost never a model failing to analyze. It is a model handed the data with no explanation of what any of it was, producing something confident anyway.
An agent needs three layers of context, and they stack.
Skills: reusable instructions for a kind of analysis
A skill is a written definition of one kind of analysis, and in our setup it has five parts: metadata, meaning a name and a description of when it should be used; the role, tone, and steps to follow; the inputs it needs and the output it should produce; guardrails and edge cases; and a validation step so it can check its own work. Once that’s in place, there’s no need to write a huge prompt from scratch every time.
By the way, our Product Lead Veronika Tamaio Flores has shared how to build AI skills for reliable analytics. In this video she walks through the anatomy of a good AI “skill,” how to write reusable skills that work across Claude, Cursor, ChatGPT, and Gemini, how to automate report generation with built-in validation, and where to find skill templates.
For example, our weekly reporting skill already knows how we want to approach the analysis. Instead of explaining the whole process again, we can simply ask it to look at this week’s data. You don’t have to start from a blank page either. we keep a curated, open collection of analytics skills at github.com/coupler-io/skills, covering marketing, sales, finance, and ecommerce analysis, which is a reasonable place to see what a well-formed skill looks like before writing your own.
Business context: what the numbers mean
This context holds a business calendar covering launches, pricing changes, outages, and seasonality; business logic and internal conventions; key terms and customer segments; current strategy, priorities, and KPIs; and instrumentation quirks alongside known data gaps. This is the biggest of the three layers and the one teams most often skip, because none of it is a column in a table. It is everything an analyst would tell a new hire on day one. Lead scoring was not a field in our schema and that is exactly why the demo-call answer came back wrong.
Data context: what the numbers are
This layer covers table and column definitions, data types, allowed values and units, business-friendly metric definitions, calculated fields and aggregation rules, and naming conventions along with synonyms.
Where context should live
Once you start documenting your data and business context, the next question is where to keep it. There are three common approaches.
In the tribal model, context lives in people’s heads, Slack messages, and outdated documentation. It works until the person who knows why a metric is calculated a certain way is unavailable or leaves the team.
In the repository model, context lives alongside the workflow in version control, with changes tracked and reviewed. This gives you a clear history and works particularly well for technical teams, but it can create friction for people who don’t normally work in GitHub.
The third option is to keep the context with the data itself. Definitions, business events, and known gaps live on the dataset, under governed access, so they are available to whoever or whatever, is querying it. This is the same reliability the repository gives you, without the engineering tax, and it is where we have ended up. The repository still matters, but for a narrower job.
However, there is no single right answer. The best place to store your context is the place your team will actually keep up to date. A well-maintained Google Doc is more valuable than a perfectly structured repository nobody touches.
What matters most is that the knowledge doesn’t stay invisible. If you take one thing from this section, make it this: write down what your metrics mean, how they should be used, and where they can be wrong.
How it works, step by step
The setup has five parts: a human question, a set of sources, one engine that holds the calculations and the context, the interfaces people actually work in, and version control over how the analysis was done.
1. It starts with a human question
Every useful analysis starts with a specific question connected to a decision.
This is the part that should not be automated. If you automate the question itself, you can end up with an impressive analytics setup that produces plenty of answers but doesn’t help anyone make better decisions.
Start with what you need to decide, then use AI to investigate the question.
2. Everything is a source, including the warehouse
Your data already lives in a dozen systems, and the first move is to stop fighting that. Ours arrives from BigQuery and GA4 for traffic, PostHog for product usage, Pipedrive for the sales pipeline, the ad platforms for spend, plus product and server-side events and billing spreadsheets. We do not force everything into one warehouse first. The warehouse is a source like any other.
3. You have one analytical engine
Everything lands in one governed layer, and that layer does four things at once. It holds the AI context: schema, documentation, and metric definitions. It holds the skills that understand and validate a question. It holds the transformations that join, filter, and blend across sources. And it holds the governance (data quality plus access controls) that makes it safe to open up beyond one person’s laptop.
The important part is that the calculations happen here, in the engine, rather than inside a probabilistic model. One layer unifies every source, and then serves every tool.
On top of that engine, Coupler.io plays three roles for the people and the AI using it.
First, it keeps the data flowing. Our pipelines bring in data from sources such as the funnel, PPC, and sales demos and keep it automated.
Second, it gives the AI access to current data. The agent can read the schema and run SQL against the latest snapshot. In our setup, the data is refreshed every 15 minutes. The exact interval matters less than having access to production data rather than working from an outdated export.
Third, it gives the AI context about the data. Metric definitions and column descriptions live directly on the dataset, so the information describing the data stays connected to the data itself.
4. The interfaces people actually use
Several interfaces sit on top of that one engine, and which one we open depends on the job. A dashboard for monitoring, a spreadsheet for a fast pivot, Claude for the question you’d otherwise type into a chat, Cursor for building a new dataflow, any other LLM or agent through the same governed access, and the native tools for what they already do well. Same numbers, same context, different front door.
Why you need one place for context
Writing context down only works if there is one place it goes and somebody is responsible for each piece of it. The practical question I kept hitting was this: how do I explain the lead scoring change to every employee, every client, and every future analysis? The answer is not to repeat it in a dozen meetings. It gets written once, next to the dataset, with an owner and a date attached, so anyone reading it later knows who to ask and how stale it might be.
Ownership splits along the lines you would expect. Sales contributes what the pipeline stages actually mean. Marketing contributes campaign and channel context. Product owns the events. Finance owns the revenue logic. Nobody is documenting someone else’s domain, which is the main reason this tends to survive contact with a real team.
The payoff is that one written decision serves several audiences at once. Authorized AI interfaces read it through governed access, so any LLM or agent works from the same understanding rather than whatever happened to be in one person’s prompt. The team reads it — marketing, sales, product, finance. And if you are an agency, your clients read the same thing your AI does. Write the decision once, everyone downstream inherits it.
How to keep context up to date
Context that nobody maintains turns into another stale document: definitions change, launches happen, instrumentation breaks, and the accuracy you gained starts to decay. Keeping it current has to be somebody’s actual responsibility, and the whole team needs a way to contribute. Four things make that realistic.
- Connect what you already write, rather than rewriting it.
Your GitBook, Confluence, or Notion pages are already context, plug them in.
- Let the chat write context back.
End a useful analysis by asking it to save the finding, so the tool that discovered something also records it.
- Use the integrations you already have, so context arrives from the systems the team is in anyway and nobody has to adopt a new process.
- And promote good chats into skills: a conversation that finds a better approach should become reusable, not a screenshot in Slack.
Underneath all of this sits one rule worth stating plainly: everything starts as a sandbox and only some of it earns the right to be governed. A spreadsheet export is often the fastest way to test a hypothesis, and it should stay disposable. But if the same pivot keeps proving useful, automate its refresh. A one-off chart answers a question; a dashboard is a decision that repeats. A good prompt is disposable; a verified skill is an asset. Spreadsheets, dashboards, and prompts are not the problem. Unmanaged ones are.
Make smarter decisions with the help of AI
Over the last three months, I ran into data mismatches twice while doing conversational analytics with AI. That’s a real cost, and I won’t pretend otherwise. But the results still add up: you get faster idea validation and repeatability you can actually rely on.
If you’re a marketing or product lead who has to make quick calls, treat this as more than a recommendation. It’s the difference between using your experience and being blinded by it.
FAQ
Why does AI give confident answers that turn out to be wrong?
Usually the model isn’t the problem. It was handed data with no explanation of what that data represents. In our demo-call example, the SQL was correct and the interpretation was wrong, because the decisions behind the drop (lead scoring, a narrower ICP, a new booking flow) were never written down anywhere the agent could see them. A better model, a chat interface, or a semantic layer wouldn’t have fixed that. Written context did.
What context does an agent need?
It needs three layers. Data context covers what the numbers are: definitions, types, units, calculated fields, aggregation rules, and synonyms. Business context covers what the numbers mean: the business calendar, segments, strategy, KPIs, and known gaps. Skills are reusable instructions for a type of analysis. If you’re short on time, start with aggregation rules and known data gaps, since those cause the most damage when they’re missing.
What’s the difference between data context and business context?
Data context describes the dataset itself, such as how a column is calculated or what level of detail a table holds. Business context describes what happened in the business that the data can’t tell you, such as launches, pricing changes, outages, or a change in how sales qualifies leads. Business context is the layer teams skip most often, because none of it is a column in a table.
Where should we store context?
There are three common options. Context can live in people’s heads and in Slack, which works until that person is unavailable or leaves. It can live in a version-controlled repository, which is reliable but creates friction for people who don’t work in GitHub. Or it can live on the dataset itself under governed access, so every tool and person querying the data reads the same definitions. We’ve ended up with the third option, and we still use the repository for plans, reports, and rules.
Do AI chats replace dashboards?
No. Dashboards stay better for stable KPIs, budget tracking, the regular pulse, and anything that has to make sense to someone with no context. They also work as a validation surface. They caught both of the mismatches we hit in three months.
