In short: PPC automation didn't become newly possible. It became newly affordable. AI didn't add capabilities; it collapsed the payback period on ones we've had since 2019, turning six-month builds into two-week ones. The winners are the super-seniors who finally get to build the workflows that never used to pay off, like clearing thousands of junk search queries with a model an ordinary PC can run.
I once watched our systems architect, a man with twenty-five years of engineering behind him, spend two full days reading Google Ads API documentation before a single query returned data. Two days, one query. He is the best engineer I know, and it still took him two days. That was simply the entry fee the platform charged anyone who wanted the real power.
I’ve spent about twenty years in PPC, twelve of them writing code against that API. Between 2015 and 2017 I ran ppc-scripts.eu, a small blog about Google Ads Scripts, back when automating PPC wasn’t cool yet. Then I stopped writing. Not because the ideas dried up. The gap between “this is possible” and “this is worth doing for a client” stayed stubbornly wide for a decade, and there are only so many ways to describe tools nobody can afford.
This spring I delivered a market-expansion analysis, sixteen products priced across five countries with heat maps, in about six hours. Done by hand, that’s around 400 hours of work. Built as custom software the old way, it’s two months of development and an invoice of €16,000 to €20,000 that no client ever wanted to pay. Same deliverable, and the price collapsed. Nothing about the analysis got smarter this spring. The economics of building it broke.
Almost everything you’ve read about AI killing the PPC specialist gets that mechanism backwards. AI didn’t change what you can do in paid search. Most of it was always possible, and most of it existed by 2019. What it changed is who can afford to do it. This article is the proof, told from inside the tools I actually build with. Two eras that made automation too expensive to bother with, the moment the math flipped, and one real job, clearing junk search queries with a local open-source model, broken down step by step.
- AI added almost no new PPC capabilities. It collapsed the payback period on the ones we've had since 2019, and that alone rewrites what's worth building.
- The decisive currency stopped being lines of code. What's scarce now is ideas plus domain knowledge, knowing what to build and which data to join.
- The craft is splitting in two. Those who skip the tools freeze in place; those who know the Google Ads API to the bone and combine data with imagination pull ahead.
- The worked example inside shows a local open-source model clearing thousands of junk search queries in minutes, a job that used to be strictly manual.
The Scripts era: a few days for a “simple” script
The ceiling was never the technology, and I want to show you that from the very first tool I touched. Google Ads Scripts felt like magic when they arrived. JavaScript, right in the account, looping over campaigns. In practice a “simple” script, say pausing keywords over a CPA threshold or flagging broken final URLs, took a few days of writing and debugging once you handled the edge cases, the quotas and the silent failures.
Then came the part nobody budgeted for. Running it across accounts meant one copy of the script per account, drifting out of sync, breaking quietly whenever one client’s naming convention didn’t match the others. Scaling and distribution was its own job. So most scripts in the wild never went past reporting, pulling some numbers into a Sheet on a schedule. Anything that actually changed the account was too fragile and too expensive to maintain.
Even the easy automation layer was gated by maintenance cost, not capability. Carry that forward. It’s the pattern of everything that follows.
The API era: two days to the first query, two years to a tool
The Google Ads API, the AdWords API back then, was the real power and the real wall. The two days my colleague spent in the documentation weren’t a knock on him. That was the surface area everyone signed up for.
We went all in anyway and built PPC Robot, a deeply customizable reporting and operations tool. Technically beautiful, genuinely powerful. It also took two developers, full-time, two years, and the development it needed to keep going ran somewhere around €100,000 a year. It never paid for itself. It covered a fraction of what our PPC specialists actually needed, so eventually we parked it in a limited internal mode. Not because it was bad. Because the math never closed.
And we still shipped real things on top of that API, four and five years ago:
What that engine actually produced
- 404 / broken final-URL checker across accounts shipped
- Shopping campaign generator from the feed shipped
- Shopping / Performance Max segmentation shipped
- BigQuery pipeline + reporting into Sheets / Excel shipped
- Merchant Center account status checks shipped
Look at that list and notice something. None of it is exotic by today’s standards. It was all possible. It just cost a fortune to build and a fortune to keep alive. Every meaningful feature, a keyword-research tool, an expansion tool, ad translation, a Shopping generator, was measured in months of two seniors’ time, and no client would pay what that costs.
The ceiling was never the technology. It was the payback period.
The first job that broke free: junk search queries
“AI changed everything” is a claim you should refuse to take on faith. So here are two jobs that used to be uneconomic and now aren’t. Both are things I run, not hypotheticals, and for the first one I’ll walk you through the whole flow.
Cleaning irrelevant search terms out of an account is high-value and mind-numbing, and until recently there was no honest way to automate it. Rules can catch an exact token, but deciding whether “nike air max history” is worth paying for takes reading comprehension. So the job stayed a semi-manual crawl through thousands of queries, eyeballing patterns, adding negatives by hand. Picture a running-shoe shop paying for clicks on “running shoes repair”, “nike air max history” and “free running shoes”, none of which it sells or services. Multiply that by thousands of rows, every week, across every account. That’s the job nobody wants and everybody needs.
Here’s what changed. A Python script pulls the queries from the Google Ads API and hands them to an open-source model, Google’s Gemma 4, that nearly any current PC can run. It reads thousands of queries in a few minutes. And when you ground it in context about the client, the sitemap, the site and DB structure, the breadcrumb taxonomy, the product feed, it stops guessing and starts reasoning. It excludes correctly and names the patterns behind the junk, faster than any human skim. Here’s that flow as five concrete steps.
PULL · get the raw search terms
Pull the search-terms report from the Google Ads API. Query, clicks, cost, conversions. Why first: this is the evidence, the actual money already spent on each term. You want cost attached to every row so the model can tell expensive junk from harmless junk. You get: a flat table of every term the account has paid for in the window.
GROUND · build a context pack about the site
Assemble what the site actually is, in a form the model can read. The XML sitemap, the breadcrumb taxonomy, the product feed (id, title, category), and the DB and category structure. Why this is the whole game: a model with no context guesses; a model that knows you have no “repair” or “rental” category reasons. You get: a context pack that turns the model from a guesser into something that knows your catalogue.
ASK · classify queries and name the patterns
Prompt Gemma 4 with the terms plus the context pack. Classify each query as relevant or irrelevant to what we sell, and, the important part, return the patterns behind the irrelevant ones (a token, an intent, a category mismatch). Why patterns, not rows: flagging 200 junk queries saves you an afternoon; naming the category of junk excludes the next thousand you haven’t even seen yet. You get: an irrelevant-query list and, above it, the handful of rules that generated it.
REVIEW · validate the rules, not the rows
A human reads the patterns, five to ten of them, not 5,000 individual rows. Why this is the time saver: judgment is applied once per rule instead of once per query, and a wrong rule is obvious in a way a single mislabeled row never is. You get: a short, trusted list of exclusion patterns a human actually signed off on.
PUSH · add the negatives at the right level
Push the approved negatives back through the API at the correct level, ad group, campaign or shared list, depending on how broad the pattern is. Why level matters: a site-wide junk token (“free”, “wikipedia”) belongs on a shared list, not buried in one ad group. You get: a clean account and a reusable negative list that keeps working next week.
To see why this works, look at what the ASK step actually returns for our running-shoe shop. The rows are illustrative, the shape is exactly what comes back, and the prize is the block at the bottom:
Query Verdict Why
free running shoes irrelevant freebie intent, no purchase
running shoes repair irrelevant service we don't offer
nike air max history irrelevant informational, no buy intent
running shoes wikipedia irrelevant reference-seeker
→ PATTERN: tokens "free", "repair", "history", "wikipedia"
= non-commercial modifiers absent from our taxonomy.
Recommend excluding as a shared negative list.Four rows became one rule. A human reads that one line, agrees it’s right, and the rule keeps catching “running shoes free shipping returns”-style junk you haven’t even seen yet. That’s the moment a mind-numbing weekly chore becomes a ten-minute review.
The quiet headline here is that an open-source model running locally is enough. You don’t need a frontier API to make this pay, and your data never leaves the house. That’s the economics moving, not the capability.
The second job: keyword research
This one used to be a budget line of its own. Real keyword research, the kind that maps demand to your landing pages and tells you what’s missing from the site, used to mean dozens of hours of pulling data (AdWords API, suggest boxes, OpenRefine), semi-manual cleanup, classification by landing page, and trend, volume and gap reporting on top.
One keyword-research project, then vs. now
- The old way (data pull, clean, classify, report) 50–100 hrs
- What the client paid for that ≈ €2,000–4,000
- The same project today, with one good skill single-digit hrs
- And the output is more accurate
It’s not just cheaper. It’s better, more precise, with the hours spent on validation and judgment instead of on plumbing. Cheaper and better is exactly the combination that was supposed to be impossible. I’ve broken the modern version down end to end in the market-expansion blueprint and the content-gap analysis, both with the real intermediate output shown at every step.
The part that still surprises me is the cadence. Research like this used to be an annual project a client signed off on once. The same pipeline can now run daily, watching demand move instead of photographing it once a year.
The economics, before and after
This is the whole thesis in one table. Same jobs, same quality bar; only the cost of doing them moved. Documented figures where I have them, order-of-magnitude from twenty years of agency work for the rest.
| The job | The old way | Today |
|---|---|---|
| Market-expansion analysis (multi-market pricing) | ~400 hrs by hand · or 2 months dev, €16–20k | 6 hrs |
| Keyword research (one project) | 50–100 hrs · €2,000–4,000 billed | single-digit hrs · more accurate |
| Negative-query triage | semi-manual crawl, thousands of rows by hand | script + local model names the patterns |
| Ship one new automation feature | months (2 devs × 2 yrs for one whole tool) | weeks |
| Keep a reporting engine alive | ~€100k / yr, never paid for itself | near-zero with a local model |
Read the table top to bottom and the pattern repeats in every row. The capability column didn’t move; we could do all of this in 2019. The price column fell through the floor. And the payback period is what decides whether a smart idea ever gets built.
AI didn’t unlock new PPC capabilities so much as it collapsed the payback period on the old ones. When a six-month build becomes a two-week build, the entire backlog of “we’d love to, but it’d never pay off” suddenly clears.
What it looks like when you lean into it
Lynt has been a tech-heavy agency from day one. We have a systems architect, a security engineer, a data analyst building BI and a full-time developer on the team, which a normal agency simply doesn’t. For years that muscle was hard to point at PPC problems, for all the payback reasons above. Now it compounds.
Boostera, our own tool, took two years of development. It enriches Google Merchant Center feeds with AI, so Shopping campaigns run on better product data than the raw feed gives them. Around it sits the plumbing the new economics finally justifies. Competitor price scraping per market, the kind that fed the pricing tables in the expansion blueprint. Keyword-research pipelines that run on a schedule instead of once a year. Customer-level business reporting in BigQuery with forecasts on top. MCP servers on every service we touch, so an AI agent can pull from any of them mid-task.
Two years ago I would have had to defend each of those projects against the same question, will it ever pay for itself. Today the question barely comes up. When builds get cheap, infrastructure stops being a luxury and starts being the moat.
What this actually means for the industry
The popular take says AI is ending the PPC specialist. Getting that backwards has real career consequences for people reading this, so let me plant a flag.
“The era of PPC specialists is ending” is nonsense. The opposite is happening. Good specialists spent years frustrated that the smart thing, the thing they could clearly see, wasn’t worth building. Now they get to build it. Automatically, profitably, at scale. A whole shelf of PPC strategies that used to be uneconomic or simply absurd to attempt is suddenly on the table.
What is happening is a sharper split inside the craft. On one side stand the people who treat the platform UI as the whole job and let the new tools pass by. Nobody fires them tomorrow. They freeze in place while the job moves. On the other side stand the people who know the Google Ads API to the bone, join data sources nobody else joins, and build themselves specialized dashboards instead of waiting for a vendor to ship a feature. Twelve years of writing code against that API taught me where the second group’s edge really lives. The code got cheap. What stayed scarce is imagination and domain knowledge, knowing which data to combine and why.
And to kill the obvious misreading, this is no story about cheaper service. Tools, compute and development still cost money. The point is that a project that used to be four to six months of two senior developers now ships in weeks, so the investment finally makes sense. The client gets a dramatically better service for a similar price.
Why I’m writing again
I stopped blogging in 2017 because the gap between an idea and an economically sane execution was too wide to be interesting. That gap just closed. So this blog picks up where ppc-scripts.eu left off, and it stays concrete. Use cases with real numbers, the exact flows, the actual outputs, messy parts and limits included. The first deep dives are already up.
Somewhere in your own backlog is the automation you shelved years ago because it would never pay off. Dig it out and run the numbers again. If they’ve flipped the way mine did, you know what to build next. And if you want to compare notes, you know where to find me.
FAQ
Are you saying agencies should fire their PPC specialists?
The exact opposite. Specialists who understand strategy and tools are now more valuable, because they can finally execute the ideas that used to be uneconomic. What shrinks is the value of pure platform-UI button-pushing.
Is the €100k/year and two-devs-for-two-years figure exact?
No, treat it as order-of-magnitude. The point isn’t the precise euro amount. A single in-house reporting engine carried a six-figure annual cost and still never paid for itself. That’s the economics this whole piece is about.
Do I need an expensive frontier model to do this?
Not for jobs like negative-query triage. A capable open-source model such as Gemma 4, run locally with good site context, does the work. That keeps both your data and your costs in your control.
Is this only about search queries?
No, that’s just the easiest job to watch run. The same economics moved for market-expansion analysis (six hours instead of ~400), competitor price scraping per market, keyword research that runs daily instead of once a year, and feed enrichment with Boostera. Pick whichever chore you shelved and rerun its numbers.
So this is just hype with a fresh coat of paint?
If it were, I wouldn’t have started writing again. The change is narrow and real, a collapsed payback period on capabilities we already had. That’s a business change, not a magic one, and it’s why the backlog suddenly clears.
What will actually be on this blog?
Concrete use cases with numbers, the flows behind them, and the outputs, limits and failure modes included. Less manifesto, more of the exact thing we ran and what it returned.
