Write a Data Analyst Portfolio Case Study Without Inventing Impact
By Prakhar Shrivastava · Worked practice example
A portfolio case study should let another person understand what you measured, reproduce the calculation, and see where your conclusion stops. This worked outline uses an invented checkout funnel. It does not describe a client result or a success achieved by this website.
State a question that the data can answer
A useful question is: “At which observed checkout step do the most users stop progressing during this period?” That question can be answered with funnel data. “Which redesign will increase revenue?” requires additional evidence, usually including an intervention or experiment. Avoid presenting the second answer when you only have data for the first.
Define the unit and sequence
For this exercise, count distinct users in one completed seven-day period. Every user in a later step must have completed the preceding steps in order during that period. Use the same timezone and identity rule throughout. A production funnel might instead use sessions or a fixed conversion window after entry; either can be valid, but mixing definitions cannot.
Assume bots, internal testers, and duplicate events have already been excluded using documented rules. If that is only an assumption, label it as one and explain how you would test it against raw events. A screenshot of a dashboard is not a substitute for defining the underlying metric.
Show the calculations
| Step | Users | Progression from prior step |
|---|---|---|
| Product viewed | 1,000 | Entry step |
| Added to cart | 600 | 60% |
| Checkout started | 300 | 50% |
| Paid order | 240 | 80% |
The overall conversion is 240 ÷ 1,000 = 24%. Product-to-cart loses 400 users, the largest absolute loss. Cart-to-checkout loses 300 users, or 50% of the 600 entering that transition, the largest proportional loss. Checkout-to-payment loses 60 users, or 20%. These statements use different denominators and should not be treated as interchangeable.
Explain what the funnel cannot tell you
The table does not prove that the cart page is confusing or that a payment provider is broken. Users may compare prices, save items, discover delivery restrictions, or simply leave. Tracking may also be incomplete. Name these as hypotheses, then list the evidence needed to distinguish them: error logs, event validation, device breakdowns, user research, and release history.
Avoid claiming a revenue impact from user counts alone. Paid orders can have different values, and more conversions may be offset by refunds or lower margins. If you model an opportunity, label the assumptions clearly and separate it from an observed result.
Model an opportunity without calling it a result
Suppose cart-to-checkout progression increased from 50% to 55%, with 600 cart users and downstream payment progression unchanged at 80%. The model gives 600 × 55% × 80% = 264 orders, versus 240 now: 24 additional orders. That is a five-percentage-point improvement at the cart transition and a 10% relative increase in orders under the assumptions. No such improvement has been observed in this dataset.
Make a bounded recommendation
Recommend validating cart and checkout tracking first. Then investigate the largest relevant losses by device or another available segment. If research identifies a specific issue, propose a change and define an evaluation plan. Choose a primary metric, guardrails such as refunds and payment errors, and an appropriate observation window before assessing the change.
A responsible recommendation connects an action to evidence. “Redesign the entire checkout” is difficult to justify from this table. “Verify the cart-to-checkout events and inspect error rates before prioritising a targeted change” is narrower and testable.
Package the project for a reviewer
Include a short README describing the question, data source, synthetic-data status, metric definitions, query or notebook, expected output, and limitations. Keep raw data separate from transformations. Use a small table like the one above when it communicates more clearly than a decorative dashboard. Document how someone can rerun the analysis.
End with three sentences: what you observed, what remains uncertain, and what you would do next. If you later run an experiment or obtain outcome data, add those results with the actual dates and methods. Do not write a fictional business impact in the past tense to make a portfolio appear stronger.
Practise related methods in the business case-study guide and the SQL hub.