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 de super-seniors die eindelijk de workflows mogen bouwen die zich vroeger nooit terugverdienden, zoals duizenden rommel-zoekopdrachten opruimen met een model dat een gewone pc kan draaien.
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 de echte kracht wilde.
Ik zit zo’n twintig jaar in PPC, waarvan twaalf jaar code schrijvend tegen 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 wijd, en er zijn maar zoveel manieren om tools te beschrijven die niemand kan betalen.
Dit voorjaar leverde ik een marktexpansie-analyse op, zestien producten geprijsd over vijf landen met heat maps, in ongeveer zes uur. Handmatig is dat zo’n 400 uur werk. Gebouwd als maatwerksoftware op de oude manier is het twee maanden ontwikkeling en een factuur van €16.000 tot €20.000 die geen klant ooit wilde betalen. Dezelfde deliverable, en de prijs stortte in. De analyse werd dit voorjaar niet slimmer. De economie van het bouwen brak.
Bijna alles wat je hebt gelezen over AI die de PPC-specialist om zeep helpt, heeft dat mechanisme achterstevoren. 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. Twee tijdperken die automatisering te duur maakten om de moeite te nemen, 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 liet de terugverdientijd instorten van de mogelijkheden die we al sinds 2019 hadden, en dat alleen al herschrijft wat het bouwen waard is.
- De beslissende valuta is niet langer regels code. Wat schaars is, is 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 bevriest; wie de Google Ads API tot op het bot 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 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 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, uit sync drijvend, stilletjes brekend zodra de naamgeving 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 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 het oppervlak waar iedereen voor tekende.
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, en de ontwikkeling die nodig was om het draaiende te houden liep rond de €100.000 per jaar. 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 naar 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 van twee seniors, en geen klant betaalt wat dat kost.
Het plafond was nooit de technologie. Het was de terugverdientijd.
De eerste klus die losbrak: rommel-zoekopdrachten
“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 loop ik de hele flow met je door.
Irrelevante zoekopdrachten uit een account opschonen is waardevol en geestdodend, en tot voor kort was er geen eerlijke 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-handmatige tocht door 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”, waarvan hij niets verkoopt of repareert. Vermenigvuldig dat met duizenden rijen, elke week, over 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 bijna elke huidige pc kan draaien. Het leest duizenden zoekopdrachten in een paar minuten. En als je het grondt in context over de klant, de sitemap, de site- en DB-structuur, de breadcrumb-taxonomie, de product feed, stopt het met gokken en begint het te redeneren. Het sluit correct uit en benoemt de patronen achter de rommel, sneller dan welke menselijke scan ook. 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 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 product feed (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 deel, 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 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: 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 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. Een mens leest die ene zin, is het ermee eens dat hij klopt, en de regel blijft “hardloopschoenen gratis verzending retour”-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.
De stille kop hier 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 het huis. Dat is de economie die verschuift, niet wat mogelijk is.
De tweede klus: zoekwoordenonderzoek
Deze was vroeger een eigen budgetregel. 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, 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 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 loodgieterswerk. 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 op elke stap getoond.
Het deel dat me nog steeds verrast is het ritme. Onderzoek als dit was vroeger een jaarproject waar een klant één keer voor tekende. 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. Gedocumenteerde cijfers waar ik ze heb, ordes van grootte uit twintig jaar bureauwerk voor de rest.
| 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-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 herhaalt zich op elke rij. De kolom met wat mogelijk is bewoog niet, dit konden we allemaal al in 2019. De prijskolom zakte door de vloer. En de terugverdientijd is wat beslist of een slim idee ooit gebouwd wordt.
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.
Hoe het eruitziet als je erop inzet
Lynt is vanaf dag één een technologiezwaar 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. Jarenlang was die spierkracht moeilijk op PPC-problemen te richten, om alle terugverdienredenen hierboven. Nu stapelt hij zich op.
Boostera, 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 het loodgieterswerk dat de nieuwe economie eindelijk rechtvaardigt. Concurrentprijzen scrapen per markt, het soort 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 op elke dienst die we aanraken, zodat een AI-agent er midden in een taak uit kan putten.
Twee jaar geleden had ik elk van die projecten moeten verdedigen tegen dezelfde vraag, of het zich ooit terugverdient. Vandaag komt die vraag amper nog op. Wanneer bouwen goedkoop wordt, houdt infrastructuur op een luxe te zijn en wordt het de slotgracht.
Wat dit echt betekent voor de branche
De populaire stelling zegt dat AI een einde maakt aan de PPC-specialist. Dat achterstevoren hebben heeft echte carrièregevolgen voor wie dit leest, dus laat me een vlag planten.
“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 voor zich 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 wel gebeurt is een scherpere splitsing binnen het vak. Aan de ene kant staan de mensen die de platform-UI als de hele baan behandelen en de nieuwe tools voorbij laten gaan. Niemand ontslaat ze morgen. Ze bevriezen terwijl het vak verder trekt. Aan de andere kant staan de mensen die de Google Ads API tot op het bot 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 code schrijven tegen die API leerde me waar de voorsprong van die tweede groep echt zit. De code werd goedkoop. Wat schaars bleef is verbeelding en domeinkennis, weten welke data je combineert en waarom.
En om de voor de hand liggende misvatting meteen te begraven, dit is geen verhaal over goedkopere dienstverlening. Tools, rekenkracht en ontwikkeling kosten nog steeds geld. Het punt is dat een project dat vroeger vier tot zes maanden van twee senior developers was nu in weken oplevert, dus de investering is eindelijk logisch. 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 wijd was om interessant te zijn. Die kloof is net gesloten. Dus deze blog pakt 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. Haal haar tevoorschijn en reken de som opnieuw. Als de cijfers zijn omgeslagen zoals de mijne, 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 droeg een jaarlijkse kostenpost van zes cijfers en verdiende zichzelf nog steeds 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 economie verschoof voor marktexpansie-analyses (zes uur in plaats van ~400), voor het scrapen van concurrentprijzen per markt, voor zoekwoordenonderzoek dat dagelijks draait in plaats van één keer per jaar, en voor feedverrijking met Boostera. 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 smal en echt, een ingestorte terugverdientijd op mogelijkheden die we al hadden. 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 precies dat wat we draaiden en wat het opleverde.
