Leveranciersdata normaliseren voor uw webshop: van vuile import naar veilig productrecord

Leveranciersdata is zelden rechtstreeks geschikt voor een webshop. De veilige aanpak is niet “CSV importeren en achteraf fouten herstellen”, maar een vaste tussenlaag bouwen: ruwe input bewaren, velden normaliseren, harde controles uitvoeren en alleen geldige records publiceren.

Dat klinkt technisch. Daarom werken we hieronder één product volledig uit: van een rommelige leveranciersrij tot een bruikbaar intern record — inclusief wat het systeem bewust níét mag invullen.

Trash in, trash out. Automatisering maakt slechte input vooral sneller. Een betrouwbare import herkent ontbrekende of twijfelachtige data en stopt het product vóór publicatie.

Concreet voorbeeld: de slechte importdata#

Stel dat een verlichtingsleverancier deze rij aanlevert:

Op het eerste gezicht zit bijna alles erin. Toch is deze rij niet publiceerbaar:

• lx-0042 bevat spaties en gebruikt een afwijkende schrijfwijze;
• de titel is een reeks afkortingen, geen begrijpelijke productnaam;
• de EAN bevat spaties en moet na opschoning nog een geldige controlecode hebben;
• de prijs combineert een decimale komma en valuta in één tekstveld;
• JA zegt dat er voorraad is, maar niet hoeveel;
• bij 2400 ontbreekt de eenheid: gram en kilogram geven een totaal ander resultaat;
• de categoriecode bestaat niet in de webshop;
• merk en bruikbare afbeeldings-URL ontbreken.

Blind importeren geeft dus een product met slechte filtering, onzekere verzenddata en mogelijk een verkeerde voorraadstatus. Een taalmodel een mooie beschrijving laten schrijven lost die structurele fouten niet op.

Stap 1: vertaal elke bron naar één intern datamodel#

Geef elk concept intern één vaste naam en datatype. De leverancierskolommen mogen verschillen; uw kernmodel blijft gelijk.

Bewaar daarnaast altijd de ongewijzigde bronrij en het tijdstip van import. Dan kunt u later reconstrueren waarom een waarde gewijzigd of geweigerd werd.

Stap 2: normaliseer zonder feiten te verzinnen#

Na de veilige omzettingen kan het interne record er zo uitzien:

{
  "supplier_sku": "LX-0042",
  "source_title": "LED PROF 120CM 4000K 36W 230V WH",
  "gtin": "5411234567897",
  "purchase_price": 79.50,
  "currency": "EUR",
  "stock_quantity": null,
  "length_mm": 1200,
  "color_temperature_k": 4000,
  "power_w": 36,
  "color": "wit",
  "weight_kg": null,
  "source_category": "LGT>PRO>IND",
  "category_id": "industrial-line-lighting",
  "brand": null,
  "image_url": null
}

Dit is al veel consistenter, maar nog steeds geen “goed product” voor de klant. De lege waarden zijn hier net belangrijk: het systeem geeft eerlijk aan wat het niet weet. 2400 wordt bijvoorbeeld niet automatisch 2,4 kg zolang de leverancier de eenheid niet heeft bevestigd.

Stap 3: laat validatie beslissen of publicatie veilig is#

Maak de publicatieregels expliciet. Voor deze catalogus kunnen dat bijvoorbeeld de volgende controles zijn:

De juiste uitkomst is dus geen halflege productpagina, maar een gecontroleerde status:

{
  "publish_status": "blocked",
  "reason_codes": [
    "STOCK_QUANTITY_MISSING",
    "WEIGHT_UNIT_UNKNOWN",
    "BRAND_MISSING",
    "MAIN_IMAGE_MISSING"
  ],
  "next_action": "supplier_data_review"
}

Zo ziet uw team meteen welke vier gegevens ontbreken. Nog belangrijker: dezelfde problemen zijn per leverancier telbaar, zodat u niet telkens losse producten hoeft na te kijken.

Stap 4: zo ziet goede, publiceerbare output eruit#

De leverancier bevestigt daarna dat het gewicht in gram staat, levert een voorraadhoeveelheid van 18 stuks, vult het merk aan en stuurt een geldige afbeelding. Pas dan maakt de publicatielaag het definitieve record:

Een leesbare titel mag uit bevestigde kenmerken worden samengesteld. Een commerciële beschrijving kan vervolgens worden verrijkt, maar productfeiten zoals vermogen, materiaal, compatibiliteit of certificering mogen nooit worden gegokt.

Dezelfde leveranciersfeed maakt uw productpagina niet onderscheidend#

Uw leverancier stuurt dezelfde titel, specificaties en afbeeldingen meestal ook naar andere resellers. Als iedereen die feed één op één publiceert, ontstaan tientallen productpagina’s die de zoeker inhoudelijk bijna hetzelfde bieden.

Dat is niet automatisch een “duplicate-content penalty”. Het praktische SEO-probleem is eenvoudiger: waarom zou een zoekmachine uw pagina kiezen wanneer ze geen extra antwoord geeft? Google adviseert content te maken die nuttig is voor mensen en originele waarde toevoegt, in plaats van bestaande informatie alleen samen te vatten of anders te formuleren. Zie de Google-richtlijnen voor behulpzame, betrouwbare content.

Voorbeeld: dezelfde feiten, meer eigen waarde#

Uniek betekent hier niet dat u synoniemen zoekt voor dezelfde leverancierszin. Het betekent dat u eigen kennis, service-informatie en gecontroleerde context toevoegt die een klant helpt kiezen of installeren.

Maak niet automatisch honderd “unieke” teksten van één dunne feed. Als brondata geen bruikbare feiten bevat, produceert herschrijven vooral honderd varianten van hetzelfde tekort. Voeg eerst echte informatie toe en schaal pas daarna de redactie.

Welke correcties mag u automatiseren?#

Een bruikbare scheidslijn:

• Veilig automatisch: witruimte verwijderen, hoofdletters standaardiseren, decimale komma omzetten, gekende eenheden converteren, bestaande categoriecodes mappen en een EAN-controle uitvoeren.
• Automatisch met controle: kenmerken uit een titel halen, producttitels samenstellen, categorieën voorstellen en beschrijvingen herschrijven op basis van bevestigde attributen.
• Niet verzinnen: merk, materiaal, afmetingen, voorraad, veiligheidsclaims, certificaten of compatibiliteit wanneer de bron ze niet betrouwbaar bevat.

Dat onderscheid voorkomt dat “verrijking” stilletjes datavervalsing wordt. Bij twijfel gaat een record naar quarantaine met een concrete reden.

Voorkom dat de volgende feed alles overschrijft#

Bij elke eigenschap moet duidelijk zijn wie eigenaar is. Een praktisch model gebruikt drie lagen:

1. Brondata: de laatste ongewijzigde waarde van de leverancier.
2. Genormaliseerde data: uw vaste formaten, mappings en validatieresultaten.
3. Webshopdata: goedgekeurde titels, teksten, categorieën en eventuele handmatige overrides.

Een nieuwe feed mag de bronlaag bijwerken, maar niet automatisch een goedgekeurde webshoptekst of bewuste categorie-override vernietigen. Leg daarom per veld vast of de leverancier, een regel, een medewerker of de webshop leidend is.

Meet datakwaliteit per leverancier#

Meet niet alleen hoeveel producten geïmporteerd zijn. Volg minstens:

• percentage records dat zonder ingreep door validatie komt;
• aantal geblokkeerde producten per reden;
• percentage geldige afbeeldingen en GTIN’s;
• tijd tussen ontvangst en publicatie;
• aantal handmatige correcties dat bij een volgende feed terugkomt;
• foutpercentage na publicatie, bijvoorbeeld verkeerde categorie of gewicht.

Hiermee ziet u of de bron structureel verbetert en waar een mappingregel meer oplevert dan extra handwerk. Voor de volledige keten—van bestand ophalen tot monitoring en fallback—leest u leveranciersdata automatiseren zonder controle te verliezen.

Een goede import is streng vóór hij snel is#

Leveranciersdata normaliseren draait niet om zoveel mogelijk producten direct live zetten. Het doel is dat goede records snel doorstromen en twijfelachtige records met een duidelijke reden stoppen. Begin met één intern datamodel, leg per veld de eigenaar vast en maak publicatie afhankelijk van expliciete kwaliteitsregels.

Dan wordt een feed geen terugkerende schoonmaakklus, maar een controleerbare productdatastroom die bij elke update opnieuw dezelfde standaard afdwingt.