Never present by screen-sharing an unfiltered dashboard. It’s the most common way these meetings go wrong, and it happens because the report you built for exploring is the one you happen to have open.
This is about the meeting itself: the first ninety seconds, telling the same story to two audiences at once, what to do when the numbers are bad, and the question you’ll always be asked.
Choosing between a live report, a PDF and a deck
Decide before the meeting, because each does a different job.
| Format | Use when | Watch for |
|---|---|---|
| Live report | They’ll want to dig, or you need to answer “what about…” in the room | Loading time, and the temptation to wander. Open on the summary page. |
| It’ll be forwarded, or read again later without you | Exports capture what’s rendered — a paginated table exports only the visible rows. | |
| Deck | Senior audience, or the report is one item on a longer agenda | Screenshots go stale. Date them, and link to the live report. |
The mechanics of exporting and sharing are in how to share and schedule a Data Studio report. What matters here is that a live report is a tool for answering questions, not for delivering a narrative — and if you present from one, you present from the summary page and stay there until you’ve finished saying what you came to say.
What to say in the first ninety seconds of a reporting call
Say the headline before anything else. Not the agenda, not the methodology, not a recap of what you did — the answer.
“Revenue’s up 14%, driven almost entirely by non-brand organic. The thing I want to talk about today is that two of our top pages are at risk, and there’s a decision for you in it.”
That does three jobs at once. It tells them whether to relax, it tells them what the meeting is about, and it puts the decision on the table early enough to actually discuss.
The alternative — building to the finding — works when you’re in the room and controlling the pace. But a client meeting isn’t a keynote. People join late, get pulled out, and check their phones. Front-load it.
Telling the same story twice to two audiences in one meeting
Most client calls have two audiences and they want opposite things.
The specialist — your day-to-day contact, in the detail daily. They need implementation detail, technical clarity, and to feel involved and respected. They’re who you work with every week, and undermining them in front of their boss is expensive in ways that don’t show up for months.
The senior person — doesn’t use the terminology, doesn’t care about position tracking. Cares about profitability, growth, and user experience. Has authority to unblock things, which is usually why you want them there.
Get it wrong in either direction and it costs you. Too technical and the senior person disengages, or derails the meeting with a question you’ve to spend ten minutes on. Too high-level and the specialist feels talked over and starts asking detailed questions to reassert themselves — which reads to their boss as you not having the answers.
The answer isn’t to average them. Tell the same story twice, adapted, in the same meeting. Headline and consequence for the senior person, then “and in detail, what that means for the work is…” for the specialist. Signposting the switch out loud helps both of them.
Translating specialist language for the person who signs things off
The commonest way a senior person disengages isn’t boredom, it is one unexplained term in the first two minutes. After that they’re quietly working out whether to keep listening, and the rest of your findings are competing with that.
The fix isn’t to dumb the report down. It’s to pair every specialist term with the consequence it produces, once, and then use the term freely afterwards.
| What you would say to the specialist | What the senior person needs to hear |
|---|---|
| Crawl budget is being wasted on faceted URLs | Google is spending its time on pages we don’t sell from, so our commercial pages get looked at less often |
| We have index bloat from paginated archives | Thousands of near-duplicate pages are diluting the ones that matter |
| Average position improved from 8.4 to 6.1 | We moved from the bottom of page one to the top half, which is roughly where the clicks start |
| Core Web Vitals are failing on mobile | The site is slow enough on phones that Google has flagged it and some people leave before it loads |
| Non-brand organic is up 22% | More people are finding us who weren’t already looking for us by name |
The right-hand column isn’t a simplification, it is the finding. The left-hand column is how it was measured. Leading with the measurement rather than the finding is the single most common presentation error in technical marketing.
When a client challenges a number in the room
It happens in every long engagement: someone says the figure doesn’t match what they see in their own analytics, or their agency-before-you reported something different, and the meeting stops.
The instinct is to defend the number. Do not — defend the method instead, and do it briefly. “That’s measuring sessions in GA4 with the brand filter applied; the number in your platform excludes internal traffic differently. Both are right, they’re counting different things. I will send the definition.”
Three habits stop this becoming a recurring event. Write the definition of every headline metric down once, where the client can see it, so the discussion happens off the critical path. Never quietly change a definition between reports — announce it in the month it changes. And when you genuinely don’t know why two systems disagree, say so and put a date on finding out, because a confident guess that turns out wrong will be remembered every time you present a number afterwards.
How to present a month where the numbers are bad
Lead with it. A bad number that surfaces on slide seven reads as something you were hoping to get past.
Then give the shape: what happened, what caused it, what it means, what you’re doing. The cause matters most because it determines whose problem it is — and being straight about that early is what stops the conversation becoming about blame.
Two habits do most of the damage here, and both are about you rather than the data:
Being afraid of the conversation. Softening a bad month, or hoping nobody asks. It buys one comfortable meeting and costs the next three.
Shaping the story to the reaction you expect. Going in combative because you think you’ll be blamed, or quietly downplaying because you think they’ll panic. Both produce a subjective account, and objectivity is the whole basis of being believed next time.
When the cause of the drop is on the client’s side
The hardest version: performance is down because recommendations weren’t implemented, or a migration shipped without you.
Report it as a fact with a consequence, not an accusation. The structure that does this best is a table — what was agreed, what was done, what resulted — because the empty cells make the point without you having to say it out loud. That structure is the STAR table in the guide to narrative frameworks for reports.
Two things make it land better. Keep a running record rather than raising it once a quarter, so it’s a standing item rather than an ambush. And bring the numbers: opportunity lost, not just work not done.
Bringing someone more senior on the client side into the conversation
Sometimes the work is blocked by something your contact can’t unblock — a dev resource, a budget line, a decision above them.
Getting someone senior into that conversation isn’t going over anyone’s head, and it’s worth being explicit about why. Your contact has often already asked internally and been told no. An external party raising the same point gets heard differently — that’s not politics, it’s just how organisations weigh things. Done openly, with your contact, it usually helps them rather than exposing them.
Do it with them, never around them. “Would it help if I put this in front of your director?” is a different conversation from your contact discovering you already did.
The question you’ll always be asked: so what should we do?
“So what should we do?”
Have the answer written down before the meeting. Two or three actions, each owned and dated, each tied to the number it’s meant to move.
Improvising this is where credibility leaks. You’ve done the analysis, so you’ve a view — but a view assembled live sounds like a view assembled live, and it’s the part they’ll remember.
The second most common: “why did that happen?” If you don’t know, say you don’t know and say when you’ll. “I don’t know yet, I’ll have an answer by Thursday” costs nothing. A confident guess that turns out wrong costs a great deal.
Six ways a client reporting meeting goes wrong
Screen-sharing the whole report. Every page is equally available, so nothing is being said. You end up narrating charts.
Walking through it in build order. Sources, then channels, then pages, then conversions. That’s the order you made it in, not the order it should be heard in.
Reading the numbers out. They can see the numbers. Say what they mean.
Filling silence. After you’ve stated the headline, stop. The pause is where the conversation you actually want starts.
Ending on a chart. End on the actions, then confirm who’s doing what.
Waiting for the QBR. A conflict raised once a quarter has had three months to compound.
What to send after the reporting meeting
Send the actions in writing the same day — owned, dated, tied to the metric. This isn’t admin. It’s what makes the next report easy to write, because you already know what you’re reporting against.
Keep the same list running month to month rather than starting a fresh one each time. A standing table of what was agreed, what was done and what resulted is the single most useful artefact in a long engagement: it makes progress visible when results are still lagging, and it makes an implementation gap a matter of record rather than an accusation you’ve to raise. That’s the STAR table structure in the guide to narrative frameworks for reports, used as a running document rather than a one-off.
And if the report is going to be read again without you, make sure the summary page carries the story on its own. That’s the job of the executive summary page.
Frequently asked questions
How should I present a Data Studio report to a client?
Decide the format first — live report if they will want to dig, PDF if it will be forwarded, deck for a senior audience. Open on the summary page, state the headline in the first ninety seconds, and end on owned, dated actions rather than a chart.
How do I tell a client that performance is down?
Lead with it, then give the cause, the consequence and what you are doing. Never let a bad number surface late in the meeting; it reads as something you hoped to get past.
How do I present to a technical contact and their boss at the same time?
Tell the same story twice, adapted, and signpost the switch. Headline and consequence for the senior person, then the implementation detail for the specialist. Averaging the two loses both — the senior person disengages and the specialist feels talked over.
Where to go next on presenting and reporting
- Data storytelling for marketers: the full guide
- How to build an executive summary page in Data Studio
- Narrative frameworks, and which one your report needs
- Who owns the dashboards: reporting operations for agencies
- Metrics that tell a story, and the ones that do not
- How to share and schedule a Data Studio report