Zo controleer je met AI verrijkte productattributen voordat Google of Meta ze afwijst

De meeste catalogi halen hun productgegevens tegenwoordig door een AI-stap: een ontbrekende kleur aanvullen, een materiaal afleiden uit een titel, een beschrijving schrijven voor een SKU die er nooit een had. Het werkt goed genoeg dat teams het niet meer controleren. Dat is precies het probleem. De eigen documentatie van Google Merchant Center bevestigt dat het systeem voor automatische itemupdates, dat afwijkende waarden voor price, sale_price, availability en condition ongemerkt corrigeert door je landingspagina te crawlen, niet geldt voor color, material, size of GTIN (Google Merchant Center Help). Zitten die attributen fout, dan lost niets het voor je op — de foute waarde blijft gewoon live in je feed staan totdat een handmatige audit of een afkeuring door een kanaal het opmerkt. Deze gids is bedoeld voor iedereen die AI- of regelgebaseerde verrijking draait op een catalogus van een paar honderd tot een paar honderdduizend SKU's, en geeft je een concreet QA-proces — vijf foutpatronen om op te controleren, een scoringsmodel en een workflow voor steekproeven — om deze fouten af te vangen voordat ze Google, Meta of TikTok Shop bereiken.

Waarom met AI verrijkte attributen ongemerkt falen

Feed-QA was van oudsher gericht op de attributen die kanalen actief voor je bewaken. Google corrigeert een verouderde prijs of een verkeerde voorraadstatus automatisch op basis van je landingspagina, zonder dat je er iets voor hoeft te doen (documentatie over automatische itemupdates). Dat vangnet leert teams aan te nemen dat dezelfde bescherming overal geldt. Dat is niet zo. Kleur, materiaal, maat, patroon en GTIN zijn bewust van automatisering uitgesloten, omdat Google ze niet betrouwbaar uit een paginacrawl kan afleiden zoals een getoonde prijs.

Dat gat is nu belangrijker dan twee jaar geleden, omdat juist die attributen op schaal worden ingevuld door AI-verrijkingsfuncties — de attributen die een verkoper in de bronfeed nooit had ingevuld. Een AI-model dat "echt leer" afleidt uit een productfoto, of drie inconsistente kleurnamen normaliseert tot één, werkt in het enige deel van de feed waar een fout antwoord geen automatisch vangnet heeft.

De vijf foutpatronen die AI-verrijking introduceert

Deze zijn niet hypothetisch. Elk ervan hangt samen met een gedocumenteerde eis van Google of Meta waarvan een generieke AI-stap geen ingebouwde reden heeft om op de hoogte te zijn.

• Formaatovertredingen. Het attribuut color van Google wijst hexcodes, puur numerieke waarden en alles boven 40 tekens per kleurnaam af — een model dat de opdracht krijgt "haal de kleur uit de afbeelding" geeft zonder aarzelen #3B2F2F terug (specificatie van het color-attribuut).
• Mismatch met de landingspagina. Google eist dat de aangeleverde kleur exact overeenkomt met de bewoording op de landingspagina — "als je 'Toasted Walnut' op je landingspagina gebruikt, lever die waarde dan aan in je productgegevens. Lever geen 'Brown' aan" (specificatie van het color-attribuut). Een verrijkingsstap op basis van een generieke beeldclassificatie heeft geen zicht op wat er werkelijk in je productpaginatekst staat.
• Overmoedig verzonnen details. Een model maakt van een vaag of ontbrekend materiaalveld vaak iets dat specifiek klinkt maar niet klopt — "leer" voor een product dat eigenlijk van polyurethaan is. De materiaalspecificatie van Google vereist dat de waarde "de belangrijkste stof of het belangrijkste materiaal waarvan je product is gemaakt" weergeeft, geen aannemelijke gok (specificatie van het material-attribuut).
• Attributen die in elkaar overlopen. Een maatwaarde die in het patroonveld belandt, of een materiaalbeschrijving in het kleurveld: het gebeurt vaker dan teams verwachten zodra verrijking zonder toezicht over tienduizenden rijen met inconsistente brontitels draait.
• Inconsistentie tussen kanalen. Draait de verrijking apart per kanaalexport, dan kan hetzelfde product "Toasted Walnut" krijgen in je Google-feed en "Brown" in je Meta-feed — een verwarrend signaal voor shoppers en aan minstens één kant een mismatch met de landingspagina.

Voor en na: vijf echte foutpatronen ontleed

