Data analyst portfolio: projects, datasets and explaining your findings

A data analyst is hired to turn messy data into decisions. Your portfolio should show exactly that: a question, the data you used to answer it, what you found, and what someone should do about it. Charts and code are supporting evidence. This guide walks through choosing projects and datasets, writing up findings, and presenting dashboards and notebooks so a hiring manager can follow your thinking in a few minutes.

What a reviewer is looking for

People reviewing analyst portfolios tend to look for the same handful of things, whether or not they say so:

• Can you ask a useful question? Not "let's explore this dataset," but "which customers are most likely to cancel in their first three months?"
• Can you get the data into shape? Cleaning, joining and checking data is most of the job.
• Do you choose sensible methods? Simple, correct analysis beats complicated, shaky analysis.
• Can you explain what you found to someone who won't read your code?
• Do you know the limits of your conclusion?

Every project you include should give evidence for several of these.

Choosing projects

Three to five solid projects is enough. Breadth across a few techniques helps, but each project should stand on its own as a complete piece of work.

A good mix might include:

1. A business-style analysis: sales, churn, marketing performance or operations, with a clear recommendation at the end.
2. A dashboard or reporting project: something a stakeholder would check regularly.
3. A data cleaning or pipeline project: combining messy sources into something usable.
4. A project on a topic you care about: local transit, sports, public health, housing. Interest shows in the quality of the questions.

If you're aiming at a specific industry, weight your projects toward it. An analyst applying to an online retailer will get more mileage from a basket analysis than from a sports statistics project, however clever.

Avoid making a famous beginner dataset your headline project. Reviewers have seen the same passenger-survival and flower-measurement analyses many times. If you use one, push it somewhere new.

Choosing datasets

The dataset shapes how interesting your project can be. Look for data that is:

• Real and a bit messy. Clean, pre-packaged datasets hide the cleaning work you'd do on the job.
• Large enough to need thought, but small enough to work with on your own machine.
• Relevant to a question someone would pay to answer.
• Legal to use and share. Check the license or terms, and never publish data with personal information in it.

Good sources include government open data portals, city and transit agencies, public research repositories and data you collect yourself, such as your own spending, a survey of friends (with their consent) or a small web project's analytics. Combining two sources is often what makes a project distinctive: weather data joined with bike-share trips, or census data joined with local business listings.

If you have work-related analysis you can't share, you can recreate its structure on a public dataset. Say so: "This mirrors a churn analysis I did at work, rebuilt on public data."

Writing up findings

This is where most analyst portfolios fall short. The work is there, but the write-up reads like a lab notebook. Structure each project so the conclusion comes first.

A simple structure

1. The question, in one sentence.
2. The answer, in two or three sentences, with the key number.
3. Why it matters: the decision it informs.
4. The data: source, size, time range, and what you had to clean.
5. The approach: methods, in plain language.
6. Key charts: two or three, each with a takeaway title.
7. Limitations and next steps.

For a deeper look at the format, see how to write a case study.

Before and after: a summary

Before:

"In this project I performed exploratory data analysis on a bike-share dataset using Python, pandas and seaborn. I cleaned the data, created features and built visualizations."

After:

"Question: why do some bike-share stations run empty every weekday morning? Using one year of public trip data, I found that most of the shortage comes from a small group of stations near train stops, where riders take bikes downhill to offices and rarely ride them back. Moving a small number of bikes from overnight surplus stations to those stops before the morning peak would cover most of the gap. The full analysis, including the cleaning steps and the rebalancing estimate, is below."

The second version gives a question, a finding and a recommendation before a single line of code. It also mentions the method only where it helps.

Write chart titles that state the finding

A chart titled "Trips by hour" makes the reader work out the point. A chart titled "Morning trips are concentrated at stations near train stops" tells them what to look for. Label the axes, include units, and avoid colors that carry no meaning.

Be honest about limits

A short "Limitations" section is a sign of maturity, not weakness. For example:

• "The data covers one city and one year, so seasonal patterns may not hold elsewhere."
• "Correlation between rainfall and ridership doesn't show that rain alone causes the drop; events and holidays may play a part."
• "About 3 percent of trips had missing end stations and were excluded."

Only state numbers you actually calculated. If you didn't measure something, describe it qualitatively.

Presenting dashboards

A dashboard on its own, with no context, leaves people unsure what to look at. On your portfolio:

• Show a static screenshot first, with a sentence on who it's for and what decisions it supports.
• Link to the live version if it's public, and test that the link works without logging in.
• Explain two or three design choices: why these metrics, why this layout, what you left out on purpose.
• Describe how it would be used: "A store manager checks this every Monday to decide staffing for the week."

Keep the dashboard itself focused. A page with fifteen charts often signals that nobody decided what mattered.

Presenting notebooks and code

Technical reviewers will open your notebooks or repository. Make them easy to read:

• Put a short summary at the top of each notebook with the question and the answer.
• Use headings to split the notebook into stages: load, clean, explore, analyze, conclude.
• Remove dead cells, giant printed tables and leftover errors.
• Comment on why you did something, not what the code does line by line.
• Include a README explaining how to get the data and run the analysis.
• Make sure no credentials or personal data are in the files or their history.

Link each project to its own repository or notebook rather than to your profile in general.

The rest of your portfolio

Around the projects, keep the other sections short and concrete. A headline like "Data analyst focused on retail and customer behavior" is clearer than a list of tools. Your skills section should group tools (SQL, Python, spreadsheets, a BI tool) and methods (cohort analysis, A/B test evaluation, forecasting), and list only what you'd be comfortable discussing. See writing a skills section for more. For experience, focus on decisions your analysis influenced, using real numbers where you have them; quantifying your achievements shows how without overstating.

Putting it together

A data analyst portfolio succeeds when each project reads like a short, clear answer to a real question. Choose a few projects with interesting, real data, lead every write-up with the finding and the recommendation, title charts with what they show, and be upfront about limitations. Give dashboards context and keep notebooks tidy enough that a technical reviewer can follow them. The analysis shows you can do the work; the write-up shows you can make it useful to someone else.