A strong data analyst portfolio shows three to four projects, each built on a real question and a real dataset, written up as a short case study that a hiring manager without SQL can follow. Lead every project with the decision your analysis enabled, not the tools you used. Show the messy middle too: how you cleaned the data, what you assumed, and what you would caveat, because that is where judgment lives. Insight beats a wall of dashboards every time.
The premise
Your portfolio proves judgment, not tool fluency
Every data analyst portfolio looks the same from a distance: a grid of dashboards, a badge wall of tools, a Titanic notebook, a housing-price regression. It is a genre now, and hiring managers have read a thousand of them. The problem is that none of it answers the only question they actually have, which is whether you can be trusted to look at a messy business problem and come back with something worth acting on.
Tools are the cheapest thing you bring. SQL, Python, a BI tool, a stats library, they are all learnable in weeks and interchangeable across jobs. What a company is really buying is your judgment: the instinct to ask the right question, to notice when a number is too clean to be real, to say "we cannot conclude that yet" when the data will not support the claim. That is the scarce thing, and it is the thing a badge wall cannot show.
So build the whole portfolio around one shift: stop showing what you can operate and start showing how you think. Every choice below flows from that. Fewer projects, more depth, the messy middle on display, and a decision at the top of every case study instead of a chart.
The build
Build each project in five moves
Do these in order for every project. The order matters: the question comes before the dataset, and the decision comes before the dashboard.
Start with a real question, not a dataset.
Write the question a stakeholder would actually ask: "Which customers are about to churn, and is it worth intervening?" or "Did the price change cost us more in volume than it earned in margin?" A question with a decision attached is what makes the analysis matter. A dataset you found first and questioned later almost never gets there.
Find data with real mess in it.
Use a public dataset, a scrape you built, an API pull, or anonymized data from a past job. The point is friction: missing values, duplicate rows, inconsistent categories, a timezone bug. Clean data hides your best skill. Messy data is where you get to show it.
Do the analysis and record the decisions.
As you clean and model, keep a running note of every judgment call: why you dropped those rows, why you capped that outlier, which assumption the whole result rests on. These notes become the most valuable part of the writeup, because they are the part nobody can copy from a tutorial.
Name the decision your analysis enabled.
Finish by writing the one sentence a stakeholder would act on: "Focus retention spend on the 8 percent of accounts with these three signals." If you cannot name a decision, the project is a chart in search of a purpose. Send it back to step one.
Write it up as a readable case study.
Structure it as question, approach, what surprised you, decision, and caveats. Write for a hiring manager who does not read SQL. If they can follow the story and repeat your conclusion to their boss, the project works. Put the code one click away for the people who want it.
The case study
The anatomy of a project writeup
Every project is a short story with the same five beats. Each beat does a specific job for a specific reader.
Question
The business problem
One or two sentences naming the question and who cares about the answer. This is the hook. A reader should know within seconds why this analysis was worth doing, before you show a single number.
Approach
The method, in plain words
How you got the data, how you cleaned it, and what technique you used, described so a non-technical reader can follow. Name the tools once and move on. The method is context, not the headline.
Middle
The messy part
The cleaning decisions, the assumptions, the thing that broke and how you caught it. This is the section most portfolios hide and the one that actually proves you can be trusted with real data.
Decision
The so-what
The single decision your analysis enables, stated plainly. Lead the whole writeup with this if you can. Insight is the product; the chart is just the receipt.
Caveats
The honest limits
What the data cannot tell you, where the result is fragile, what you would check with more time. Naming your own limits is the strongest possible signal of judgment. Amateurs oversell; analysts caveat.
Proof
The code, one click away
A link to the notebook, query, or repo for the readers who want to verify. Keep it off the main page so the story stays readable, but always make it reachable. Show your work without burying the point.
The mindset
Show the messy middle on purpose
The instinct is to hide the mess. You spent two days reconciling a customer table that had three different spellings of the same country, and the finished chart shows none of that struggle. So you leave it out, and the writeup jumps from "here is the data" to "here is the beautiful result" as if the middle never happened. That polish is exactly what makes portfolios forgettable, because the middle is the only part that is uniquely yours.
Think about what a hiring manager is scanning for. They already assume you can make a bar chart. What they cannot assume is that you will notice when a join silently dropped a third of the rows, or that you will question a conversion rate that jumped to a suspiciously round number overnight. When you write "I expected clean daily data but found the tracker double-fired on mobile, so I deduplicated on session and the lift shrank from 40 to 12 percent," you have shown more judgment in one sentence than a whole gallery of dashboards.
Assumptions deserve the same honesty. Every analysis rests on a few, and the good analyst states them out loud: "This assumes the test and control groups were comparable, which the pre-period data supports." Naming an assumption is not a weakness to hide, it is proof you know where your conclusion could break. That is the difference between someone who runs a query and someone a team can actually rely on.
The contrast
The dashboard dump versus the case study
Two portfolios can contain the identical analysis and land completely differently. The difference is framing, and framing is a choice.
| Capability | Folio | The dashboard dump |
|---|---|---|
| Starts with | A business question with a decision attached | A dataset the analyst happened to find |
| Leads with | The decision the analysis enabled | A grid of charts and a tool list |
| The cleaning step | Shown on purpose as proof of judgment | Hidden so the result looks clean |
| Written for | A hiring manager who does not read SQL | Other analysts, or nobody in particular |
| Number of projects | Three or four, each deep | A dozen, each shallow |
| What it signals | Judgment you can trust with real problems | Familiarity with a tutorial |
Same skills, same tools, opposite outcome. The case-study framing is free, and it is the whole game.
The home
Publish it where the writing can breathe
A data analyst portfolio has an awkward hosting problem. A raw notebook is unreadable to the hiring manager who most needs to understand it, and a BI dashboard link expires, sits behind a login, or looks broken on a phone. The people making the hiring decision are often the least technical readers in the loop, and they will judge you on whether they could follow the story, not on whether your code ran. So the portfolio needs to be a real website that leads with prose and keeps the code a click away.
That is the case for building it on your own site instead of leaving it scattered across a notebook host and a dashboard tool. A portfolio builder gives you sections for outcomes, projects, experience, and skills, plus a block-based page engine and custom pages, so each case study can be its own readable page with the decision up top and the notebook linked below. Folio drafts that writeup from your own profile using a leading AI model, and you review and approve every word, so you start from your real projects instead of a blank page and keep the result as structured content you can edit and export any time. Pair it with a matching AI resume and cover letter, exported to clean PDF and DOCX, and your analysis and your application tell one consistent story.
Then make it findable and make it yours. Publish on a custom domain with the certificate handled for you, let the built-in SEO write the titles, meta descriptions, sitemap, and structured data, and add each new project the week you finish it. A living portfolio with four sharp case studies and a decision at the top of each one will out-hire a repo of twenty notebooks every time, because it proves the one thing the notebooks cannot: that you know which questions are worth answering.
Frequently asked questions
What should a data analyst portfolio include?
Three or four projects, each built on a real question and a real dataset and written up as a short case study. Every writeup should name the business question, explain the approach in plain words, show the cleaning and assumptions, state the decision the analysis enabled, list the honest caveats, and link the code one click away. Lead with insight, not a wall of dashboards.
How many projects should a data analytics portfolio have?
Three or four deep projects beat a dozen shallow ones. Depth reads as judgment; a long list of small notebooks reads as a class assignment. Pick projects where you asked a real question, wrestled with messy data, and reached a decision someone could act on, then write each one up properly.
What makes a good data portfolio project?
A real question with a decision attached, a dataset messy enough to show your cleaning skills, and a writeup that a non-technical hiring manager can follow. The best projects show the middle: why you dropped certain rows, which assumption the result rests on, and what you would caveat. That is where judgment shows, and judgment is what you are being hired for.
Do I need dashboards in my data analyst portfolio?
A dashboard can be part of a project, but it should never be the point. Hiring managers have seen countless dashboards and cannot tell a good one from a lucky one at a glance. Lead with the decision your analysis enabled and the reasoning behind it. Insight over dashboards, every time.
How do I write up a data project for a non-technical audience?
Structure it as a story: the question, your approach in plain language, what surprised you in the data, the decision it enabled, and the caveats. Name your tools once and move on. If a hiring manager who does not read SQL can follow the writeup and repeat your conclusion to their boss, it works. Keep the notebook one click away for the technical readers.