Data Analyst

What this role actually does

The data analyst’s job is to turn a business question into a defensible answer. Not to build predictive models — that comes later — but to frame the question precisely, find or clean the data that speaks to it, apply the right statistical test, and communicate the result in a way that changes what someone does tomorrow.

Day-to-day: SQL queries at 9am, a pivot table at 11, a seaborn scatter plot at 2pm, a deck to stakeholders by 4. The skill is not any single tool. It is the judgment to choose the right statistical approach, interpret it without the seven standard mistakes, and translate it for a room that does not speak statistics.

Where this role sits relative to its neighbours.The data analyst is not a data scientist. You may never train a predictive model — and that is fine, because what you do is often harder to get right. Designing a sound experiment, choosing between parametric and non-parametric tests, correctly interpreting a confidence interval: these demand a rigour that much “data science” shortcuts. A bad model overfits. A bad analysis gives the company the wrong answer, which they then act on confidently.

The role is also not a data engineer. You are a consumer of pipelines, not a builder of them. Your work begins when the data is (roughly) available. In practice you will still need to clean it, reshape it, and understand its provenance — the boundary blurs daily.

What this stage is really training is statistical thinking: knowing your assumptions, checking them, quantifying uncertainty honestly, and knowing exactly what the data can and cannot say. That discipline is the foundation for every subsequent stage on this map.

Core concepts to master

Depth tags: Competent = can do independently, Production = reliable under pressure, Expert = can teach it and debug edge cases.

Unfamiliar with a term? The glossary defines every concept used across the map.

• The analysis lifecycle and question framingCompetent

  Every downstream mistake — wrong test, misleading chart, bad conclusion — traces back to a poorly framed question. Define it precisely first.

• Data cleaning and wranglingCompetent

  Real data is never clean. If you cannot clean it, you cannot analyse it; garbage in, garbage out is not a cliché, it is the job.

• Exploratory data analysis (EDA)Competent

  Models and tests are blind to patterns a well-made scatter plot reveals immediately. EDA is not optional warm-up — it is where the real story hides.

• Descriptive statistics — location, dispersion, shapeCompetent

  Mean, variance, skewness, IQR: these are the vocabulary of quantitative argument. Without them you are describing data in adjectives.

• Probability distributionsCompetent

  Every parametric hypothesis test assumes a distribution. Violating the assumption invalidates the test. Know which applies and how to check.

• Correlation versus causationProduction

  Confusing the two is the most consequential analytical mistake in business. A correlation justifies further investigation; only a controlled experiment justifies action.

• Inferential statistics — sampling, CIs, hypothesis testingProduction

  The formal apparatus for answering 'is this difference real?': t-tests, ANOVA, chi-square, non-parametric alternatives. The conclusion is meaningless if this is wrong.

• p-values and their seven common misinterpretationsExpert

  p < 0.05 does not mean the effect is real, important, or reproducible. Misreading p-values has misled entire research fields.

• Effect sizes and multiple-comparison correctionExpert

  Statistical significance says the effect is non-zero; Cohen's d and η² say whether it matters. Running 20 tests uncorrected gives you roughly one false positive for free.

• Experiment design and A/B testing basicsProduction

  The analyst who designs experiments properly — randomisation, power analysis, pre-registration — is ten times more valuable than one who only analyses completed studies.

• Data visualisation principlesCompetent

  Bad charts lie. Good charts persuade. Excellent charts reveal things the analyst missed. Tufte's ink-to-data ratio is discipline, not pedantry.

• DashboardingCompetent

  Eighty percent of analytical output is a dashboard. Building one that answers the right question and gets used is table stakes for the role.

• Storytelling with dataProduction

  An analysis that does not change a decision was a waste of time. Translating a statistical result into a narrative that drives action is a real, learnable skill.

• SQL for analytics — joins, window functions, CTEsCompetent

  SQL is how you access the majority of enterprise data. Window functions and CTEs are what separate the analyst from the spreadsheet user.

Mathematics required

Minimum — what you must understand to do this job properly

Probability basics:sample spaces, events, conditional probability, Bayes’ theorem at a conceptual level. Not the full measure-theoretic machinery — but enough to know why the t-test has a null distribution and what “sampling from a population” means.

Distributions: the normal distribution (and why the CLT makes it ubiquitous), the t-distribution (and why it has heavier tails), the chi-square and F distributions (and what they model). Know the shapes, the parameters, and the conditions under which each appears. You do not need to derive them — you need to know which one applies.

