Productlancering op marketplaces: checklist voor PIM-teams

Een productlancering op marketplaces in 2026 draait niet om een marketingdatum, maar om de vrijgave van productdata. Voor één SKU-familie zijn vaak al een stabiele EAN, categoriespecifieke attributen, gelokaliseerde titels, variantlogica, conforme afbeeldingen, veiligheidsvelden, voorraadstatus en kanaalspecifieke uitzonderingen nodig voordat Amazon, bol.com, Zalando, OTTO, Kaufland, Google Shopping of Temu het product aan kopers toont.

In de praktijk zit het risico vooral in de manier waarop teams lanceringen nog steeds voorbereiden: met een controle in spreadsheets. Dat werkte toen één webshop het belangrijkste kanaal was. Het loopt vast zodra een multichannel verkoper hetzelfde assortiment naar meerdere marketplaces moet publiceren, ieder met een eigen attributenmodel en eigen afkeurregels. De attributengids van Amazon benoemt ontbrekende verplichte attributen, ongeldige waarden, overschreden tekenlimieten en conflicten in voorwaardelijke velden als afzonderlijke oorzaken van fouten. Kaufland documenteert verplichte en optionele attributen per categorie via de seller API. Zalando publiceert verplichte artikelmapping en strikte afbeeldingsregels. Google Merchant Center werkt met verplichte, voorwaardelijke en categoriespecifieke velden. Verkopers lopen niet vast omdat ze geen productteksten kunnen schrijven. Ze lopen vast omdat niemand de PIM als releasesysteem beheert.

Deze checklist maakt van dat probleem een herhaalbaar operationeel model. Hij is geschreven voor PIM-eigenaren, e-commercemanagers en marketplace operators die willen dat productlanceringen in één keer door de controles komen, na livegang gesynchroniseerd blijven en minder noodreparaties in Seller Central veroorzaken. Als uw team productdata nog steeds in bestanden samenstelt, begin dan met het koppelen van uw brond data via PIM-feeds en breng die data onder in een beheerste PIM-workflow.

Waarom standaard launch-checklists de echte blokkade missen

De meeste e-commercechecklists voor een productlancering gaan over positionering, e-mailcampagnes, beeldmateriaal en KPI’s na livegang. Nuttig, zeker. Maar daar loopt een listing meestal niet op vast. Marketplace-lanceringen stranden vaak juist in de operationele details: een kleurwaarde die in Shopify wel wordt geaccepteerd, maar in Google Merchant Center niet; een schoen met één materiaalveld, terwijl Zalando aparte waarden verwacht voor bovenmateriaal, voering, binnenzool en zool; een Kaufland-categorie die pas na selectie extra verplichte attributen toont; of een Amazon-detailpagina waarop een attribuut wordt vergrendeld nadat er al een verkeerde waarde is aangeleverd.

In de zoekresultaten ziet u dezelfde blinde vlek terug. PIM-pagina’s van concurrenten hebben het over één centrale productbron, contentscores en syndication. Forumdiscussies laten de dagelijkse praktijk zien: varianten zonder maat of kleur, GTIN-vrijstellingen die anders uitpakken dan verwacht, afgekeurde product-ID’s, AI- of shared-catalog-waarden die eigen content overschrijven en listings die worden onderdrukt vanwege velden die tijdens de voorbereiding optioneel leken. Wat ontbreekt, is een launch gate waarin productcontent, marketplace-validatie en gereedheid van het magazijn samenkomen.

Controlepunt 1: leg de SKU-scope en het variantmodel vast

Leg eerst de lanceerscope vast op het niveau van SKU-families. Werk dus niet vanuit “alle voorjaarsartikelen” of “de nieuwe collectie”. Begin met parentproducten, childvarianten, verkoopbare SKU's, de EAN- of GTIN-status, bundellogica en ieder kanaal waarop het product live moet komen. Het parent-childmodel is geen cosmetische keuze. Bij Amazon ontstaan variatiefouten vaak door dubbele variatiekenmerken of child SKU's die niet passen bij het verwachte variatiethema. Google Shopping verwacht, waar relevant, variantkenmerken zoals item group ID, kleur, maat, materiaal, patroon, geslacht of leeftijdsgroep. Voor Zalando moet de artikelmapping op artikelniveau kloppen, met onder meer SKU, EAN, kleur, maat, seizoen en afbeeldingen.

