Google Ads als redeneerprobleem: een ROAS-daling van 22% ontleed in vier mechanismen

Elke week duik ik diep in een AI-onderwerp en test ik het in de praktijk. Deze week gaat het over het systeem dat ik in klantmeetings op een gegeven moment geen “dashboard” meer noemde, maar “agents”. Die verandering was niet cosmetisch. Een dashboard laat zien wat er gebeurde; dit systeem analyseert waarom, en of het ertoe doet.

Ik publiceer dit omdat twee klanten achter elkaar dezelfde vraag stelden: wat doet jouw stack eigenlijk dat die van ons niet doet? Het eerlijke antwoord paste niet op één slide, dus schrijf ik het hier op.

Waarom ik stopte met het bouwen van dashboards

Elk Google Ads-dashboard dat ik ooit had opgeleverd, van mezelf of van iemand anders, had steeds hetzelfde euvel. Het liet zien wat er veranderde, zonder de oorzaak erbij en zonder een oordeel over de ernst. Een toevallige ROAS-daling van 22% op een dinsdag ziet er identiek uit als een ROAS-daling van 22% die wordt veroorzaakt door een structureel campagneprobleem. Het dashboard toonde beide als rood.

De klanten waarmee ik werkte wilden eigenlijk geen rode en groene cijfers. Ze wilden drie antwoorden die een dashboard hen niet kon geven:

1. Is dit een anomalie, een trend, of het verwachte resultaat van iets dat we al besloten hebben?
2. Als het een probleem is, wat is het onderliggende mechanisme?
3. Als we willen opschalen, waar levert de volgende euro aan spend incrementele conversies op, en waar alleen opgeblazen kosten?

Een dashboard beantwoordt geen van deze drie vragen; het vat samen zonder te redeneren. Naast elkaar gezet:

Dus stopte ik met het bouwen van dashboards en begon ik agents te bouwen.

Wat “agent” betekent in deze stack

Geen copilot, en geen chatwrapper rond de reporting-API van een leverancier. De Google Ads AI Agent is een multiagentsysteem: meerdere gespecialiseerde AI-agents, elk met een eigen taak en een eigen geheugen. Het systeem leest live accountdata via de Google Ads API met GAQL, de querytaal van die API: campagnes, advertentiegroepen, asset groups, keywords en zoektermen. Die data wordt verrijkt met device-, netwerk- en conversion-actionsegmentatie, en het geheugen blijft bewaard tussen sessies.

Elke analysecyclus werkt met echte accountdata. Geen screenshots, geen CSV-exports, geen “wat was de spend vorige week”-giswerk. De agent heeft het al opgehaald.

Achter de API-laag zitten vier specialistagenten, elk met een eigen geheugen:

• Campaign Manager · real-time performance-analyse, WoW/MoM, brand vs. non-brand, budgetaanbevelingen, impression-share-kansen
• Brand Cannibalization · brand-integriteit op zoektermniveau, incremental-vs.-baseline-modellering
• PMax Correlation · asset-group-overlap, feeddekking, query-mix-verschuivingen, creative fatigue
• Budget Marginal-Return · incrementele waarde per eenheid extra spend, het fitten van schaalcurves

De orchestrator stuurt een vraag naar de agents die nodig zijn om die te beantwoorden, en de geheugenlaag zorgt ervoor dat elke agent al weet wat er vorig kwartaal op dit account gebeurde.

Een ROAS-daling ontleden, per mechanisme

Wanneer een klantaccount week-over-week 22% ROAS verliest, slaat het systeem niet meteen alarm. Het ontleedt eerst: welke mechanismen tellen op tot dat ene rode cijfer? In het vak heet dat decompositie.

Een typische decompositie die ik afgelopen vrijdag op een echt account uitvoerde, zag er zo uit:

• CPC-inflatie: +14,2% gemiddelde CPC, zichtbaar als oplopend verlies aan vertoningsaandeel door positie. Drie concurrenten verhoogden hun biedingen op een gedeelde keywordcluster.
• CVR-daling: −8,1% op de landingspagina die 38% van het conversievolume afhandelt. Laadde prima, converteerde gewoon slechter.
• Conversievertraging: de conversies van de vorige week kwamen nog steeds laat binnen. Ongeveer 6,4% van de schijnbare ROAS-daling was een meetartefact dat binnen 72 uur zou corrigeren.
• Query-mix-uitbreiding: PMax trok 14 nieuwe zoekcategorieën aan. De nieuwe mix had 19% lagere historische CVR dan de oude mix.

