Kort gezegd: PPC-automatisering werd niet ineens mogelijk — het werd ineens betaalbaar. AI voegde geen mogelijkheden toe; het liet de terugverdientijd instorten van dingen die we al sinds 2019 hadden, en maakte van bouwprojecten van zes maanden klussen van twee weken. De winnaars zijn niet minder specialisten, maar super-seniors die eindelijk de workflows bouwen die zich vroeger nooit terugverdienden — zoals het schiften van irrelevante zoekopdrachten met een lokaal Gemma-model.
Het hele argument in één zin
PPC goed automatiseren kon altijd al — het verdiende zichzelf alleen nooit terug, dus deed bijna niemand het. AI gaf ons geen nieuwe krachten; het liet de kosten instorten van het gebruiken van de oude, en die ene economische verschuiving zet een decennium aan “we zouden dolgraag willen, maar het zou zich nooit terugverdienen” weer op tafel. Alles hieronder is het bewijs, verteld vanuit de tools waar ik echt mee bouw — niet vanuit een keynote van een leverancier.
Dit haal je concreet uit dit stuk: de drie tijdperken die PPC-automatisering te duur maakten om de moeite te nemen, het exacte moment waarop de rekensom dit jaar omsloeg, en één echte klus — rommel-zoekopdrachten opruimen met een lokaal open-source model — stap voor stap uiteengerafeld, met op elke fase de tussentijdse output waar je naar zou staren. Aan het eind kun je het verschil zien tussen “AI gaf ons nieuwe vaardigheden” (grotendeels onwaar) en “AI veranderde wie zich de oude kan veroorloven” (waar het echt om gaat), en heb je een flow die je kunt kopiëren.
Tussen 2015 en 2017 had ik een kleine blog over Google Ads scripts, daarna ben ik gestopt met schrijven. Niet omdat de ideeën opdroogden — maar omdat de kloof tussen “dit kan” en “dit is de moeite waard voor een klant” een decennium lang hardnekkig wijd bleef. Bijna alles wat je hebt gelezen over AI die de PPC-specialist om zeep helpt, heeft het mechanisme achterstevoren. AI veranderde niet wat je kunt doen in paid search. Het meeste kon altijd al. Wat het veranderde is wie het kan doen, en tegen welke kosten — en dat is een veel grotere zaak dan weer een knop voor automatisch bieden. Ik laat je zien hoe ik dat weet.
Het Scripts-tijdperk: een paar dagen voor een “simpel” script
Waarom ik hier begin: om je te laten zien dat het plafond nooit de technologie was. Het was de arbeid, vanaf de allereerste tool die ik aanraakte.
Google Ads Scripts voelden als magie toen ze kwamen. JavaScript, direct in het account, in een loop over campagnes. In de praktijk was een “simpel” script — zoekwoorden pauzeren boven een CPA-drempel, kapotte final-URL’s markeren — een paar dagen schrijven en debuggen zodra je de randgevallen, de quota’s en de stille fouten te pakken had.
Toen kwam het deel waar niemand budget voor had: het over meerdere accounts draaien. Eén script per account, gekopieerd en geplakt, uit sync drijvend, stilletjes brekend zodra de naamgevingsconventie van één klant niet matchte met de rest. Schalen en distributie was een klus op zich. Dus de meeste scripts in het wild kwamen nooit verder dan rapportage — wat cijfers in een Sheet trekken volgens een schema. Alles wat het account daadwerkelijk veranderde was te kwetsbaar, en te duur om te onderhouden, om het de moeite waard te maken voor de meeste bureaus.
De les die je meeneemt: zelfs de “makkelijke” automatiseringslaag werd begrensd door onderhoudskosten, niet door wat mogelijk was.
Het API-tijdperk: twee dagen tot de eerste query, twee jaar tot een tool
Waarom dit ertoe doet: dit is waar de terugverdienkloof zo wijd werd dat het een zakelijke beslissing werd, geen technische.
De Google Ads API — destijds de AdWords API — was de echte kracht, en de echte muur. Ik zag onze systeemarchitect, een man met ruim 25 jaar engineering achter zich, twee volle dagen documentatie lezen voordat er ook maar één query data teruggaf. Dat is geen sneer naar hem. Dat is het oppervlak waar je je voor inschreef.
We gingen toch all-in en bouwden PPC Robot: een diep aanpasbare rapportage- en operationele tool, technisch prachtig, oprecht krachtig. Het kostte ook twee developers, fulltime, twee jaar. De ontwikkeling die nodig was om het draaiende te houden liep rond de €100.000 per jaar — ongeveer, orde van grootte — en het verdiende zichzelf nooit terug. Het dekte een fractie van wat onze PPC-specialisten echt nodig hadden, dus uiteindelijk parkeerden we het in een beperkte interne modus. Niet omdat het slecht was. Omdat de rekensom nooit klopte.
En we leverden alsnog echte dingen op bovenop die API, vier en vijf jaar geleden:
Wat die machine daadwerkelijk produceerde
- 404 / kapotte final-URL-checker over alle accounts geleverd
- Shopping-campagnegenerator vanuit de feed geleverd
- Shopping / Performance Max segmentatie geleverd
- BigQuery-pipeline + rapportage naar Sheets / Excel geleverd
- Merchant Center accountstatus-checks geleverd
Kijk naar die lijst en merk iets op: niets ervan is exotisch volgens de huidige maatstaven. Het kon allemaal. Het kostte alleen een fortuin om te bouwen en een fortuin om in leven te houden. Elke betekenisvolle feature — een zoekwoordenonderzoek-tool, een uitbreidingstool, advertentievertaling, een Shopping-generator — werd gemeten in maanden. Dat is de hele les van dat tijdperk in één zin: het plafond was nooit de technologie. Het was de terugverdientijd.
Twee dingen die dit jaar braken
Waarom ik nu concreet word: “AI veranderde alles” is een claim die je moet weigeren op goed geloof aan te nemen. Dus hier zijn twee klussen die vroeger onrendabel waren en dat nu niet meer zijn — allebei dingen die ik draai, geen hypothesen — en voor de eerste laat ik je precies zien wat elke stap oplevert.
1. De verkeerde zoekopdrachten uitsluiten
Irrelevante zoekopdrachten uit een account opschonen is waardevol en geestdodend. De oude manier was een half-handmatige tocht door duizenden zoekopdrachten, patronen scannen met het blote oog, met de hand uitgesloten zoekwoorden toevoegen. Stel je de situatie voor: een hardloopschoenenwinkel betaalt voor klikken op “hardloopschoenen reparatie”, “nike air max geschiedenis” en “gratis hardloopschoenen” — die hij geen van alle verkoopt of repareert. Vermenigvuldig dat met duizenden rijen, elke week, over elk account. Dat is de klus die niemand wil en iedereen nodig heeft.
De handeling die veranderde: een Python-script haalt de zoekopdrachten op uit de Google Ads API en geeft ze aan een open-source model — Googles Gemma 4 — met goede instructies en, cruciaal, context over de site: de sitemap, de site-/DB-structuur, de breadcrumb-taxonomie, de product feed. Het resultaat: het model markeert niet alleen losse rommel-zoekopdrachten; het brengt de patronen erachter naar boven, sneller en goedkoper dan een mens dat scant. Hier is die flow als vijf concrete stappen.
PULL — haal de ruwe zoekopdrachten op
Haal het zoekopdrachtenrapport op uit de Google Ads API: zoekopdracht, kliks, kosten, conversies. Waarom eerst: dit is het bewijs — het echte geld dat al aan elke term is uitgegeven. Je wilt kosten gekoppeld aan elke rij zodat het model dure rommel van onschuldige rommel kan onderscheiden. Je krijgt: een platte tabel van elke term waarvoor het account in het venster heeft betaald.
GROUND — bouw een context-pakket over de site
Verzamel wat de site daadwerkelijk is, in een vorm die het model kan lezen: de XML-sitemap, de breadcrumb-taxonomie, de product feed (id, titel, categorie) en de DB-/categoriestructuur. Waarom dit het hele spel is: een model zonder context gokt; een model dat weet dat je geen “reparatie”- of “verhuur”-categorie hebt redeneert. Je krijgt: een context-pakket dat het model verandert van een gokker in iets dat je catalogus kent.
ASK — classificeer zoekopdrachten en benoem de patronen
Prompt Gemma 4 met de termen plus het context-pakket: classificeer elke zoekopdracht als relevant / irrelevant voor wat we verkopen, en — het belangrijkste deel — lever de patronen achter de irrelevante op (een token, een intentie, een categoriemismatch). Waarom patronen, geen regels: 200 rommel-zoekopdrachten markeren bespaart je een middag; de categorie rommel benoemen laat je de volgende duizend uitsluiten die je nog niet eens hebt gezien. Je krijgt: een lijst met irrelevante zoekopdrachten en, daarboven, de handvol regels die de lijst opleverden.
REVIEW — valideer de regels, niet de rijen
Een mens leest de patronen — vijf tot tien ervan — niet 5.000 losse rijen. Waarom dit de tijdwinst is: het oordeel wordt één keer per regel toegepast in plaats van één keer per zoekopdracht, en een foute regel valt op een manier op die een enkele verkeerd gelabelde rij nooit zou doen. Je krijgt: een korte, vertrouwde lijst met uitsluitingspatronen die een mens echt heeft afgetekend.
PUSH — voeg de uitgesloten zoekwoorden op het juiste niveau toe
Push de goedgekeurde uitgesloten zoekwoorden terug via de API op het juiste niveau — advertentiegroep, campagne of gedeelde lijst — afhankelijk van hoe breed het patroon is. Waarom het niveau ertoe doet: een site-breed rommel-token (“gratis”, “wikipedia”) hoort op een gedeelde lijst, niet weggestopt in één advertentiegroep. Je krijgt: het account opgeschoond, en een herbruikbare lijst met uitgesloten zoekwoorden die volgende week blijft werken.
De stille kop hier is niet “AI is slim.” Het is dat een lokaal draaiend open-source model genoeg is — je hebt niet eens een frontier-API nodig om dit rendabel te maken. Dat is de economie die verschuift, niet wat mogelijk is.
Zie het draaien: wat elke stap daadwerkelijk uitspuugt
De vijf stappen zijn het recept; dit is het eten. Hieronder staat het concrete artefact dat elke stap je overhandigt voor onze hardloopschoenenwinkel — waar je letterlijk naar kijkt voordat je verder gaat. De vormen zijn precies wat de tools teruggeven; de rijen zijn illustratief, geen echte klant. (Overal illustratieve voorbeelden.)
PULL → de ruwe zoekopdrachten, met geld eraan vast. Elke term waarvoor het account betaalde, gesorteerd zodat de verspilling zichtbaar is:
Search term Clicks Cost Conv
running shoes 420 €310 12
free running shoes 88 €61 0
running shoes repair 54 €40 0
nike air max history 31 €24 0
running shoes wikipedia 19 €14 0Vier van deze vijf rijen zijn pure uitgaven met nul conversies — €139 die het account nooit had hoeven betalen. Het probleem is overduidelijk in vijf rijen en onzichtbaar in vijfduizend.
GROUND → het context-pakket waartegen het model redeneert. Geen proza — een compacte kaart van wat de site echt is:
sitemap.xml → 1,010 URLs (categories, products, blog)
breadcrumb tax. → Footwear > Running > Road / Trail
product feed → 1,205 SKUs (id, title, category, price)
DB structure → no "repair", "rental" or "history" nodes existDie laatste regel doet het werk: het model weet nu dat “reparatie” niet iets is wat deze winkel aanbiedt, in plaats van te gokken.
ASK → oordelen, en de patronen erboven. Het model geeft een oordeel per zoekopdracht terug — maar de hoofdprijs is het blok onderaan:
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.Vier rijen werden één regel. Die regel vangt “hardloopschoenen gratis verzending retour”-achtige rommel die je nog niet hebt gezien — wat precies het punt is.
REVIEW → een mens tekent de regel af. Je leest één zin — “non-commercial modifiers absent from our taxonomy” — bent het ermee eens dat het klopt, en je bent klaar. Geen 5.000 rijen scrollen. Het oordeel valt één keer.
PUSH → de uitgesloten zoekwoorden landen op het juiste niveau. Omdat het patroon site-breed is, gaat het op een gedeelde lijst met uitgesloten zoekwoorden, niet op één advertentiegroep:
Shared negative list: "non-commercial modifiers"
free · repair · history · wikipedia · manual · pdf
Applied to: all Search campaignsEén patroon, één lijst, elke campagne beschermd — en het blijft volgende week zijn waarde verdienen zonder weer een menselijke ronde. Dat is het moment waarop een geestdodende wekelijkse klus een review van tien minuten wordt.
2. Zoekwoordenonderzoek
De tweede klus is degene die vroeger een eigen budgetregel was. Echt zoekwoordenonderzoek — het soort dat vraag koppelt aan je landingspagina’s en je vertelt wat er op de site ontbreekt — betekende vroeger tientallen uren data trekken (AdWords API, suggest-boxen, OpenRefine), half-handmatig opschonen, classificatie per landingspagina, en rapportage over trends / zoekvolume / gaps bovenop.
Eén zoekwoordenonderzoek-project, toen vs. nu
- De oude manier — data trekken, opschonen, classificeren, rapporteren 50–100 uur
- Wat de klant daarvoor betaalde ≈ €2.000–4.000
- Hetzelfde project vandaag, met één goede skill enkele uren
- En de output is nauwkeuriger
Het is niet alleen goedkoper. Het is beter — preciezer, met de uren besteed aan validatie en oordeel in plaats van aan het stugge sjouwwerk eronder. Die combinatie, goedkoper én beter, is precies wat onmogelijk hoorde te zijn. Ik heb de moderne versie van begin tot eind ontleed in de blueprint voor marktexpansie en de content-gap-analyse — allebei met de echte tussentijdse output op elke stap getoond.
De economie, vóór en na
Dit is de hele these in één tabel. Dezelfde klussen, dezelfde kwaliteitslat — alleen de kosten om ze te doen verschoven. Gedocumenteerde cijfers waar ik ze heb; de rest is orde van grootte uit twee decennia waarin één bureau dit deed.
| De klus | De oude manier | Vandaag |
|---|---|---|
| Zoekwoordenonderzoek (één project) | 50–100 uur · €2.000–4.000 gefactureerd | enkele uren · nauwkeuriger |
| Zoekopdrachten schiften | half-handmatige tocht, duizenden rijen met de hand | script + lokaal model benoemt de patronen |
| Eén nieuwe automatiseringsfeature leveren | maanden (2 devs × 2 jr voor één hele tool) | weken |
| Een rapportagemachine in leven houden | ~€100k / jr, verdiende zichzelf nooit terug | bijna nul met een lokaal model |
Lees de tabel van boven naar beneden en het patroon is op elke rij hetzelfde: de kolom met wat mogelijk is veranderde niet — we konden dit allemaal al in 2019. De prijs-kolom zakte door de vloer. Dat is geen technologieverhaal. Het is een terugverdientijd-verhaal, en de terugverdientijd is wat beslist of een slim idee ooit gebouwd wordt.
Wat je je eigen moet maken: AI ontsloot niet zozeer nieuwe PPC-mogelijkheden, het liet de terugverdientijd op de oude instorten. Wanneer een bouwproject van zes maanden een klus van twee weken wordt, ruimt de hele backlog van “we zouden dolgraag willen, maar het zou zich nooit terugverdienen” ineens op.
Wat dit echt betekent voor de branche
Waarom ik hier een vlag plant: de populaire stelling — “AI maakt een einde aan de PPC-specialist” — is lui, en het verkeerd hebben heeft echte gevolgen voor de carrière van mensen die dit lezen.
“Het tijdperk van de PPC-specialist loopt ten einde” is onzin. Het tegenovergestelde gebeurt. Goede specialisten waren jarenlang gefrustreerd dat het slimme — het ding dat ze duidelijk zagen — “het bouwen niet waard was.” Nu mogen ze het bouwen. Automatisch, rendabel, op schaal. Een hele plank vol PPC-strategieën die vroeger onrendabel of simpelweg absurd waren om te proberen, ligt ineens op tafel.
Wat er wel gebeurt is een scherpere splitsing binnen het vak. Aan de ene kant juniors zonder verbeelding, visie of toolvaardigheid — mensen die de platform-UI behandelen als de hele baan. Aan de andere kant super-seniors die de tools hanteren, de workflows uitvinden, buiten de hokjes van het platform denken, databronnen koppelen die niemand anders koppelt, en zichzelf gespecialiseerde dashboards bouwen in plaats van te wachten tot een leverancier een feature uitbrengt.
En om de voor de hand liggende misvatting de kop in te drukken: dit is geen verhaal over goedkopere dienstverlening. Tools, rekenkracht en ontwikkeling kosten nog steeds geld. Het punt is dat een project dat vroeger zes maanden ontwikkeling was nu twee weken is — dus de investering is eindelijk logisch. De klant krijgt een dramatisch betere dienst voor een vergelijkbare prijs, geen slechtere voor minder.
Waarom ik weer schrijf
Ik stopte jaren geleden met bloggen omdat de kloof tussen idee en economisch verstandige uitvoering te wijd was om interessant te zijn. Die kloof is net gesloten. Dus deze blog is terug, en hij wordt concreet: use cases met echte cijfers, de exacte flows, de daadwerkelijke outputs — inclusief de rommelige delen en de grenzen. De eerste deep dives staan al online; er komen er meer.
Als jouw reactie op dit alles is “we kunnen eindelijk dat ding doen dat we altijd al wilden” — mooi. Dat is het hele punt van dit tijdperk. Laten we het bouwen.
Het deel dat je kunt jatten
Het schiften van irrelevante zoekopdrachten met een lokaal open-source model (Gemma 4) — de vijf-stappenflow hierboven, als copy-paste recept:
1. PULL Google Ads API → search-terms report (query, clicks, cost, conv)
2. GROUND Build a context pack the model can reason against:
- sitemap.xml (what the site actually sells)
- site / DB structure + breadcrumb taxonomy
- product feed (id, title, category)
3. ASK Prompt Gemma 4: "Given this site context, classify each query as
relevant / irrelevant to what we sell. Return the irrelevant ones
AND the PATTERNS behind them (token, intent, category mismatch)."
4. REVIEW Human validates the ~10 patterns, not 5,000 rows one by one.
5. PUSH Add negatives back via the API at the right level (shared list for
site-wide junk tokens; ad group for local noise).Drie dingen die beslissen of dit zich terugverdient:
- Context is het hele spel. Een model zonder site-context gokt; een model met je sitemap, taxonomie en feed redeneert. Geef het grond voordat je het vertrouwt.
- Jaag op patronen, niet op rijen. De winst zit niet in het markeren van losse rommel-zoekopdrachten — het is het model dat de categorie rommel benoemt zodat je de volgende duizend ook uitsluit.
- Open-source is genoeg. Je hebt hier geen frontier-API voor nodig. Een goed lokaal model houdt de data in huis en de kosten bijna nul — wat precies de reden is dat het zich eindelijk terugverdient.
FAQ
Bedoel je dat bureaus hun PPC-specialisten moeten ontslaan?
Precies het tegenovergestelde. De specialisten die strategie en tools begrijpen zijn nu waardevoller, want ze kunnen eindelijk de ideeën uitvoeren die vroeger onrendabel waren. Wat krimpt is de waarde van puur knoppen drukken in de platform-UI.
Klopt het bedrag van €100k/jaar en twee devs voor twee jaar exact?
Nee — zie het als een orde van grootte. Het gaat niet om het precieze eurobedrag; het gaat erom dat één interne rapportagemachine een jaarlijkse kostenpost van zes cijfers droeg en zichzelf nog steeds nooit terugverdiende. Dat is de economie waar dit hele stuk over gaat.
Heb ik een duur frontier-model nodig om dit te doen?
Niet voor klussen als triage van uitsluitings-zoekopdrachten. Een capabel open-source model zoals Gemma 4, lokaal gedraaid met goede site-context, doet het werk — wat zowel je data als je kosten in je eigen hand houdt.
Wat maakt de AI-uitsluitingsronde beter dan zelf met mijn ogen scannen?
Twee dingen: het leest het volledige zoekopdrachtenrapport in plaats van een steekproef, en het levert de patronen op, niet alleen de rijen. Je valideert tien regels in plaats van vijfduizend rijen, en die regels blijven volgende week nieuwe rommel afvangen. De mens tekent nog steeds af — het model doet alleen het doorbladeren.
Dus dit is gewoon hype in een nieuw jasje?
Als dat zo was, was ik niet opnieuw gaan schrijven. De verandering is smal en echt: geen nieuwe mogelijkheden, maar een ingestorte terugverdientijd op bestaande. Dat is een zakelijke verandering, geen magische — en daarom ruimt de backlog ineens op.
Wat komt er eigenlijk op deze blog te staan?
Concrete use cases met cijfers, de flows erachter en de outputs — inclusief grenzen en faalmodi. Minder manifest, meer “dit is precies wat we draaiden en wat het opleverde.”
