How to Automate Google Ads Reporting Using n8n for Free

Key Takeaways

• The pipeline is free — self-hosted n8n, the Google Ads API (free to call), Google Sheets, Looker Studio — but Google Ads API access is genuinely harder to set up than Meta's, so budget more time for the access stage.
• Google Ads access needs three things people conflate: a developer token (from your manager account), OAuth2 credentials with a refresh token for offline access, and the customer IDs. Get all three straight before touching the workflow.
• You query Google Ads with GAQL, its own SQL-like query language, against the search or searchStream endpoint. Learning the shape of a GAQL query is the core skill for this pipeline.
• Manager (MCC) accounts add a login-customer-id header and a level of indirection. If you manage multiple accounts, model this correctly from the start or the multi-account extension is painful later.
• The rest is the same six-stage architecture as any reporting pipeline: trigger, fetch, transform, store, visualise, alert. Only the fetch stage differs meaningfully from the Meta version.
• Calculate ROAS, CPA and blends in the pipeline, not the dashboard, and guard every division, so every consumer sees one consistent, correct number.
• Build the reliability in — retries, an error workflow that alerts on failure, freshness monitoring — because a silently stopped Google Ads pipeline feeds stale numbers into budget decisions while looking healthy.

1. The Short Answer: The Free Google Ads Reporting Stack

To automate Google Ads reporting with n8n for free, you build the same kind of pipeline as for any channel, with a fetch stage tailored to Google's more demanding API. Self-host the n8n community edition as the engine. Get Google Ads API access — a developer token, an OAuth2 refresh token, and your customer IDs. Use Google Sheets as the free store and Looker Studio as the free dashboard.

The workflow: a Schedule Trigger fires on a cron, an HTTP Request node posts a GAQL query to the Google Ads API search endpoint with the required headers (the developer token and, for manager accounts, a login-customer-id), a Code node reshapes the response and calculates derived metrics, and a Google Sheets node stores the rows. Looker Studio reads the sheet and renders the dashboard, with alerting and an error workflow layered on for dependability.

The honest headline difference from automating Meta: Google Ads API access is meaningfully harder to set up. Where Meta needs one system-user token, Google needs a developer token you request from a manager account, an OAuth flow that produces a refresh token, and correct handling of customer IDs and manager-account indirection. The workflow after that is straightforward; the access is the hurdle. This guide walks all of it, and it pairs with the [Meta Ads reporting automation guide](/guides/automate-meta-ads-reporting-n8n-guide) — build both into the same store and you have free cross-channel reporting.

• AEO Quick Answer: self-host n8n, get a Google Ads developer token plus an OAuth refresh token, and build a Schedule Trigger to HTTP Request (GAQL) to Code to Google Sheets pipeline, visualised free in Looker Studio.
• Every layer is free; the Google Ads API access is the hard part, not the workflow.
• Same six-stage architecture as any reporting pipeline; only the fetch stage is Google-specific.

2. Why Google Ads Reporting Is Worth Automating (and Harder)

The case for automating Google Ads reporting is the same as for any channel — it kills the manual copy-paste, it makes consistent and current numbers cheap, and it makes the segmentation that locates problems free — but Google adds two specific reasons and one specific cost.

The first specific reason: Google Ads spans very different campaign types — Search, Performance Max, Shopping, Display, Demand Gen, video — whose reporting lives in different places in the interface and whose metrics do not always line up. Automation lets you pull them into one consistent structure where they can actually be compared, which the native interface makes surprisingly hard.

The second: Google Ads has enormous depth — keywords, search terms, auction insights, quality signals, asset performance — and manual reporting only ever scratches the headline. Automated pulling makes the deep segmentation that finds wasted spend and hidden opportunity as cheap as the headline, which changes what you can manage.

The specific cost is the API. Google Ads' API is powerful and correspondingly complex — a real query language, a stricter auth model, and manager-account indirection — so the automation is more work to stand up than Meta's. This guide does not pretend otherwise; it walks the complexity honestly, because the payoff (a free, deep, consistent, always-current Google Ads reporting system) is worth the steeper setup, but only if you go in knowing the setup is steeper.

