← Back to the learning paths
Apply AI to your jobIntermediate → Advanced

AI-Augmented Data Analyst

Answer the question that was actually asked — and know when your answer is wrong.

The job of an analyst is not to produce a number. It is to produce a number someone can bet on, and to say clearly when they should not. That distinction is what this path is organised around, and it is why the AI part comes third rather than first. A model that writes SQL faster than you is genuinely useful — it will also confidently join two tables on a key that means different things in each, hand you a result that is plausible, well-formatted and wrong, and never mention that it guessed. You cannot supervise what you cannot do slowly by hand, so you start with the unglamorous foundations: query languages, and the cleaning work that consumes most of a real analyst's week and appears in none of the tutorials. Then statistics, taught defensively — not to compute a p-value but to know why the p-value you computed after looking at the data means nothing. Then the copilot, used the way a senior analyst uses a fast junior: give it the boring work, check everything, never let it touch the definition of the metric. And finally the part that actually determines whether your work matters, which is the twelve minutes in a meeting where you have to say what you found and what you are not sure about, to people who will decide either way.

LevelIntermediate → Advanced
Estimated duration5-7 months
Phases3

What you will learn

SQL beyond SELECT: joins, windows, CTEsData cleaning and reconciliationDefensive statistics and uncertaintyExperiment reading and causal cautionVisualisation that does not misleadAI copilots under supervisionMetric definition and governanceExecutive communication of findings

Prerequisites

  • Comfort with spreadsheets and basic arithmetic
  • Some exposure to SQL or any query language
  • Access to a real dataset with real problems in it

Where it leads

  • Data Analyst
  • Business Intelligence Analyst
  • Analytics Engineer
  • Product or Marketing Analyst

Phases

Phase 1 — The unglamorous foundations

Get the data, and get it right — the two things that consume most of the job and appear in none of the tutorials.

Estimated duration · 8-10 weeks

SQL that survives a real schema

Tutorial SQL runs on three clean tables. Production SQL runs on forty tables named by someone who left in 2019, where the same customer appears three times with different identifiers. The skills that matter are joins you can reason about, window functions, and the discipline of checking your row count after every join — because a silent fan-out that doubles your revenue figure will not raise an error, it will raise a promotion until someone notices.

Topics covered

Joins you can reason about, and fan-out you can detectWindow functions: running totals, ranks, period comparisonsCTEs and readable decomposition of long queriesGrain: what one row actually representsNULL semantics and the aggregates they silently breakReading an unfamiliar schema without documentationQuery performance you should care about, and the rest

What you will build

  • Reconstruct a metric your company already reports, from raw tables, and reconcile to the last decimal — then document every discrepancy you found
  • Write one query with three window functions replacing a colleague's spreadsheet, and prove they match on twelve months of data
  • Take a query that returns too many rows and find the fan-out; write down the join key that lied

Cleaning: the actual job

Nobody puts cleaning in the job description and everybody spends their week doing it. Duplicates that are not exact duplicates, dates in four formats, a field that changed meaning when the CRM was migrated, and a "country" column with eleven spellings of the same country. The skill is not the transformation — it is the forensic instinct to ask why a value looks like that, because the answer is usually an event in the business, not a typo.

Topics covered

Profiling a dataset before trusting a single rowFuzzy duplicates and entity resolutionMissing data: absent, zero, unknown, and refused are four thingsOutliers that are errors vs outliers that are the storyWhen a field changed meaning: schema archaeologyReproducible cleaning scripts instead of manual editsDocumenting every judgement call you made

What you will build

  • Profile a real dataset and publish a one-page data quality report naming the five defects that would change a conclusion
  • De-duplicate a customer table where the duplicates are not exact, and defend your matching rule against a colleague
  • Rewrite a manual cleaning routine as a reproducible script, and show it produces the identical result twice

Phase 2 — Honest statistics

Learn enough statistics to know when you are fooling yourself — which is the only reason to learn statistics.

Estimated duration · 8-10 weeks

Uncertainty, and saying it out loud

Every number you deliver has a range around it, and the professional act is stating that range instead of hiding it behind two decimal places. False precision is the most common lie in analytics and it is almost always unintentional: a segment with eleven customers produces a conversion rate that looks like a fact and is closer to a coin flip. You will learn to compute the interval, and more importantly to refuse the question when the data cannot answer it.

Topics covered

Distributions before averages: why the mean often liesConfidence intervals as a communication tool, not a ritualSample size: how small is too small to speakVariance and why a stable average can hide chaosBootstrapping when the formula does not applyFalse precision and the tyranny of two decimalsThe professional sentence: "the data cannot answer that"

What you will build

  • Take a dashboard from your company and add an honest interval to its three headline numbers — then note which ones become meaningless
  • Find one segment in a real report whose sample is too small to support the claim being made, and write the correction
  • Reproduce a reported average, then show the distribution behind it and explain what the average hid

