Kort gezegd: PPC-automatisering werd niet ineens mogelijk. Het werd ineens betaalbaar. AI voegde geen mogelijkheden toe; het zorgde ervoor dat dingen die we al sinds 2019 hadden zichzelf veel sneller terugverdienen, waardoor ontwikkeltrajecten van zes maanden klussen van twee weken werden. De winnaars zijn de super-seniors die eindelijk de workflows mogen bouwen die zich vroeger nooit terugverdienden, zoals duizenden rommel-zoekopdrachten opruimen met een model dat op een gewone pc draait.
Ik heb ooit toegekeken hoe onze systeemarchitect, een man met vijfentwintig jaar engineering achter zich, twee volle dagen Google Ads API-documentatie las voordat één query data teruggaf. Twee dagen, één query. Hij is de beste engineer die ik ken, en toch kostte het hem twee dagen. Dat was simpelweg het entreegeld dat het platform vroeg van iedereen die zijn echte kracht wilde benutten.
Ik zit zo’n twintig jaar in PPC en programmeer al twaalf jaar met die API. Tussen 2015 en 2017 draaide ik ppc-scripts.eu, een kleine blog over Google Ads Scripts, toen PPC automatiseren nog niet cool was. Daarna stopte ik met schrijven. Niet omdat de ideeën opdroogden. De kloof tussen “dit kan” en “dit is de moeite waard voor een klant” bleef een decennium lang hardnekkig breed, en er is nu eenmaal een grens aan het aantal manieren waarop je tools kunt beschrijven die niemand kan betalen.
Dit voorjaar leverde ik een marktexpansie-analyse op, zestien producten geprijsd in vijf landen, met heat maps, in ongeveer zes uur. Handmatig is dat zo’n 400 uur werk. Gebouwd als maatwerksoftware op de oude manier zou het twee maanden ontwikkeling zijn en een factuur van € 16.000 tot € 20.000 die geen enkele klant ooit wilde betalen. Dezelfde deliverable, en de prijs stortte in. De analyse werd dit voorjaar niet slimmer. De rekensom achter het bouwen ervan is compleet omgeslagen.
Bijna alles wat je hebt gelezen over AI die de PPC-specialist om zeep helpt, heeft dat mechanisme precies verkeerd om. AI veranderde niet wat je kunt doen in paid search. Het meeste kon altijd al, en het meeste bestond al in 2019. Wat veranderde is wie het zich kan veroorloven. Dit artikel is het bewijs, verteld vanuit de tools waar ik echt mee bouw. Ik neem je mee langs twee tijdperken die automatisering te duur maakten om er moeite voor te doen, het moment waarop de rekensom omsloeg, en één echte klus: rommel-zoekopdrachten opruimen met een lokaal open-source model, stap voor stap uiteengerafeld.
- AI voegde vrijwel geen nieuwe PPC-mogelijkheden toe. Het maakte de terugverdientijd van de mogelijkheden die we al sinds 2019 hadden drastisch korter, en dat alleen al herschrijft wat het bouwen waard is.
- De beslissende valuta is niet langer regels code. Wat schaars is, zijn ideeën plus domeinkennis, weten wat je moet bouwen en welke data je moet koppelen.
- Het vak splitst in tweeën. Wie de tools links laat liggen, blijft stilstaan; wie de Google Ads API door en door kent en data combineert met verbeelding, trekt weg.
- Het uitgewerkte voorbeeld hieronder laat een lokaal open-source model duizenden rommel-zoekopdrachten in minuten opruimen, een klus die tot voor kort strikt handwerk was.
Het Scripts-tijdperk: een paar dagen voor een “simpel” script
Het plafond was nooit de technologie, en dat wil ik je laten zien vanaf de allereerste tool waar ik ooit mee werkte. Google Ads Scripts voelden als magie toen ze kwamen. JavaScript, direct in het account, in een loop over campagnes. In de praktijk kostte een “simpel” script, zeg zoekwoorden pauzeren boven een CPA-drempel of kapotte final-URL’s markeren, een paar dagen schrijven en debuggen zodra je de randgevallen, de quota’s en de stille fouten had afgedekt.
Toen kwam het deel waar niemand budget voor had. Het over meerdere accounts draaien betekende één kopie van het script per account, en die kopieën raakten uit sync en gingen stilletjes stuk zodra de naamgeving van één klant niet matchte met de rest. Schalen en distributie vormden een klus op zich. Dus de meeste scripts in het wild kwamen nooit verder dan rapportage, wat cijfers volgens schema in een Sheet trekken. Alles wat het account daadwerkelijk veranderde was te kwetsbaar en te duur in onderhoud.
Zelfs de makkelijke automatiseringslaag werd begrensd door onderhoudskosten, niet door wat mogelijk was. Neem dat mee. Het is het patroon van alles wat volgt.
Het API-tijdperk: twee dagen tot de eerste query, twee jaar tot een tool
De Google Ads API, destijds nog de AdWords API, was de echte kracht en de echte muur. De twee dagen die mijn collega in de documentatie doorbracht waren geen sneer naar hem. Dat was de complexiteit die iedereen erbij moest nemen.
We gingen toch all-in en bouwden PPC Robot, een tot in de details aanpasbare tool voor rapportage en operations. Technisch prachtig, oprecht krachtig. Het kostte ons ook twee developers, twee jaar lang, fulltime. En daarna kostte alleen de ontwikkeling die het draaiende hield al zo’n € 100.000 per jaar. Het verdiende zichzelf nooit terug. Het dekte een fractie van wat onze PPC-specialisten echt nodig hadden, dus uiteindelijk beperkten we het tot intern gebruik. 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, dan valt je iets op. Niets ervan is exotisch naar huidige maatstaven. Het kon allemaal. Het kostte alleen een fortuin om te bouwen en een fortuin om in leven te houden. Elke betekenisvolle feature werd gemeten in maanden werk van twee seniors, of het nu ging om een zoekwoordenonderzoek-tool, een uitbreidingstool, advertentievertaling of een Shopping-generator, en geen enkele klant wilde betalen wat dat kostte.
Het plafond was nooit de technologie. Het was de terugverdientijd.
De eerste klus die eindelijk rendabel werd: rommel-zoekopdrachten
“AI veranderde alles” is een claim die je niet voor zoete koek moet aannemen. 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 loop ik de hele flow met je door.
Irrelevante zoekopdrachten uit een account halen is waardevol en geestdodend, en tot voor kort was er geen betrouwbare manier om het te automatiseren. Regels vangen een exact token, maar beslissen of “nike air max history” een klik waard is, vergt begrijpend lezen. Dus bleef de klus een half-handmatig doorspitten van duizenden zoekopdrachten: patronen scannen met het blote oog, uitgesloten zoekwoorden met de hand toevoegen. Stel je een hardloopschoenenwinkel voor die betaalt voor klikken op “hardloopschoenen reparatie”, “nike air max geschiedenis” en “gratis hardloopschoenen”: hij repareert niet, hij geeft niets weg, en wie de modelgeschiedenis opzoekt, komt niet kopen. Vermenigvuldig dat met duizenden rijen, elke week, in elk account. Dat is de klus die niemand wil en iedereen nodig heeft.
Dit is wat veranderde. Een Python-script haalt de zoekopdrachten op uit de Google Ads API en geeft ze aan een open-source model, Googles Gemma 4, dat op bijna elke huidige pc draait. Het leest duizenden zoekopdrachten in een paar minuten. En als je het voedt met context over de klant, de sitemap, de site- en DB-structuur, de breadcrumb-taxonomie, de productfeed, stopt het met gokken en begint het te redeneren. Het sluit de irrelevante zoekopdrachten correct uit en benoemt de patronen achter de rommel, sneller dan een mens ze kan doornemen. Hier is die flow als vijf concrete stappen.
PULL · haal de ruwe zoekopdrachten op
Haal het zoekopdrachtenrapport op uit de Google Ads API. Zoekopdracht, klikken, 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 de periode 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 productfeed (id, titel, categorie) en de DB- en 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 of irrelevant voor wat we verkopen. En het belangrijkste: lever de patronen achter de irrelevante op (een token, een intentie, een categoriemismatch). Waarom patronen, geen rijen: 200 rommel-zoekopdrachten markeren bespaart je een middag; de categorie rommel benoemen sluit de volgende duizend uit die je nog niet eens hebt gezien. Je krijgt: een lijst met irrelevante zoekopdrachten en daarboven de handvol regels waaruit die lijst is voortgekomen.
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 meteen op, terwijl een enkele verkeerd gelabelde rij ongemerkt voorbijglipt. Je krijgt: een korte lijst met uitsluitingspatronen die een mens echt heeft nagelopen en goedgekeurd.
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 rommel-token dat voor de hele site geldt (“gratis”, “wikipedia”) hoort op een gedeelde lijst en moet niet worden weggestopt in één advertentiegroep. Je krijgt: een schoon account en een herbruikbare lijst met uitgesloten zoekwoorden die volgende week blijft werken.
Om te zien waarom dit werkt, kijk naar wat de ASK-stap daadwerkelijk teruggeeft voor onze hardloopschoenenwinkel. De rijen zijn illustratief, de vorm is precies wat er terugkomt, en het waardevolste deel is het blok onderaan:
Zoekopdracht Oordeel Waarom
gratis hardloopschoenen irrelevant wil iets gratis, koopt niet
hardloopschoenen reparatie irrelevant dienst bieden we niet aan
nike air max geschiedenis irrelevant informatief, geen koopintentie
hardloopschoenen wikipedia irrelevant zoekt naslaginformatie
→ PATROON: tokens ‘gratis’, ‘reparatie’, ‘geschiedenis’, ‘wikipedia’
= niet-commerciële toevoegingen die niet in onze taxonomie staan.
Advies: uitsluiten via een gedeelde lijst met uitgesloten zoekwoorden.Vier rijen werden één regel. Een mens leest die ene zin, is het ermee eens dat hij klopt, en de regel blijft “gratis hardloopschoenen weggeefactie”-achtige rommel vangen die je nog niet eens hebt gezien. Dat is het moment waarop een geestdodende wekelijkse klus een review van tien minuten wordt.
Wat hier onderbelicht blijft, is dat een lokaal draaiend open-source model genoeg is. Je hebt geen frontier-API nodig om dit rendabel te maken, en je data verlaat nooit je eigen machine. Wat veranderde is de economie, niet wat mogelijk is.
De tweede klus: zoekwoordenonderzoek
Deze was vroeger een eigen budgetpost. Echt zoekwoordenonderzoek, 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, volume en 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 AI-skill enkele uren
- En de output is nauwkeuriger
Het is niet alleen goedkoper. Het is beter, preciezer, omdat de uren naar validatie en oordeel gaan in plaats van naar het aan elkaar knopen van data. Goedkoper én beter is precies de combinatie die 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 bij elke stap getoond.
Het deel dat me nog steeds verrast is het ritme. Onderzoek als dit was vroeger een jaarlijks project dat een klant één keer goedkeurde. Dezelfde pipeline kan nu dagelijks draaien en de vraag zien bewegen in plaats van hem één keer per jaar te fotograferen.
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. Waar ik gedocumenteerde cijfers heb, gebruik ik ze; de rest zijn ordes van grootte uit twintig jaar bureauwerk.
| De klus | De oude manier | Vandaag |
|---|---|---|
| Marktexpansie-analyse (prijzen over meerdere markten) | ~400 uur handmatig · of 2 maanden dev, € 16.000–20.000 | 6 uur |
| Zoekwoordenonderzoek (één project) | 50–100 uur · € 2.000–4.000 gefactureerd | enkele uren · nauwkeuriger |
| Rommel-zoekopdrachten schiften | half-handmatig doorspitten, 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 herhaalt zich op elke rij. De kolom met wat mogelijk is bewoog niet; dit konden we allemaal al in 2019. De prijskolom kelderde. En de terugverdientijd is wat beslist of een slim idee ooit gebouwd wordt.
AI ontsloot nauwelijks nieuwe PPC-mogelijkheden. Het zorgde er vooral voor dat de oude zichzelf veel sneller terugverdienen. Wanneer een ontwikkeltraject van zes maanden een klus van twee weken wordt, loopt de hele backlog van “we zouden dolgraag willen, maar het zou zich nooit terugverdienen” ineens leeg.
Hoe het eruitziet als je erop inzet
Lynt is vanaf dag één een technologiegedreven bureau geweest. We hebben een systeemarchitect, een security engineer, een data-analist die BI bouwt en een fulltime developer in het team, wat een normaal bureau simpelweg niet heeft. Door de lange terugverdientijden die ik hierboven beschreef, was die slagkracht jarenlang moeilijk in te zetten voor PPC-problemen. Nu werkt die als rente op rente.
Boostora, onze eigen tool, kostte twee jaar ontwikkeling. Het verrijkt Google Merchant Center-feeds met AI, zodat Shopping-campagnes draaien op betere productdata dan de ruwe feed geeft. Eromheen zit de infrastructuur die de nieuwe economie eindelijk rechtvaardigt. Het scrapen van de prijzen van concurrenten per markt, dat de prijstabellen in de expansie-blueprint voedde. Zoekwoordenonderzoek-pipelines die volgens schema draaien in plaats van één keer per jaar. Zakelijke rapportage op klantniveau in BigQuery met forecasts erbovenop. MCP-servers voor elke dienst waar we mee werken, zodat een AI-agent er midden in een taak data uit kan trekken.
Twee jaar geleden had ik elk van die projecten moeten verdedigen tegen dezelfde vraag: gaat dit zich ooit terugverdienen? Vandaag komt die vraag amper nog op. Wanneer bouwen goedkoop wordt, is infrastructuur geen luxe meer, maar de voorsprong die niemand kan kopiëren.
Wat dit echt betekent voor de branche
De populaire stelling zegt dat AI een einde maakt aan de PPC-specialist. Wie dat verkeerd om begrijpt, betaalt daarvoor in de eigen loopbaan, dus laat me hier kleur bekennen.
“Het tijdperk van de PPC-specialist loopt ten einde” is onzin. Het tegenovergestelde gebeurt. Goede specialisten waren jarenlang gefrustreerd omdat de slimme oplossing die ze duidelijk voor zich zagen, het bouwen niet waard was. Nu mogen ze die bouwen. Automatisch, rendabel en op grote schaal. Een hele plank vol PPC-strategieën die vroeger onrendabel of simpelweg absurd waren om te proberen, is ineens een serieuze optie.
Wat wel gebeurt, is een scherpere splitsing binnen het vak. Aan de ene kant staan de mensen die de platform-UI voor het hele vak houden en de nieuwe tools aan zich voorbij laten gaan. Niemand ontslaat ze morgen. Ze blijven stilstaan terwijl het vak verder trekt. Aan de andere kant staan de mensen die de Google Ads API door en door kennen, databronnen koppelen die niemand anders koppelt, en gespecialiseerde dashboards voor zichzelf bouwen in plaats van te wachten tot een leverancier een feature uitbrengt. Twaalf jaar programmeren met die API heeft me geleerd waar de voorsprong van die tweede groep echt zit. De code werd goedkoop. Wat schaars bleef, zijn verbeelding en domeinkennis: weten welke data je combineert en waarom.
En om meteen een voor de hand liggende misvatting weg te nemen: dit is geen verhaal over goedkopere dienstverlening. Tools, rekenkracht en ontwikkeling kosten nog steeds geld. Het punt is dat een project waar vroeger twee senior developers vier tot zes maanden aan kwijt waren nu in weken wordt opgeleverd, waardoor de investering eindelijk logisch is. De klant krijgt een dramatisch betere dienst voor een vergelijkbare prijs.
Waarom ik weer schrijf
Ik stopte in 2017 met bloggen omdat de kloof tussen een idee en een economisch verstandige uitvoering te breed was om interessant te zijn. Die kloof is net gesloten. Dus deze blog pakt de draad op waar ppc-scripts.eu ophield, en hij blijft concreet. Use cases met echte cijfers, de exacte flows, de daadwerkelijke outputs, rommelige delen en grenzen inbegrepen. De eerste deep dives staan al online.
Ergens in je eigen backlog ligt de automatisering die je jaren geleden op de plank legde omdat ze zich nooit zou terugverdienen. Graaf die op en reken de som opnieuw. Als de rekensom voor jou net zo is omgeslagen als voor mij, weet je wat je hierna bouwt. En als je wilt sparren, weet je waar je me kunt vinden.
FAQ
Bedoel je dat bureaus hun PPC-specialisten moeten ontslaan?
Precies het tegenovergestelde. 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 per jaar en twee devs voor twee jaar exact?
Nee, zie het als een orde van grootte. Het gaat niet om het precieze eurobedrag. Eén interne rapportagemachine kostte jaarlijks een zescijferig bedrag en verdiende zichzelf toch nooit terug. Dat is de economie waar dit hele stuk over gaat.
Heb ik hier een duur frontier-model voor nodig?
Niet voor klussen als het schiften van rommel-zoekopdrachten. Een capabel open-source model zoals Gemma 4, lokaal gedraaid met goede site-context, doet het werk. Dat houdt zowel je data als je kosten in eigen hand.
Gaat dit alleen over zoekopdrachten?
Nee, dat is alleen de klus die je het makkelijkst kunt zien draaien. Dezelfde rekensom klopt nu ook voor marktexpansie-analyses (zes uur in plaats van ~400), voor het scrapen van prijzen van concurrenten per markt, voor zoekwoordenonderzoek dat dagelijks draait in plaats van één keer per jaar, en voor feedverrijking met Boostora. Pak de klus die jij op de plank legde en reken de som opnieuw.
Dus dit is gewoon hype in een nieuw jasje?
Als dat zo was, was ik niet opnieuw gaan schrijven. De verandering is beperkt en echt: de terugverdientijd van de mogelijkheden die we al hadden, is drastisch korter geworden. Dat is een zakelijke verandering, geen magische, en daarom loopt de backlog ineens leeg.
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 over wat we precies draaiden en wat het opleverde.
