Work like a mid-level data analyst: define KPIs, forecast, run and analyse A/B tests, model analytics tables and turn stakeholder requests into recommendations.

Data Analytics in Practice

Write the request down exactly as it was given to you.

List the scoping questions you would ask: the decision, why now, what they expect, who will see it, deadline and minimum useful version, what success looks like.

Answer those questions: ask the real requester, or for the practice request write realistic answers yourself.

Restate the request in one or two sentences in your own words, including the decision and the deadline.

Write a one-page brief with: decision, two to four specific questions, out of scope, data sources and metric definitions, deliverable, deadline, assumptions and risks.

Estimate the effort in hours or days and note what a quicker partial version could deliver.

Share the brief with the requester (or a peer) and record any changes they ask for.

## Why it matters

"Can you pull the numbers on churn?" is a typical request. It could mean a single figure for a slide due in an hour, or a three-week investigation into why customers leave. Analysts who start querying immediately often deliver the wrong thing, late, and then do it again. Scoping, a short conversation and a one-page brief before the work starts, is the habit that most separates mid-level analysts from juniors. It saves more time than any SQL trick.

## Ask about the decision, not the data

The most useful question is: **"What will you do differently depending on the answer?"** If the answer is "nothing", the request may not need doing. If it is "we will decide whether to offer annual discounts", you now know what the analysis must inform.

Other good questions:

- **Why now?** Something triggered this: a board meeting, a drop in a metric, a competitor launch.
- **What do you expect to find?** Their hypothesis tells you where to look first, and what would surprise them.
- **Who else will see it?** An executive slide needs a different format from a team working session.
- **When do you need it, and what is the minimum useful version?** A rough answer on Thursday may beat a perfect one next month.
- **What does success look like?** A number, a chart, a recommendation, a dashboard?
- **What do you already know or have?** Earlier reports, definitions, data sources.

Repeat back what you heard: "So you want to know whether customers on monthly plans churn faster than annual ones, to decide by the 15th whether to push annual discounts. Is that right?"

## The analysis brief

Write it down, even briefly, and share it for agreement. A one-page template:

```text
Title:        Monthly vs annual plan churn
Requester:    Priya (Head of Growth)        Analyst: you
Decision:     Whether to promote annual plans with a discount next quarter
Questions:    1. What is 90-day churn for monthly vs annual customers?
              2. Does the gap hold within each acquisition channel?
              3. What revenue difference would a 10-point shift to annual make?
Out of scope: Reasons for churn (survey analysis), pricing elasticity
Data:         subscriptions, payments tables; churn = no active plan 30 days after period end
Deliverable:  3-slide summary + query in the team repo
Deadline:     Draft Thursday 12th, final Monday 16th
Assumptions/risks: plan-switchers counted by plan at signup; 2025 data before
                   the price change excluded
```

The **out of scope** line is as important as the questions. It protects you from scope creep and makes trade-offs explicit.

## Size and prioritise

Estimate effort roughly (hours, days, weeks) and say it. If the team has many requests, a simple priority rule helps: **impact of the decision × urgency ÷ effort**. Many teams run an intake form or ticket queue for requests so they are visible and comparable. When you must say no or "not yet", offer an alternative: an existing dashboard, a quicker partial answer, or a later date.

## Worked example: a vague request

> "Marketing says the new campaign is doing great. Can you confirm?"

Scoping questions reveal: the decision is whether to double the campaign budget next month; "doing great" refers to clicks; the real question is whether the campaign brought **incremental** paying customers. The brief narrows the work to: paid conversions attributed to the campaign, compared with a matched period or a holdout region, with cost per acquired customer. Out of scope: brand awareness. Deadline: before the budget meeting on the 20th.

Without scoping, you might have delivered a nice click chart that answered nothing.

## Common mistakes

- Starting work on the literal request without asking about the decision.
- Agreeing verbally and never writing it down.
- No deadline or minimum version, so the work expands.
- Accepting a metric name ("active users") without agreeing its definition.
- Not checking back mid-way when findings change the question.

## Quick recap

- Ask what decision the answer will change, why now, and when it is needed.
- Repeat the request back in your own words.
- Write a one-page brief: decision, questions, out of scope, data, deliverable, deadline, assumptions.
- Estimate effort, prioritise openly, and offer alternatives when you say no.

## Try it

The **Do** tab walks you through turning a real or practice request into a written brief.


Turn a vague stakeholder request into a clear analysis brief with a decision, questions, scope and deadline.

Scoping requests

How to Communicate with Stakeholders | Google Data Analytics Certificate

Data Analysis Workflow--How to Answer Requests(Good and Bad)

Write the recommendation in one sentence: the action, the scale and the timing.

Write two or three supporting reasons, each with its key number and the source of that number.

Translate the expected impact into business terms (money, time, customers or risk) and give it as a range.

