Google Ads-dashboards laten zien dat het misgaat. AI-agents zien waarom.

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 stilletjes 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 past niet op een slide.

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, maar nooit waarom, en ook niet of het ertoe deed. 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, het redeneert niet. 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. 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% op auction-share-impression-loss-to-budget. Drie concurrenten verhoogden 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.

Zoektermclustering, geen zoektermlijsten

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 zijn geen statische rapporten. Ze evolueren 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 weet wanneer een intentiegroep verschuift, niet alleen dat deze “onderpresteert”.

Brand-integriteit, op de juiste granulariteit

Brand-cannibalisatie-analyse gebeurt normaal op keywordniveau. Dat is de verkeerde granulariteit. 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 is niet “je hebt brand-cannibalisatie”; het is “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: drijft automatisering netto nieuwe waarde, of herverdeelt het gewoon bestaande conversies tegen slechtere kosten?

Performance Max: de black box opengemaakt

PMax staat bekend als een black box. Maar hij is alleen zwart als je niet de juiste tabellen bevraagt.

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

Native PMax-rapportage vertelt je hier weinig over; Google breidt de interface wel stap voor stap uit. Maar 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 gebruikt ze niet.

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 simulatie is hier het eigenlijke beslissingsinstrument. Dat hadden dashboards nooit.

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

De klant betaalde niet voor “meer rapporten”. Ze betaalden voor het deel van mijn brein dat ROAS-dalingen 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

De vraag van een beslisser is niet “moeten wij dit bouwen” maar “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 niet “bouw vier agents”, maar: 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 raken de Google Ads API nooit rechtstreeks aan; wie deze stap zet, loopt voor op de markt. En omdat Google Search voor Nederlandse webshops, lokale bedrijven en B2B nog jaren het hoofdkanaal blijft, is dit waar AI nu 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 tien jaar geleden 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 zit in GAQL, 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 zet alarmen om in reasoning.

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