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.

In mei bouwde ik een Google Ads-launch voor Safety Trading, een Nederlandse groothandel in werkkleding en persoonlijke beschermingsmiddelen, met een catalogus van 11.271 SKU's. 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.

Dit stuk is in juli bijgewerkt. De oorspronkelijke versie eindigde bij drie gepauzeerde campagnes die klaarstonden voor review. Inmiddels staan ze live, is er een kwartaal aan meetwerk overheen gegaan en heb ik in die periode één fout gemaakt die meer heeft opgeleverd dan de hele launch. Die staat er nu ook in, inclusief de cijfers. De tweede helft van dit artikel gaat over wat er na de knop gebeurde.

Het bord waar dit allemaal op staat

Alles wat hieronder staat, staat ook op één bord. Niet als naslagwerk achteraf, maar als de plek waar het werk gebeurt: elke vraag, elke meting, elke zoekterm, elk negatief en elk besluit als een los kaartje, voordat er een plan wordt geschreven. Het plan is daarna een samenvatting van het bord, geen nieuw document.

Twee frames naast elkaar, zoals het bord er in de praktijk uitziet. Het bord telt zevenendertig van deze frames, verdeeld over acht banden: de klant komt binnen, onderzoek, het tweede brein, de keuzes, bouwen, uitvoer en ritme, waar het account nu staat, en de afspraken.

De volgorde op dat bord is de volgorde van dit artikel. En de reden dat het bord blijft bestaan na oplevering is dat er elk kwartaal opnieuw doorheen wordt gelopen: kloppen de antwoorden uit de intake nog, klopt de catalogus, klopt het doelgetal.

De opzet, in één alinea

Safety Trading draait een Magento 2-webshop met 11.271 actieve producten verdeeld over 26 merken en bestaat sinds 2004. 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.

Wat de catalogus zelf al vertelde

Voordat er iets over campagnes werd gezegd, is de catalogus geteld. Niet omdat tellen leuk is, maar omdat bijna elke latere discussie erop terugvalt.

De verdeling was scheef, en dat had gevolgen

Kleding was 4.012 artikelen, ruim een derde van de catalogus. Schoeisel 1.962, ongeveer een zesde. Losse PBM-artikelen 96. Op producttype werd het nog concreter.

De merkladder liep van 4.305 artikelen bovenaan tot 147 onderaan. Dat is een factor dertig tussen het grootste en het kleinste merk dat nog serieus meetelt. Een structuur die elk merk gelijk behandelt, geeft het kleinste merk dus dertig keer te veel aandacht of het grootste merk dertig keer te weinig.

Daarnaast leverde de analyse zeven zakelijke en drie particuliere koperssegmenten op. Die scheiding is belangrijker dan hij klinkt: een inkoper die honderd broeken met logo bestelt, zoekt anders, converteert anders en is een ander bedrag waard dan iemand die één paar schoenen koopt. Ze in dezelfde advertentiegroep stoppen betekent dat het biedalgoritme op het gemiddelde van twee verschillende bedrijven stuurt.

De gaten in de feed, in percentages

Hetzelfde onderzoek legde bloot hoe vol de velden waren die er voor Shopping toe doen. De vulgraden liepen van 10,7 procent tot 100 procent, met 13,9 procent, 68,1 procent, 84,0 procent en 95,6 procent daartussen. Twee velden waren dus vrijwel leeg, twee waren grotendeels gevuld en de rest zat in het midden.

Dat is geen esoterische techniek. Een veld dat voor 10,7 procent gevuld is, betekent dat negen van de tien producten geen signaal meegeven op dat punt. Wie daar toch op filtert in een asset group, bouwt een campagne op een tiende van zijn eigen assortiment zonder het te merken.

De concurrentie, en wat we bewust niet doen

Er zijn drie soorten concurrenten in deze markt, en ze vragen om drie verschillende reacties.

De vier directe specialisten zijn per stuk uitgeschreven: waar ze sterk in zijn, waar hun assortiment dun is, en op welke termen ze zichtbaar zijn.

En toen het interessante deel: wat we op basis daarvan besloten niet te doen. Er wordt niet op concurrentnamen geboden. Twee redenen, en de tweede is de zwaarste. Ten eerste staat het in de gedragscode die we hanteren. Ten tweede: waar dat soort verkeer wordt gekocht, ligt het rendement onder de 1,5, terwijl de ondergrens voor dit account op 4,0 staat. Je koopt dus verkeer dat je met zekerheid geld kost, om een gevoel te bevredigen dat je iets doet.

Geen enkele daarvan is 100 procent, en dat is expres. Volledige zichtbaarheid kopen betekent per definitie dat je de duurste veilingen wint die je ook had kunnen laten lopen.