List at least two specific caveats and state your confidence level (high, medium or low) with the reason.

Describe two or three options, including doing nothing, with the main trade-off of each.

Write the ask: who needs to decide what, by when, and the next step if they agree.

List the five hardest questions a sceptic might ask and write a one-line answer to each.

Deliver it in five minutes or less to a peer, mentor or study group and note their questions.

## Why it matters

Junior analysts report findings. Mid-level analysts make **recommendations**: they say what the organisation should do, why, what it will cost, and how confident they are. This is uncomfortable at first, because recommendations can be wrong. But stakeholders hired you to reduce uncertainty in their decisions, and a list of "interesting findings" pushes the hard part back to them. A good recommendation is also honest about its limits, which is what makes people trust the next one.

## The structure: answer first

Use a top-down, "answer first" structure (often called the pyramid principle, from Barbara Minto):

1. **Recommendation:** one sentence. "Shift 30% of the paid social budget to search next quarter."
2. **Why:** two or three supporting points, each with its key number.
3. **Evidence:** charts and details behind each point, available but not leading.
4. **Caveats and risks:** what could make this wrong.
5. **Options considered:** including doing nothing.
6. **The ask and next step:** the decision you need, from whom, by when.

Busy readers who stop after line 1 or 2 still get the message.

## Worked example

> **Recommendation:** Move 30% of the paid social budget (about $45k per quarter) to paid search, starting next quarter, and review after eight weeks.
>
> **Why:**
> 1. Search brings paying customers at **$38 each vs $71** from social (last two quarters, last-click attribution).
> 2. Search customers keep paying longer: **62% vs 48%** still subscribed after 90 days.
> 3. Search volume is not saturated: our impression share is 41%, so extra budget can buy more clicks at similar cost.
>
> **Caveats:** Last-click attribution undercounts social's role earlier in the journey, so true social value is higher than shown. Search costs per click may rise as we spend more. We do not have a controlled test yet.
>
> **Options:** (a) keep the split (no risk, no gain); (b) move 30% now (recommended); (c) run a four-week geographic holdout test first (slower, more certain).
>
> **Ask:** Approve option (b) with an eight-week review, or option (c) if you prefer certainty over speed. Decision needed by the 28th for next quarter's budget.

Notice that the caveats are specific, and the options let the decision-maker choose their own risk level.

## Quantify impact and confidence

- Translate metrics into the organisation's language: money, time, customers, risk. "+1.5 points conversion" becomes "about 230 extra orders a month".
- Give **ranges**: "saves $20k to $35k per quarter".
- State **confidence** plainly: high (controlled experiment, large sample), medium (consistent observational evidence), low (early signal, small sample). Explain why.
- Separate **what the data shows** (association) from **what you infer** (cause), unless you have an experiment.

## Anticipate questions

Before presenting, list the five hardest questions a sceptic would ask and prepare short answers:

- "How do you know it is not seasonal?"
- "What happens if competitors respond?"
- "What does the finance team's number say?"
- "What would make you change your mind?"
- "What does it cost to be wrong?"

Talk to key stakeholders **before** the meeting. Nobody likes being surprised by a recommendation in front of their boss, and early feedback catches gaps.

## When the data does not support what people hope

Sometimes your analysis contradicts a leader's favourite idea. Stay factual and calm: show the evidence, acknowledge what you might be missing, and suggest a way to resolve it (a test, more data). Your job is to make the decision better informed, not to win the argument, and not to bend the numbers.

## Common mistakes

- Presenting the analysis in the order you did it.
- Hedging so much that there is no recommendation.
- Caveats that are vague ("data may have issues") instead of specific.
- No "do nothing" option, so the comparison is unclear.
- Ending without a clear ask and deadline.

## Quick recap

- Lead with the recommendation, then two or three reasons with numbers.
- Quantify impact in business terms, with ranges and a confidence level.
- Be specific about caveats; offer options including doing nothing.
- End with a clear ask, owner and deadline; pre-wire key stakeholders.

## Try it

The **Do** tab has you write and deliver a one-page recommendation from an analysis you have done.


Present a clear recommendation backed by evidence, with honest caveats, options and a specific ask.

Making recommendations

7 Effective Tips for Presenting Data at Work!

Read five job postings for analyst roles you want and list the skills and tools they share.

Choose a question tied to a decision and a public dataset with a clear licence. Write a one-page brief (Module 4, lesson 1) for it.

Load and clean the data with SQL and/or Python. Record every cleaning decision and metric definition in a notes file.

Model at least one clean analysis table (for example a fact table with one or two dimensions) and add a few data quality checks.

Do the analysis: at least three findings, using techniques from this and earlier courses (aggregation, cohorts, a forecast or a comparison).

Make one decluttered chart per finding with a takeaway title, and optionally a small dashboard in a free BI tool.

Write the case study: summary, context, data, method, findings, recommendation, limitations and how to rerun it.