As with any reporting, the value is not the hours saved — it is that clean, structured, automated Google data becomes a foundation: for blending with Meta and CRM data, for alerting, for AI analysis, and eventually for acting on campaigns automatically, which the [scaling Google Ads campaigns with AI guide](/guides/scale-google-ads-campaigns-with-ai-guide) builds on top of exactly this base.

• Google spans very different campaign types whose reporting is fragmented; automation unifies them.
• Google's depth (keywords, search terms, assets, quality) is only ever headline-scratched manually.
• The specific cost: a powerful but complex API with a query language, strict auth and manager indirection.
• The payoff is a foundation for blending, alerting, AI and eventual automated action.

3. What 'Free' Actually Means Here

As with the Meta pipeline, 'free' is true in software and false in effort, and the effort is higher here because of the API.

Genuinely free: the n8n community edition (open-source, self-hosted), the Google Ads API itself (free to call — you pay for clicks, not for reading your data), Google Sheets, and Looker Studio. The software bill is zero.

Not free: hosting (an always-on machine — free locally, a few dollars a month on a small cloud server) and, more than with Meta, the setup time. The Google Ads API access alone — developer token, OAuth, customer IDs, manager-account handling — is a real afternoon or more of careful work the first time, and it is where people most often give up. Being honest about that up front is the difference between finishing and abandoning.

A note specific to Google: the developer token. Access to the Google Ads API requires a developer token, obtained through a manager account, and tokens have access levels — a basic or test level for getting started, and higher levels that require an application and approval for larger-scale production use. For a single business reporting on its own accounts, the entry-level access is typically sufficient to begin, but understand which level you have and its limits, because hitting them unexpectedly is a common surprise. Check Google's current documentation for the exact access levels and their limits, as these change.

The framing, same as before: this replaces a paid reporting tool's subscription with your own time and trivial hosting. Given Google's steeper API, the time cost is higher than for Meta, so the trade is a little less lopsided — but for a team that will own the pipeline, it is still an excellent deal, and the depth of data you can reach through the API exceeds what most paid tools expose anyway.

• Free: n8n community edition, the Google Ads API, Google Sheets, Looker Studio.
• Not free: hosting and — more than with Meta — the API setup time.
• Google-specific: a developer token from a manager account, with access levels and limits to understand.
• The trade is a little less lopsided than Meta's because setup is harder, but still excellent for a team that owns it.

4. The Architecture: Same Six Stages

The pipeline shape is identical to any reporting automation, which is worth internalising because it means the only genuinely new thing here is the fetch stage.

Trigger. A Schedule Trigger on a cron — daily for yesterday, weekly for a rollup. Unchanged from any reporting pipeline.

Fetch. Call the Google Ads API with a GAQL query, handling the developer token, OAuth, customer IDs and pagination. This is the stage that differs from Meta and where all the Google-specific complexity lives. It gets the most attention in this guide.

Transform. Reshape the response into clean flat rows and calculate derived metrics — ROAS, CPA, blends. Google returns metrics in a nested structure with a specific unit convention (money in micros, which must be divided down), so the transform has a Google-specific quirk to handle, covered later.

Store. Write clean rows to Google Sheets (or a database at scale). The store is the source of truth everything else reads.

Visualise. Looker Studio renders the dashboard. Note that Looker Studio also has a native Google Ads connector that needs no API work at all — worth knowing as a shortcut for simple cases, and worth outgrowing when you need the depth, the control, and the cross-channel blending that only the API pipeline gives you.

Alert. A branch for the daily digest, threshold alerts and, critically, an alert when the pipeline itself fails. Same as any pipeline, same importance.

Build in this order, prove each stage before the next, and the Google-specific difficulty stays contained in the fetch stage rather than spreading through the whole build.

• Trigger, transform, store, visualise, alert — all standard.
• Fetch is the only Google-specific stage: GAQL, developer token, OAuth, customer IDs, pagination.
• Transform has a Google quirk: money is returned in micros and must be divided down.
• Looker Studio's native Google Ads connector is a no-API shortcut for simple cases — outgrown when you need depth and blending.

