What is data analysis?
Data analysis combines a defined decision question, suitable data, quality checks, an appropriate method and a reproducible conclusion that respects uncertainty and the population represented. The worked questions cover a join that duplicates revenue, mean versus median, missing survey responses, an experimental comparison, training and test leakage, a recommendation with limits. Use the explained answers to check your method, then practise applying the same principles to fresh facts instead of memorising an answer sequence.
Why this skill matters
Many analysis errors arise before the final formula. A one-to-many join can duplicate revenue, a self-selected sample can limit generalisation and a future-only field can leak an outcome into a predictive model. The worked cases connect structure, design and interpretation. They show why a polished visualisation or high score does not compensate for invalid data relationships or unsupported causal claims.
A subject-specific method
Step 1
Define the decision and outcome measure, specifying the unit of observation and the population to which the eventual conclusion is intended to apply.
Step 2
Inspect keys, missing values, data types, coverage and timing before choosing a method, especially when combining tables with different row grains.
Step 3
Use a calculation or comparison matched to the question, checking denominators, aggregation and potential selection or temporal leakage in the chosen design.
Step 4
Evaluate alternative explanations and uncertainty, separating a descriptive association from evidence supporting a causal effect or an out-of-sample prediction.
Step 5
Communicate the result with method, assumptions and limitations so that another person can reproduce it and understand the decision it can support.
Original worked scenario
Scenario: A dataset has 1,000 records, of which 80 are duplicates and 20 lack the target outcome. Task: Choose the best supported response or conclusion. Worked answer: Establish a documented deduplication rule and missing-data strategy before reporting rates. Why this works: A deduplication rule needs to distinguish a repeated record from a legitimate repeated event. Missing outcomes also need investigation before deciding whether exclusion or another treatment is appropriate. The stated counts flag quality questions; they do not justify automatically deleting 100 rows or assuming the two groups are disjoint. Common trap: Deleting all incomplete rows without analysis may introduce bias.
How to prepare effectively
Begin a practice analysis with a data dictionary containing the row grain, keys and measure definitions. Then make a small synthetic dataset whose correct totals you already know. Join a one-row order to two payments and inspect the output. This concrete example makes duplication risk more memorable than a general warning to clean the data. For summary statistics, calculate both the mean and median of a skewed set and explain what each describes. Investigate an extreme observation before deciding whether it is an error or a genuine case. Removing it solely because the result becomes more convenient is not a defensible quality rule. Record any exclusion and its reason. For comparisons, identify how the groups were formed. A self-selected survey, a historical discount programme and a randomised experiment provide different kinds of evidence. Do not describe them as interchangeable merely because each produces two percentages. Check exposure, measurement and uncertainty before treating a difference as a policy effect. For predictive tasks, define the moment when a prediction would be made. Exclude information only known later, and choose a validation design that reflects the intended use. A high historical score can be misleading when features contain future outcomes or when test records are not independent of training information. End each notebook with a short decision statement and a reproducibility check. State the result, its population, the important limitation and the next evidence needed. Reperform selected calculations and reconcile totals before presenting a polished chart. In formal assessments, use only permitted tools and information; in independent practice, protect confidential records and use synthetic or appropriate public data.
Mistakes that reduce scores
Common traps include double-counting after a one-to-many join, deleting inconvenient outliers without a rule, generalising from a self-selected sample and using information unavailable at prediction time. A difference between groups may reflect selection or confounding. Validate the data structure and design before interpreting a polished chart or model score.
Frequently asked questions
Why identify the grain before joining tables?
The row unit determines how measures aggregate. Joining orders to multiple payments can repeat order revenue and inflate a naive sum.
Should an extreme observation always be removed?
No. Investigate whether it is an error or a genuine case, and document a defensible inclusion or exclusion rule.
What is temporal leakage?
Using information unavailable at the intended prediction time. It can inflate historical performance without supporting the planned real-world decision.
Does a randomised comparison remove every concern?
No. Assignment, measurement, exposure, uncertainty and implementation still require checking. The design supports specific inferences only when its conditions hold.
Data analysis starts with a decision and a unit of observation
Data analysis includes defining a question, collecting or selecting suitable data, checking quality, applying a method and explaining the result. Before opening a tool, state the decision the analysis should inform. A request to improve sales could mean increasing order volume, margin, repeat purchase or cash collection. Different outcomes require different measures and sometimes different datasets. Define the grain of each table: one row per customer, order, order line, event or reporting period. Many serious errors arise when analysts combine tables at different grains without accounting for duplication. Document keys, coverage, time zones and the meaning of missing values. A clean-looking dashboard is not evidence that these foundations are correct. The examples below emphasise reasoning rather than a particular software package. They cover aggregation, selection bias, experiments, missing data and communication. Every scenario is fictional and its assumptions are stated. The purpose is to learn how to justify a conclusion and recognise what additional information would be needed, rather than memorise a dashboard number.
Question 1: A join that duplicates revenue
An orders table has one row for order X with revenue 500. A payments table has two rows for X, representing instalments of 200 and 300. After joining on order ID, what happens if you sum the order-revenue column without adjustment? Answer: It totals 1,000 because the join produces two rows repeating the 500 order revenue. Aggregate payments to order level before joining, or use a method that preserves the intended revenue grain. Simply dropping duplicate rows indiscriminately can remove legitimate transactions elsewhere. Inspect the relationship between keys and verify totals before and after a join. A successful query can still produce an invalid measure.
Question 2: Mean versus median
Five delivery times are 2, 3, 3, 4 and 28 days. What are their mean and median, and what does their difference suggest? Answer: The mean is 40 divided by 5 = 8 days; the median is 3 days. One long delivery pulls the mean upward. Neither measure should be chosen merely because it makes performance look better. The median describes the middle observation, while the mean includes the full effect of delays. Report a suitable summary for the decision, and investigate the 28-day case rather than deleting it solely because it is inconvenient.
Question 3: Missing survey responses
Only 20% of customers answer a satisfaction survey, and dissatisfied customers may be more motivated to respond. Can the response average automatically represent every customer? Answer: No. Non-response can create selection bias. Compare available characteristics of respondents and non-respondents, examine collection methods and state coverage limitations. Increasing the number of responses through the same biased process may not solve the problem. The result is still evidence about respondents, but a population-wide claim needs a defensible sampling or adjustment approach. Do not claim the bias's exact size or direction without enough evidence, even when a possible mechanism is plausible.
Question 4: An experimental comparison
Customers are randomly assigned to two checkout designs. Out of 1,000 visitors per group, 100 purchase under A and 120 under B. What is the observed conversion difference, and can you call the improvement certain from these counts alone? Answer: Conversion is 10% versus 12%, a difference of two percentage points and a 20% relative increase against A. The observed difference does not by itself establish statistical certainty or a lasting business effect. A suitable uncertainty analysis, experimental checks and decision criteria are needed. Confirm that assignment, measurement and exposure were valid. Do not confuse the size of the observed effect with the strength of the evidence about it.
Question 5: Training and test leakage
A model intended to predict late payments uses a field that is populated only after a payment becomes overdue. Why is that field a problem when estimating performance before the due date? Answer: It contains information unavailable at prediction time, creating leakage. The model may appear accurate in historical testing while failing in the intended workflow. Construct features using only information available at the decision time and evaluate on a suitable held-out period or sample. Random splitting alone may not protect against temporal leakage. Define the prediction moment before choosing features, and preserve that rule in both development and deployment.
Question 6: A recommendation with limits
A report finds that customers receiving a discount renew more often, but discounts were mainly offered to long-standing customers. What can the analyst responsibly recommend? Answer: Report the association, identify customer tenure as a possible confounder and propose a better comparison or proportionate experiment before claiming the discount caused renewal. Long-standing customers may already have a higher renewal tendency. It is possible that the discount helps, but the supplied comparison does not isolate its effect. A useful recommendation names the next evidence needed and the decision risk rather than presenting an attractive correlation as a proven policy benefit.
Presenting analysis that another person can verify
State the outcome definition, period, population and method beside the result. Identify exclusions and missing coverage that could affect interpretation. Use a chart suited to the relationship, with readable labels and a clearly described denominator. Explain uncertainty in terms the decision-maker can act on: what is known, what remains unresolved and which choice depends on that uncertainty. For assessment preparation, build a small analysis notebook using synthetic or public data. Record a question, a data-quality check, a calculation and a conclusion that respects the evidence. Reperform a few results manually and verify joins against known totals. Avoid uploading confidential customer or employee data merely to practise. Good analysis is reproducible, appropriately scoped and connected to a decision; a complicated toolchain does not compensate for an undefined question or an invalid denominator.
Continue with the matching discipline
Explore the Data Analysis assessment, using the production skill name shown on that page. Review the assessment format, current access terms and account requirements before starting. A skills assessment does not guarantee employment or a particular result.