Publish it: a GitHub repository with a clear README (and optionally a blog post or dashboard link). Check that notebooks run top to bottom and links work.

Ask one person to review it and fix what confused them.

Practise a two-minute spoken summary covering the question, one hard problem you solved, the main finding and what you would do next.

## Why it matters

For data analyst roles, a portfolio often matters as much as a degree or certificate, especially when you are changing careers. Hiring managers want evidence that you can do the whole job: take a fuzzy question, get and clean data, analyse it correctly, and communicate a recommendation. One complete, well-written case study shows that far better than ten notebooks of tutorial exercises. It also gives you something concrete to talk about in interviews.

Real-world context: many data analyst roles ask for a bachelor's degree (statistics, economics, computer science, business or similar), but employers increasingly accept a strong portfolio and relevant experience. Optional certificates such as the Google Data Analytics Certificate or Microsoft's Power BI Data Analyst (PL-300) can help you get past screening; requirements and exam details change, so check the official sites (grow.google, learn.microsoft.com). Checked on 2026-10-23.

## What makes a strong case study

- **A real question with a decision attached.** "Which neighbourhoods should a bike-share operator add stations to?" beats "Exploring the bike-share dataset".
- **Real, messy data.** Public sources: government open data portals (data.gov, data.gov.uk, Eurostat), city open data, Kaggle datasets with clear licences, Google BigQuery public datasets, Our World in Data. Avoid the most overused datasets (Titanic, Iris) unless you add something new.
- **The full workflow:** question, data, cleaning, analysis, visualisation, recommendation, limitations.
- **Your judgement on display:** why you chose a metric, how you handled missing data, what you ruled out.
- **Skills the job asks for:** SQL, Python or spreadsheets, a BI dashboard, and clear writing. Check five job postings you would apply for and match them.

## A structure for the write-up

Use this outline for the README or blog post:

1. **Summary (3 to 5 sentences):** question, approach, main finding, recommendation.
2. **Context and question:** who would use this and what decision it supports.
3. **Data:** sources with links and licences, time range, size, key fields, and known issues.
4. **Method:** cleaning steps, metric definitions, analysis techniques (cohorts, a forecast, a test analysis), and why.
5. **Findings:** three or four, each with one decluttered chart and a takeaway title.
6. **Recommendation:** what to do, expected impact, confidence.
7. **Limitations and next steps:** what you could not do and what you would do with more data or time.
8. **Repository guide:** how to rerun it (requirements file, SQL scripts, notebook order).

## Where to publish

- **GitHub repository:** code, SQL, a clean README with the write-up and charts. Make sure notebooks run top to bottom.
- **A short article** on a personal site or blog platform, written for a non-technical reader.
- **An interactive dashboard** in Looker Studio or Tableau Public (public data only) linked from the README.
- **A one-page PDF or slide summary** to attach to applications.

Never publish data from an employer or school, or any personal information. Respect dataset licences and cite sources.

## Worked example outline

> **Question:** Where should a city bike-share add 10 new stations to increase rides?
> **Data:** 12 months of public trip records (about 3 million rows) plus station locations and census population by area.
> **Method:** SQL in DuckDB to aggregate trips by station and hour; a star schema with `fact_trips`, `dim_station`, `dim_date`; Python for demand per resident by neighbourhood; a simple seasonal forecast of next summer's demand.
> **Findings:** stations within 500 m of rail stops have 2.4× the rides; three dense neighbourhoods have no station within 800 m; summer demand is forecast to grow 8% to 12%.
> **Recommendation:** prioritise the three unserved neighbourhoods near rail; expected +4% to +7% total rides.
> **Limitations:** no data on failed rental attempts (empty docks), so demand at full stations is undercounted.

## Interview-ready

Be ready to explain in two minutes: the question, one hard data problem you solved, the key finding and what you would do differently. Interviewers often ask "why did you choose that metric?" and "what would you do with more time?"

## Common mistakes

- Code without a narrative, or a narrative without the code.
- No question, just "exploration".
- Default, cluttered charts.
- Overclaiming causation from observational data.
- Notebooks that do not run, broken links or missing data instructions.
- Ten small projects instead of one or two complete ones.

## Quick recap

- One end-to-end case study with a real question beats many tutorials.
- Use real public data with clear licences, and show your judgement.
- Write it up with summary, data, method, findings, recommendation and limitations.
- Publish code and write-up, keep private data private, and rehearse a two-minute explanation.

## Try it

The **Do** tab breaks the case study into steps you can complete over a few weeks.


Plan, complete and publish an end-to-end analytics case study that shows employers how you work.

Portfolio case study

Building Your First Data Analytics Portfolio: A Step-by-Step Guide (2024)

Learn how to SOLVE a data analytics case study problem

Scope requests into clear briefs, present recommendations with honest caveats, and publish a portfolio case study.