Data storytelling is communicating information to a specific audience with a compelling narrative. It has three components — the data, the narrative and the visuals — and it needs all three. Two of them gets you something. Only all three reliably changes what somebody does.
Most writing on this subject is aimed at data teams presenting once a quarter. Marketers have a different problem: shipping a report every month to someone who half-reads it, and needing them to act on it anyway. This guide is written for that, and it hubs the rest of the practical pieces in this cluster.
What data storytelling means, and what it isn’t
A useful definition has to survive contact with a monthly retainer report, so start with what each of the three components has to be before it earns its place.
The data has to be accurate, reliable and appropriate for generating insight. In practice that means unsampled where the finding depends on precision, drawn from sources that will still be reachable next month, and assembled in a view you could reproduce in front of a sceptical client. If you wouldn’t be comfortable making a strategy decision on it, it isn’t ready to carry a story.
The narrative has to be compelling, action-oriented, and aligned with what the project and its stakeholders are actually trying to do. Not aligned with what you found interesting.
The visuals have to assist trend and pattern identification — they exist to enable an insight that isn’t easily seen in the raw rows and columns. A chart that merely restates a table hasn’t earned the space.
The genuinely useful part of the model is what happens when you’ve only two of the three. That pairwise reading is Brent Dykes’ data, narrative and visuals model, first set out in Forbes in 2016 and expanded in his book Effective Data Storytelling.
Data and visuals enlighten — the reader understands the results, and nothing follows from that. Data and narrative explain — the reader understands the context, but has to picture the shape themselves. Narrative and visuals engage — briefly, and with nothing underneath the claim. Only the combination of all three evokes change, which is the entire reason anyone commissions a report.
How data storytelling differs from reporting and from data visualisation
These three words get used interchangeably and they name three different activities. Reporting is presenting what happened. Data visualisation is making what happened legible. Data storytelling is arranging what happened so the reader arrives somewhere and does something.
You can do the first two beautifully and still hand over an artefact nobody acts on — which is the single most common outcome in agency reporting, and the reason this guide exists.
The four skills data storytelling asks for
Most treatments of data storytelling name three skills: data science, data visualisation, and narrative. That model is incomplete in a way that matters commercially, because it doesn’t explain why two analysts with identical charts and identical findings get different outcomes from the same client.
Data science is knowing how to extract knowledge and insight from data, plus the technical skill of combining and manipulating several sources without breaking the meaning of any of them. In Data Studio terms this is where the distinction between a data source and a dataset and the mechanics of blending do their work.
Narrative is conveying insight, communicating wins and urgency, and demonstrating cause and impact through the data rather than asserting them alongside it.
Data visualisation is understanding how best to visualise a given type of data so that a stakeholder can comprehend a quantity of information nobody could read as rows. Choosing a chart from the shape of your data is the practical version of this skill.
Relationships is the fourth, and it’s the one usually left off. It means understanding your stakeholders: their hidden motivations, and specifically what success and failure look like to them — which is frequently not what the contract says. A consultant who knows that their contact is personally measured on lead quality, and that their contact’s director doesn’t believe in organic search, will write a materially different report from one who doesn’t, using the same numbers.
The practical consequence is that “get better at data storytelling” usually resolves to “understand the people you report to”, not “learn a new chart type”.
Where data storytelling sits in the reporting process, and why it gets skipped
A typical reporting workflow has four stages: data collection, data analysis, data visualisation, and then data storytelling. Storytelling is the last stage and roughly the last ten per cent of the effort — and arguably the most important part of the whole process, because it determines whether the other ninety per cent gets used.
It gets skipped for two structural reasons rather than lazy ones, and naming them helps because they’re both fixable.
The first is scheduling. Storytelling sits last in the workflow, so it is the stage that meets the deadline. Everything before it is a prerequisite; it is the only stage that can be compressed without the report failing to exist. The fix is to write the summary before you build the detail pages rather than after — building the executive summary page on day one is the concrete version of that.
The second is that storytelling needs a skill the other three stages don’t: knowing your stakeholders well enough to know what they would act on. That’s a relationship skill sitting at the end of a technical process, which is a bad place for it, and it explains why teams who are strong at the first three stages often plateau.
Why a dashboard isn’t a data story: exploratory versus explanatory
This is the distinction that does the most work in practice, and it’s the one that separates a consultant whose reports get acted on from one whose reports get filed. The citable origin is Cole Nussbaumer Knaflic on exploratory versus explanatory analysis, written in 2014 and expanded in the first chapter of Storytelling with Data. Her image for it: exploratory analysis is turning over a hundred rocks to find one or two gemstones; explanatory analysis is what happens when you’ve something specific you want to show somebody.
Exploratory analysis means handing someone the data. Sending a client a link to their Search Console, their GA4 property, a live Data Studio dashboard or a third-party tool export. They dig; you haven’t interpreted anything on their behalf. This is useful, honest, and it isn’t a story.
Explanatory analysis means handing over the meaning. A monthly or quarterly report in which you’ve gone through the data at your disposal, the work your team completed, and the results achieved, and put forward an account that explains what happened, why, and what should happen next. It’s also what you produce when hit by an external event — an algorithm update, a new SERP feature, or an industry shift like the arrival of generative search.
The failure mode is presenting one as the other, and it runs in both directions. Send a dashboard link and call it the monthly analysis, and you’ve implied you had nothing to add beyond access. Present an exploratory finding as a causal explanation, and you’ve turned a correlation into a decision nobody should have made. Confusing the purpose of a dashboard with that of a point-in-time report is one of the quickest ways to undermine your authority as a data consultant.
The marketer’s real difficulty is being asked for a single artefact that does both jobs, and the answer isn’t a compromise between them. It’s an explanatory summary page sitting in front of an exploratory report: story first, exploration afterwards. That structure has a name and a research pedigree, covered in the guide to narrative frameworks and the martini-glass structure for dashboards.
Four questions to answer before you build the report
Twenty minutes on these saves rebuilding the report twice, and they’re worth writing down rather than holding in your head.
Who is reading this? Not their job title — what they’re personally accountable for, and what they have to report upward. What decision are they making? If there isn’t one, you’re writing a status update, which is a legitimate artefact as long as everyone knows that’s what it is. What is the one number? If you can’t pick a single number, you don’t yet know what the report is about. What shape is the answer? Up, down, flat, or “it depends on something we need to talk about” — the fourth being the one that most needs a story.
The narrative structure a monthly report actually needs
The most durable structure for a data story is the three-part dramatic shape: setup, conflict, resolution. In the data context it belongs to Scott Berinato’s HBR Quick Study on telling stories with data in three steps, and to his books Good Charts and the Good Charts Workbook. It’s routinely misattributed to Jim Stikeleather’s 2013 HBR article How to Tell a Story with Data, which is about Tufte and audience types and contains no such structure. The underlying dramatic triad is much older and belongs to nobody, running back through Freytag to Aristotle.
Setup is a reality: the situation as it stood. The period, the baseline, what you were trying to do. Conflict is an event that changes that reality — and without this element there’s no storytelling at all, only a status update. Resolution is the new reality the conflict creates, which in a client report means a named action with an owner and a date, or an explicit decision to accept the situation and move on.
That structure translates into four steps you can run against a monthly report. Define the central conflict or question, which in agency reporting usually comes from input and output metric performance and pacing against targets. Provide the context and background, which is what annotating internal and external events directly in the dashboard is for. Present the data and the critical insights, which is where expert commentary attached to specific KPIs earns its place. Then resolve the conflict and conclude — with a roadmap or an action plan, not just a finding.
Several other structures exist and each suits a different situation: Minto’s pyramid for a senior reader who only needs to act, Duarte’s sparkline for a live presentation, the inverted pyramid for something that will be skimmed. Comparing the narrative frameworks and choosing between them is a longer piece of its own.
Where the conflict in an agency report comes from
Since nothing is a story without a conflict, the practical question is where to find one every month without inventing it. In agency reporting it reliably comes from one of three places.
Strategy conflicts sit between what the client is asking for and the goal they set. A client pushing for rankings on terms with no commercial intent is a conflict worth surfacing, and showing the two side by side changes the conversation from a disagreement into a decision.
Internal-event conflicts sit between performance and implementation: recommendations not shipped, tests never run, a migration launched without telling you. The version that lands shows opportunity lost rather than work not done, because a number attached to inaction is much harder to defer than a complaint about it. Raising an implementation gap in the meeting itself has its own etiquette, and the three-column table — what was agreed, what was done, what resulted — does most of the work.
External-event conflicts sit between performance and the market: a competitor tripling publishing output, a new SERP feature taking clicks, an algorithm update. This is the context that stops a flat month reading as failure, and stops a good month reading as a win when it was actually the market moving.
Report all three regularly rather than saving them for the quarterly review. A conflict raised once a quarter has had three months to compound, and by the time it surfaces it reads as an excuse rather than an observation.
The same data can support more than one story — choose deliberately
A dashboard rarely licenses exactly one interpretation, and pretending it does is where reports quietly become dishonest. Here is a real shape: a site where blog posts carry a steady organic base while resource pages produce the traffic spikes, the backlinks and the social mentions.
Read it one way and the story is pursue brand: resources create social mentions, earn links, and occasionally go viral, and a value-based approach builds loyalty. That story produces a roadmap of on-page work on resource pages, more investment in gated content, and a digital authority programme.
Read it the other way and the story is pursue traffic: blog posts drive more sessions overall, traffic converts over time, and the current content performs well but sits too high in the funnel. That story produces a roadmap of harder traffic KPIs, better lead generation inside the blog, and a content pivot down-funnel.
Both readings are supported. The data can’t arbitrate between them, because the choice depends on what the business is for — and that means the choice belongs in the open, with the client, rather than being made silently by whoever wrote the chart titles.
What a Data Studio report with storytelling in it looks like, before and after
The clearest way to show the difference is to take one section of a real SEO report and rebuild it. Nothing in the underlying data changes.
Before is a table of page sections: how many pages in each, the month-on-month change in that count, sessions, and the month-on-month change in sessions, sorted descending. Every figure in it is accurate. There is no title, so the reader has to supply the question themselves. Every row is equally loud, so nothing is being said. The percentages have no visible baseline, which makes a 431% change unreadable — of what? And there’s no cause, no consequence and nobody’s next step anywhere on the page.
After makes five changes, and only one of them touches a chart type.
The sections are cut from six to two — blog and resources — on a stated rule: these are the two the team can directly influence and is actively working on. Pages published are mapped against sessions gained, so the effort sits next to the result and the reader can see the relationship without being told about it. The chart titles become the questions somebody actually asked: how many sessions did we gain from the blog? Two annotations explain the shape — one recording that the resource section was redesigned with new landing pages added, one recording that thin blog posts were deleted and redirected in December, which is what the December-to-January dip is. That second annotation defuses a scary-looking drop that would otherwise consume the meeting. And the section heading becomes the action rather than the subject: not “performance by page section” but what the team should do about it.
The finding this exposes is an uncomfortable one, which is exactly why it lands: despite heavy investment in resource pages, the blog is still producing more traffic and more new users. A report that can’t say that is a status update. A client who hears it can move budget on Monday.
Three things did the work, and none of them was a new chart type: fewer metrics chosen on a stated rule, annotations explaining the shape of the data, and the action in the heading.
Three habits that make any marketing report more readable
These are the cheapest interventions available and they generalise across every report you’ll ever build.
Put context on every number. A comparison period, a denominator, or a related metric beside it. A number with no frame is a fact rather than information, and interpreting it is the job you were hired to do — leaving it to the reader hands your work back to them. Choosing metrics that carry their own context goes into which comparison to pick.
State the “so what” in writing. The finding written down, usually as the chart title. If the insight only exists in your head during the call, the report doesn’t contain it — and the report is what gets forwarded. The “so what?” test for a dashboard is a three-question version you can run over an existing report in an afternoon.
Label anything surprising. A spike with no explanation generates a question; a spike with a label generates a decision. Adding annotations and expert commentary in Data Studio covers the four ways to get real annotations into a report that refreshes itself.
What the evidence for data storytelling actually says
This field quotes its evidence loosely, and a cornerstone piece that repeats the standard numbers without checking them isn’t worth much. So, carefully — including where the evidence doesn’t support what everyone says it does.
The “63% remember stories, 5% remember statistics” claim doesn’t hold up
This is the most-repeated statistic in data storytelling, and it isn’t a study. It comes from a classroom exercise Chip Heath ran at Stanford, reported in Made to Stick: students gave one-minute speeches on crime statistics, averaging 2.5 statistics each, and about one in ten told a story instead. On recall afterwards, 63% remembered the stories and 5% remembered any individual statistic. There is no published paper, no stated sample size, no control condition and no replication. Every one of the several hundred agency posts quoting the figure traces back to that single paragraph.
The experimental work is less flattering still. A 2022 controlled experiment by Zdanovic, Lembcke and Bogers, published at CHIIR, tested data-storytelling visualisations against plain ones and found no significant difference in recall at all, contrary to long-held assumptions in the visualisation community. Cognitive load and the reader’s prior knowledge of the topic appear only as candidate moderators the authors flag for future work.
None of which means storytelling doesn’t work. It means the memory argument is the wrong argument, and repeating it as fact is a small credibility leak in a piece of writing that’s entirely about credibility.
The persuasion evidence is much better founded
Small, Loewenstein and Slovic’s 2007 identifiable-victim study gave participants $5 and a charity appeal. Those who read only the story of Rokia, a seven-year-old girl in Mali, gave a mean of $2.38. Those who read only a statistical appeal about need across several African countries gave $1.14 — a little over twice as much for the story.
The more useful finding is the third condition, which almost nobody quotes: the story plus the statistics raised less than the story alone, and priming people to think analytically reduced giving to the identifiable victim further. Bolting a statistical justification onto a human story doesn’t add persuasion; it subtracts it. For anyone writing a summary page, that’s a direct instruction about what to put next to the headline.
The mechanism underneath is narrative transportation. Green and Brock showed in 2000 that a reader absorbed into a narrative holds more story-consistent beliefs and detects fewer “false notes” in it. That’s worth treating as a warning as much as a technique: the same mechanism that makes your account land is the one that stops the client noticing where it is thin.
The argument against telling stories with data
The counterweight deserves stating in the same breath, and it comes from inside science publishing. Yarden Katz, writing in Nature Methods, put it directly:
“Great storytellers embellish and conceal information as necessary to evoke a response in their audience. Inconvenient truths are swept away while marginalities are amplified or spun to make a point more spectacular.”
That describes what a consultant does to a bad month, precisely. Nature Methods‘ editors made the same point in the same issue: a narrative communicates scientific information effectively, but when telling a perfect story becomes an end in itself, the process is easily compromised.
The practical version for reporting: a compelling narrative built on a correlation is more dangerous than a dull one built on a fact, precisely because it is more persuasive. If you’re inferring rather than measuring, say which — in the report, not just in the meeting.
Ten data storytelling mistakes that cost consultants credibility
These are the recurring failures, each with the mechanism that causes it and the fix. I’ve written about all ten at length before — ten common data storytelling mistakes and how to avoid them works through each in far more depth than a hub page should.
1. Not knowing whether you’re being exploratory or explanatory. The mechanism is that both artefacts look like “the report”, so the choice gets made by whichever one you happened to build. The fix is to decide before you build, and to put an explanatory summary in front of an exploratory dashboard rather than trying to make one artefact do both.
2. Not understanding your own data well enough. Sampling, a filter you forgot was applied, a blend that silently drops rows, a metric that changed definition in the platform. The mechanism is that a report is trusted at the level of its least-checked number, and the failure surfaces publicly. The fix is a reproducibility check: could you rebuild this view from scratch and get the same figure?
3. Choosing the wrong chart for the data. Usually a pie chart doing a bar chart’s job, or a dense combo chart doing an exploratory job on an explanatory page. The fix is to pick from the shape of the data and the question, which is what the chart-type decision matrix is for.
4. Choosing a confusing colour scheme. Colour that decorates rather than means, palettes that collapse under the most common forms of colour vision deficiency, or a scheme where red and green carry opposite meanings on adjacent pages. The fix is to give each colour exactly one job and grey out everything that isn’t the point, which the dashboard design principles guide works through with a colourblind-safe palette test.
5. Choosing an inappropriate medium. A live dashboard sent to someone who will read it once on a phone; a static PDF sent to someone who wanted to dig. The fix is to choose the format from how the artefact will be consumed, which presenting a report to a client works through.
6. Not providing enough context. The most common mistake and the cheapest to fix: a number with no comparison, no denominator and no target. The mechanism is that the reader silently supplies a baseline, and it’s usually the wrong one.
7. Not knowing your audience well enough. Reporting position tracking to someone who is measured on profitability, or implementation detail to someone who joined the call ten minutes late. This is the fourth skill failing, and it costs more than any chart-type error.
8. Not providing commentary or informed analysis. Handing over charts and letting the client interpret them. The mechanism is straightforward: interpretation is the thing they’re paying for, and withholding it reads as either not having a view or not having done the work.
9. Not providing a way out. A report that ends on a chart ends on a question. Leaving the client to derive their own next steps is an abdication — as a consultant it is your role to present the analysis and the recommended actions, owned and dated.
10. Being afraid of the conversation. Softening a bad month, or shaping the account to the reaction you expect — going in combative because you anticipate blame, or downplaying because you anticipate panic. Both produce a subjective report, and objectivity is the entire basis of being believed the following month.
Numbers nine and ten are the ones that separate consultants, and they’re almost absent from the wider literature on this subject.
A note on the Data Studio and Looker Studio names
Google renamed the tool Looker Studio and then renamed it back to Data Studio, so guides published under either name describe the same product. We use Data Studio because it is the current name. Looker without “Studio” is a different product entirely — Google’s enterprise BI platform, with its own visualisations and its own modelling layer.
Frequently asked questions
What is data storytelling?
Communicating information to a specific audience with a compelling narrative. It has three components — the data, the narrative and the visuals — and needs all three: data and visuals enlighten, data and narrative explain, narrative and visuals engage, but only all three reliably change what someone does.
What is the difference between data storytelling and data visualisation?
Visualisation makes data legible; storytelling arranges it so the reader arrives somewhere and acts. You can visualise beautifully and still produce something nobody acts on — the missing pieces are usually context on the numbers and a stated conclusion with an owner.
Why does nobody act on my dashboard?
Usually because it is exploratory when the moment called for explanatory. A dashboard is built for digging; a story is built for deciding. The fix is an explanatory summary page in front of the exploratory report, rather than a compromise between the two.
Where to go next in this data storytelling cluster
- Narrative frameworks, and which one your report needs
- How to build an executive summary page in Data Studio
- The “so what?” test for a dashboard
- Metrics that tell a story, and the ones that do not
- Annotations and expert commentary in Data Studio
- Reference lines, bands and targets in Data Studio
- Data Studio chart types, and how to choose one
- Presenting a Data Studio report to a client
- Who owns the dashboards: reporting operations for agencies
- Dashboard design principles for readable reports