ID [id] in Google Shopping: eisen, best practices en voorbeelden

Wat is het kenmerk id?

Het kenmerk id is de unieke code van elk product in je Google Merchant Center-feed. Het is de primaire sleutel waarmee Google je product in elk systeem volgt: feedverwerking, deelname aan de veiling, attributie van klikken en conversies, signalen voor Smart Bidding, campagnetargeting en prestatierapportage. Alle data die Google over een product verzamelt, hangt aan de id.

Anders dan de meeste feedkenmerken heeft id geen invloed op wat kopers zien — het verschijnt nooit in Shopping-advertenties of productvermeldingen. Het effect is volledig structureel en operationeel. Omdat het onzichtbaar is, wordt het makkelijk onderschat, maar het is waarschijnlijk het veld in je feed met de grootste gevolgen. De regel is simpel: ken het één keer correct toe en wijzig het daarna nooit meer.

Technische specificaties

Waar de ID verschijnt

• Feedbeheer in Merchant Center — De ID is de rijsleutel op het tabblad Vereist aandacht, in productlijsten en in probleemrapporten. Onderzoek je een afkeuring of een probleem met de datakwaliteit, dan zoek je het product op aan de hand van de ID.

• Campagne-interface van Google Ads — In Shopping-campagnes verwijzen rapporten op productniveau, bodaanpassingen en uitsluitingen allemaal naar de Merchant Center-ID. Bij targeting op productgroepen in Standard Shopping en Performance Max dient de ID als verwijzing naar het product.

• Tags voor dynamische remarketing — De remarketingtag op je website moet dezelfde ID-waarden doorgeven als die in je Merchant Center-feed, zodat Google gebruikersgedrag (productweergaven, toevoegingen aan de winkelwagen, aankopen) aan specifieke producten kan koppelen om doelgroepen op te bouwen en advertenties te personaliseren.

• Conversietracking — Bij Shopping-campagnes worden conversiedata via de ID aan het juiste product toegeschreven. Dat is de basis voor ROAS-rapportage op productniveau en voor de signalen van Smart Bidding.

Kopers zien de ID nergens in een Google-omgeving — het is puur een interne systeemcode.

Regels

• Moet uniek zijn binnen je Merchant Center-account — Staan er twee producten met dezelfde ID in dezelfde feed, dan overschrijft het ene het andere. Ook over meerdere feeds binnen één account moeten ID’s uniek zijn.

• Maximaal 50 tekens — ID’s van meer dan 50 tekens worden afgekapt of veroorzaken feedfouten. Richt je ID-schema zo in dat je ruim binnen deze limiet blijft.

• Hoofdlettergevoelig — Gebruik hoofdletters consequent in je hele feed en in alle systemen die naar product-ID’s verwijzen (Google Ads, remarketingtags, analytics). Wisselend hoofdlettergebruik is een veelvoorkomende oorzaak van attributiefouten.

• Moet overeenkomen met de waarden in remarketingtags — Gebruik je dynamische remarketing, dan moet de waarde van ecomm_prodid (of het equivalent daarvan) in de tag op je website exact overeenkomen met de id in Merchant Center, inclusief hoofdletters.

• Stabiel bij elke feedupload — Hetzelfde fysieke product moet bij elke feedupload dezelfde ID hebben. Bij elke upload nieuwe ID’s genereren (bijv. met tijdstempels of automatisch oplopende nummers) is een ernstige ontwerpfout.

Best practices

Gebruik je SKU als ID

De allerbeste aanpak voor product-ID’s is je interne SKU gebruiken — de code waarmee je bedrijf al naar specifieke productvarianten verwijst in je voorraadbeheer, ERP of orderbeheersysteem. SKU’s zijn stabiel (ze veranderen niet als prijzen, beschrijvingen of afbeeldingen veranderen), uniek per variant (elke combinatie van maat en kleur heeft een eigen SKU) en herkenbaar voor je operationele team (handig bij het debuggen van feedproblemen).

Een ID-schema voor grote catalogi

Bij catalogi met duizenden SKU’s maakt een gestructureerd ID-schema het beheer eenvoudiger:

Strategie voor variant-ID’s

Bij productvarianten (verschillende maten, kleuren of configuraties van hetzelfde basisproduct) heeft elke variant een unieke ID nodig. Een vaste naamgeving voorkomt verwarring:

• Basisproduct: DRESS-WRAP-MIDI (lever het basisproduct niet aan — lever de varianten aan)