The logic of inference: what a null hypothesis is and why we test against it. What a p-value actually is (the probability of observing data at least this extreme, given the null is true — not the probability the null is false). What a 95% confidence interval is (a procedure that generates intervals containing the true parameter 95% of the time — not a 95% probability that this particular interval contains it).

Descriptive formulas: mean, weighted mean, variance, standard deviation, percentiles, IQR. These are vocabulary; fluency is expected.

Research-grade — where real understanding lives

Derive the t-statistic. Understand why dividing by s / √n gives a t-distribution rather than a normal — the randomness of s is the reason. This derivation makes the whole apparatus of inference legible.

The F-ratio in ANOVA geometrically. It is the ratio of between-group variance to within-group variance. When groups genuinely differ, the numerator is inflated; when they do not, both terms are just noise and their ratio follows the F-distribution under the null. Understanding this geometrically — not just computationally — transforms ANOVA from a black box into a sensible quantity.

The CLT stated properly.Not “big n → normal,” but: the distribution of the sample mean converges to normal at rate O(1/√n), regardless of the population distribution, under finite variance. Understand when it fails: heavy-tailed distributions, small samples from skewed populations, correlated observations.

Multiple comparisons in depth. Why running 20 independent tests at α = 0.05 yields roughly one false positive by chance. The Bonferroni correction (divide α by the number of tests) and why it is conservative. The Benjamini-Hochberg procedure and why it is often preferred — it controls the false discovery rate rather than the family-wise error rate, giving more power when many tests are run.

→ Probability & Statistics in the mathematics curriculum covers this material in full, with worked derivations — Bayes, MLE, CLT, and hypothesis testing.

Tools and engineering skills

Python: pandas and NumPy are the workhorses. matplotlib and seaborn for visualisation. scipy.stats for hypothesis tests. statsmodels for regression and rigorous statistical modelling. You should be comfortable with the full data manipulation lifecycle in pandas: cleaning, groupby, merge, reshape, time series indexing. Write clean, reproducible notebooks — run from top to bottom, dependencies explicit.

SQL: not just SELECT. Window functions (ROW_NUMBER, LAG/LEAD, RANK, running totals), common table expressions, subqueries, and the ability to reason about what a query is actually doing. Most production analytical data lives in a warehouse (BigQuery, Redshift, Snowflake); SQL is how you access it. Fluency is non-negotiable.

Excel / Google Sheets: you will use these regardless of your Python fluency. VLOOKUP, INDEX-MATCH, pivot tables, and conditional formatting are not optional when you work with non-technical stakeholders who live in spreadsheets.

A BI tool — Tableau or Power BI: the ability to build an interactive dashboard a stakeholder can self-serve is a genuine professional skill. Tableau Public is free and sufficient for building and sharing work publicly.

Git: yes, even for analysis work. Version-control your notebooks, your SQL scripts, your data cleaning steps. Analysis that cannot be reproduced is analysis that cannot be trusted — and cannot be corrected when someone finds a mistake six months later.

The project

A single analysis is a demonstration that you understand the tools. Four projects together — a rigorous statistical report, a SQL investigation, a live dashboard, and an A/B test post-mortem — are a demonstration that you are ready for the job. Do all four. There is no shortcut through the portfolio.

Expected total time: 10–14 weeks alongside the curriculum. Build them in order — each one uses skills from the previous.

Project 1 — the rigorous statistical report (4–5 weeks)

What it proves: your statistical thinking is trustworthy.

Choose a rich, multi-variable public dataset — World Bank development indicators, OECD health statistics, US Bureau of Labor Statistics employment series, or any domain you genuinely find interesting. Frame five distinct research questions, each requiring a different statistical approach: at minimum one t-test, one one-way ANOVA, one chi-square test of independence, one correlation analysis, and one regression. For every question, execute the full protocol:

1. State H₀ and H₁ in formal notation before touching the data.
2. Check all required assumptions — normality (Shapiro-Wilk + QQ plot), homogeneity of variance (Levene’s test), independence — and document the results. “It looks fine” is not a check. A Shapiro-Wilk W = 0.97, p = .23 is a check.
3. Run the appropriate test. If assumptions are violated, run the correct non-parametric alternative and explain why.
4. Report in APA format: F(2, 147) = 8.3, p < .001, η² = .10, indicating a medium effect.
5. Compute effect sizes (Cohen’s d, r, η², or φ depending on the test). A statistically significant result with d = 0.04 is not a finding worth acting on.
6. Apply Benjamini-Hochberg correction across all five tests. Adjust your conclusions accordingly.