Waarom budget erbij vaak het verkeerde antwoord is

De meting die dat onderbouwde: 81 procent van de gemiste vertoningen ging verloren op rangorde, en 4,5 procent op budget. Die twee getallen worden constant door elkaar gehaald, en het onderscheid bepaalt of geld erbij iets doet of niets.

Verlies op budget betekent dat de campagne uit stond omdat het geld op was. Daar helpt meer budget. Verlies op rangorde betekent dat de advertentie te laag stond, en daar verandert meer budget niets aan, behalve het bedrag op de factuur. In dit account lag 81 procent aan de kant waar budget niet helpt. Het antwoord was dus relevantie en bod, niet geld.

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.

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.

Die verboden claims staan expliciet 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.

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.

Van 2.410 ruwe termen naar 47 advertentiegroepen

Het zoekwoordwerk is het deel waar de meeste tijd in gaat, en waar de meeste accounts het verschil maken. Niet in het verzamelen, maar in het wegstrepen.

De trechter zoals hij op het bord staat. Elke stap smaller dan de vorige, met het aantal erbij. De rode balk is de uitsluitlijst en die is groter dan het zoekwoordbestand dat overblijft.

Ingezoomd. Naast elke stap staat waarom hij bestaat. "Wegstrepen is het echte werk" is geen slogan: 548 termen gaan niet mee, en elke term die je wel had gekocht maar niet had moeten kopen, kost geld zolang de campagne draait.

Normaliseren is in het Nederlands zwaarder werk dan in het Engels. Werkschoen en werkschoenen, veiligheidsschoen en veiligheidsschoeisel, hi-vis en hivis en high visibility. Samenstellingen en spatiefouten lopen door elkaar heen, en die stap alleen al haalt er een derde uit.

Wat dat tweede brein kostte

Hier hoort een eerlijk getal bij, want "bouw eerst een kennisbank" is makkelijk advies als je niet zegt wat het kost.

De tijd die dat kostte is naar schatting veertig uur, eenmalig. Dat is een schatting en geen urenregistratie, dus behandel het als ordegrootte. Wat er tegenover staat is dat elke volgende vraag over dit account in minuten wordt beantwoord in plaats van in dagen, en dat het antwoord elke keer hetzelfde is.

De voorrangsregel

Drie lagen die elkaar kunnen tegenspreken, hebben een regel nodig voor wie wint. Die is hier: laag 3 wint van laag 2, en laag 2 wint van laag 1. De klantcontext overruled mijn methode, en mijn methode overruled wat het platform aanraadt.

Dat laatste is geen eigenwijsheid. Een advertentieplatform adviseert mede in zijn eigen belang, en die belangen lopen niet altijd gelijk met die van de adverteerder. Zonder expliciete voorrangsregel wint in de praktijk altijd de laag die het hardst roept, en dat is meestal de aanbeveling in de interface.

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 drie campagnes zoals ze de lucht in gingen

Ze stonden eerst gepauzeerd in het account, in afwachting van menselijke review. De launch-poort vereiste dat negen punten waren afgetekend (de customer match-lijst, de verbeterde conversiemeting, en zo verder) voordat er iets aan mocht.

• L1 Brand Defense: Search, manual CPC, exact-match branded zoekwoorden op de eigen naam. 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 was een gok. Elk merk op de include-lijsten van de asset groups stond in de feed en had meer dan 1 SKU. Elk uitgesloten merk had een specifieke reden vastgelegd in de analyse. Elk audience signal was vooraf gekoppeld. Dat de merkcampagne in week één alsnog op leveranciersmerken bleek te bieden, is precies waarom de eerste controle na livegang geen formaliteit is.

Van marge naar bod: waar het doelgetal vandaan komt

De meeste accounts sturen op een rendementsdoel dat ooit iemand heeft genoemd. Hier is het teruggerekend.

Vanaf dat laatste getal is elk gesprek concreet, zonder één afkorting. Boven de 26 euro per order is het alarm, daaronder mag het groeien.

Wat er gebeurde toen het live stond

De eerste week leverde het soort bevindingen op waar een audit voor bedoeld is. Drie zoekcampagnes hadden samen 637 euro besteed en één conversie opgeleverd. Het vertoningsverlies zat voor 81 procent op rangorde in plaats van op budget. En de merkcampagne bood op leveranciersmerken in plaats van op de eigen bedrijfsnaam, wat betekent dat het goedkoopste verkeer in het account niet werd afgedekt terwijl er wel voor merken van anderen werd betaald.