De PIM-eigenaar moet vóór de contentverrijking drie velden vastzetten: de interne SKU, de externe identifier en de kenmerken die de variant bepalen. Veranderen die later alsnog, dan moeten elke feedmapping en iedere overdracht naar het magazijn opnieuw worden gecontroleerd. De lancering vastzetten betekent niet dat de data niet meer beter mag worden. Het betekent dat de identiteit van wat u lanceert stabiel genoeg is, zodat marketplace-, webshop- en magazijnsystemen hetzelfde product herkennen.

1. 1
   Stel de lijst met SKU-families op

   Neem per regel de parent SKU, child SKU, EAN of GTIN, bundelindicator, variantthema en het lanceerkanaal op.
2. 2
   Markeer uitzonderingen op identifiers vroeg

   GTIN-vrijstellingen, private-label producten, bundels en multipacks hebben vóór feedvalidatie een eigen route nodig.
3. 3
   Zet de variantkenmerken vast

   Kleur, maat, materiaal, patroon en verpakkingsaantal mogen niet per marketplace anders worden herschreven, tenzij die afwijking bewust is gekozen.

Gate 2: kies eerst de marketplacecategorie, daarna pas verrijken

De gekozen categorie bepaalt welke punten op de checklist komen. Bij Kaufland laat de seller API per categorie zien welke attributen verplicht of optioneel zijn. OTTO geeft de relevantie van attributen aan en stelt wettelijke attributen verplicht. Zalando splitst verplichte artikeldata uit naar categorie en producttype. Google Merchant Center schakelt velden voor onder meer kleding, bundels, certificeringen en varianten in of uit op basis van producttype en doelland. Schrijft uw team al titels, omschrijvingen en beeldinstructies voordat de categorie vaststaat, dan verrijkt u op basis van eisen die nog kunnen veranderen.

Een robuustere werkwijze is: kies eerst de kanaalcategorie en haal daarna het attribuutsjabloon naar het PIM. Leg per productfamilie drie lijsten vast: verplicht om te publiceren, aanbevolen voor zichtbaarheid en velden voor compliance of veiligheid. Juist die aanbevolen laag heeft commerciële impact. Verkopers op marketplaces halen vaak de minimale publicatie-eis en vragen zich daarna af waarom hun zichtbaarheid tegenvalt. Filters, zoekrelevantie, AI-winkelsamenvattingen en contentscores van marketplaces leunen op gestructureerde attributen die technisch niet altijd verplicht zijn.

Gate 3: bouw een kanaalgereedheidsscore, geen algemene compleetheidsscore

Een algemene compleetheidsscore voor producten is te grof voor marketplace-werk. Een product kan in de PIM op 95% staan en toch op bol.com of Amazon worden afgekeurd omdat een voorwaardelijk veld ontbreekt, in Google mislopen omdat kleur niet op variantniveau is gemapt, of bij Zalando vastlopen door een verkeerde beeldverhouding. De score moet daarom per kanaal én per categorie worden bepaald.

Werk met een gereedheidsscore in vier lagen. Eerst de blokkerende velden: identiteit, titel, beschrijving, afbeelding, categorie, prijs en beschikbaarheid. Daarna de voorwaardelijke velden: variantattributen, velden voor bundels en multipacks, kledingafmetingen, certificeringsgegevens, materiaalsamenstelling en, waar vereist, gegevens over de verantwoordelijke persoon of GPSR-gegevens. Vervolgens de conversievelden: bullets, zoektermen, rijke afbeeldingen, maattabel, lifestyle-media en gelokaliseerde beschrijvingen. Tot slot de operationele velden: voorraadbron, fulfillmentroute, leverbelofte en retourregels. De PIM feeds van ChannelDock mogen pas publiceren wanneer de blokkerende laag op groen staat en een eigenaar de voorwaardelijke laag heeft beoordeeld.