The traps: correlation, p-hacking, and who is missing from your data

Every analyst knows correlation is not causation and every analyst violates it by Thursday, because the pressure in the room is for a cause. Add p-hacking — slicing until something is significant, which it always eventually is — and survivorship bias, where your dataset quietly contains only the people who stayed. These three ruin more analyses than any technical error, and none of them announce themselves. You learn them as reflexes, not as trivia.

Topics covered

Confounders and the third variable you did not measurep-hacking: why a hypothesis after the fact is not a hypothesisMultiple comparisons and the segment that was always going to winSurvivorship bias: who your dataset silently excludesSimpson's paradox on your own numbersReading an A/B test honestly, including the ones you stopped earlyWhen an observational answer is the only one available

What you will build

  • Find a causal claim in a real internal report and list the three confounders that were never ruled out
  • Deliberately p-hack a dataset until you find a "significant" result, then write the page explaining why it is garbage
  • Identify a dataset in your company that excludes churned users, and quantify how much the headline metric moves once you add them back

Phase 3 — Copilot and delivery

Use AI where it genuinely accelerates you, then deliver findings people can act on without being misled.

Estimated duration · 8-10 weeks

AI as a copilot you supervise

A model will write in ten seconds the query that took you twenty minutes, and that is a real gain you should take. It will also invent a column name, join on a key that means something different in each table, and describe its output with total confidence. Treat it as a fast junior: hand it the boring work, verify every result against a number you computed yourself, and never let it define the metric — because a wrong definition scales silently across every dashboard downstream.

Topics covered

Where a copilot genuinely saves hours: boilerplate, regex, refactoringWhy it hallucinates schema, and how to catch it every timeGiving it the schema and the grain, not just the questionVerifying generated SQL against a hand-computed controlExploratory analysis at speed, with a human hypothesisThe metric definition it must never touchWhat you must never paste into a tool you do not control

What you will build

  • Race the copilot on five real queries: record time saved and every error it made — publish both columns
  • Build a verification habit: for ten generated queries, compute one control number by hand and log the mismatches
  • Write a one-page team policy on what may and may not be pasted into an external AI tool, with three concrete examples

Visualisation and the twelve minutes that decide

Your analysis is worth exactly what survives the meeting. That means a chart whose axis starts at zero unless you say why it does not, a headline that states the finding rather than naming the variables, and the discipline to lead with the answer instead of the methodology nobody asked about. It also means saying what you are unsure of out loud — the credibility you spend admitting one limitation buys you the room for the next three findings.

Topics covered

Choosing the chart the question demands, not the one you likeTruncated axes, dual axes, and the other honest-looking liesA headline that states the finding, not the variablesAnswer first, method on requestStating your uncertainty without losing the roomThe recommendation is part of the analysis, not an add-onMetric definitions as governed artefacts, not folklore

What you will build

  • Redesign a misleading chart from your own company and write the two sentences explaining what the original implied and why it was false
  • Deliver a real finding in twelve minutes to a non-technical stakeholder, and capture the decision it produced in writing
  • Publish a metric dictionary for five contested indicators, with the exact SQL and the named owner of each definition

Questions

If AI can write SQL, why should I still learn it?

Because the model writes SQL that runs, and running is not the same as correct. It will join on a column called customer_id in two tables where the identifier means different things, return a number, and format it beautifully. Nothing errors. You cannot audit that unless you can read the query and know what the grain of each table is — and if you cannot audit it, you are not the analyst, you are a courier carrying a number you do not understand into a room where someone will spend money on it. The copilot genuinely doubles your speed on work you already know how to check. It does nothing for work you cannot check, except make the mistake arrive faster and look more polished.

Do I need heavy mathematics for this path?

No, and the emphasis is deliberately elsewhere. You need to be comfortable with proportions, distributions and the idea of a range around an estimate — that is roughly secondary-school level plus a way of thinking. What this path demands instead is intellectual honesty, which is harder to acquire than a formula. The failures we see in real analyses are almost never a miscalculated statistic; they are a question answered with data that could not answer it, a segment too small to speak, a cause asserted where only a correlation existed. If you want to build predictive models you will eventually need linear algebra and calculus, and the Machine Learning path is where that lives. For analysis, the bottleneck is judgement.

Why does cleaning get a whole step? It sounds like grunt work.

It is grunt work, it is most of the job, and it is where the analysis is actually won or lost. Every course skips it because clean example data makes for a satisfying lesson, and every analyst then discovers that their first real week is spent finding out why the same client appears three times and why revenue dropped to zero for one month in 2021. Those are not annoyances to get past — they are the analysis. The month of zero revenue is a system migration, and if you paper over it with an average you have deleted a fact about the business. The people who are good at this are not the ones who know the fanciest transformation; they are the ones who ask why a value looks the way it does, and keep asking until they get an answer that involves a human decision rather than a shrug.

Related paths

Want to walk this path with a coach and a cohort?

Discover the 212AY Academy →