De tabel hieronder laat zien hoe elk foutpatroon eruitziet als echte feedwaarde, waarom het misgaat en wat de gecorrigeerde regel moet bevatten.

Een QA-scoringsmodel voor met AI verrijkte attributen

Beoordeel elke verrijkte regel op vijf criteria, met elk 0–2 punten, voordat die live gaat. Zo wordt een subjectieve check als "ziet dit er goed uit" iets dat een junior teamlid of een externe kracht consistent kan toepassen.

Een regel met een score van 9–10 kan automatisch worden gepubliceerd. Een regel met 6–8 gaat naar een wachtrij voor handmatige steekproeven. Alles onder de 6 gaat in quarantaine — buiten de volgende export gehouden — totdat iemand het corrigeert. Dit sluit aan bij hoe Google deze attributen zelf behandelt: niet als automatiseringsrisico, maar als risico voor handmatige controle, omdat de eigen automatisering op basis van crawlen er uitdrukkelijk voor stopt.

De QA-checklist inbouwen in je verrijkingsworkflow

1. Draai vóór publicatie automatische regelcontroles op elke verrijkte regel. Tekenlimieten, verboden tekens (hexpatronen, puur numerieke kleurwaarden) en verboden generieke termen ("multicolor", "various", "assorted") kun je allemaal met eenvoudige regex-regels afvangen, zonder menselijke tussenkomst — dezelfde laag regelgebaseerde logica achter feedverrijking kan deze controles uitvoeren als poort voordat waarden de export bereiken.
2. Neem steekproeven op basis van risico, niet gelijkmatig. Geef voorrang aan handmatige controle in categorieën waarin GMC het attribuut als verplicht behandelt — kleding en accessoires voor kleur, volgens de categoriespecifieke eis van Google (specificatie van het color-attribuut) — en aan elke SKU waarbij de betrouwbaarheidsscore van de AI, als je verrijkingstool die toont, onder je drempel ligt.
3. Vergelijk met brongegevens, niet met aannemelijkheid. Het probleem is niet dat verrijkte waarden er fout uitzien — het probleem is dat ze er juist goed uitzien. Controleer elke markering voor "zekerheid over details" tegen een echt specificatieblad van de leverancier of de tekst op de productpagina, niet tegen de vraag of de waarde redelijk klinkt.
4. Voer de consistentiecontrole tussen kanalen na elke export opnieuw uit, niet alleen na de verrijking. Draait je verrijkingsstap voordat de feed in exports per kanaal wordt gesplitst, dan is dit grotendeels al door de opbouw opgelost. Draait de verrijking per kanaal (gebruikelijk wanneer kanalen een andere opmaak nodig hebben), dan heeft die een eigen afstemmingsronde nodig.
5. Leg vast wat je in quarantaine plaatst. Een stijgend quarantainepercentage voor een specifiek attribuut of een specifieke categorie is een signaal om de verrijkingsprompt of de regelset aan te passen, niet alleen de afzonderlijke regels.

Bij een feed die dagelijks in plaats van elk uur synchroniseert, kan een foute verrijkte waarde die erdoorheen glipt een volledige synchronisatiecyclus live voor shoppers staan voordat je die bij de volgende export kunt corrigeren — nog een reden waarom de controle vóór publicatie moet plaatsvinden en niet erna.

Wat dit niet dekt, en waar het tekortschiet

Dit proces vangt formaatovertredingen, mismatches en niet-controleerbare details af — het beoordeelt niet of een door AI geschreven titel of beschrijving goede tekst is; dat is een aparte, subjectievere controle. Het vervangt ook geen juridische of compliancecontrole voor gereguleerde categorieën (supplementen, claims over cosmetica, kinderproducten), waar een fout of verzonnen attribuut een complianceprobleem is en niet alleen een kwestie van feedkwaliteit.

Op echt grote schaal — catalogi met miljoenen SKU's, meerdere bijdragers en formele goedkeuringsketens — is een handmatige wachtrij op basis van steekproeven zoals hierboven op zichzelf niet meer genoeg. Rond dat soort governanceworkflows zijn platforms als Productsup gebouwd, met regelengines en audittrails die in het platform zijn ingebakken in plaats van eroverheen gelegd. En als de beperking in de beoordelingscapaciteit zit en niet in de tooling, is het managed-servicemodel van Feedonomics — een team dat je feed beoordeelt in plaats van software die je zelf configureert — een legitiem alternatief voor intern personeel aannemen. Geen van beide is nodig om de checklist hierboven te gebruiken; het is wel goed om ze te kennen voordat je besluit dit op schaal zelf te bouwen.