• T-14d
  Categorie- en attribuutsjabloon vastgezet

  De marketplace-categorie, verplichte velden en compliancevelden zijn overgenomen in de PIM-checklist.
• T-7d
  Content en media vastgezet

  Titels, beschrijvingen, vertalingen, beeldsets en variantwaarden wijzigen niet meer, tenzij er een foutmelding is geregistreerd.
• T-2d
  Proefvalidatie van de feed

  Exporteer een pre-launchfeed, controleer afgekeurde regels en herstel de bronvelden in de PIM in plaats van alleen in het marketplacekanaal te corrigeren.
• T+1d
  Acceptatiemonitoring

  Controleer kanaaldiagnostiek, onderdrukte listings, ontbrekende producten en waarschuwingen voor voorraad-/prijsverschillen.

Gate 4: valideer media alsof het data zijn

Afbeeldingen worden vaak gezien als creatief materiaal, maar marketplaces controleren ze net zo strikt als gestructureerde productdata. De openbare beeldrichtlijnen van Zalando leggen onder meer portretformaat, verhoudingen, bestandstype, kleurmodus en minimale afmetingen vast. OTTO vraagt om een correcte hoofdafbeelding en stelt eisen aan bestandsnamen, achtergrond, formaat en de ruimte die het product in beeld inneemt. bol.com werkt met gelabelde mediabestanden en categoriespecifieke labels. Voor Temu verwijzen marketplace-toolingleveranciers vaak naar een minimumaantal afbeeldingen en beeldregels per categorie. Een PIM-launchgate moet daarom controleren of afbeeldingen aanwezig zijn, welke rol ze hebben, welk bestandsformaat wordt gebruikt, of de resolutie klopt en welke kanaalspecifieke weergavelabels nodig zijn.

De belangrijkste regel is eenvoudig: laat één veld ‘afbeelding’ niet per kanaal iets anders betekenen. Leg beeldrollen expliciet vast: hoofdafbeelding, packshot, voorzijde, achterzijde, zijkant, detail, sfeerbeeld, maattabel, energielabel, veiligheidslabel, handleiding en conformiteitsdocument. Koppel die rollen vervolgens aan de eisen per kanaal. Een fashionartikel voor Zalando heeft mogelijk model- en materiaalbeelden nodig; een meubelartikel voor OTTO vraagt misschien om montage-instructies of maattekeningen; een bol.com-vermelding heeft vaak gelabelde assets nodig die aansluiten op het datamodel van de betreffende categorie.

Poort 5: scheid bronwaarden van kanaalspecifieke afwijkingen

In het canonieke productrecord legt u vast wat niet per kanaal hoort te verschillen: merk, SKU, EAN, materiaal, afmetingen, ingrediënten, compatibiliteit, veiligheidsinformatie en de basisomschrijving. Kanaalspecifieke afwijkingen gebruikt u juist voor de vertaling daarvan naar elke marketplace: maximale titellengte, lokale taxonomie, toegestane kleurlijst, materiaalsplitsing per categorie, beeldvolgorde, bullet-indeling, juridische formulering en taal. Zodra die twee lagen door elkaar lopen, groeien kanaalgegevens uit elkaar. Een marketplace-specialist corrigeert iets rechtstreeks in Amazon, een vertaler past alleen de bol.com-export aan en bij de volgende geplande PIM-feed worden beide wijzigingen weer overschreven.

Voor multichannelverkopers werkt het model bronwaarde plus transformatie het best. “Antraciet” kan bijvoorbeeld de canonieke kleur blijven, terwijl Google “grijs” ontvangt, Zalando de toegestane leverancierskleur plus hoofdkleur krijgt en Kaufland een Duits kleurattribuut met het juiste datatype nodig heeft. Uw PIM moet laten zien wie eigenaar is van de afwijking, waarom die bestaat en wanneer deze voor het laatst is beoordeeld. Zo wordt productdata eenvoudiger te controleren én terug te draaien.