5. Prerequisites and n8n Setup

The prerequisites overlap heavily with the Meta pipeline, with Google-specific additions.

A Google Ads account you want to report on, and — this is important — a Google Ads manager account (MCC). The developer token that the API requires is obtained through a manager account, so even if you have a single ad account, you typically need a manager account above it to get API access. If you do not already have one, creating a manager account is an early step.

A Google Cloud project. OAuth credentials for the Google Ads API are created in the Google Cloud console, in a project you own. The project is free; it is the container for the OAuth client that will authorise your API calls.

The developer token, requested from within the manager account's API settings. Understand its access level and limits.

Somewhere to run n8n — the same choice as any pipeline: local Docker for testing (free, only runs when the machine is on), a small always-on cloud server for anything you depend on (a few dollars a month), or n8n Cloud (paid, outside the free goal). Secure it from the start with authentication and HTTPS, because it will hold live credentials to your ad accounts.

A Google account for Sheets and Looker Studio, which you already have if you have Google Ads.

Comfort with APIs and OAuth. The Google Ads pipeline demands a little more technical comfort than Meta's, specifically around OAuth and the refresh-token flow. If OAuth is unfamiliar, the access section below is the one to read slowly and, ideally, to work through with Google's live documentation open alongside, because the exact steps in the consoles change and the concepts are what carry across.

• A Google Ads account and, for API access, a manager (MCC) account to obtain the developer token.
• A Google Cloud project to hold the OAuth client.
• The developer token, with its access level and limits understood.
• An always-on, secured place to run n8n.
• A Google account for Sheets and Looker Studio, and comfort with OAuth.

6. Getting Google Ads API Access (The Hard Part, Done Carefully)

This is the stage that stops people, and it stops them because three separate things — the developer token, the OAuth credentials, and the customer IDs — get conflated. Keep them distinct and the path is walkable.

The developer token identifies your application to Google Ads and gates your access level. You obtain it once, from your manager account's API settings, and you send it as a header on every API request. It is not authentication — it does not say who you are, only what application is calling and at what access level. A common confusion is expecting the developer token to authorise access to accounts; it does not. Authorisation is OAuth's job.

The OAuth credentials authorise access to specific accounts on behalf of a user. You create an OAuth client in your Google Cloud project, then run the OAuth consent flow once to obtain a refresh token — a long-lived token that lets your pipeline get fresh access tokens indefinitely without a human re-authorising each time. The refresh token is the key to unattended automation: an access token expires in an hour, but a refresh token keeps producing new ones. Request offline access with the appropriate Google Ads (AdWords) scope during the consent flow, or you will not receive a refresh token, which is the single most common OAuth mistake here.

The customer IDs identify which account you are querying. Each Google Ads account has a customer ID. For manager accounts, you also send a login-customer-id header identifying the manager account you are authenticating through, distinct from the customer ID of the account whose data you want. Getting the relationship between the login-customer-id (the manager you log in through) and the target customer ID (the account you query) right is the piece people most often get wrong, and it produces confusing permission errors when muddled.

n8n's role. n8n supports OAuth2 credentials, and you configure a credential with your OAuth client details and the refresh token so that n8n handles token refresh automatically on every run. The developer token and login-customer-id are sent as headers on the HTTP Request. Store all of these — client secret, refresh token, developer token — in n8n's encrypted credentials, never in the workflow body.

Prove it outside n8n first. Before wiring anything, confirm you can make a successful API call with your developer token, a valid access token derived from your refresh token, and the right customer IDs — using a simple test query. Debugging the auth inside an automation is far harder than debugging it in isolation. Once a raw call succeeds, reproducing it in n8n is straightforward; until it does, no amount of workflow-building will help.

• Three distinct things: developer token (identifies the app, gates access level), OAuth (authorises account access), customer IDs (which account).
• The developer token is a header, not authentication — a common confusion.
• OAuth's refresh token is the key to unattended automation; request offline access with the AdWords scope or you get no refresh token.
• Manager accounts: the login-customer-id (manager you log in through) is distinct from the target customer ID (account you query).
• Prove a raw API call works before wiring it into n8n; store all secrets in n8n credentials.

