A Beginner's Guide to A/B Testing for Data Scientists
A practical guide to A/B testing for data scientists: framing testable hypotheses, sizing samples, reading...
A portfolio project does not need a deep learning model or a million-row dataset. It needs a question you actually care about, a source of data you can defend, and a clear account of what you found.
Public APIs are the most honest source available: someone else collected the data, it updates on its own schedule, and you have to work with it as it really is — messy field names, missing values, timezone quirks and all. This walkthrough builds one small project end to end. Pull weather data from a public API, clean it with pandas, make three charts, and write a README a colleague can read in two minutes. Pick a weekend. The result will not be the most advanced thing you have ever built, but it will be something you can explain, defend, and improve. That is exactly what a first portfolio project should be.
Start with a question you genuinely want answered. Does it rain more on weekends where I live? Which months bring the most earthquakes above magnitude 4? How has electricity demand shifted in my region? The question decides which API you need, which columns matter, and what the charts should show. Choosing a dataset first usually means a week of plotting things nobody asked about.
A good question is narrow enough to answer in a weekend but broad enough to have a real answer. “Is there weather?” is too broad. “Did it rain more on weekends than weekdays at the local airport in 2024?” is specific, testable, and immediately interesting to anyone who has planned a Saturday picnic. The narrower question also tells you what to ignore. You do not need every weather variable — just precipitation, date, and maybe location.
For a first project, the API should meet three conditions:
Good candidates include Open-Meteo for historical weather and air quality, the USGS earthquake catalogue, World Bank indicators, and most city open data portals. Skip scraping for project one. Page structures change, and you will spend the weekend repairing a parser instead of learning pandas. Also skip APIs that require OAuth, complex authentication, or a paid plan. The goal is to practise the full workflow, not to fight an access token.
Work in a virtual environment, install requests and pandas, and write a script that fetches the data and stores the response.
The storage part matters more than it sounds. Write the raw JSON to disk — something like data/raw/weather_2024-01-15.json — before you parse anything. Check the status code, and print the first few keys if the shape is unfamiliar. Now you have a fixed dataset to iterate on: no waiting, no rate limits, no surprises when an endpoint changes at midnight.
Save the raw response first. An hour spent re-downloading data is an hour not spent analysing it.
If the file is small, commit it. If it is large, or the API's terms restrict redistribution, keep it out of the repository and add a fetch script plus a note in the README explaining how to regenerate it. Name files with the date and parameters you used, such as the city, latitude, or start and end dates. That small habit makes your project reproducible and saves you from wondering which version of the data produced a chart three weeks later.
It also helps to write the fetch step as a function rather than a pile of top-level code. That way, when you later want a different city or a longer date range, you change one argument instead of rewriting the script. Add a simple retry if the request fails, and print the status code when it does. A failed pull should stop the script, not quietly produce an empty DataFrame.
Most JSON turns into a DataFrame in one line with pandas.json_normalize() when the records are nested. Some APIs — Open-Meteo is a good example — return parallel arrays instead, so build the frame from those lists directly, convert the time column with pd.to_datetime(), and set it as the index.
Fix each issue with a line of code, then write one sentence about what you did and why. Silent fills are the quickest way to produce a chart you cannot defend. If you drop rows, say how many and what they were. If you fill missing rainfall with zero, ask whether that means “no rain” or “sensor offline”. Those are different claims, and your README should make the choice clear.
A useful habit is to keep a short cleaning log. It can live in the README or in comments beside the code. For example: “Dropped 4 duplicate timestamps. Converted temperature from Kelvin to Celsius. Left 2 missing precipitation values as NaN rather than filling them.” That log turns cleaning from invisible guesswork into part of your analysis.
Run df.info(), df.describe(), and a few value_counts() calls before you plot. You are checking for surprises. Does the date range actually match what you requested? Are there gaps in the time series? Is the minimum temperature plausible? Does the most common category make sense? If the API returns daily data, you should have roughly one row per day; if you do not, find out why before you draw a line through the gaps.
Look at the shape of the distribution, not just the average. A mean rainfall of 3 mm could mean steady drizzle every day or one storm that dropped 90 mm. A median tells you something different from a mean, and a box plot or histogram will show whether a few extreme values are driving the story. Check the extremes by sorting the column and looking at the top and bottom rows. Sometimes the largest value is a real event; sometimes it is a unit error, a duplicate, or a placeholder such as 999.
If the summary surprises you, investigate before plotting. A chart made from unchecked numbers is just a rumour with colours.
Write down three facts you can defend from the data. For example: “There were 212 rainy days. The wettest month was October. Weekend rainfall was slightly higher on average, but the median was almost identical.” Those facts become the spine of your README and your charts.
Three charts is enough for a first project. One gives context, one makes a comparison, and one shows detail. For the weather question, that might be a line chart of daily precipitation across the year, a bar chart of average rainfall by month, and a box plot comparing weekday and weekend rainfall. Each chart should have one job. If a chart needs a paragraph to explain what it is showing, split it into two.
Label axes with units. State the timezone. Add a title that makes a claim, not just a description: “Weekend rainfall is higher on average, but the difference is small” is better than “Rainfall by day type”. Annotate the one point that matters most — the wettest day, the missing sensor period, the month that breaks the pattern. Remove gridlines, legends, and colours that do not help. A clean chart is easier to trust.
Your README is not an afterthought. It is the part most people will actually read. Put the question at the top, then the data source, then the method, then the findings. Include the one chart that answers the question. Finish with limitations and next steps. If a colleague cannot understand what you did and why it matters in two minutes, the project is not finished.
Do not bury the answer. If weekend rainfall was higher but not meaningfully so, say that in the first two lines. Negative or boring results are still results. They show that you can follow evidence instead of forcing a story.
Put the project on GitHub with a clear folder structure: a README, a notebook or script for fetching, one for cleaning, and one for analysis. If the raw data is small and allowed, include it. If not, include the fetch script and document how to run it. Pin your package versions in a requirements file so the project still works six months from now. Never commit API keys. Use environment variables or a local secrets file, and explain that in the README.
Finally, make the notebook run from top to bottom after a restart. That simple test catches hidden state, missing files, and cells that only worked because you ran them out of order. A reproducible project is more impressive than a clever one that nobody can rerun.
The goal is not perfection. It is to finish something small, honest, and reproducible that shows how you think. Pull the data, save it raw, clean it carefully, look before you plot, make three charts, and write the README. Then pick another question and do it again. The second project will be easier, and the third will start to feel like a real workflow.
Photo: Daniil Komov / Pexels
A practical guide to A/B testing for data scientists: framing testable hypotheses, sizing samples, reading...
A practical guide to pulling your city's open bike data, cleaning trip records without bias, and mapping...
A practical walkthrough of cleaning daily sales history, separating trend from holiday seasonality, and...