Dat is geen “ROAS staat op min”. Dat zijn vier aparte problemen, waarvan er drie elk een andere oplossing vragen en één helemaal geen actie nodig heeft. Een dashboard had voor al deze zaken hetzelfde rode cijfer getoond.

De agent slaat elke decompositie op in het geheugen. Zodra CPC-inflatie de volgende keer opduikt, herinnert hij zich dat hij dezelfde veilingverschuiving twee weken eerder al zag, en hoeft hij het niet opnieuw uit te leggen. Zo stapelt de kennis zich op.

Zoektermen clusteren in plaats van lijsten opleveren

Zoektermrapporten houden op nuttig te zijn zodra een account echt volume draait. Een CSV van 50.000 rijen helpt niemand een beslissing te nemen.

De agent voert elke zoekterm door een embeddingmodel, een model dat tekst omzet in getallen zodat je op betekenis kunt groeperen in plaats van op exacte woorden. Hij clustert op semantische gelijkenis en commerciële intentie, en mapt vervolgens elke cluster tegen de huidige campagne- en landingspaginacontext. Twee structurele problemen komen direct naar boven:

1. High-intent queries begraven in lage-prioriteitscampagnes. Een cluster van “koop X met same-day shipping”-queries bevindt zich in een campagne met een −15% bidaanpassing voor het device dat het beste converteert.
2. Irrelevante queries die spend opblazen. Een cluster van broad-match-drift met 0,4% conversieratio dat 11% van het maandbudget verbruikt.

De clusters staan niet vast; ze bewegen mee met het account. Nieuwe queries worden toegewezen aan bestaande clusters of splitsen zich af als nieuwe. De CVR, CPC en intentiescore van een cluster worden in de tijd bijgehouden, zodat het systeem ziet wanneer een intentiegroep verschuift in plaats van alleen dat deze “onderpresteert”.

Brand-integriteit, op zoektermniveau

Brand-cannibalisatie-analyse gebeurt normaal op keywordniveau. Dat is het verkeerde niveau. De meeste accounts lekken brand via zoektermen, niet via keywords, met name via Performance Max en broad match.

De agent berekent incrementele conversies versus baseline-brandvraag. De output blijft niet steken bij “je hebt brand-cannibalisatie”. Er staat: “Performance Max heeft de afgelopen 30 dagen 1.847 conversies op brand-zoektermen binnengehaald; baseline brand-vraag suggereert dat ~1.610 daarvan ook op Search Brand hadden geconverteerd tegen 78% lagere CPC; netto nieuwe waarde van PMax op deze queries: 237 conversies, tegen €38 effectieve CPA versus €4 op Search Brand”.

Dat is de vraag die de meeste accounts nooit stellen: levert automatisering netto nieuwe conversies op, of verschuift ze bestaande conversies naar een duurder kanaal?

Performance Max: wat er buiten de interface wél zichtbaar is

PMax staat bekend als een black box. De API geeft aanzienlijk meer dan de interface, al blijft een deel echt dicht: zoektermen komen er gegroepeerd in categorieën uit en er is geen uitsplitsing per kanaal.

De PMax-agent voert correlatiemodellering uit op asset groups, feeddekking, query-mixsegmenten en zoekcategoriesignalen. De signalen die naar boven komen:

• Creative fatigue op asset-groupniveau (CTR-verval ten opzichte van de eerste 30 dagen van de asset group)
• Feed-gaps waar high-intent productclusters lage-kwaliteitsafbeeldingen of ontbrekende attributen hebben
• Asset-group-overlap waarbij twee asset groups bieden op dezelfde queryclusters en elkaars IS kannibaliseren
• Query-mix-verschuivingen waarbij de categoriemix van de campagne wegbeweegt van zijn hoogste-CVR-clusters

De standaardrapportage in de interface laat hier weinig van zien, al breidt Google die stap voor stap uit; er is inmiddels ook een zoektermenrapport voor Performance Max. Het patroon blijft dat de interessantste data eerst in de API zit en pas later, of nooit, in de UI verschijnt.

Budgetbeslissingen als marginal-return-curves

Statische ROAS-targets zijn in veel accounts een gewoonte die niemand meer ter discussie stelt. De agent stuurt er niet op.

In plaats daarvan fit hij per campagne een marginal-return-curve, een curve die laat zien wat elke volgende euro budget nog oplevert, op basis van historische schaalcurves, impression-share-plafonds en CPC-elasticiteit. In plaats van “campagne A staat op 4.2 ROAS, target 4.0, verhoog budget” krijg je output als: “campagne A produceert incrementele conversies tegen €18 effectieve CPA tot +€800/dag; daarboven betaal je voor opgeblazen CPC's en 4% extra IS”.