7. GAQL: Querying Google Ads

Where Meta's insights endpoint takes parameters, Google Ads takes a query written in GAQL — the Google Ads Query Language — and learning its shape is the core skill of this pipeline.

GAQL looks like SQL and works differently. A query selects fields, from a resource, with an optional where clause for filtering and an order and limit. You select the fields you want — the campaign or ad group attributes and the metrics — from a resource like campaign or ad_group or keyword_view, filter by date and status, and the API returns matching rows. The mental model is 'select these metrics and attributes for this kind of entity, filtered thus', which maps naturally onto a report.

The resource you select from determines the grain. Selecting from the campaign resource gives you campaign-level rows; from ad_group, ad-group-level; from keyword_view, keyword-level; from search_term_view, the actual search terms that triggered your ads. Choosing the right resource for the report you want is the main GAQL decision, and it is the equivalent of Meta's 'level' choice.

Date filtering is explicit and important. GAQL filters dates in the where clause, and Google provides both explicit date ranges and named ranges. Filtering to the right range — yesterday for a daily pull, a window for a rollup — is done here, and getting it right is what makes the pipeline pull the intended data. A segments.date field lets you get daily rows within a range, which is how you build a day-by-day history rather than a single aggregate.

The endpoint and pagination. You send the GAQL query in the body of a POST to the Google Ads API search endpoint (or searchStream for large result sets that stream). The search endpoint paginates with a page token, so — as with Meta — you loop: query, get results and a next-page token, query again with that token, until there is no next token. searchStream streams the whole result set without paging, which is convenient for large pulls but handled differently in the workflow. Choose based on your result sizes and your comfort with each pattern.

Build queries in Google's query tools first. Google provides tools to build and test GAQL queries interactively and see the real response, which is where you should develop and validate a query before putting it in n8n — exactly as you prove any API call in isolation before automating it. A query that works in the query builder will work in the pipeline; a query you wrote blind into n8n is a debugging session waiting to happen.

• GAQL is SQL-like: select fields and metrics from a resource, with a where clause for date and status filters.
• The resource (campaign, ad_group, keyword_view, search_term_view) sets the grain — Google's equivalent of Meta's level.
• Filter dates in the where clause; use segments.date for day-by-day rows rather than a single aggregate.
• POST the query to the search endpoint (paginated with a page token) or searchStream (streams large sets); loop pages as with Meta.
• Develop and validate queries in Google's query tools before putting them in n8n.

8. Building the Workflow, Node by Node

With access proven and a GAQL query validated, the workflow is short and mostly identical to any reporting pipeline. Treat node names as the shape, not a script, since they evolve across n8n versions.

Node one — the Schedule Trigger. Cron cadence: daily early morning for a full previous day, weekly for a rollup. Unchanged from any pipeline.

Node two — the fetch. An HTTP Request node POSTs your GAQL query to the Google Ads API search endpoint. The OAuth2 credential (with your refresh token) authenticates and n8n refreshes the access token automatically; the developer token and, for manager accounts, the login-customer-id go in the request headers. The body contains the GAQL query. All secrets come from n8n credentials, never the node parameters.

Node three — pagination. If using the search endpoint, loop on the page token until there is no next page, accumulating rows; if using searchStream, handle the streamed response according to your n8n version's capabilities. Either way, ensure you capture all rows — the silent partial-data failure is as real here as with Meta.

Node four — the transform. A Code node reshapes Google's nested response into flat rows and calculates derived metrics. This is where you handle Google's specific quirks: money values come back in micros (millionths of the currency unit) and must be divided down to real currency, and metrics are nested under a metrics object that must be flattened. Calculate ROAS, CPA and blends here, once.

Node five — the store. A Google Sheets node appends or upserts the clean rows, one per entity per day, with the standardised columns and context tags (account, level, currency, pull date).

