Data Analyst Business Case Studies:
Questions and Worked Answers

A business case asks you to turn an unclear problem into an analysis someone can act on. Start by defining the decision, the metric and the time period. A drop in orders, revenue and conversion rate can describe three different problems.

Ask what changed, compared with which baseline, and for whom. Confirm whether the figures use the same timezone, currency, refund policy and event definitions. A tracking change can look like a product problem.

1. Define: state the business question and the unit of analysis.
2. Validate: check the data, definitions and comparison period.
3. Break down: calculate changes by relevant segment or metric component.
4. Investigate: distinguish observations from explanations that still need evidence.
5. Recommend: propose an action, its risks and how to assess the result.

Product-to-cart loses 400 users, the largest absolute loss. Cart-to-checkout loses 300 users, or 50% of the users entering that step, the largest proportional loss. Overall conversion is 240 ÷ 1,000 = 24%.

The table does not explain why people left. Payment errors, delivery costs, comparison shopping and missing events are hypotheses. Check event coverage, release dates, device breakdowns and support reports before selecting a fix.

Build a portfolio case study from this funnel →

For a defined period, order revenue equals number of orders × average order value, when both measures cover the same orders and use the same revenue definition. Another equivalent breakdown is active buyers × orders per active buyer × average order value. Do not multiply by retention again when it is already reflected in the active-buyer count.

Revenue fell US$68,000, or 13.6%. Holding the old order value fixed, the loss of 100 orders accounts for US$50,000. Applying the US$20 order-value reduction to the current 900 orders accounts for the other US$18,000. This sequential decomposition reconciles the total; another ordering allocates the interaction differently.

Next compare channels, product categories and new versus returning buyers. A lower average order value could reflect discounts, product mix or refunds. It does not by itself prove that customers became less willing to pay.

Work through a revenue investigation in SQL →

A cohort groups people using a shared starting event, such as their first purchase. Define the return event and the observation window before comparing cohorts.

If 200 users signed up on a particular day and 50 of those same users completed the chosen activity exactly seven days later, Day-7 retention is 50 ÷ 200 = 25%. Total daily active users is not the numerator: it includes people outside the original cohort.

For month-to-month activity retention, divide users active in both months by users active in the first month. Subtracting new users from current monthly activity is not always equivalent because it can include reactivated users.

Only compare cohorts that have had enough time to reach the measured age. A recent cohort without 30 days of follow-up cannot yet supply a Day-30 retention rate. Differences between cohorts may reflect acquisition mix, seasonality or product changes; the chart alone does not establish cause.

Practice case: A fictional agency reports 40 leads last week and 60 this week. Last week counted accepted inquiry forms. This week combines 30 accepted forms, 20 WhatsApp clicks and 10 booking-link clicks. All figures cover complete seven-day periods.

Answer: The reported total increased by 50%, but the definition changed. The comparable accepted-form count fell from 40 to 30, a 25% decrease. External contact clicks show intent; without confirmation, they do not establish that messages were sent or appointments booked. Do not label the combined 60 as confirmed leads.

“Not measured” is not zero. We cannot calculate a comparable change in total contact activity from these figures. We also cannot add the rows to count distinct people: one visitor may use multiple contact options.

1. Document the change in event definitions and its deployment date.
2. Validate the accepted-form success signal, failures and repeated callbacks.
3. Compare accepted forms using consistent filters and complete periods.
4. Report external clicks separately until their downstream outcomes are observable.

The decrease in accepted forms is an observation, not proof of declining demand. Check collection coverage and possible movement to other contact methods. Use the GA4 event plan and tested duplicate-callback example to turn this answer into an implementation specification.

A product-level North Star metric is a proposed measure of value delivered to users. It is a choice to justify, not a universal formula. A feature-level primary metric may be narrower.

For a hypothetical language-learning app, weekly learners who complete a practice session could be a candidate. Explain its limits: session completion may not measure learning quality. Pair it with evidence about learning progress and continued use.

A useful metric definition names the event, eligible population, unit, time window and exclusions. Add guardrails such as error rate, refunds or support contacts where relevant. Do not present an invented metric as a named company’s official measure.

Suppose research suggests that showing delivery costs earlier could reduce checkout abandonment. A randomised experiment can estimate the effect of that change under the experiment’s assumptions.

1. Write the hypothesis and choose one primary outcome, such as paid orders per eligible user.
2. Choose the randomisation unit. User-level assignment often avoids showing one person multiple versions; other products may need account or geographic assignment.
3. Set a meaningful effect size, uncertainty threshold, statistical power and observation window before calculating the sample size.
4. Validate exposure logging and assignment balance. Consider interference, missing outcomes and changes during the test.
5. Estimate the effect with an uncertainty interval. Assess business relevance and guardrails, not just whether a p-value crosses a threshold.

Randomisation balances groups in expectation; it does not guarantee that every characteristic is identical. Avoid repeatedly checking a fixed-horizon test and stopping at the first positive result. Use a stopping rule appropriate to the analysis method.

A verified production fault may need an immediate repair rather than an experiment that knowingly leaves users exposed. Match the evaluation method to the decision.

First confirm the denominator, dates and platform coverage. The change is 14 percentage points, about a 19.4% relative decrease. Ask whether the tracking definition or the mix of users changed.

Compare the timing with releases and incidents, then break the change down by device, app version, payment method and new versus returning users. Prioritise segments by their contribution to the overall loss, alongside the reliability of their sample sizes.

A release-related bug, higher delivery fees and event loss remain competing explanations. Use error logs and event reconciliation to test them. A sudden drop suggests a time-specific event, but does not prove a technical cause.

Recommend the next action supported by the evidence. If a bug is confirmed, repair it and monitor completion, errors and refunds. If the evidence suggests a design change, propose an evaluation. Do not promise recovery to a particular conversion rate within 48 hours without a basis.

Check your answer

• Did you define the metric and quantify the change correctly?
• Did you separate evidence from hypotheses?
• Does your proposed action follow from the evidence?
• Did you name an evaluation method and a limitation?

Can overall conversion fall while every channel improves?

Yes. The overall rate is weighted by each channel’s share of traffic. A shift toward a lower-converting channel can reduce the total even when each channel improves. Compare both within-channel rates and traffic shares before attributing the change to product performance. Run the SQL traffic-mix example.

What should you check before trusting an A/B-test result?

Check the planned assignment, eligible population, exposure logging and complete outcome windows before interpreting lift. An unexpectedly uneven allocation may indicate a data-quality issue. Run the Python assignment check and read Microsoft’s primary research on diagnosing sample ratio mismatch.

How do you avoid understating retention for recent cohorts?

Only include users who have reached the required observation age. A user who signed up yesterday cannot yet have a measured Day-7 outcome. Work through the eligible-cohort SQL example.