Eerst de catalogus, dan de campagne: hoe een kennisbank van 11.271 SKU's elke Google Ads-beslissing stuurde

De meeste Google Ads-launches beginnen met de verkeerde vraag. Het team gaat zitten en vraagt zich af "waarop moeten we bieden?" voordat er een helder, gestructureerd antwoord ligt op "wat verkopen we eigenlijk?". Zo begint de campagnestructuur als een kopie van de concurrent met een andere merknaam erin geplakt, en wordt het budget op basis van aannames verdeeld. De eerste drie maanden gaan dan op aan het ontdekken welke campagne te weinig data krijgt, welk merk juridisch niet in de geautomatiseerde shopping-campagnes mag verschijnen en welk veld in de productfeed al die tijd leeg bleek te zijn.

Deze week bouwde ik een Google Ads-launch voor een Nederlandse groothandel in werkkleding en persoonlijke beschermingsmiddelen (PBM), met een catalogus van 11.271 SKU's, unieke artikelnummers. Ik begon met precies de omgekeerde vraag. Elke beslissing in de uiteindelijke campagnestructuur is terug te voeren op een gestructureerde kennisbank die ik eerst had opgebouwd, en op een reeks geautomatiseerde rapporten die de AI-agents lezen voordat ze überhaupt iets aanbevelen. Het klinkt als marketingpraat om dit een 'tweede brein' te noemen, maar functioneel klopt de term precies. De catalogus en de analyse ervan staan in versiebeheer en de agents lezen daaruit. Telkens als er een vraag opkwam zoals 'moeten we Codeor in PMax zetten?' of 'is er genoeg Airtox-volume voor een eigen ad group?', stond het antwoord al in de data.

De opzet, in één alinea

De klant draait een Magento 2-webshop met 11.271 actieve producten verdeeld over 26 merken. De twee dingen die ik vanaf dag één weigerde te doen, waren: beginnen aan de campagnestructuur voordat de catalogusdata gestructureerd was, en de accountstructuur van de concurrent kopiëren alleen omdat die goed rankte. Allebei voelen ze in week één productief aan. Allebei leveren ze het soort account op dat je in maand vier alsnog moet herbouwen.

De klassieke launch tegenover deze aanpak

Het verschil zit niet in slimmere advertenties, maar in de volgorde waarin beslissingen worden genomen en waar de kennis vandaan komt.

Voor wie is deze aanpak interessant, en voor wie niet?

De eerlijke voorwaarde: dit loont pas bij een serieuze catalogus. Denk aan webshops en groothandels vanaf pakweg duizend producten, met specificatiedata die ertoe doet (veiligheidsklassen, materialen, certificeringen) en een productfeed die achterloopt op de webshop. Precies het profiel van veel Nederlandse B2B-webshops op Magento of Shopify: de advertentieplatformen zijn niet het knelpunt, de eigen productdata is dat. Wie een webshop met vijftig producten draait, heeft dit hele bouwwerk niet nodig; daar volstaat een goede feed-audit en een middag gestructureerd nadenken.

De realistische eerste stap is ook geen AI-project. Exporteer de volledige catalogus, tel per merk het aantal producten en het percentage ingevulde specificaties, en leg dat naast wat er daadwerkelijk in de productfeed staat. Dat is een dag werk en het levert vrijwel altijd minstens één ontdekking op die anders pas na drie maanden advertentiebudget boven water was gekomen. De agents en de automatisering komen daarna; de discipline om eerst de data te ordenen is het echte werk.

Laag 1: de kennisbank

De eerste bouwstap is een reproduceerbare pipeline die de hele catalogus als markdown in de repo trekt. Drie scripts, in volgorde.

1. fetch_magento.py: benadert de Magento REST API op /rest/stc_default/V1/products, pagineert met een throttle van 2 seconden, normaliseert attribuutverschillen tussen attribuutsets en schrijft ruwe JSON weg.
2. flatten.py: neemt de ruwe JSON en maakt er één rij per SKU van, met de 35 specificatie-attributen die ertoe doen (merk, producttype, veiligheidsklasse, slipweerstand, materiaal van de neuskap, maatvoering per locale).
3. render_kb.py: produceert KNOWLEDGE_BASE.md, één mensleesbaar bestand dat 11.271 producten, 26 merken en 27 attribuutsets samenvat, plus de omvang van het contenttekort (10,7% van de producten heeft een omschrijving langer dan 50 tekens; de rest is leeg of standaardtekst).

