Data Analyst
Data Analytics
Turn raw data into decisions a product team will actually act on. Over 10 weeks you'll work with real business datasets, write production-quality SQL, build dashboards stakeholders will use weekly, and present findings to product and engineering owners. The work is half technical, half communication. You'll learn the SQL patterns that scale, the BI conventions that prevent stale numbers, and the storytelling structure that gets your insight onto the roadmap. Topics covered: advanced SQL, exploratory data analysis, dashboarding (Metabase / Looker patterns), A/B test analysis, cohort and funnel analysis, executive communication, statistical fundamentals.
Time commitment
8-12 hours per week
Prerequisites
Basic SQL (SELECT, WHERE, JOIN, GROUP BY). Comfort with spreadsheets at an intermediate level. Willingness to write — clear analyst work is mostly clear writing.
You'll leave with
Published dashboards plus 3-5 short analysis writeups answering real product questions, framed for a non-technical product audience. A muscle memory for going from ambiguous question to defensible recommendation in a week.
What you receive
Structured weekly plan
Clear objectives, defined tasks, and concrete deliverables for every week of the program.
AI-led evaluation
Every submission is reviewed across technical proficiency, ownership, communication, and learning.
Human expert on request
Request a human expert reviewer for advanced topics, escalations, or specialised guidance.
Verifiable credentials
Formal offer letter on approval. Verifiable experience letter on completion.
The 12-week roadmap
Every week is planned before you start.
- Week 1
SQL fluency check + first dashboard
Establish your SQL baseline against a real dataset. Write production-style queries that answer ambiguous business questions, then ship one focused dashboard with 3-4 charts that tell a coherent story. Week 1 sets your craft baseline; weeks 2-10 build on it.
What you'll do
- Connect to the practice dataset your mentor will share
- Write 5 SQL queries answering open-ended product/business questions (one query per question)
- Install Metabase or Apache Superset locally; connect it to the dataset
- Build a dashboard with 3-4 charts that answers ONE specific product question
- Write a one-paragraph narrative under the dashboard explaining what it shows
You hand in: SQL query file with comments explaining each query's intent, 2-3 dashboard screenshots, and the written narrative.
- Week 2
Cohort + funnel analysis on a real product question
Pick one substantive product question (retention, activation, conversion — your choice with your mentor) and answer it with both a cohort analysis and a funnel breakdown. Present your findings as if to a product manager who has 5 minutes — chart + one sentence per insight + a recommendation. This is the work pattern of the role.
What you'll do
- Agree on the product question with your mentor; write a 2-line problem statement
- Write the cohort SQL — pick a sensible cohort definition (signup week, first action, etc.)
- Write the funnel SQL — define each step, handle drop-offs cleanly
- Build the visuals in your dashboard tool; iterate until each chart needs no caption to read
- Write a 1-page summary: question → what you found → recommended next step
You hand in: Updated SQL files, dashboard screenshots, and the 1-page summary written for a product audience (not for your mentor).
- Week 3
Metric definitions that survive contact with a second person
Pick three metrics your organisation would argue about and define them precisely enough that two analysts writing independent SQL would get the same number. Then test that claim by having someone actually try.
What you'll do
- Choose three metrics that sound obvious and are not (active user, conversion, churn)
- Write each definition: numerator, denominator, time grain, exclusions, edge cases
- Implement each as a reusable SQL snippet or view
- Have a peer implement one from your written definition alone
- Reconcile any difference and tighten the wording that caused it
You hand in: A metric dictionary, the implementations, and a note on where your peer's number differed and why.
- Week 4
Experiment design before anyone runs the experiment
Design an A/B test properly: hypothesis, primary metric chosen in advance, sample size calculated rather than guessed, and a stopping rule written down before any data arrives. Most bad experiment results are decided at this stage, not at analysis.
What you'll do
- Write a falsifiable hypothesis with a single pre-registered primary metric
- Calculate the sample size for a minimum detectable effect you would act on
- Define the stopping rule and commit to it in writing
- List the guardrail metrics that would make you stop early
- Write the analysis plan before seeing any data
You hand in: The experiment design document, the power calculation with its assumptions, and the pre-committed analysis plan.
- Week 5
Analysing a result, including a disappointing one
Analyse experiment data, report the effect with its uncertainty, and resist the pull towards a story. A flat result reported clearly is more valuable than a significant one found by looking at twelve segments.
What you'll do
- Analyse the primary metric first and write the answer down before looking further
- Report the effect size with a confidence interval, not just a p-value
- Check the guardrail metrics
- Run segment analysis and explicitly label it exploratory, not confirmatory
- Write the summary a decision-maker can act on in five minutes
You hand in: The analysis notebook, the effect with its interval, and a summary that states plainly what you do and do not know.
- Week 6
Data quality from the analyst's side of the fence
Take a dataset you trust and find out where it lies. Every analyst inherits data with quiet defects, and catching them before they reach a slide is a large part of the job.
What you'll do
- Profile a working dataset: nulls, duplicates, ranges, cardinality, orphaned keys
- Find at least three genuine quality issues and quantify each one
- Trace one back to its source and identify the cause
- Write validation queries that would have caught them
- Report the findings to whoever owns the upstream data
You hand in: A profiling report, the three issues with their impact quantified, the validation queries, and the note you sent upstream.
- Week 7
Forecasting, and being honest about the interval
Produce a forecast that carries its uncertainty visibly. A single line into the future is worse than useless when someone plans headcount against it; the interval is the deliverable.
What you'll do
- Pick a metric with genuine seasonality and enough history to matter
- Build a baseline forecast first — naive or seasonal naive
- Build a better model and beat the baseline on a held-out period, or admit you did not
- Produce prediction intervals, not just point estimates
- Write what would make this forecast wrong
You hand in: The forecast with intervals, the baseline comparison on held-out data, and the stated failure conditions.
- Week 8
Self-service: making your work reusable by someone else
Turn one-off analysis into something a non-analyst can answer their own questions with — and watch a real person use it without helping them.
What you'll do
- Identify a question you are repeatedly asked
- Build a parameterised dashboard that answers it without you
- Document each filter and metric in the tool itself, not in a separate doc
- Watch someone use it for ten minutes and say nothing
- Fix everything they got stuck on
You hand in: The dashboard, your notes from the observation session, and a list of what you changed as a result.
- Week 9
Communicating to people who will not read the appendix
Present a finding to a non-technical audience. The analysis is done; this week is about whether the decision actually changes, which is the only measure that matters.
What you'll do
- Take your strongest finding and write the one-sentence version first
- Build five slides maximum: question, method in a line, finding, caveat, recommendation
- Remove every chart that does not change what someone would do
- Present it live and field the hard questions
- Write down which question you could not answer
You hand in: The deck, a recording or written account of the session, and the list of questions you could not answer.
- Week 10
Segmentation without fooling yourself
Build a segmentation that is actually actionable. Most segmentations are statistically valid and operationally useless; the test is whether anyone can do something different for one segment tomorrow.
What you'll do
- Choose the behavioural dimensions that plausibly drive different treatment
- Build the segmentation and check stability across two time periods
- Profile each segment in plain language a marketer would recognise
- Propose one concrete different action per segment
- Estimate the value of acting, and state the assumption that estimate rests on
You hand in: The segmentation, the stability check, the plain-language profiles, and the proposed actions with sizing.
- Week 11
The analysis you would defend under scrutiny
Take your best work from the program and have it genuinely challenged. Then fix what the challenge exposed, which is the part most portfolios skip.
What you'll do
- Pick your strongest analysis and write down its three weakest assumptions
- Have a peer or mentor attack the methodology in a review session
- Re-run the analysis addressing the most serious objection
- Record whether the conclusion survived
- Add a limitations section you would be comfortable reading aloud
You hand in: The revised analysis, a record of the critique, and the limitations section.
- Week 12
Portfolio: the work, not the tooling
Assemble a portfolio that shows judgement rather than tool familiarity. Anyone can screenshot a dashboard; what is scarce is evidence that you framed an ambiguous question well and knew what your answer could not support.
What you'll do
- Select three pieces that show range: exploratory, causal, and operational
- Write each up as question, approach, finding, limitation, and what happened next
- Include one piece where the answer was inconclusive and you said so
- Make every dataset and query reproducible by a stranger
- Write a short reflection on what you would do differently now
You hand in: The published portfolio with three documented analyses, reproducible sources, and the reflection.