Then run a multiple linear regression on one of the outcomes: report standardised and unstandardised coefficients, R², adjusted R², and the F-statistic. Check residuals (homoscedasticity, normality, influential points via Cook’s distance). Interpret every coefficient precisely: “holding all other predictors constant, a one-unit increase in X is associated with a 0.31-unit increase in Y (β = 0.31, 95% CI [0.18, 0.44]).”

The deliverable is a written report — not a notebook. A 15–20 page document: introduction (the research questions and why they matter), methods (every test, every assumption check, and why each was chosen), results (tables and figures, one finding per paragraph), discussion (what the findings mean, what they cannot mean, and the three most important limitations). The test: could this report be submitted to an applied statistics conference without embarrassment? That is the bar.

Project 2 — SQL + EDA investigation (2–3 weeks)

What it proves: you can work with real, messy, production-scale data.

Use a multi-table dataset in a SQL environment — Google BigQuery’s public datasets (Chicago taxi trips, Stack Overflow activity, US Census data) are free to query from the BigQuery console. Write SQL to answer 10 business questions of increasing complexity:

• Basic:“What is the average trip duration by day of week?”
• Intermediate:“What is the 7-day rolling average of daily revenue, and which weeks show a > 20% decline from the prior week?” — requires AVG() OVER (ORDER BY day ROWS 6 PRECEDING) and LAG().
• Advanced:“For drivers in the top quartile of Q1 revenue, what fraction remained in the top quartile in Q2? Produce the full quartile transition matrix.” — requires multiple CTEs, NTILE(4), and a self-join.

Then bring the dataset into Python. EDA: distributions, outliers (IQR fence and z-score, not just visual), missingness (how much, what pattern — MCAR vs. MAR vs. MNAR), correlations, surprises. Document every cleaning decision — not just what you did but why, and what the business consequence of getting it wrong would be. Close with a one-page written brief: three findings that would change a decision, addressed to a non-technical manager.

Project 3 — the live dashboard (2–3 weeks)

What it proves: you can communicate analysis to people who do not do analysis.

Build and publish a dashboard on Tableau Public (free tier, no paywall). Pick a real, specific question — not “here are some charts about the data” but “which US counties are most at risk for opioid mortality in the next two years?” or “which product categories are underperforming relative to inventory cost?” The question has to be specific enough that the dashboard answers it.

Requirements, every one of them:

• At least 6 distinct views connected by dashboard actions and filters — clicking a region in one view filters all others.
• At least one non-trivial calculated field (a rate, a ratio, a running total, a conditional category — not just SUM([Sales])).
• At least one parameter that lets the user adjust a threshold or change the grouping dynamically.
• Custom tooltips that provide context on hover — not the default dimension/measure dump.
• A written title and one-sentence narrative on each dashboard page stating what the viewer is looking at and what conclusion they should draw. If the chart requires explanation, the chart is not done.

Publish to Tableau Public with a link in your portfolio. The test: hand it to someone who did not build it, describe the question it answers, and ask them to find the answer without your help. If they cannot, revise until they can.

Project 4 — the A/B test post-mortem (2–3 weeks)

What it proves: you understand experimentation — the highest-value analyst skill at any technology company.

Design a realistic A/B test from scratch on a plausible business scenario: a checkout flow redesign, a recommendation algorithm change, a push notification copy change. Execute all five phases before touching any data:

1. Pre-registration. Write your hypotheses, your primary metric (what you are trying to move), two guardrail metrics (what must not get worse), your analysis plan, and your stopping rule. Lock this before generating a single row of simulated data.
2. Power analysis. Decide on a minimum detectable effect (MDE) that would be practically meaningful. Compute the required N at α = 0.05, power = 0.80 using scipy.stats. Then double it and explain why naive power calculations consistently undershoot.
3. Data simulation. Simulate the experiment — you control the ground truth. This is the point. Simulate three scenarios: (a) the treatment works as expected, (b) the treatment has no effect, (c) the treatment helps the primary metric but hurts a guardrail. The correct analysis should detect all three correctly.
4. Analysis. Two-proportion z-test for the primary metric. Multiple-testing correction across all three metrics. Novelty effect check: does the treatment effect decay across the experiment window (plot treatment effect by day of exposure)? Segment analysis: does the treatment differ for new vs. returning users, mobile vs. desktop? If you have a pre-experiment covariate, apply CUPED and compare the variance reduction.
5. Post-mortem document. Write it in the format a tech company would circulate: decision up front (ship / do not ship / iterate, with one-sentence reason), then the full analysis for anyone who goes deeper. One page of executive summary, appendix of statistical detail. Be precise about what you can and cannot conclude from an observational analysis versus a randomised experiment.

Then re-analyse the same simulated data using a Bayesian Beta-Binomial model. Compare conclusions. In which scenario do the frequentist and Bayesian approaches disagree? Why? Write a half-page explanation for a non-statistician.

Senior extension — for any one project

Present your findings to someone who is not a statistician. Record or take notes on the conversation. Revise the report or dashboard based on the questions they asked — those questions reveal exactly where your communication failed, and that is where the gap is. Iterate until a non-technical person can give you back the key finding in their own words.

Research extension — pre-registration in the wild

Before running Project 1, submit a pre-registration on the Open Science Framework (osf.io — free, public). State your hypotheses, your expected effect sizes, your analysis plan, and your stopping rule. Then execute the analysis exactly as registered — including any null results you did not expect. Write a one-page reflection: what did you expect, what did you find, and what would you pre-register differently next time? This is not academic formality. It is the discipline that separates the analysts whose conclusions you can trust from the ones who p-hacked their way to a story.

Resources

Ordered by when to use them. The highest-ROI combination at this stage is StatQuest + Practical Statistics — intuition and practice in parallel. OpenIntro Statistics is the best free alternative to Practical Statistics if cost is a constraint. Every free canonical option is flagged.

How you know you’re done

Exit criteria — you can answer “yes” to all of these:

• Given a two-sample comparison, you choose between a t-test, a Mann-Whitney U test, and their alternatives, and justify the choice based on sample size, distributional assumptions, and measurement scale.
• You can explain what a p-value is — and five things it is not — to someone without a statistics background.
• You can identify whether an A/B test result is underpowered and compute the required sample size for a given effect size and α.
• Given a multiple-comparison problem, you apply an appropriate correction and explain the trade-off between Type I (false positives) and Type II (false negatives) error.
• Your visualisations are Tuftian: ink encodes data, chart type matches the question, axes are honest, the title states the conclusion.
• An interviewer says “walk me through a statistical analysis you ran” and you have a real answer with precise methods, honest caveats, and a conclusion you stand behind.

Self-test questions

1. A coin flips heads 57 times in 100 tosses. Write the null and alternative hypotheses, run a two-sided binomial test, and interpret the result. What is the p-value, and what does it mean?
2. You run 20 independent A/B tests on a website. Three show p < 0.05. How many false positives would you expect by chance? What correction do you apply, and what does it cost you in statistical power?
3. What is the difference between statistical significance and practical significance? Construct a concrete example where one is present without the other.
4. A t-test requires that the data be normally distributed. Your sample has n = 150. Does this matter? Explain, with reference to the Central Limit Theorem.
5. You run a one-way ANOVA with three groups and get F(2, 147)  = 6.2, p = .003. What can you conclude? What can you not conclude? What do you run next?

Bridge to the next stage

The data analyst answers questions about what happened and whether a difference is real. The data scientist asks: can I predict what will happen next?

You carry forward everything: statistical rigour, SQL fluency, the habit of checking assumptions, and honesty about what the data can and cannot say. What changes is the scale of the mathematics and the reach of the toolset. Linear algebra and calculus — optional context at this stage — become essential. The scikit-learn API enters. You start thinking in features rather than variables, in training sets rather than samples, in predictive error rather than inferential error.

The biggest conceptual shift is from inference to prediction. Inference asks: what does this sample tell me about the population? Prediction asks: given these inputs, what is the output? They use the same probability theory. The questions are fundamentally different, and that difference shapes everything about how you evaluate success.

What to take into Stage 2: probability and distributions, solid; the discipline of not fooling yourself; Python and pandas, fluent; the habit of measuring and communicating uncertainty. These compound. They do not need to be relearned — only extended.