De KB wordt elke nacht opnieuw gegenereerd via een GitHub Action met een handmatige startknop (een workflow_dispatch-trigger). Dat is bewust handmatig, want het klantgerichte rapport moet eerst een kwaliteitscheck doorstaan voordat het wordt verspreid. De eerste run kostte de agent ongeveer 35 minuten. Latere runs duren 6 tot 8 minuten, omdat de Magento-attribuutdefinities stabiel zijn en ik de ID-labelmapping cache.

Wat de KB direct aan het licht bracht

• Snickers Workwear is 38% van de catalogus (4.305 producten). Het is met afstand het merk met de meeste hefboomwerking in het account.
• Airtox heeft 1 product. Het kan geen eigen ad group krijgen. Het kan geen doelgroep vormen binnen PMax (Performance Max, het campagnetype waarin Google zelf plaatsing en biedingen bepaalt op basis van je feed).
• Codeor is een datadump zonder inzicht: 25 parents, 32% specificatiedekking, geen consistente attribuutinvulling. Het kan niet in PMax worden opgenomen, omdat het filter dan producten zonder bruikbaar signaal zou meeslepen en zo de training van elk ander item zou schaden.
• 99,7% van de producten heeft een meta_title en 99,1% een meta_description, dus SEO-basiszaken zijn niet het knelpunt. Het contenttekort zit in productomschrijvingen, niet in metadata.

Vier feiten. Zonder de KB was elk daarvan een ontdekking in maand drie geweest.

Laag 2: de brain feed

De KB bestaat, maar de agents lezen die niet automatisch. Het tweede onderdeel is daarom een brain feed: een compacte samenvatting van de kennisbank (brain_feed.json en brain_feed.md) die in de system prompts van de agents wordt geïnjecteerd, maar alleen voor de scopes die dat nodig hebben.

• SEA-scope leest het merkaandeel en de specificatiedekking voordat er een ad group-structuur wordt aanbevolen.
• SEO-scope leest het contenttekortrapport voordat er wordt aanbevolen voor welke parent-SKU's (de hoofdproducten waar alle maten en kleuren onder hangen) er omschrijvingen geschreven moeten worden.
• Blog-scope leest de merkenmix voordat er onderwerpsclusters worden voorgesteld.
• Shopping-scope leest de feed-gereedheid voordat er wordt aanbevolen welke producten in PMax thuishoren.
• Strategy- en CRO-scopes lezen de volledige brain feed.

Performance- en social-scopes krijgen de feed niet. Voor hun werk maakt het niet uit welk specificatie-attribuut het vaakst leeg is bij werkbroeken. Door de feed daar achterwege te laten, blijft het tokenbudget beheersbaar.

Technisch gezien is het maar één regel code in de agent prompt loader, maar de impact is structureel. Elke SEA-aanbeveling die het systeem geeft, gaat nu uit van hetzelfde catalogusbeeld. De aanbevelingen wijken niet meer af tussen sessies.

Laag 3: de automatisch gegenereerde rapporten

De catalogus is de input; de rapporten per merk en per categorie zijn de werkbasis. Drie varianten.