Node six — delivery and alerts. Optionally, a branch for a daily digest and threshold alerts, plus the all-important error alerting. Build the happy path first — trigger, fetch, store — prove it end to end, then add pagination robustness, then transform richness, then alerting. Incremental building means a break is always in the piece you just added.

• Schedule Trigger — cron cadence.
• HTTP Request — POST GAQL to the search endpoint; OAuth2 credential authenticates, developer-token and login-customer-id in headers, all secrets from credentials.
• Pagination — loop the page token (search) or handle the stream (searchStream); capture all rows.
• Code node — flatten, divide micros down to currency, calculate ROAS/CPA/blends once.
• Google Sheets node — append/upsert standardised, tagged rows.
• Optional branch — digest, threshold alerts, and error alerting. Build the happy path first.

9. The Micros Quirk and Other Google-Specific Transforms

Google's API has a few specific conventions that, unhandled, produce wrong numbers that look plausible — the most dangerous kind of bug. The transform stage is where you handle them.

Money in micros. Google returns monetary values — cost, average CPC, conversion value — in micros, which are millionths of the account currency unit. A cost of ten currency units comes back as ten million. If you do not divide by a million, every money figure in your report is off by a factor of a million, and — worse — a ROAS computed from two micro values is coincidentally correct (the millions cancel), so the bug hides until someone reads the raw cost. Divide micros down to real currency in the transform, explicitly and consistently, and document that you have done so.

Nested metrics and attributes. Google's response separates the entity's attributes (its name, ID, status) from its metrics (cost, clicks, conversions) into different parts of each row's structure. The transform flattens these into one flat record. Getting the nesting right is the equivalent of parsing Meta's action arrays — fiddly, and the place wrong numbers originate if rushed.

Conversions and conversion value. Google's conversion model has its own subtleties — conversions can be counted in different ways, attributed across windows, and include or exclude certain conversion actions depending on settings. The numbers your API pull returns reflect your account's conversion configuration, so understand that configuration, because two accounts with different conversion settings are not directly comparable even with identical queries. Document what your conversion metrics actually count.

Segments multiply rows. When you add a segment — by date, by device, by network — Google returns one row per combination, so a campaign with a date segment over a week returns seven rows, and adding a device segment multiplies again. This is powerful and can explode row counts, so segment deliberately, matching the segmentation to the decision, rather than adding every segment and drowning in rows.

Currency and account context. As with Meta, tag every row with its account, currency and the date it was pulled, so multi-account blends do not mix currencies and a re-pull is distinguishable from the original. The transform is the cheap insurance step that prevents a dozen downstream confusions, and it matters more with Google because the multi-campaign-type, multi-segment data is inherently more heterogeneous.

• Money is in micros — divide by a million or every cost figure is off by a million (and ROAS hides the bug).
• Flatten nested attributes and metrics into one flat record — the equivalent of parsing Meta's action arrays.
• Conversion numbers reflect your account's conversion configuration; document what they actually count.
• Segments multiply rows fast — segment deliberately to match the decision, not exhaustively.
• Tag rows with account, currency and pull date so blends and re-pulls stay clean.

10. Choosing What to Report

Google's depth makes 'report everything' even more tempting and even more counterproductive than with Meta. Report what drives decisions, at the grain that matches them.

The efficiency core, at campaign level: cost, impressions, clicks, click-through rate, average cost per click, conversions and conversion value, from which you derive cost per acquisition and [ROAS](/glossary/roas). This answers 'are we spending efficiently' and is the minimum useful report.

The campaign-type view. Because Google spans Search, Performance Max, Shopping, Display, Demand Gen and video, a report that compares efficiency across campaign types is uniquely valuable — it is exactly the comparison the native interface makes awkward, and it surfaces which campaign types are actually earning their budget. Include campaign type as a dimension.

The search-term and keyword depth, for Search campaigns. The search_term_view resource shows the actual queries that triggered your ads, which is where wasted spend on irrelevant terms and untapped high-intent terms both hide. Automating this pull makes a genuinely valuable analysis — which is normally too tedious to do manually — routine. This connects directly to the negative-keyword and bidding discipline in our [Google Ads bid strategies](/resource/blogs/google-ads-bid-strategies) work.

