How to Build a Data Analyst Portfolio in 2026

A portfolio is judged quickly. A recruiter or hiring manager follows a link from your CV, looks for something they can open, and decides within minutes whether to read further. For analyst roles, what they want to see is specific: a business question answered with real data, SQL they can read, a dashboard or chart that makes the finding clear, and writing that a manager could act on. This guide covers how to present that work; for which projects to build, see data analytics projects for your resume.

What reviewers check first

1. Can I open something immediately? A live dashboard, a short case study or a clear screenshot, not a zip file to download.
2. Is there a real question and answer? "Which customer segments drive revenue, and what should we do about the at-risk group?" beats "exploratory analysis of retail data".
3. Can this person write SQL? Readable queries with sensible names and comments.
4. Can they explain? A short written summary that leads with the finding.
5. Is the work careful? Documented cleaning, reconciled totals, stated limitations.

Design every part of the portfolio so these questions are answered without effort.

The structure: a hub, case studies, supporting files

A hub page. One page with your name, a line about the kind of analyst work you want, and a card for each project: title, the business question, one headline finding and links. A free static site is enough; GitHub Pages, for example, publishes a website straight from files in a repository (GitHub Docs: about GitHub Pages).

Two or three case studies. Each project gets a page or document with a consistent structure:

1. The question and who would use the answer.
2. The data: source, size, period and licence.
3. Cleaning and checks: what was excluded and how many rows, and totals reconciled.
4. The analysis: two to four charts or tables, each with a one-sentence takeaway.
5. The recommendation, with the size of the opportunity or risk where possible.
6. Limitations and what you would do next.

Supporting files. A repository with the SQL, notebooks or cleaning steps, with a README that explains what each file is and how to reproduce the results; the README is usually the first thing a visitor sees in a repository (GitHub Docs: about READMEs).

Sharing dashboards without exposing data

Interactive dashboards impress, but publishing them has consequences. Power BI's Publish to web makes a report viewable by anyone on the internet without signing in, and Microsoft warns that this includes detail-level data the report aggregates; it is not for confidential or proprietary information (Microsoft Learn: publish to web). The rules that follow:

• Only publish public or properly licensed data. Never employer or client data, even aggregated.
• Assume everything published publicly can be downloaded. Build portfolio dashboards on data you would be happy for anyone to have.
• If you use Tableau, its public gallery, Tableau Public, is a common way to share portfolio work; treat anything published there as public too.
• When you cannot publish, use clear screenshots and a two-minute screen-recorded walkthrough instead.

A good dashboard screenshot is often enough: reviewers rarely have time to explore every filter, and a screenshot with annotations shows exactly what you want them to notice.

Presenting SQL and spreadsheets well

• SQL: one file per question, a comment at the top saying what it answers, readable formatting, meaningful aliases, and the result pasted below or in the case study. Common table expressions that read in steps are easier to review than one enormous query.
• Spreadsheets: share a version with sample or public data, separate tabs for raw data, calculations and outputs, and a notes tab with definitions.
• Power BI files: describe the data model, list the main measures and what each calculates, and include screenshots, since many reviewers will not open the file itself.

Connecting the portfolio to your CV

Each CV project line should state the result and link to the case study: "Retail customer segmentation: 26% of customers produced 68% of revenue; recommended a win-back test for lapsed regulars (case study link)". Use the same numbers in the CV, the case study and the dashboard; consistency signals care. Building a sales dashboard is an example of a project written up this way.

A checklist before you apply

• Every link on the hub page, CV and case studies opens correctly in a private browser window.
• Each case study leads with the question and the finding in its first lines.
• Cleaning steps and exclusions are documented with counts.
• No confidential or personal data appears anywhere.
• Charts have titles that state the finding, labelled axes and sources.
• Spelling and formatting have been checked by someone else.
• You can explain every number in every project in an interview.

Mistakes that get portfolios skipped

• Tutorial copies of popular datasets with no new question.
• Dashboards without a point: many visuals, no finding, no recommendation.
• Broken links or files that only open with special software.
• Unreadable code: no comments, cryptic names, no explanation of results.
• Overclaiming: calling a simple chart "machine learning" or presenting guesses as findings.

Portfolio projects such as a sales analysis dashboard, customer behaviour analysis and business performance dashboards are part of the Data Analytics course.

Sources

• Publish to web from Power BI (Microsoft Learn) — Microsoft Learn
• About GitHub Pages (GitHub Docs) — GitHub Docs
• About READMEs (GitHub Docs) — GitHub Docs