It's your first week on the data team at GreenWheels, a small e-bike share startup. Your manager drops a message: 'We ran a two-week pilot in one neighbourhood. Here's the trip log — can you take a look and tell me one thing we can trust before the Monday standup?' No fancy model, no dashboard. Just you, a messy little table, and the exact skills you've spent this whole track building. This project is that task. You'll walk a real dataset from first glance to one honest, defensible sentence — the way actual junior data work begins.
What you'll learn
What
This is a guided end-to-end mini-project. You'll take a single small dataset — the GreenWheels pilot trip log — and carry it through the full Foundations workflow: read it, identify each column's data type, assess its quality, check for bias, compute a few basic statistics, and write up one insight you can defend.
Why
Every skill so far has been practised in isolation. Real data work is the whole chain at once, on a table nobody has cleaned for you. This is where the pieces click together — and where you learn the most important professional habit: reporting what the data can honestly support, and flagging what it can't.
Where it's used
This is the shape of a junior data analyst's daily work: a stakeholder hands you a raw export and a vague question, and you turn it into a trustworthy answer with clearly stated caveats. Do this well and you're doing the job.
Where this runs in production
Micro-mobility companies test in one neighbourhood before scaling. The first analysis of a pilot log — exactly this task — decides whether the idea is worth expanding.
Junior analysts are constantly handed a raw export and asked for a quick read. Doing it rigorously — with caveats — is what earns trust for the bigger projects.
Senior data people are known less for flashy conclusions than for knowing exactly how far a dataset can be trusted. This project trains that instinct from day one.
trip_id rider_type age minutes distance_km rating T-01 member 31 12 3.1 5 T-02 member 27 8 2.0 4 T-03 casual NULL 15 3.6 5 T-04 member 45 9 2.2 4 T-05 casual 52 6 1.4 3 T-06 member 31 12 3.1 5 <-- identical to T-01 T-07 member 38 210 4.0 5 <-- 210 minutes? T-08 casual 24 11 2.7 NULL T-09 member 29 7 1.8 4 T-10 casual 63 14 3.3 2 T-11 member Member 10 2.5 4 <-- 'Member' in age? T-12 casual 41 9 2.1 3
Twelve rows, six columns. It looks tidy at a glance — but notice the flags on the right. A first glance is never the last word; the job now is to read it properly and stress-test it.
1) Read — what is one row, and what does each column mean? 2) Types — numerical or categorical for each column? 3) Quality — missing values, duplicates, outliers, inconsistencies? 4) Bias — how was this data collected, and who's missing? 5) Statistics — a few honest summaries of the key columns. 6) Report — one insight you can defend, with caveats. You'll do each step in the sections that follow.
A good mechanic doesn't tell you the car is great because it started once. They pop the hood, check the fluids, and tell you what's solid and what's worn. Your job with this dataset is the same: not to celebrate that it 'has data', but to inspect it honestly and report what's trustworthy and what needs a caveat. Enthusiasm is cheap; a careful read is what your manager is actually paying for.
As you spot problems — the 210-minute trip, the duplicate, the 'Member' typed into an age — resist the urge to quietly delete or 'correct' them and move on. Recall the data-quality lesson: every fix is a decision that changes the result, and it must be visible. In this project you'll note each issue and how you'd handle it, not erase it. A silent fix is how a wrong number sneaks into a Monday standup.
Click each stage to see what you're doing and which earlier lesson it draws on. This is the path every row of the GreenWheels log takes to become a defensible sentence.
Go column by column and label each as numerical, categorical, or ordinal.
rider_type sorts each trip into a group, so it's categorical. age, minutes, and distance_km are measured quantities you can do arithmetic on. rating's 1–5 are ordered categories — you can rank them but the gaps aren't guaranteed equal.
Your task
Now run the final summary yourself. The messy trips have already been reduced to the clean, valid minutes below (duplicate dropped, 210-minute outlier excluded). Compute the median trip length and count the rider types, then print a one-line finding. Fill the blanks and run it.
Median trip minutes: 9 Members: 5 Casual: 4 Finding: typical trip ~ 9 min; caveat: tiny, biased sample
Write your solution in the editor on the right, then hit Run.
In the GreenWheels log, what is the unit of observation (what does one row represent)?
The rating column holds values 1–5. How is it best classified?
What's the right way to handle it?
How should you respond?
Data-quality check: given a list of ages where one entry is the string 'Member', print how many entries are NOT valid numbers. Hint: loop over the values and use str(a).isdigit() to test whether each one is all digits, counting the ones that fail.
Why do you report the median trip length rather than the mean for this dataset?
Walk me through how you'd approach a small, unfamiliar dataset you've just been handed.
I work through a consistent sequence. First I read it: I figure out what one row represents — the unit of observation — and what each column means, so I'm not analysing something I've misunderstood. Second, I classify each column's type — numerical, categorical, or ordinal — because that determines which summaries and operations are even valid. Third, I audit quality: I look for missing values, duplicate rows, outliers, and inconsistencies like a value in the wrong format, and I flag each one rather than silently fixing it. Fourth, I ask how the data was collected and who might be missing from it, because that tells me how far the conclusions can generalise. Fifth, I compute a few honest summary statistics on the key columns, choosing the median over the mean when there are outliers. Finally, I write up one or two findings the cleaned data actually supports, with the caveats stated plainly. The throughline is that I'm not trying to make the data look impressive — I'm trying to understand exactly what it can and can't tell me.
You found a duplicate row and a 210-minute trip in a bike-share log. How do you decide what to do with them, and why not just delete them?
I treat each as a flagged decision, not a silent cleanup. For the exact-duplicate row, an identical match across every column almost always means the same event was logged twice, so I'd remove one copy before counting trips — but I'd note that I did it and how many I removed, because if it were somehow a genuine repeat I'd want that visible. For the 210-minute trip, when every other ride is 6 to 15 minutes, that value is almost certainly an error — probably a trip someone forgot to end — so I'd exclude it from the summary statistics and state that I excluded it and why. I don't just delete things quietly because every edit changes the result, and a hidden edit is how a wrong or misleading number reaches a stakeholder with no paper trail. The professional standard is that anyone reading my summary can see exactly what I dropped, what I kept, and the reasoning — so the analysis is reproducible and honest, even when the individual calls are judgment calls.
Your pilot analysis shows a typical 9-minute trip rated 4 out of 5. Your manager wants to announce this as how the whole city will use e-bikes. What do you say?
I'd affirm what the data genuinely shows and then carefully correct the overreach. The 9-minute median and roughly 4-out-of-5 rating are real findings for this pilot, and they're encouraging. But the pilot ran in a single neighbourhood, over two summer weeks, and captured only people who chose to try a brand-new service — that's selection bias plus a narrow sampling window. So those numbers describe self-selected early adopters in one area under easy conditions, not the city as a whole. People in other neighbourhoods, riders in bad weather, and everyone who didn't opt in are absent from the data, and they'd likely behave differently, probably less favourably. My recommendation would be to treat the pilot as a promising signal that justifies a larger, more representative test — multiple neighbourhoods, a longer window across seasons — before making any city-wide claim. Framing it that way protects the company from over-investing on a flattering but unrepresentative sample, and it's exactly the kind of caveat that makes a data team trustworthy.
Common Mistakes to Avoid
1) Jumping straight to statistics before reading the table and auditing its quality. 2) Silently deleting or 'correcting' bad rows instead of flagging each decision visibly. 3) Reporting the mean when an outlier (the 210-minute trip) makes the median the honest choice. 4) Generalising a one-neighbourhood, self-selected summer pilot to the whole city. 5) Delivering a confident headline with no caveats — the caveats are what make a junior analyst trustworthy, not timid.
Ask the AI Tutor
Try these prompts in the AI Tutor panel: • 'Give me a fresh 10-row messy dataset and let me run the six-step workflow on it.' • 'Check my one-sentence insight for overreach and missing caveats.' • 'Quiz me: for this dataset, mean or median, and why?' • 'Role-play my manager over-generalising my result so I can practise pushing back.' • 'Ask me to name the bias in how a given dataset was collected.'
Glossary
Exploratory analysis — the first, open-ended look at a dataset to understand it before modelling. Unit of observation — what one row represents (here, one trip). Data audit — the systematic check for missing values, duplicates, outliers, and inconsistencies. Outlier — a value far outside the normal range (the 210-minute trip). Selection bias — distortion from who chose to be in the data (self-selected pilot riders). Caveat — an explicit statement of a finding's limits. Defensible insight — a conclusion the cleaned data genuinely supports, stated with its caveats.
Recommended Resources
• Practice: download any small CSV from Kaggle's 'beginner' datasets and run the exact six-step workflow on it, writing one caveated insight. • Habit: for every dataset you meet, write its one-sentence unit-of-observation description before anything else. • Reference: skim pandas' .head(), .info(), and .describe() — the three commands that will soon automate steps 1–3 and 5 for you. • Next in DSM: you've completed Foundations. Next comes Python Programming, where you'll turn this by-hand workflow into real, reusable code.
Recap
✓ Real data work is the whole Foundations chain at once: read → types → quality → bias → statistics → report. ✓ You read the GreenWheels log (one row = one trip) and typed every column before touching a statistic. ✓ You audited it honestly — two missing values, a duplicate, a 210-minute outlier, and a 'Member' typed into age — flagging, not hiding, each. ✓ You named the selection bias and narrow window, so the insight applies to the pilot, not the city. ✓ You reported one defensible, caveated sentence — the real deliverable of a junior data task. 🎉 That completes the Foundations domain. You can now take a raw dataset from first glance to a trustworthy, honestly-caveated insight — entirely by reasoning. Next up: Python Programming, where you'll turn every by-hand step of this project into real, reusable code with pandas.
Run your code to see the output here.