This is a working Google Ads reporting automation you can build today. Every Monday, someone rebuilds the same report by hand: pull the numbers, drop them in a template, write two sentences of commentary, send it.
A working n8n report pulls spend, conversions and cost per acquisition from the Google Ads API on a schedule, writes them into a Google Sheet next to the trailing period, and has an AI step draft commentary from the numbers you give it, not from numbers it guesses. Below is the actual build: the specific nodes, and the one thing that will quietly ruin it if you skip it.
Why the built-in Google Ads node isn’t enough
n8n ships a native Google Ads node, and it’s thin. Per the official node documentation, it supports getting all campaigns and getting one campaign. That’s the operation list. There’s no built-in way to pull spend, conversions or CPA at the account or campaign level through that node.
You get that data by dropping to the HTTP Request node and calling the Google Ads API’s searchStream endpoint yourself, using a GAQL query against the metrics and segments resources. A basic pull looks like: SELECT campaign.name, metrics.cost_micros, metrics.conversions FROM campaign WHERE segments.date DURING LAST_7_DAYS, authenticated with the same OAuth2 credential and developer token you’d use anywhere else against the API.
The credential setup people skip
The developer token needs Basic or Standard access approved by Google before it works against a live client account rather than a test account, and that approval can take a few days. Apply for it before you promise a client a live date, not after.
The Google Ads reporting automation workflow
A Schedule Trigger fires weekly. HTTP Request calls the GAQL endpoint per client account, looped with a Split In Batches node once you’re past one or two clients. A Set node reshapes the response into flat rows. Those rows land in a Google Sheets node, appended into a running tab rather than overwriting it, so the trailing-period comparison has something to compare against.
Then, and only then, the AI step runs.
Keeping the AI step honest
Give the model the current numbers, the previous period’s numbers, and a narrow instruction: describe what changed and by how much, using only the figures provided. Do not ask it to explain why something changed. It will answer anyway, confidently, and it will be inventing a cause it cannot actually see from a spreadsheet.
We tested this the annoying way, by asking a model to comment on a CPA spike with no context. It produced a plausible-sounding paragraph about seasonal demand fluctuation for an account that had no seasonal pattern at all. It wasn’t lying exactly. It just had nothing to work with and filled the gap the way language models do.
Every generated sentence should trace to a number in the sheet beside it. If a client questions the commentary, you should be able to point at the exact cell in under a minute.
What the report cannot fix
This is the part that matters more than the build. A report only tells you the truth if what it’s reporting is true, and automating the pull doesn’t check that.
We took over a roofing account where the dashboard said 318 conversions at roughly $10 a lead, sixteen months running. A perfectly automated version of that same report would have looked identical: clean data, no errors, green arrows every week. It would have shipped the wrong story faster and to more people. 96% of those 318 were phone-button taps, not calls, and real leads over that period came to 12. We wrote up the full breakdown in the 318-lead mirage, but the point for a reporting build is simpler. Automation makes a report faster, not more honest. Check what your conversion actions actually measure before you automate reporting on top of them, or you’ve just built a faster way to be wrong.
Error handling for a report, specifically
A reporting workflow that returns zero rows because a query failed is worse than one that visibly crashes, because a crash gets noticed and a silent empty report gets emailed to a client looking finished. Assign a dedicated error workflow under the report’s Workflow Settings, and add a Stop and Error node that fires if the row count comes back at zero when it shouldn’t.
Token expiry catches people too. OAuth2 refresh tokens for the Google Ads API can be revoked or expire depending on your app’s verification status, and n8n won’t always surface that clearly. It just starts returning authentication errors on the HTTP node. Build the alert before the report goes live, not after the first silent failure.
What could go wrong
Rate limits across a full roster. One account rarely hits a limit in testing. Ten accounts on the same schedule, all firing at 9am Monday, can. Stagger the schedule or batch with a delay between calls.
Sheet structure drift. If someone manually edits the destination sheet, adds a column, or renames a tab, the append step can silently write into the wrong place. Lock the structure, or write to a dedicated tab nobody touches by hand.
Where I’m still not sure
How much AI commentary is actually worth including. For a $2k a month account, the numbers barely move week to week and the commentary reads as padding. I’ve started leaving it out entirely below a certain spend threshold and just sending the raw table, and I don’t have hard data yet on whether clients prefer that or just haven’t said anything.
If you’re building this, get the tracking right first. Read where wasted spend actually hides for the leaks a good report should be catching, or see the fuller build order in the five n8n workflows to build first. Want this running on your accounts? Book a free audit and we’ll scope it against real data, not a demo account.
Researched and drafted with AI assistance, then reviewed, fact-checked and edited by Rajat Verma before publishing. All account examples are from real campaigns managed by Turquoise Digital and are anonymised.