De curve is hier het beslissingsinstrument. Een dashboard levert die niet.

Geheugen is de doorslaggevende laag

Elke structurele wijziging, budgetverschuiving en performance-anomalie wordt opgeslagen. Wanneer de agent een campagne evalueert, weet hij al:

• Hoe die campagne de laatste drie keer reageerde toen we het budget opschaalden
• Welk seizoenspatroon momenteel actief is en wat het vorig jaar met de CVR deed
• Welke structurele wijziging iemand twee weken geleden doorvoerde en wat de agent verwachtte dat er zou gebeuren
• Welke “anomalie” eigenlijk de verwachte vertraging is van een beslissing die het team al nam

Dit is de laag die ervoor zorgt dat het systeem niet elke maandag dezelfde vragen stelt.

Wat er veranderde in de output voor klanten

De eerlijke maatstaf voor elk agentsysteem is: werden de aanbevelingen geaccepteerd? Bij twee pilotaccounts, over de laatste 90 dagen:

• 71% van de door de agent gegenereerde aanbevelingen werd door het team geaccepteerd zonder aanpassing (versus 22% bij de vorige dashboardgedreven workflow)
• Mediane tijd van anomaliedetectie tot corrigerende actie: 47 minuten (versus 4,2 dagen)
• Aantal wekelijkse statusmeetings: 0 (versus 3 per week)
• Accountmanagementuren: 41% lager voor dezelfde dekking

Die klanten betaalden niet voor “meer rapporten”. Ze betaalden voor het denkwerk dat een ROAS-daling ontleedt, alleen draait dat nu elke vijf minuten en onthoudt het alles.

Twee pilotaccounts en 90 dagen is geen bewijs op onderzoeksniveau, maar wel genoeg richting om er mijn werkwijze op te bouwen.

Voor wie dit nu interessant is, en voor wie nog niet

Een beslisser heeft hier één vraag over: wat levert dit op? Het antwoord hangt af van het account.

Interessant wordt het zodra drie dingen samenkomen: een serieus maandbudget, een mix van Search en Performance Max, en een team dat wekelijks beslist over budget en structuur. Daar kost de waarom-vraag handmatig de meeste uren, en daar zit dus de winst van een systeem dat ontleedt en onthoudt. Voor een klein account met een paar honderd euro spend per maand is dit overkill; daar volstaat een maandelijkse check door iemand die weet waar hij moet kijken.

De realistische eerste stap is een stuk kleiner dan vier agents bouwen: regel API-toegang en laat één vraag structureel beantwoorden, bijvoorbeeld de ROAS-decompositie hierboven. Of simpeler: vraag je bureau bij de volgende rapportage niet wát er veranderde, maar waarom. Aan het antwoord hoor je of er achter het dashboard iemand nadenkt.

Voor de Nederlandse context: veel bureaus werken hier nog met Looker Studio-dashboards en bouwen zelf niets rechtstreeks op de Google Ads API. Wie die stap wel zet, heeft er voorlopig weinig concurrentie. En omdat Google Search voor Nederlandse webshops, lokale bedrijven en B2B voorlopig het hoofdkanaal blijft, is dit een van de plekken waar AI nu al direct rendement oplevert.

Wat ik andere bureaus vertel

Als jouw Google Ads-stack draait om “we hebben een dashboard gebouwd met onze eigen KPI's”, los je een probleem uit 2018 op. Rapportage was toen het knelpunt. Mijn inschatting: het knelpunt zit nu bij het redeneren, van cijfer naar mechanisme naar beslissing.

De verschuiving vraagt drie dingen:

1. Behandel de API als primaire bron, niet de UI. Alles wat ertoe doet is met GAQL op te vragen, goed gesegmenteerd, met conversion-action- en netwerkuitsplitsingen. Bouw niet bovenop screenshots.
2. Ontleed, aggregeer niet. Een rood cijfer is het begin van een analyse, niet de output. Elke metric moet te herleiden zijn tot een som van benoemde mechanismen.
3. Onthoud. Een systeem dat de schaalbeslissing van vorige week vergeet, blijft je alarmeren over de gevolgen ervan alsof het anomalieën zijn. Geheugen maakt van een alarm een beredeneerd advies.

Dashboards verdwijnen hiermee niet; er komt een laag bovenop die het denkwerk doet. Stop dus met het bouwen van alleen rapportagetools. Bouw iets dat het account blijft analyseren in de tijd tussen je klantmeetings.