Voor Shopping werd het een getrapte opzet met drie prioriteiten en een biedladder: 0,20 euro onderaan, 0,40 tot 0,50 in het midden en 0,65 tot 0,75 bovenaan. Die trapsgewijze opbouw bestaat om de brede onderlaag goedkoop te laten filteren, zodat de dure bovenlaag alleen de zoekopdrachten krijgt die er al doorheen zijn gekomen.

Drie dingen in de feed die niemand had gemeld

• Elke maat stond als een eigen artikel in de feed. Dat verklaart waarom een catalogustelling en een feedtelling zo ver uiteenliepen, en waarom sommige asset groups op papier veel groter leken dan ze in de praktijk waren.
• Het isolatieveld stond leeg. Voor een assortiment met thermo- en winterkleding is dat het veld waarop een koper in november filtert.
• Er stond een parkeerbod van één cent op. Dat is het soort instelling dat ooit als test is neergezet en daarna nooit meer is aangeraakt, en het zorgt ervoor dat een deel van de catalogus feitelijk niet meedoet.

En één dingetje dat vaak vergeten wordt: op Performance Max bestaat geen bodaanpassing per dagdeel. Alleen aan of uit. Wie daar een dagdeelcorrectie op voorstelt, levert een advies dat technisch niets kan doen.

Onderin elk methodeframe staat een oranje omrand blok: wat de regel in dit account concreet opleverde, met de cijfers erbij. Zonder zo'n blok blijft een methode een mening.

De fout van 16 juli, en waarom die de meeste waarde had

Op 16 juli heb ik het rendementsdoel van 250 naar 400 procent gezet. Het leek een logische aanscherping: de cijfers zagen er goed uit, dus dan kan het doel omhoog.

Niet een beetje minder volume tegen een beter rendement, wat de bedoeling was, maar minder van allebei. Een te scherp doel knijpt een account dicht: het systeem koopt alleen nog de zoekopdrachten waarvan het bijna zeker weet dat ze converteren, en dat zijn er te weinig om iets van te leren. Op 26 juli is het teruggezet naar 175 procent en herstelde het.

De echte oorzaak lag een laag dieper

Het doel van 4,0 was op zichzelf niet raar. Het probleem was dat de meting ongeveer dertig procent van de orders zag. In de periode die we naast de orderadministratie hebben gelegd: circa 50 werkelijke orders tegenover 15 gemeten. De sessiedekking was wél 80 procent, dus het verkeer werd goed geregistreerd; het waren de aankopen die wegvielen.

Wat dit verraderlijk maakt, is dat een standaardaudit het niet vindt. Een vergelijking tussen het analyticspakket en het advertentieplatform kwam op 14,5 procent afwijking en zag er dus geruststellend uit. Maar die twee lezen dezelfde tag: als de tag niet vuurt, missen ze het allebei en zijn ze het keurig met elkaar eens. De enige controle die iets bewijst, is de orderadministratie van het bedrijf zelf.

Op papier haalde het account het doel niet. In werkelijkheid wel. Sindsdien is de volgorde hard: eerst de meting op orde, dan pas het doel aanscherpen. Nooit andersom.

Wat de wekelijkse ronde oplevert

Zodra een account draait, is het werk niet bouwen maar wegstrepen.

Dat laatste is precies waarom een uitsluiting bij mij een drempel moet halen en geen mening mag zijn. De drempel: nul conversies, meer dan honderd kliks en meer dan honderd euro, getoetst over negentig dagen.

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.
• Meet voordat je stuurt. Dit is de regel die ik heb toegevoegd na 16 juli, en het is de duurste les uit het hele traject. Een doelgetal is alleen zo goed als de meting eronder, en een bevestiging uit een dashboard is geen bewijs. Leg het naast de orderadministratie.
• 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.
• 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.
• Veertig uur is geen kleinigheid. Bij een catalogus van duizend producten en een bescheiden budget is die investering niet terug te verdienen. De grens ligt ergens rond een paar duizend artikelen en een budget waarbij een maand verkeerd sturen meer kost dan het bouwwerk.
• 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. En de fout van 16 juli was ook geen datafout: de data klopte, mijn interpretatie niet. 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.

En dan de aanvulling van na twee maanden draaien. Een goed gebouwd account is nog steeds een account waarin je een verkeerde knop kunt omzetten. Het verschil is dat je het binnen een week terugziet in plaats van na een kwartaal, en dat je precies kunt nalezen wat er stond voordat je eraan zat. Dat is uiteindelijk waar het tweede brein voor is: niet om fouten te voorkomen, maar om ze klein en terugdraaibaar te houden.

Met dank aan Safety Trading voor de toestemming om dit met naam en cijfers te publiceren. Accountnummers, campagne-ID's en budgetten blijven er bewust af.

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.