The predictive signals: the trend of cost per acquisition rather than its level, impression share and its lost-to-budget and lost-to-rank components (which tell you whether you are capped by budget or by competitiveness), and quality signals. These tell you where performance is heading and why, which is more actionable than a snapshot.

What to leave out: the same vanity trap. Impressions and clicks are diagnostics, not goals. And with Google's depth specifically, resist pulling every available field into the report just because the API offers it — a report drowning in columns is a report nobody reads. Report the metrics the [performance, social and retention marketing KPI guide](/guides/kpis-performance-social-retention-marketing-guide) identifies as decision-driving, at the grain that matches the decision, and leave the rest available in the API for when a specific question needs it.

• Core: cost, impressions, clicks, CTR, avg CPC, conversions, conversion value; derive CPA and ROAS.
• Campaign-type comparison — uniquely valuable and awkward in the native interface.
• Search-term and keyword depth for Search — where wasted spend and untapped intent hide.
• Predictive: CPA trend, impression share lost to budget vs rank, quality signals.
• Leave out vanity metrics as headlines and resist pulling every field just because the API offers it.

11. Storing, Visualising and Blending

The store and dashboard are the same free stack as any pipeline, with one Google-specific opportunity: blending.

Google Sheets as the store, up to real scale. One row per entity per day, standardised columns, context tags. Sheets is free and native to Looker Studio and right until the volume — which, with Google's segmentation depth, can grow faster than Meta's — actually strains it, at which point a database is worth the complexity. Google's data explodes with segments, so watch your row counts and be deliberate about what you store.

Looker Studio as the dashboard. Build views that answer real questions: an efficiency overview across campaign types, a trend view, a search-term or keyword deep-dive. Keep calculation out of the dashboard — ROAS and blends are computed in the pipeline, displayed in the dashboard. The native Google Ads connector is a shortcut for a quick standalone Google dashboard, but it does not give you the API pipeline's control, depth, or — crucially — the ability to blend.

The blending payoff. This is where the API pipeline earns its extra setup cost over the native connector. Once Google data lands in the same store as Meta data (from the [Meta reporting guide](/guides/automate-meta-ads-reporting-n8n-guide)), with consistent columns, you have a unified cross-channel view — total spend, blended CAC, cross-channel ROAS — that no single platform's native reporting provides and that most paid tools charge for. Building both channel pipelines into one store is the single highest-value move in this whole exercise, because cross-channel truth is what most teams lack and most need.

Design for the reader. The person reading a Google Ads dashboard wants to know whether spend is efficient, which campaign types are working, and where the waste is — quickly. Lead with those, put the deep segmentation a click away, and resist proving how much of Google's vast data you captured. A dashboard that answers the real question in seconds beats a comprehensive one that buries it.

• Google Sheets to real scale; Google's segmentation depth grows rows fast, so watch counts and store deliberately.
• Looker Studio for the dashboard; native connector is a quick shortcut but no depth, control or blending.
• The blending payoff: Google and Meta in one store gives a unified cross-channel view most tools charge for.
• Design for the reader's real question: efficiency, which campaign types work, where the waste is.

12. Delivery, Alerting and Reliability

The alerting and reliability layer is identical in principle to any pipeline and worth restating because it is what makes the thing dependable rather than a demo.

The daily digest and threshold alerts. After the store step, a branch composes a summary — yesterday's spend, ROAS, top movers, impression-share warnings — to Slack, email or Telegram, so the team sees the headline without opening anything. An IF node fires threshold alerts on things needing action: spend over a cap, ROAS under a floor, a campaign spending nothing (often a disapproved ad or an exhausted budget), impression share lost to budget crossing a line. Alert only on genuinely actionable conditions, or the channel gets muted.

Rate limits and quotas. The Google Ads API enforces quotas and rate limits, and heavy pulling — many accounts, deep segmentation, frequent runs — can hit them. Respect this by querying only what you need, spacing requests, and handling a rate-limit or quota response with a wait-and-retry rather than a hard failure. Google's limits interact with your developer token's access level, which is another reason to understand that level.