Ten slotte vervangt niets hiervan het lezen van de specificatie van het nieuwe attribuut of de nieuwe categorie die je hierna gaat verrijken. Google en Meta passen formaatregels en categorie-eisen zo vaak aan dat een checklist die je vandaag opstelt over zes maanden opnieuw naast de brondocumentatie moet worden gelegd; het is geen kwestie van eenmaal instellen en vergeten. Gaat het je specifiek om door AI gegenereerde afbeeldingen en beschrijvingen in plaats van gestructureerde attributen, lees dan onze aparte beleidsgids over door AI gegenereerde productcontent — dat artikel behandelt compliance met kanaalbeleid, terwijl dit artikel over QA van datakwaliteit gaat.

Veelgestelde vragen

Corrigeert Google Merchant Center een verkeerde kleur- of materiaalwaarde automatisch?

Nee. De automatische itemupdates van Google gelden alleen voor prijs, actieprijs, beschikbaarheid en staat. Kleur, materiaal, maat en GTIN zijn uitgesloten, dus een onjuiste waarde in die velden blijft live totdat jij of je verrijkingsproces die corrigeert. Zie de gids voor de Google Merchant Center-integratie van Feedance voor hoe feedexports naar GMC worden ingesteld.

Wat gebeurt er als ik een kommagescheiden lijst met kleuren aan Google aanlever?

Google gebruikt alleen de eerste kleur in de lijst en laat de rest ongemerkt vallen — een kommagescheiden reeks wordt niet als meerdere waarden behandeld (zo los je op: ongeldige waarde voor color). Gebruik in plaats daarvan schuine strepen, met maximaal drie kleuren per product.

Vereist Meta dezelfde kleur- en materiaalattributen als Google?

Nee. De veldspecificatie voor commercecatalogi van Meta noemt kleur en materiaal optioneel, terwijl maat specifiek verplicht is voor de categorieën kleding en schoenen. Meta vereist wel dat kleur in woorden wordt geschreven in plaats van als hexcode (velden van de commercecatalogus van Meta).

Is een verkeerd kleurattribuut hetzelfde risico als een overtreding van het beleid voor misleiding?

Meestal niet. Eén onjuist attribuut verschijnt doorgaans als probleem op itemniveau op het tabblad "needs attention" van Merchant Center, niet als schorsing op accountniveau. Misleiding is een apart, zwaarder beleid dat gericht is op opzettelijke of patroonmatige valse claims over een bedrijf of aanbieding, niet op een losse attribuutfout.

Hoeveel van mijn catalogus moet ik na een AI-verrijkingsronde handmatig controleren?

Weeg je steekproef op basis van risico in plaats van gelijkmatig: geef voorrang aan categorieën waarin een attribuut verplicht is (bijvoorbeeld kleding en accessoires voor kleur) en aan elke regel die je verrijkingstool als weinig betrouwbaar markeert, voordat je de resterende controletijd over de rest van de catalogus verdeelt.

Kan dezelfde met AI verrijkte attribuutwaarde verschillen tussen mijn Google- en Meta-feed?

Dat zou niet moeten, als beide hetzelfde product beschrijven. Draait de verrijking apart per kanaalexport, voeg dan na de export een afstemmingsstap toe om gevallen af te vangen waarin de twee waarden uit elkaar zijn gegroeid.

Wat moet ik doen als ik ontdek dat er al verzonnen attributen live in mijn feed staan?

Haal de betreffende SKU's eruit, corrigeer de waarden aan de hand van brongegevens (leveranciersbladen of de live productpagina, niet een nieuwe run van hetzelfde verrijkingsproces) en lever ze opnieuw aan. Controleer daarna of hetzelfde foutpatroon elders in de catalogus voorkomt — een hallucinatie staat zelden op zichzelf.

Levert AI-verrijking ooit attribuutwaarden op die een handmatig proces zou missen?

Ja — het is echt nuttig om attributen in te vullen in grote catalogi waar handmatige invoer niet realistisch is, en om patronen op te merken (zoals inconsistente naamgeving) die iemand die regel voor regel controleert niet ziet. De QA-laag bestaat om de specifieke foutpatronen af te vangen, niet als argument tegen het gebruik ervan.

Haal je feed door de gratis productfeed-audittool van Feedance om te zien hoe je huidige attribuutgegevens ervoor staan voordat je aan je volgende verrijkingsronde begint.