Understanding Data Storytelling
Data storytelling turns an analysis into a decision someone can evaluate. It connects a question, evidence, interpretation, and a proposed response. Unlike a persuasive anecdote, a defensible data story lets the audience trace its central claim back to measurements. Start with the decision: “Should the support team investigate slower resolutions?” is more useful than “What does our dashboard show?” The audience determines which details need explanation, not which inconvenient results can be omitted.
Define the measurement before describing a change. A resolution rate needs a numerator, such as tickets resolved within two days, and a denominator, such as all eligible tickets opened during a week. State eligibility rules and ensure every ticket has had enough time to reach the deadline. Counts describe workload; rates describe outcomes relative to opportunities. Both matter. Fifty late tickets could represent a serious deterioration or simply a larger workload with an unchanged late-resolution rate.
Comparisons give numbers meaning. Compare against a relevant prior period, target, or group, using consistent definitions. Moving from 80% to 90% is an increase of 10 percentage points, but a relative increase of 12.5%. These answer different questions. Also inspect meaningful subgroups: an overall rate can change because group performance changed, because the population mix changed, or both. Aggregation simplifies communication, but can conceal the distinction needed for a sound recommendation.
Use the lesson’s setup, conflict, and resolution structure as an organizing aid, not a demand for drama. Setup establishes the decision and baseline. Conflict identifies the important finding or unresolved question. Resolution proposes an action proportionate to the evidence. “Explain why” should mean explaining relevance and plausible mechanisms, not inventing causation. Observational comparisons alone rarely establish why an outcome changed; staffing, case difficulty, and recording practices may all differ.
Choose a display that supports the comparison. Bars suit category comparisons; lines suit ordered time measurements; a compact table suits exact values. One chart per insight is a useful default, not a universal law. Label units, periods, denominators, and sources. Pair the headline with limitations and a next step. Clear communication preserves uncertainty rather than hiding it behind a memorable but overstated conclusion.
Practical walkthrough
Consider a fictional support manager deciding whether a lower overall resolution rate warrants a broad process overhaul. The example below contains complete, illustrative counts for two weeks and two ticket categories. It uses standard Python without external dependencies.
First, define success as resolution within two days of opening. Assume both weeks are fully observed, tickets belong to exactly one category, and definitions stayed constant. In real records, check duplicate identifiers, missing outcomes, and inconsistent category labels before aggregation. Missing outcomes must not silently become failures or disappear from the denominator.
Second, calculate each category’s rate and the overall rate. Sum successes and eligible tickets separately before dividing. This follows the split, aggregate, and combine approach covered in the pandas user guide’s grouping material, although this tiny example needs no library. Do not average category percentages unless equal category weighting is deliberately intended.
Third, compare the aggregate with its components. Both category rates remain unchanged, yet the overall rate falls. Calculate the difficult category’s share of tickets to check whether the workload composition shifted. This distinguishes an arithmetic explanation of the aggregate from an unsupported claim about staff performance.
Finally, draft a concise decision statement: “Overall timely resolution fell as complex tickets became a larger share of volume; neither category’s observed rate declined.” Present the category counts alongside that headline. Recommend investigating complex-ticket demand and capacity before a broad overhaul. Assign the support manager to review the next fully observed week using the same definitions. Two weeks describe this dataset, not a reliable long-term trend or proof of any intervention’s effect.
Worked example
data = {
"Week 1": {"Routine": (72, 80), "Complex": (10, 20)},
"Week 2": {"Routine": (18, 20), "Complex": (40, 80)},
}
overall_rates = []
for week, groups in data.items():
print(week)
successes = 0
tickets = 0
for category, (resolved, total) in groups.items():
assert 0 <= resolved <= total and total > 0
successes += resolved
tickets += total
print(f" {category}: {resolved}/{total} = {100 * resolved / total:.1f}%")
rate = 100 * successes / tickets
overall_rates.append(rate)
complex_share = 100 * groups["Complex"][1] / tickets
print(f" Overall: {successes}/{tickets} = {rate:.1f}%")
print(f" Complex share: {complex_share:.1f}%")
change = overall_rates[1] - overall_rates[0]
print(f"Overall change: {change:+.1f} percentage points")
Expected output
Week 1
Routine: 72/80 = 90.0%
Complex: 10/20 = 50.0%
Overall: 82/100 = 82.0%
Complex share: 20.0%
Week 2
Routine: 18/20 = 90.0%
Complex: 40/80 = 50.0%
Overall: 58/100 = 58.0%
Complex share: 80.0%
Overall change: -24.0 percentage points
Each tuple contains timely resolutions followed by eligible tickets. The loop computes rates from counts and formats percentages to one decimal place. Routine tickets stay at 90%, and complex tickets stay at 50%. However, complex tickets rise from 20% to 80% of the workload. Consequently, the overall rate drops from 82% to 58%, a decline of 24 percentage points. This is a weighted-average effect: the lower-rate category receives more weight in the second week. The figures support a composition-based description, but they do not explain why complex demand increased or establish that additional staffing would improve timely resolution in practice.
Common mistakes and how to avoid them
Writing the headline first and selecting only evidence that supports it.
Check relevant periods and subgroups before finalizing the headline. Include contradictory findings when they could change the decision, and distinguish exploratory observations from preplanned comparisons.
Averaging subgroup percentages to obtain an overall rate.
Divide total successes by total eligible observations. Here, averaging 90% and 50% produces 70% for both weeks, which describes neither week’s actual ticket-level outcome.
Turning a descriptive pattern into a causal recommendation.
Separate observation, hypothesis, and action. Investigate demand and capacity first; evaluate a proposed staffing change with an appropriate comparison rather than promising an improvement.
Making visual simplicity more important than faithful interpretation.
Keep essential denominators, definitions, and caveats visible. Use a zero baseline for magnitude-encoding bars, and provide an accessible table when exact values matter.
Review questions
Why can the overall rate fall when neither category’s rate declines?
The overall rate weights categories by their ticket counts. Shifting more tickets into the lower-rate category reduces the aggregate even when both category rates remain constant.
What is the difference between a percentage-point change and a relative percentage change?
Percentage points subtract rates directly. Relative change divides that difference by the starting rate. The fall from 82% to 58% is 24 percentage points, or about 29.3% relative to 82%.
What should accompany a strong data-story headline?
Include the comparison period, metric definition, supporting counts or rates, material limitations, and a proportionate next step. These let the reader evaluate rather than merely remember the claim.
Why is investigating complex-ticket capacity preferable to immediately demanding a broad overhaul?
The observed decline concerns workload composition, not declining within-category rates. A targeted investigation addresses that evidence while leaving open whether capacity, demand, or another factor requires action.