Retries and the error workflow. Retry transient failures with exponential backoff. And define an n8n error workflow that alerts you whenever the reporting run fails — the single most important reliability feature, because a silently stopped Google Ads pipeline is especially dangerous: budget decisions get made on a dashboard that looks current and stopped updating days ago. An error alert on the pipeline itself is not optional.

Idempotency and freshness. Make re-runs safe by upserting on date and entity rather than blindly appending, so a retry cannot duplicate rows. And monitor data freshness — is the latest row's date what it should be — to catch a silently-stopped pipeline immediately. The Google Ads data is the report's subject; the pipeline is infrastructure, and infrastructure that is not monitored fails invisibly.

Token and access monitoring, Google-specifically. Watch your OAuth refresh token (which can be revoked or, in some cases, expire under certain conditions) and your developer token's access level and quotas. A revoked refresh token silently breaks the pipeline, and it is a Google-specific failure mode worth a specific check.

• Daily digest and threshold alerts (spend cap, ROAS floor, dead campaign, impression share lost to budget) — only on actionable conditions.
• Respect Google's quotas and rate limits, which interact with your developer token's access level; wait-and-retry on throttle.
• Define an error workflow that alerts on failure — critical, because a stopped pipeline feeds stale budget decisions.
• Upsert for idempotent re-runs; monitor data freshness.
• Monitor the OAuth refresh token specifically — a revoked token silently breaks the pipeline.

13. Security and Governance

This pipeline holds OAuth credentials and a developer token to your Google advertising, and its security deserves the same seriousness as the Meta pipeline, with Google-specific notes.

Store every secret in n8n credentials. The OAuth client secret, the refresh token, and the developer token all go in n8n's encrypted credentials, never in the workflow body or a committed file. The refresh token in particular is powerful — it produces access tokens indefinitely — so its exposure is a real breach, and it must never travel in a workflow export.

Least privilege on scope and access. The OAuth scope should be the minimum needed for reporting. Understand what the Google Ads scope grants — API access can be powerful — and be deliberate about which accounts the authorising user can reach, because the pipeline can reach whatever that user can. A reporting pipeline authorised by an account with broad management access carries broad risk if compromised.

Secure the n8n instance. Authentication, HTTPS, restricted access — non-negotiable for an instance holding live Google Ads credentials. An unsecured public n8n instance is those credentials exposed to the internet, which is the most common serious mistake in self-hosted automation.

Manage the developer token and OAuth client as shared assets. These are not personal — they belong to the business, and their management (who can regenerate them, who holds the client secret) should be owned and documented, not dependent on one person's memory. A developer token or OAuth client that only one person understands is a single point of failure for all your Google reporting.

Govern changes to the pipeline. As with any shared automation, decide who owns the workflow and how changes are reviewed, because a quiet change — the wrong customer ID, a different metric definition, a currency mishandled — produces subtly wrong reports that erode trust. Treat it as infrastructure with an owner and a change process.

• Store the OAuth client secret, refresh token and developer token in n8n's encrypted credentials, never in the workflow.
• The refresh token is powerful — its exposure is a real breach; never export it in a workflow.
• Least privilege on OAuth scope and on which accounts the authorising user can reach.
• Secure the n8n instance with authentication and HTTPS; treat developer token and OAuth client as owned business assets.
• Govern pipeline changes; subtly wrong reports from unreviewed changes erode trust.

14. Common Mistakes, and What to Do Instead

Conflating the developer token with authentication. The developer token identifies the app and gates access level; it does not authorise account access. Instead, keep the three concerns distinct: developer token, OAuth, customer IDs.

Not requesting offline access, so you get no refresh token. The pipeline then cannot run unattended. Instead, request offline access with the Google Ads scope during the OAuth consent flow, and confirm you received a refresh token.

Muddling login-customer-id and the target customer ID. This produces confusing permission errors. Instead, be clear that the login-customer-id is the manager you authenticate through and the target customer ID is the account you query.

