Google Ads scripts every agency should run (and how to run them at MCC level)

TL;DR

Google Ads scripts are free JavaScript automation that runs inside the platform on a schedule — and the agency superpower is that they run at MCC level, sweeping every client account in one execution instead of being installed thirty times. Five scripts cover most of the agency's defensive monitoring: a budget pacing monitor (spend versus month-elapsed, every morning), a broken-URL checker (landing pages that 404 while ads keep spending), an anomaly detector (today versus same-weekday baseline for spend, CTR, and conversions), an N-gram miner (wasted-spend patterns invisible at the search-term level), and a disapproved-ads alert. The discipline that separates agencies that benefit from agencies that accumulate script debt: scripts live in version control, alert into the channel the team actually reads, run as named items on the verification cadence — and when a script's job outgrows the 30-minute execution limit, it graduates to a proper API pipeline like the BigQuery spend export.

---

Most agency Google Ads work is offense — builds, tests, optimizations. Scripts are how the defense runs without consuming the team: the always-on checks that catch the client whose card bounced, the campaign spending against a 404, the Tuesday that's quietly 3x last Tuesday. One specialist can't watch thirty accounts daily. Five scheduled scripts can.

Why MCC-level changes the economics

A single-account script has to be pasted, authorized, and maintained per account — at agency scale that's thirty copies that drift out of sync the first time you fix a bug in one. An MCC-level script (Tools → Bulk Actions → Scripts in the manager account) iterates AdsManagerApp.accounts() and runs the same logic across every linked account in one execution, with one place to fix bugs and one schedule to manage. If your manager account isn't structured for this — orphan links, no naming convention — fix that first; the MCC playbook is the prerequisite for everything below, and the cross-platform context sits in the multi-account pillar.

Two real constraints shape what scripts can do: executions are capped at 30 minutes (an MCC script that does heavy per-account work will hit it around a few dozen accounts — process accounts in chunks, or use the parallel executeInParallel pattern), and scripts are JavaScript with platform entities exposed — powerful for read-and-alert, clumsy for heavy data movement.

The five-script defensive set

1. Budget pacing monitor. Every morning, per account: month-to-date spend versus the client's monthly commitment, compared to the fraction of the month elapsed. Flag anything beyond ±10%. This is the script version of the pacing beat — the full system (why accounts drift, what to do at the month's tail) is its own post in ad budget pacing. Pacing is the single most valuable thing to automate first, because pacing failures compound daily and are invisible account-by-account.

2. Broken-URL checker. Weekly, fetch every final URL across active ads and keywords; alert on 404s/301-chains/server errors. Clients redesign sites without telling their agency — this script is how you find out before the spend does. (It's also the highest goodwill-per-line-of-code script in the set: catching a client's broken page within a day of their deploy reads as omniscience.)

3. Anomaly detector. Daily: compare yesterday's spend, impressions, CTR, and conversions per account against the trailing same-weekday average; alert beyond a sane band (2–3 standard deviations, or simple percentage gates to start). Catches broken conversion tags (the verification problem surfacing as a metrics cliff), runaway broad match, and platform glitches — a day later instead of a report cycle later.

4. Search-query N-gram miner. Monthly: tokenize search terms into 1–2–3-word grams, aggregate spend and conversions per gram. Patterns invisible term-by-term ("free", "jobs", "diy" bleeding spend across hundreds of long-tails) jump out at the gram level, and the output is a ready-made negative-list update for the shared lists the MCC post recommends.

5. Disapproved-ads and policy alert. Daily: scan for disapprovals and limited-by-policy across accounts. A disapproved RSA in a two-ad ad group quietly halves a test; a policy cascade on a health or finance client is an account-level emergency that should never be discovered in a Monday review.

The discipline that keeps scripts alive

Scripts fail the way all unowned automation fails — silently, eventually, embarrassingly. Four rules:

• Version control, not the editor. The script source lives in the agency's repo; the in-platform editor holds a copy. Scripts edited live in production by whoever touched them last are unauditable — and you will want the diff when an alert goes quiet.
• Alert where the team lives. Email-to-a-shared-inbox is where alerts go to die. Pipe to the channel the PPC team actually reads, and make every alert name the client and the action, not just the number.
• Scripts are verifications — schedule their verification. A script that silently stopped running is worse than no script (the team believes the watch is on). A monthly "are all scripts green" check is itself a recurring task with an owner; in Phloz the script layer sits on the client's tracking infrastructure map like any other monitoring asset, with that task attached.
• Know when to graduate. When the job becomes data warehousing (cross-platform spend, restatement-aware history), the 30-minute JavaScript sandbox is the wrong tool — that's an API pipeline writing to the canonical spend table, with scripts staying on the alerting jobs they're good at.

Start with pacing tomorrow morning — it's twenty lines, it runs at MCC level, and it pays for the entire learning curve the first time it catches an account at 140% pace on the 11th of the month.