Gate 6: test de feed vooraf en herstel de brondata

Een dry-run is geen definitieve upload waarbij u maar hoopt dat alles goed gaat. Het is een gecontroleerde export waarmee u vóór de campagnedatum mappings, toegestane waarden, ontbrekende velden, afbeeldings-URL’s, productidentificaties en kanaalspecifieke waarschuwingen controleert. De belangrijkste discipline zit in de plek waar u corrigeert. Meldt de marketplace dat er een veld ontbreekt, herstel dan het bronveld in het PIM of de mappingregel. Past u het alleen in een portaal aan, dan kan de volgende export die correctie weer overschrijven.

Diagnostiek uit Google Merchant Center, uploadrapporten van Amazon, product-contentrapporten van bol.com, kwaliteitsschermen in Channable of ChannelEngine en API-reacties van marketplaces zijn allemaal bewijsmateriaal. Leg de afkeurcode, betrokken SKU’s, eigenaar, oorzaak en structurele oplossing vast. Na verloop van tijd wordt dat foutenlogboek een herbruikbare launchbibliotheek: categorie X vraagt altijd om een materiaaluitsplitsing, kanaal Y accepteert deze kleurwaarde niet, marketplace Z vereist een afbeeldingsrol die het brandteam vaak vergeet.

1. 1
   Exporteer de launchfeed

   Gebruik dezelfde mapping als op de lanceringsdag, maar draai de export voordat voorraad wordt gepromoot en campagnes live staan.
2. 2
   Classificeer elke fout

   Splits fouten uit naar brongegevens, mapping, categoriekeuze, productidentificatie, media, compliance of een systeemissue bij de marketplace.
3. 3
   Los het bij de bron op

   Pas het PIM-veld, de transformatie of de kanaalmapping aan. Vermijd correcties die alleen in het portaal staan, tenzij ze als override zijn gedocumenteerd.
4. 4
   Exporteer opnieuw tot alles stabiel is

   Een launchset is klaar wanneer er geen blokkerende fouten meer zijn en elke waarschuwing een eigenaar of geaccepteerde onderbouwing heeft.

Controlepunt 7: koppel lanceringsdata aan voorraad, orders en een terugvalplan

Een product kan zonder problemen door de contentvalidatie komen en toch operationele problemen veroorzaken wanneer de commerciële lancering losstaat van de voorraad. Klanten op marketplaces zien de productdata, maar het magazijn moet het artikel kunnen picken, verzenden, retour nemen en ondersteunen. Controleer daarom vóór publicatie de magazijn-SKU, barcode, picklocatie, voorraadbuffer, verzendregel, verpakkingsprofiel, retourafhandeling en levertijdbelofte. Verkopers die ChannelDock gebruiken, kunnen diezelfde operationele laag inzetten om productcontent te koppelen aan voorraadbeheer, orderimport en verzendregels.

Ook het terugdraaien van een lancering moet vooraf duidelijk zijn. Als Amazon een parent-familie onderdrukt, Google een feed afkeurt, Zalando afbeeldingen weigert of de voorraad in de praktijk niet beschikbaar is: wie pauzeert dan het kanaal, en wat wordt er precies gepauzeerd? Alleen het aanbod, de productcontent, de advertentiecampagne, het verkoopkanaal of uitsluitend de getroffen varianten? Marketplace-teams hebben vaak wel een publicatiechecklist, maar geen checklist om publicatie gecontroleerd terug te draaien. Daardoor groeien kleine contentfouten al snel uit tot vragen voor de klantenservice.

Geen rollbackplan

• Campagnes sturen nog steeds verkeer naar afgekeurde producten
• Aanpassingen in het portaal zorgen voor dataverschillen
• Beschikbaarheidsbeloften blijven actief terwijl de content geblokkeerd is
• Support hoort pas via klanten dat er iets misgaat