• Bloemen / S: DRESS-WRAP-MIDI-FLORAL-S

• Bloemen / M: DRESS-WRAP-MIDI-FLORAL-M

• Effen marineblauw / S: DRESS-WRAP-MIDI-NAVY-S

Groepeer ze met een gedeelde item_group_id (bijv. DRESS-WRAP-MIDI), zodat Google weet dat het varianten van hetzelfde product zijn.

Invloed op de prestaties

• Continuïteit van Smart Bidding — Smart Bidding-strategieën (doel-ROAS, Conversiewaarde maximaliseren) verzamelen conversiesignalen per product-ID. Een stabiele ID met 6 maanden conversiegeschiedenis levert veel betere biedbeslissingen op dan een nieuwe ID die bij nul begint. Een ID-wijziging zet de prestaties van Smart Bidding direct terug.

• Veilingsignalen — De veiling van Google gebruikt historische prestatiesignalen op productniveau (CTR, conversiepercentage, kwaliteit) die aan de ID hangen. Na een ID-reset duurt het 4–8 weken om die signalen weer op te bouwen, met in die periode hogere CPC’s en een lager vertoningspercentage.

• Nauwkeurigheid van dynamische remarketing — Komen de ID’s in je remarketingtags niet overeen met de feed-ID’s, dan worden doelgroeplijsten verkeerd gevuld of blijven ze leeg, en werken je retargetingcampagnes helemaal niet meer. Zet je de ID’s vanaf dag één goed, dan voorkom je dit soort problemen.

• Rapportage en attributie — ROAS-rapporten op productniveau, cijfers over vertoningspercentage en analyses van conversiepaden zijn allemaal afhankelijk van stabiele ID’s. Wijzig je ID’s halverwege een campagne, dan kun je niet meer met het verleden vergelijken en moet je data doorgaans met de hand op elkaar afstemmen.

Veelgemaakte fouten

• Automatisch gegenereerde sequentiële ID’s gebruiken die veranderen wanneer producten opnieuw worden geïmporteerd of de database wordt gemigreerd

• Product-URL’s gebruiken als ID’s — URL’s veranderen wanneer de sitestructuur verandert

• Producttitels of -namen gebruiken als ID’s — titels veranderen om redenen van SEO of merchandising

• Verschillend hoofdlettergebruik in feed-ID’s en in de waarden van remarketingtags, waardoor de attributie van dynamische remarketing niet meer werkt

• ID’s van producten die uit het assortiment zijn gehaald hergebruiken voor nieuwe producten — de oude veilingsignalen van het verdwenen product vervuilen het nieuwe

• De ID van het hoofd- of basisproduct aanleveren in plaats van de ID’s van de afzonderlijke varianten

• Speciale tekens of spaties gebruiken die verwerkingsfouten veroorzaken in TSV/CSV-feeds

Pro-tips

• Bouw een ID-controle in je feedpijplijn in — Controleer vóór elke feedupload of er geen nieuwe ID’s zijn opgedoken voor producten die in de vorige feed al een ID hadden, of geen enkele ID langer is dan 50 tekens en of geen enkele ID niet-toegestane tekens bevat. Zo onderschep je onbedoelde ID-wijzigingen voordat ze Merchant Center bereiken en je prestatiegeschiedenis wissen.

• Houd een register van product-ID’s bij — Leg in één centrale koppeltabel vast welke Merchant Center-ID bij elke interne productcode hoort. Dat is vooral belangrijk bij een platformmigratie (je webshop naar een ander platform overzetten), waarbij interne ID’s kunnen veranderen terwijl de Merchant Center-ID’s precies gelijk moeten blijven.

• Als een ID-wijziging echt niet te vermijden is — Reken op een herstelperiode van 2–4 weken. Verhoog tijdelijk de biedingen op de betrokken producten om je vertoningspercentage vast te houden terwijl Smart Bidding opnieuw leert. Controleer de veilingsignalen wekelijks en bouw die extra budgetbescherming af naarmate de prestaties stabiliseren.

• Gebruik de ID als productsleutel in al je systemen — Laat je Merchant Center-ID overeenkomen met de product-ID in Google Analytics 4 (de item_id in e-commerce-events), in je remarketingtags en in je advertentierapportage. Met één consistente productcode in alle systemen analyseer je productprestaties van begin tot eind, zonder ID’s op elkaar te hoeven afstemmen.