Forgetting that money is in micros. Every cost figure ends up a million times too large. Instead, divide micros down to currency in the transform, explicitly, and document it.

Adding every segment. Row counts explode and the report drowns. Instead, segment deliberately to match the decision.

Calculating in the dashboard. It scatters logic and produces inconsistent numbers. Instead, calculate ROAS, CPA and blends once in the pipeline.

No error alerting. A silently stopped Google Ads pipeline feeds stale budget decisions. Instead, define an error workflow and monitor freshness and the refresh token.

Pasting secrets into nodes. The refresh token and developer token end up exposed. Instead, use n8n's encrypted credentials without exception.

Using the native connector when you need depth or blending. It cannot do cross-channel or the deep segmentation. Instead, use it for quick standalone dashboards and the API pipeline for anything real.

Ignoring the developer token's access level. You hit unexpected limits. Instead, understand your access level and its quotas, and plan pulls within them.

15. Extending It: Cross-Channel, Depth and AI

A solid Google pipeline is a foundation, and the extensions are where the setup cost pays back.

Cross-channel blending, again, because it is the biggest prize. Google and Meta in one store, with consistent columns, gives a unified view of total spend, blended CAC and cross-channel ROAS that no native reporting provides. If you build only one extension, build the Meta pipeline alongside this one into a shared store — cross-channel truth is what most teams most lack.

Google's unique depth. Automated search-term and keyword pulls make routine the analysis that finds wasted spend and untapped intent, which is normally too tedious to do regularly. Auction insights, asset performance and impression-share diagnostics become continuous rather than occasional. This depth is where Google reporting automation pays back beyond mere time savings — it makes management decisions possible that manual reporting never surfaces.

AI on clean Google data. Feed the structured data to a language model for narrative summaries of what changed and why, or to anomaly detection that flags unusual movements across Google's many campaign types and segments. As always, AI is useful on clean, reliable, structured data and produces nonsense on raw exports — the pipeline is the prerequisite, not an afterthought.

Closing the loop to action. The most advanced extension connects reporting to action: with write access and real guardrails, the same platform can act — pausing wasteful search terms, adjusting budgets, flagging assets. That is the subject of the [scaling Google Ads campaigns with AI guide](/guides/scale-google-ads-campaigns-with-ai-guide), and it is a deliberate step beyond reporting, carrying real risk and demanding real guardrails, but built on exactly this reporting foundation.

• Cross-channel blending with Meta into one store is the biggest prize — build both pipelines if you build one extension.
• Google's depth: routine search-term, keyword, auction-insight and impression-share analysis that manual reporting skips.
• AI on clean structured data for narratives and anomaly detection — the pipeline is the prerequisite.
• Close the loop to action only with write access and guardrails — a deliberate step beyond reporting.

16. Putting It Together

Automating Google Ads reporting with n8n for free is achievable and genuinely worthwhile, and the stack is the same as any reporting pipeline — self-hosted n8n, the free API, Google Sheets, Looker Studio — with a fetch stage that is meaningfully harder than Meta's.

The honest truth is that the Google Ads API access is the hurdle: a developer token from a manager account, an OAuth refresh token from offline access, and correct customer-ID handling, with GAQL as the query language on top. Keep those concerns distinct, prove a raw call works before automating, and the rest of the pipeline is short and standard.

The Google-specific traps — money in micros, segments multiplying rows, the developer token's access level, the login-customer-id relationship — are all avoidable once named, and this guide has named them. The reliability layer, especially an error alert on the pipeline itself and monitoring of the refresh token, is what keeps it dependable rather than a demo that silently rots.

The payoff is real: free, deep, always-current Google Ads reporting, and — when built alongside the Meta pipeline into a shared store — a unified cross-channel view most teams lack and most tools charge for. That data foundation is the base for alerting, AI analysis, and eventually acting on campaigns automatically. If you would rather have this designed and run for you as part of a broader growth system, that is where our [process automation](/solutions/process-automations) and [ROAS optimisation](/solutions/roas-optimization) engagements do their work.