Google Ads Scripts: What They Do Well, and Where They Stop

A Google Ads script is a piece of JavaScript that runs on Google’s servers against one of your accounts, on a schedule you set. It has read and write access to the account, it can send mail, write to a Google Sheet and fetch a URL, and it costs nothing to run. That combination makes it the cheapest automation available to anyone managing paid search, and also the easiest way to quietly break an account.

This page is the map for the rest of this site: what the environment actually gives you, where it stops, and which of the three jobs a script is genuinely good at.

What a script can reach

The runtime is a sandboxed JavaScript environment with a small set of global objects. The one that matters is AdsApp, which exposes the account in two different ways.

Selectors are the object-oriented layer: AdsApp.campaigns(), AdsApp.keywords(), AdsApp.adGroups(). You filter, you iterate, and each object you get back can be modified in place — paused, bid-changed, labelled. This is how you write to the account.

Reporting is the query layer: AdsApp.search() takes a GAQL query and returns rows. It is read-only, it is far faster over large accounts, and critically it covers campaign types the selectors do not. Most useful scripts read through the query layer and write through the selector layer.

Beyond AdsApp you get a subset of Apps Script: SpreadsheetApp for Sheets, MailApp for email, UrlFetchApp for HTTP requests, Utilities for date formatting and encoding. Those four turn a script from a thing that changes bids into a thing that reports, alerts, and checks the world outside the account.

The three jobs scripts are good at

Reporting. Anything you would otherwise export, paste into a sheet and pivot. Scripts are good here because the output can land in a Sheet or an inbox on a schedule without anyone remembering to do it. The n-gram waste report is this category: it does arithmetic the interface will not do for you.

Monitoring. Comparing today against a baseline and telling you when the difference is real. Spend that jumped, a landing page that started returning 404, a campaign that stopped serving. Google’s own automated rules cover the simplest cases; a script covers the cases where the comparison needs more than one number.

Hygiene at volume. Applying a label to four hundred keywords, adding a negative list to every campaign in the account, pausing ads that point at a dead URL. Work that is not hard, just too repetitive to do by hand and too small to justify the API.

The four jobs they are bad at

Anything real-time. The finest scheduling granularity is hourly. A script cannot react to an auction, and treating it as if it can produces automation that is always acting on stale state.

Bid management. Smart Bidding sees signals a script never will. Writing a script that adjusts bids against a Smart Bidding strategy is fighting the system with worse information. The exception is accounts on manual bidding, which are now rare and usually for a reason.

Heavy computation. There is a thirty-minute wall. A script that joins two years of search terms across forty accounts will hit it, and hit it inconsistently, because execution speed depends on load you cannot see. See the limits before you design anything large.

Anything Google does not expose. Scripts cannot create a Performance Max campaign, cannot edit its text assets, and cannot touch retail listing groups. If the interface will not show you a number, a script will usually not find it either.

The distinction that matters: reads and writes

Every script on this site is labelled with what it writes to the account, and the free ones write nothing. That is not modesty, it is a working rule.

A read-only script that is wrong produces a bad email. A writing script that is wrong pauses forty campaigns at 06:00 on a Saturday, and you find out on Monday from the client. The blast radius is different by orders of magnitude, and the effort to build them is not.

The practical form of this rule is a dry-run flag: the script computes every change, logs what it would do, and applies nothing until you have read the log and flipped one variable. It costs about six lines. The safe automation checklist covers the rest.

Selectors, and the Performance Max trap

AdsApp.campaigns() does not return Performance Max campaigns. It returns Search and Display. Any pacing check, budget monitor or account-wide report written with that selector will silently exclude what is often the largest line in the account, and it will not warn you — the loop simply runs fewer times.

There is a dedicated AdsApp.performanceMaxCampaigns() selector, and for cross-channel reporting there is GAQL FROM campaign, which returns every channel type in one query. What scripts can and cannot do with Performance Max covers where each one applies.

One account or many

A script installed at account level runs against that account. A script installed at manager level can iterate accounts, and with executeInParallel it can process up to fifty of them at once, with a longer execution ceiling. That is the shape of most agency reporting.

It is also where scripts start to strain. Cross-account logic is fragile: one account with a different currency, a different conversion action name or a paused status will break a loop that works everywhere else. Manager-level scripts covers the pattern that survives it.

When to stop scripting

Scripts are the right tool until one of three things is true: you need to run more often than hourly, you need to join Google Ads data with data that lives somewhere else, or you have outgrown the thirty-minute wall. At that point the Google Ads API with a developer token is the honest answer, and the comparison lays out what that actually costs in setup.

Most accounts never reach that point. A dozen read-only scripts, scheduled, landing in one inbox, will catch more real problems than a data warehouse nobody opens.

How to use this library

Every entry in the script library states four things before the code: what it requires, what it writes, how often to schedule it, and which lines to change first. Copy the code, change those lines, run a preview, read the log, then schedule it. Nothing here asks for a signup and nothing here phones home.

If you are installing your first one, start with how to add a script to an account.