The problem with using AI for data analysis isn't that it makes mistakes. It's that a wrong answer arrives looking exactly like a right one — same fluent prose, same confident tone, same absence of hedging.
A human analyst who isn't sure tells you they aren't sure. A language model producing a figure it has effectively invented sounds precisely as assured as one performing a correct calculation. There is no tonal signal, which makes verification a required step rather than a cautious one.
That said, the useful applications are real and specific — and the most valuable one isn't the analysis at all.
The distinction that decides everything
Before trusting any output, establish which of two very different things is happening.
The model is writing and running code against your data — a query, a script, a set of operations. The arithmetic is performed by the code, deterministically, and you can read the code to see what it did. Errors here are logic errors: it filtered the wrong column, or handled blanks in a way you wouldn't have. Those are findable.
The model is reading the data as text and telling you what it sees. Now it's predicting plausible sentences about a dataset. It may add up a column correctly. It may also drop rows it didn't notice, misread a date format, or describe a column that doesn't exist — all in the same confident register.
The question to ask first Not "is this tool good at analysis" but "can I see the working?" If the answer is no, you have a plausible-sounding narrative about your data rather than a result.
Most marketers using AI for numbers don't know which mode they're in, because the interface looks the same either way. Ask the tool directly, or check whether it shows you a query or script. If it can't, treat every figure it produces as an assertion requiring confirmation.
The four-minute verification
Non-negotiable, and it catches the majority of problems.
The row-count check deserves emphasis because the error is completely silent. A file with an inconsistent header, a stray blank row, or an encoding problem can lose a chunk of your data without any warning, and every subsequent figure will be internally consistent and wrong.
The highest-value use isn't analysis
The reframe that changes how you'd actually use these tools.
Asking a model to "analyse this data and tell me what's interesting" is asking it to do the thing it's least reliable at, and to do it without context about your business. What it's genuinely excellent at is the thinking around the analysis, where no arithmetic is involved and where a slightly wrong answer costs you nothing.
- "What questions could this dataset answer?" Given a column list and a description, a model will generate twenty framings, several of which you wouldn't have thought of. You then choose which to pursue.
- "What would disprove this?" Once you have a hypothesis, asking for the evidence that would contradict it is one of the most useful analytical prompts available, and it's the discipline most people skip.
- "What confounding factor could explain this pattern?" Models are good at generating alternative explanations, which is exactly the step where enthusiasm usually wins.
- "What's missing from this table?" Spotting the absent column — no cost data, no segment breakdown, no time dimension — is a genuine strength and a common blind spot.
- "Explain what this statistical result means in this context." Concepts explained against your actual situation, which is more useful than a textbook definition.
None of these produce a number, which is precisely why they're safe. And they raise the quality of the analysis you then do properly. The general principle is the one in building an AI workflow that actually saves time — the leverage is in the parts where a mistake is cheap.
ASIQ
All-in-one AI marketing system running SEO, content, social and email together automatically.
Best for: SMBs and agencies wanting one AI system to run SEO, content, social and email
Preparation is where the real time goes
And where AI helps most, because errors are visible.
Most of the effort in any analysis is getting the data into a usable shape: joining two exports that don't share a key, reshaping a pivot into rows, parsing inconsistent dates, splitting a field, deduplicating, standardising campaign names that four people entered four ways.
These are tasks where a model is genuinely strong and where you can see whether it worked. If the join produced the wrong row count, that's obvious. If the date parsing broke, the dates look wrong. The failure is inspectable, which is the opposite of the situation with a summary statistic.
The related use: getting it to write the query or formula rather than the answer. Ask for the SQL, the spreadsheet formula, or the regular expression, then run it yourself. You get the speed benefit and keep the verification, and you end up with something reusable rather than a one-off assertion.
| Task | Reliability | Why |
|---|---|---|
| Generating questions | High | No arithmetic; you judge the output |
| Writing a query or formula | High | You run it and see the result |
| Cleaning and reshaping | High | Failures are visible in the output |
| Explaining a concept in context | High | Checkable against a known definition |
| Calculation via executed code | Moderate | Logic errors possible but findable |
| Summarising a dataset by reading it | Low | Silent errors, confident delivery |
| Drawing conclusions unprompted | Low | No business context; asserts causation freely |
Aggregation is the enemy of interrogation
A behavioural tendency worth knowing about.
Ask a model about a dataset and it will summarise. That's the default — averages, totals, top-line movements. But the interesting thing in marketing data is almost never in the aggregate; it's in a segment that behaves differently from the rest and gets averaged into invisibility.
So push explicitly. "Break this down by segment and show me where the pattern breaks." "Which group is behaving most differently from the average?" "Is this driven by everyone shifting slightly or by a small group shifting a lot?" That last question is the single most useful one to ask of any marketing metric, and a summary will never volunteer it.
This is the same failure the averages create everywhere else in measurement — a site-wide average position, a blended CPA, a mean order value all describe situations that frequently don't exist for anybody, as covered in the Search Console reports that matter.
Watch for causal language
Models assert causation more readily than a careful analyst would.
Ask why a metric moved and you'll get an explanation. It will be plausible, well-phrased, and derived from a correlation in your data plus general knowledge about marketing — not from any evidence that one thing caused the other.
The habit that fixes it: whenever a causal claim appears, ask "what else changed in that period?" and "how would we test that?" The second question usually reveals that the claim isn't testable as stated, which is the point at which you know it's a hypothesis rather than a finding.
This matters most in exactly the situation where you'd want to use it — explaining a change to leadership. A confident causal story that turns out to be wrong is worse than an honest "we can see the pattern but not the cause", which is the reporting posture argued for in a dashboard leadership will actually read and in proving pipeline impact to finance. Where causation genuinely matters, the answer is a controlled test or a model built for it, as in marketing mix modelling.
Garbage in still applies, and more so
An obvious point with a non-obvious consequence.
An analyst working with your data notices when something looks wrong — a channel with impossible numbers, a date range that doesn't match the campaign, a conversion count that doubled the day a tag was reinstalled. That noticing comes from knowing the business.
A model has none of that context. It will faithfully analyse broken data and produce a clean, confident answer about it. Which means AI analysis raises the cost of bad measurement rather than compensating for it — a point worth holding alongside setting up conversion tracking correctly and the general erosion described in why attribution keeps getting harder.
Practical mitigation: tell the model what the data should look like before asking it anything. Expected ranges, known gaps, periods where tracking changed. It can then flag what contradicts your expectations, which is a genuinely useful check — and one that only works if you supply the context. If the underlying tracking is the actual problem, that's a website and measurement job before it's an analysis one.
What not to paste in
Brief, because it should be settled policy rather than a judgement call each time.
Customer records, personal data, unpublished commercial information and client-confidential material should not go into tools without a contract covering them. Most marketing questions concern patterns rather than individuals, so an aggregated, anonymised extract is usually sufficient for the analysis anyway.
If your team doesn't have a written position on this, it's one of the shortest and most useful sections of the policy described in AI governance for marketing teams. It takes four lines and prevents the situation where someone pastes a customer export into a consumer tool because they were in a hurry.
How to prompt for analysis specifically
Different from prompting for writing, and worth its own habits.
- Describe the data before asking anything. What each column means, how it was collected, the period, known issues. Models make worse assumptions in the absence of context, and marketing data is full of ambiguous column names.
- Ask for the method before the answer. "How would you approach this?" first, then let it proceed once you agree with the approach. Catching a flawed method is easier than catching a wrong number.
- Request uncertainty explicitly. "Tell me what you're confident about and what you're inferring." Models will differentiate when asked and won't when not.
- Ask for the caveats you'd need to publish. Useful output, and it surfaces limitations the analysis glossed over.
- Never accept a single number without asking how it was calculated. The most dangerous figure in any report is the one nobody can trace back to a source.
The broader craft is in prompt engineering for marketers, though analysis differs in one key respect: with writing you can judge the output by reading it, and with numbers you can't.
Where this genuinely shines
Four situations worth trying this week, all of them low-risk.
A dataset you've never seen. Describing an unfamiliar export — what's in it, what looks odd, what's missing — is fast and the output is easy to sanity-check against the file.
Qualitative data at volume. Hundreds of survey free-text responses, support tickets or review comments grouped into themes. This is genuinely transformative because the alternative is reading them all, and the failure mode is a mis-grouped comment rather than a wrong number — closely related to the practice in turning social listening into insight and to the research approach in using AI for customer research.
Explaining someone else's analysis. Paste in a report you don't fully follow and ask what it's claiming and what it isn't. Comprehension is a strength.
Drafting the caveats. Once you've done the analysis properly, having it write the limitations section produces a more honest document than most people write unaided.
A working sequence
- Establish whether the tool runs code or reads text.
- Describe the data, the period and the known problems before asking anything.
- Use it for preparation, questions and method — not for conclusions.
- Ask for the query rather than the answer where you can.
- Push past aggregates: segment, and find where the pattern breaks.
- Run the four-minute verification on any number you'll repeat aloud.
- Challenge every causal claim with "what else changed?"
- Write down what you'd expect the answer to be, before you see it.
That last habit is the cheapest safeguard available. If the output contradicts your expectation, either you've learned something or the analysis is wrong — and you'll investigate either way. If you didn't record an expectation, a wrong answer that happens to sound reasonable passes straight through. It's the same discipline that makes specific goals more useful than vague ones, and it's what separates interrogating your numbers from being told a story about them.
The short version
A wrong answer looks exactly like a right one, so verification isn't optional. Establish first whether the tool runs code you can inspect or is reading numbers as text, because those are completely different reliability regimes. Run four checks on anything you'll repeat: recompute one figure, check the row count, ask for stated assumptions, and ask the same question two ways. Use AI for the parts where failure is visible — cleaning, reshaping, writing the query — and for the thinking around the analysis, which is where it's genuinely excellent and entirely safe. Push past aggregates, because the finding is almost always in a segment the average hides. Challenge causal language every time it appears. Don't paste customer data into tools without a contract. And write down what you expect before you look, because that's the only thing standing between you and a plausible wrong answer.
The most dangerous number in any report is the one nobody can trace. AI makes those considerably easier to produce.
Numbers in the deck nobody can trace back to a source?
We rebuild the measurement so the figures you present hold up to the second question.
Fix my reporting →Frequently asked questions
Can you trust AI to analyse a spreadsheet accurately?
It depends entirely on whether the tool is running code against the data or reading it as text. When a model writes and executes code, the arithmetic is performed by the code and you can inspect the logic. When it reads numbers and describes what it sees, it is predicting plausible text about a dataset, which produces confident errors — dropped rows, misread dates, invented columns. Knowing which mode you are in is the single most important thing to establish before trusting any output.
Why are AI analysis errors particularly dangerous?
Because a wrong answer is presented identically to a right one. Human analysts hedge, show uncertainty, or say the data is messy. A language model produces fluent, confident prose regardless of whether the underlying calculation was correct, so there is no tonal signal to warn you. That makes verification a required step rather than an optional one, and it means the risk is highest exactly when the answer sounds most authoritative.
What is AI actually best at in data work?
Preparation and question generation, rather than producing conclusions. Cleaning, reshaping, joining datasets and writing the query or formula are tasks where mistakes are visible and easily corrected. Asking what questions a dataset could answer, what would disprove a hypothesis, or what confounding factor might explain a pattern is genuinely valuable and carries no arithmetic risk. The conclusion itself is the part that most needs a human to verify.
How do you verify an AI analysis?
Recompute one figure by hand, check that the row count matches what you supplied, and ask the model to state the assumptions it made. Then ask the same question phrased differently and see whether the answer holds. If two phrasings produce materially different numbers, neither is reliable. These four checks take a few minutes and catch the majority of errors, including the silent ones where rows were excluded or a date column was parsed incorrectly.
Is it safe to upload company data to an AI tool?
Only where the tool and the data agreement permit it. Customer records, personal data and unpublished commercial information should not go into consumer tools without a contract covering them, and this is one of the clearest lines a marketing AI policy should draw. Aggregated, anonymised extracts are usually sufficient for the analysis anyway, since most marketing questions concern patterns rather than individuals.
