Google Ads Reporting With AI: Kill the Friday Deck

Reporting is not a dashboard problem — it is a question-answering problem. Every report you have ever sent exists to answer someone's questions: what happened, why, and what are you doing about it. Dashboards answer the first question and go silent on the other two, which is why the Friday deck takes hours: a human sits between the dashboard and the narrative. A connected AI collapses that gap, because it can read the account and write the explanation in the same pass.

Why dashboards answer last week's questions

A dashboard is a set of questions someone froze into widgets, months ago. Spend by campaign, conversions over time, device split — all fine, all static. The question your stakeholder actually asks on Friday is never on it: "why is CPA up if we changed nothing?", "is the new campaign cannibalising the old one?", "what happens if we move budget to the thing that is working?"

Every one of those requires a join the dashboard does not have — performance data crossed with change history, search terms, or budget constraints. So the analyst opens six tabs and builds the answer by hand. That labour, repeated weekly, is the real cost of reporting, and it is precisely the labour a connected model does in minutes. The follow-up question is the one clients actually pay for — and the follow-up is what AI reporting is uniquely good at.

The plain-English report: asking for what changed and why

The foundational reporting prompt has three clauses — window, movement, cause:

For account 123-456-7890, compare last week (Mon-Sun) with the week
before. Report spend, conversions, cost per conversion and impression
share by campaign. For every metric that moved materially, explain
the most likely cause — check search terms, change history, budget
limits and auction pressure before answering — and cite the data
behind each explanation.

The instruction to check specific causes matters. Left to itself, a model will narrate the numbers ("CPA increased due to higher costs" — thank you). Told where to look, it comes back with the kind of finding a senior analyst produces: the CPA rise traces to one campaign hitting its budget cap on the two strongest weekdays, or to a batch of new broad-match terms that spent without converting.

Building a repeatable weekly readout with saved prompts

The difference between a good session and a good process is that the process survives being busy. Save the readout prompt somewhere durable — a notes file, a doc, or a file in a repo if you work from Claude Code or a similar client — with three things pinned:

• Fixed definitions. The date convention, the conversion actions that count, the comparison window. Consistency is what makes week eight comparable to week one.
• Materiality thresholds. Tell it what "moved materially" means for this account, in its own units — a threshold tied to a day's typical spend works better than any universal number.
• Output format. Table of movers first, causes second, proposed actions third. Same shape every week, so readers stop re-learning the report and start reading it.

Then the weekly ritual is: run it, interrogate anything surprising with follow-ups, verify, send. Ten minutes on a clean week, twenty on an eventful one. Version the prompt like the asset it is — when a threshold or definition changes, note the date, because report-over-report comparability is the property readers silently rely on.

Client-safe summaries: numbers, causes, next actions

The internal readout and the client summary are different documents. The client version needs three short layers and no metric dump:

From that analysis, draft a client summary: one paragraph of results
in plain language, the two or three causes that explain the movement,
and the actions we will take next with what we expect from each.
No jargon, no metric the reader will not recognise.

Two edits to make before sending, every time. First, cut any claim you have not verified. Second, make sure proposed actions are ones you actually intend to take — the model proposes freely, and a client summary is a commitment device.

One skeleton does not fit every reader, and the fix is a sentence in the prompt rather than a second workflow: for a CMO, lead with trend and risk; for a founder, lead with cash effect and the single number that changed; for a marketing peer, keep the mechanics in. The analysis underneath stays identical — the model re-cuts the narration per audience faster than you could re-outline it. For the multi-client version of this workflow — templating without sounding templated, and handling the months where the numbers went the wrong way — see the agency reporting guide.

Where Looker Studio and connectors still fit

Honest boundary: the AI readout does not replace the always-on surface. A live dashboard still earns its place for the stakeholder who wants to glance at spend mid-month without starting a conversation, for wall screens, and for the archival record of standard metrics. What changes is the division of labour — the dashboard stops pretending to explain, and the explanation stops pretending to be a chart. Keep the Looker Studio report as the reference surface; move the narrative, the causes and the recommendations to the AI readout. What disappears is the hours spent manually assembling narrative from dashboard screenshots.

Verifying AI numbers against the UI before you send them

Trust is earned by reconciliation, so budget ninety seconds for it. Pick the headline number — usually spend and conversions for the period — and check it against the interface. When they disagree, the cause is nearly always one of four frames rather than an error:

Mismatch cause	What it looks like	The fix
Date range	Close but consistently off	Pin exact dates, not relative phrases
Timezone	Yesterday's numbers differ early in the day	Use the account timezone in prompts
Conversion lag	Recent days look worse in one view	Exclude the last few days or note the lag
Conversion actions	One view counts more conversions	Name the actions that count in the prompt

A worked example of the frame problem: the model reports 41 conversions for last week; the interface shows 47 this morning. Neither is wrong — the model read the account on Friday, conversions kept attaching to last week's clicks over the weekend, and by Thursday both views will agree on a higher number still. Lag is not an error; it is a property of the metric. The prompt fix is one clause: state the read date, and note which recent days are still filling in.

Same API underneath, so a real discrepancy that survives all four checks is rare — and worth investigating for its own sake, because it usually means a tracking change nobody announced. That investigation is a job for a fuller AI audit session.

The Friday deck did not die because decks are bad. It dies because its three jobs — what, why, next — are now a saved prompt, a verification glance, and a send. Keep the judgement; retire the assembly.