• Rapporten per merk in knowledge-base/brands/, één markdown-bestand per merk. Elk bevat een momentopname (aantal SKU's, aandeel van de catalogus, gedekte producttypes) en een uitvoerbare contenttekortlijst van parent-SKU's waarvoor nog omschrijvingen geschreven moeten worden.
• Rapporten per type in knowledge-base/categories/by-type/, 27 producttypes. Elk bevat de specificatieverdeling die voor dat type relevant is. Het rapport over werkschoenen laat zien dat 567 van de 599 producten SRC-gecertificeerd zijn voor slipweerstand, dat 404 van de 589 een composietneuskap hebben, en dat S3 met 306 producten de meest voorkomende veiligheidsklasse is.
• Rapporten per STC-top in knowledge-base/categories/by-stc-top/, drie rapporten op het hoogste categorieniveau, bedoeld om te kruiscontroleren.

Samen zijn dat 55 markdown-rapporten, allemaal gegenereerd vanuit dezelfde source-of-truth-pipeline. De gebruiker bewerkt ze nooit handmatig. Als er iets fout is, zit de fout stroomopwaarts.

Waarom dit ertoe doet voor de advertentietekst

Voordat er ook maar één headline wordt geschreven, raadpleegt de SEA-agent eerst het per-type rapport om de juridisch claim-veilige USP's te vinden. Voor werkschoenen blijkt uit de data dat ik met vertrouwen S3, SRC, composietneus en EN ISO 20345/20471 kan claimen, omdat meer dan 90% van de catalogus die claims onderbouwt. Ik kan niet claimen "stalen neus" (het grootste deel van de catalogus is composiet, niet staal), "100% waterdicht" (de specificatiedata ondersteunt dat niet over de hele SKU-basis), of "10.000+ producten". Die claims staan expliciet vermeld in LAUNCH_PLAN.md onder "vermijden". Het systeem schrijft advertenties op basis van de veilige-claimlijst, niet op basis van wat de freelance copywriter zich van vorig jaar herinnert.

Laag 4: de kruisanalyse

Kennisbank, brain feed, rapporten. Nu heeft het systeem de data die nodig is voor het echt interessante werk, namelijk een kruisanalyse tussen de catalogus en de voorgestelde campagnestructuur. Die staat in DEEP_ANALYSIS.md. Het format is simpel: voor elke asset group (de productclusters binnen een PMax-campagne) en ad group in de structuur staat het percentage dat launch-ready is.

De output is een tabel.

Deze tabel deed drie dingen. Ten eerste bezegelde hij het lot van het plan "PMax met 4 asset groups", omdat Hi-Vis maar 13 items in de feed heeft en zou zijn verhongerd door gebrek aan signaal. Ten tweede rechtvaardigde hij het volledig weren van Codeor uit PMax, ook al is het een echt catalogusmerk. Ten derde leverde hij een sprintlijst voor contentschrijven op: de 38 jassen- en bovenkleding-parents met lege omschrijvingen, gesorteerd op SKU-hefboomwerking, zodat de schrijver eerst de grootste impact aanpakt.

Vier iteraties op de campagnestructuur

De structuur zelf doorliep vier versies in drie dagen. Elke versie was een reactie op een bevinding uit de laag erboven.

V1: de eerste schets

Opgesteld alleen op basis van de briefing, voordat de KB bestond. Drie campagnes, geen audience signals, vage rendementsdoelen (tROAS). Gebruikt als stroman.

V2: datagedreven

4 PMax + 8 Search + Brand Defense + DSA (Dynamic Search Ads, waarbij Google advertenties genereert op basis van je site). Eerste versie die de catalogus daadwerkelijk weerspiegelde, maar ik had de generieke search ad groups eruit gehaald (in de foutieve aanname dat PMax die zou dekken) en de branded campagnes over 8 ad groups verspreid (te dun voor het volume).

V2.1: strategierevisie

Twaalf concrete correcties uit een strategist-review van V2.

• Generieke search ad groups terug erin, omdat PMax geen dekking van de long tail garandeert.
• Branded ad groups geconsolideerd van 8 naar 4, omdat het intentieprofiel van brand defense smaller is dan ik had gemodelleerd.
• Audience signals verplicht: Customer Match (je eigen klantenlijst als doelgroepsignaal), Site Visitors 540d, Custom Intent, Similar, In-market. Zonder deze heeft smart bidding niets om op te leunen.
• Zoektype-matches gecorrigeerd: exact voor branded, phrase voor category. Broad blijft beperkt tot PMax-exposure.
• Realistische omslagpunten voor tROAS-fasering: 50 conversies voor PMax en 30 voor Search, voordat target ROAS wordt geactiveerd.
• Data-driven attributie met een position-based 40/20/40-fallback, totdat DDA genoeg signaal heeft.
• ROAS-targets gekalibreerd op categoriegemiddeldes: 300% in maand 1, 400% in maand 3.

V2.2: feedgedreven aanpassing

Dit was de laatste versie. Ze kwam tot stand doordat de feed-audit (een export uit Channable, de feedtool tussen webshop en Google: 354 items tegenover 11.271 in de catalogus) liet zien dat de structuur moest aansluiten bij wat in week één daadwerkelijk in de feed stond, niet bij wat er later aan de feed kon worden toegevoegd.

• PMax ging van 4 asset groups naar 3. Hi-Vis eruit gehaald totdat de feed uitbreidt.
• Asset group-filters omgezet van custom_label_3 (ontbreekt in feed) naar g:brand (wel aanwezig).
• Codeor-merkuitsluiting expliciet vastgelegd in de PMax-campagne-instellingen.
• Snickers-parent-SKU's met de grootste hefboomwerking (6214, 6241, 6251, 6314, 6341) geverifieerd als aanwezig in de feed voordat ze werden opgenomen. Vijf andere top-parents wachten op feed-uitbreiding in maand 2.
• Budget verdeeld over vier lagen binnen een vast wekelijks budgetkader, met het grootste aandeel voor PMax Shopping en een kleine reserve voor herallocatie in week 3.

De uiteindelijke structuur is gepubliceerd als CAMPAIGN-STRUCTURE.json. Het bevat een veld _revision_history dat elke wijziging tussen V1 en V2.2 met reden opsomt, zodat de volgende persoon op het account weet waarom elke beslissing is genomen.

De daadwerkelijk gepauzeerde campagnes

De drie campagnes staan in het account, allemaal gepauzeerd, in afwachting van menselijke review voordat ze geactiveerd worden.

• L1 Brand Defense: Search, manual CPC, exact-match branded zoekwoorden op het eigen merk van de klant. Goedkope verzekering.
• L2 Generic + Branded: Search, manual CPC. Zeven ad groups: brand defense, generieke veiligheidsschoenen, generieke werkbroeken, Hi-Vis & multinorm, slipvaste schoenen (Shoes For Crews & Giasco), premium schoenen (Solid Gear & Puma Safety), Snickers Workwear, Carhartt & Scruffs. Gedeelde negatieve zoekwoordenlijst: 25 negatives die gratis, tweedehands, marktplaats, vintage, review, vergelijken, test, huur, leasen, abonnement, outlet, sale-prijs, de merknamen van concurrenten en de landuitsluitingen voor BE/DE dekken.
• L3 PMax Shopping: max conversion value. Drie asset groups: premium veiligheidsschoenen (Solid Gear / Puma Safety / Albatros), volume veiligheidsschoenen (Shoes For Crews / Giasco / Sanita) en werkkleding (Snickers / Carhartt / Texstar / Scruffs / Nine Worths / JAK / Top Swede / Muller & Sons / Ardon).

Geen van deze beslissingen is een gok. Elk merk op de include-lijsten van de asset groups staat in de feed en heeft meer dan 1 SKU. Elk uitgesloten merk heeft een specifieke reden vastgelegd in de analyse. Elk audience signal is vooraf gekoppeld. De campagnes zijn bewust gepauzeerd: de launch-poort vereist dat negen pre-launch punten (customer match-lijst, GA4 enhanced conversions, enzovoort) zijn afgetekend voordat ze geactiveerd worden.

Wat ik aan deze aanpak niet zou veranderen

• Bouw de KB voordat je de campagnestructuur bouwt. Bij elke catalogus van deze omvang en complexiteit. Catalogusdata rendeer je één keer en lees je daarna keer op keer opnieuw; dat is goedkoper dan de AI iets te laten verzinnen.
• Houd de feedpoorten streng. De feed-audit onderschepte tijdig een PMax-structuur van 35 pagina's die anders op dag drie zou zijn gestrand. Voer de feed-audit uit voordat je een asset group opstelt, niet erna.
• Gebruik brain feeds, geen RAG, voor catalogusdata van deze omvang. RAG (retrieval augmented generation) betekent dat een systeem per vraag losse stukjes uit een database ophaalt; dat voegt latency en onvoorspelbare retrieval toe. Deze catalogussamenvatting is klein genoeg om volledig in een system prompt te passen (onder 30K tokens), en een statische brain feed is dan deterministischer. De eerlijke grens: bij honderdduizenden producten of lange vrije teksten past het niet meer in een prompt en wordt retrieval alsnog de juiste keuze. Mijn inschatting is dat de meeste Nederlandse webshops ruim onder die grens zitten.
• Handmatige workflow_dispatch bij elke klantgerichte job. Cronjobs die automatisch rapporten naar klanten sturen, hebben me in drie verschillende projecten al eens de das omgedaan. Een menselijke controlepoort is goedkoop.

Afwegingen

• De eerste drie dagen gaan langzaam. Als een klant verwacht dat advertenties op dinsdag live staan en je begint op maandag, dan levert de tweede-brein-aanpak dat niet. Onderhandel dat vooraf.
• De agent schrijft nooit beter dan de data die hij te lezen krijgt. Als de KB verkeerde attribuutinvullingen heeft, kloppen de campagneclaims ook niet. Specificatieverificatie hoort bij de QA-lus, niet als bijzaak.
• Het elimineert de strateeg niet. Twaalf correcties tussen V2 en V2.1 waren strategische beslissingen, geen datavraagstukken. De brain feed maakt de strateeg sneller, niet overbodig.

Waar ik op uitkom

De verschuiving hier is klein maar echt. Stop ermee om de agent te vragen je catalogus te verzinnen. Bouw de catalogus in de agent. De agent vertelt je dan welke asset groups launch-ready zijn, welke merken niet in PMax passen, welke feedvelden leeg zijn, en welke specificatieclaims juridisch veilig zijn. De campagnestructuur is dan een gevolg van de data, geen creatief kunstwerkje.

Wil je een tweede paar ogen op een launch die je op het punt staat te draaien? Stuur me een bericht. Mail naar info@jermayads.nl of gebruik jermayads.nl/contact.