Slimme productselectie begint met betrouwbare data, niet met agressieve scraping

De kern: ontwerp een productinformatiesysteem, geen kopieermachine

Voor cross-border e-commerce is de verleiding groot om zoveel mogelijk productpagina’s, prijzen en afbeeldingen geautomatiseerd te verzamelen. Maar een schaalbaar systeem draait niet om het maximale aantal requests. Het draait om controleerbare productfeiten, toegestane databronnen en beslissingen die ook na verzending, retouren en advertentiekosten nog winstgevend blijken.

De verstandigste volgorde is daarom:

1. geautoriseerde catalogusdata en leverancierfeeds;
2. eigen winkel-, order- en advertentiedata;
3. lichte, toegestane webextractie voor publieke aanvullingen;
4. browserautomatisering alleen wanneer die nodig én toegestaan is.

Anti-botmaatregelen zijn bovendien meerlagig. Cloudflare beschrijft onder meer TLS-kenmerken via JA3/JA4 én afzonderlijke JavaScript-detectie. Een browserachtige netwerkhandtekening op zichzelf bewijst dus niet dat verkeer als legitiem wordt beoordeeld.1423

Bouw de pijplijn in zeven lagen

1. Inname: begin met rechten en herkomst

Leg per bron vast of je toegang hebt via een API, leveranciersfeed, contractuele toestemming of eigen account. Dat is niet alleen een juridische formaliteit: het bepaalt ook hoe betrouwbaar je voorraad, varianten en wijzigingen kunt synchroniseren.

Sla bij iedere waarneming minimaal op:

• source_product_id en source_variant_id
• verkoper of leverancier
• markt, valuta en afleverregio
• moment van observatie en bron-update
• bronversie of ruwe snapshot
• parserversie
• beschikbaarheidsstatus
• matchbetrouwbaarheid
• rechtenstatus voor tekst en afbeeldingen

Alleen een prijs en URL bewaren is onvoldoende. Zonder variant, verkoper, land, tijdstip en leveringsvoorwaarden kun je later niet uitleggen waarom een product werd geselecteerd.

2. Bewijslaag: behoud de ruwe bron

Bewaar ruwe responses, feedrecords of toegestane pagina-snapshots naast de genormaliseerde velden. Zo kun je fouten in extractie terugzoeken, gewijzigde productinformatie vergelijken en een selectie opnieuw afspelen.

Belangrijk: een mislukte uitlezing is geen bedrijfsfeit. Schrijf een technisch toegangsprobleem nooit weg als ‘uitverkocht’ of ‘product verwijderd’.

3. Normalisatie: maak data vergelijkbaar vóór je rekent

Normaliseer prijzen, btw-behandeling, valuta, maten, gewicht, verpakkingseenheden, levertijd en verzendzones. Bewaar altijd ook de oorspronkelijke waarde.

Een product van € 19,99 kan bijvoorbeeld goedkoper lijken dan een alternatief van € 24,99, maar toch minder aantrekkelijk zijn wanneer het eerste aanbod exclusief verzending, invoerheffingen of lokale btw is. Voor internationale verkoop is deze stap geen opschoning achteraf, maar een voorwaarde voor elke margeanalyse.

4. Productidentiteit: onderscheid productfamilie, SKU en offer

Maak een duidelijk datamodel voor:

• productfamilie: bijvoorbeeld een specifiek model hoofdtelefoon;
• SKU of variant: kleur, capaciteit, plugtype of verpakking;
• offer: de concrete aanbieding van een verkoper, in een markt en op een moment;
• voorraadlocatie en fulfilmentvoorwaarde: waar en onder welke voorwaarden het artikel leverbaar is.

Onderzoek naar entity resolution laat zien dat taalmodellen productrecords kunnen helpen beoordelen op onderliggende identiteit.4 Multimodale aanbevelingsliteratuur onderstreept ook dat tekst, beeld en andere content aanvullende signalen bieden bovenop alleen categorieën en item-ID’s.5

Maar visuele of tekstuele gelijkenis is geen commerciële gelijkwaardigheid. Controleer daarom in deze volgorde:

1. GTIN/EAN, merk en modelnummer;
2. capaciteit, maat, kleur en verpakkingseenheid;
3. voltage, stekkertype en regionale uitvoering;
4. meegeleverde accessoires en garantie;
5. pas daarna tekst- en beeldgelijkenis als aanvullend signaal.

Een conflict op een hard kenmerk moet een match blokkeren. Een model mag een kandidaat ook als ‘onbekend’ markeren in plaats van twee producten geforceerd samen te voegen.

AI inzetten waar het echt waarde toevoegt

OCR en multimodale extractie

Gebruik OCR voor tekst in verpakkingen, maattabellen en specificatieafbeeldingen. Laat een multimodaal model vervolgens attributen voorstellen, maar niet zonder controle de bronwaarden overschrijven.

Een robuuste werkwijze is:

1. neem eerst gestructureerde velden uit de geautoriseerde bron over;
2. extraheer zichtbare tekst uit afbeeldingen;
3. laat een model attribuutkandidaten en bewijsfragmenten aandragen;
4. valideer met categorie-, eenheids- en compatibiliteitsregels;
5. stuur lage betrouwbaarheid naar handmatige beoordeling.

Kennisgrafen kunnen daarbij nuttig zijn voor relaties zoals merk → model → specificatie → leverancier → marktversie. Onderzoek naar knowledge-graph embeddings beschrijft hoe entiteiten en relaties in compacte representaties kunnen worden vastgelegd.7 Begin echter met uitlegbare relaties en harde validatieregels; een grafmodel is geen vervanging voor een controle op een conflicterend modelnummer.

Matchkwaliteit meten

Meet niet alleen een gemiddelde F1-score. Kijk vooral naar de precisie van automatisch geaccepteerde matches: een foutieve koppeling kan leiden tot verkeerde compatibiliteitsclaims, retouren of marginverlies.

Neem lastige negatieve voorbeelden op in je testset, zoals:

• hetzelfde productbeeld met een andere verpakking;
• hetzelfde model met andere regionale stekker;
• hoofdproduct tegenover accessoire;
• identieke naam, maar afwijkende capaciteit of garantie.

Van prijsverschil naar verwachte nettowinst

Een zichtbare prijsafstand tussen marktplaatsen is geen risicovrije arbitrage. Literatuur over online competitieve prijsstelling maakt duidelijk dat productgelijkheid, tijdsdynamiek en marktstructuur een groot verschil maken.2

Gebruik daarom een nettobijdragemodel per product en prijsniveau:

$$
\mathbb{E}[\Pi_i(p)] = \mathbb{E}[Q_i(p)] \times \left[p - C_{\text{landed},i} - C_{\text{payment},i}(p) - C_{\text{acquisition},i} - \mathbb{E}[C_{\text{aftersales},i}]\right] - C_{\text{fixed},i}
$$

Waarbij:

• $Q_i(p)$ de verwachte, daadwerkelijk uitleverbare vraag is;
• $C_{\text{landed}}$ inkoop, transport, douane en niet-verrekenbare belastingen omvat;
• $C_{\text{payment}}$ betaal- en platformkosten bevat;
• $C_{\text{acquisition}}$ volgens één consistente attributiemethode wordt berekend;
• $C_{\text{aftersales}}$ retouren, refunds, chargebacks en vervangingen meeneemt;
• $C_{\text{fixed}}$ vaste content-, integratie- en operationele kosten dekt.

Voorkom dubbeltellingen. Trek bijvoorbeeld advertentiekosten niet zowel af in de CAC als nog eens in een algemene overheadpost.

Voorspellen is niet hetzelfde als prijselasticiteit schatten

Retailonderzoek rond de M5-competitie wijst erop dat globale machine-learningmodellen goed kunnen presteren wanneer zij patronen over veel gerelateerde tijdreeksen delen.3 Dat is nuttig voor vraagprognoses, maar het bewijst niet wat er gebeurt als jij actief de prijs verandert.

Voor prijsbeslissingen is causaliteit essentieel. Het onderzoek Causal Forecasting for Pricing combineert causale modellering met forecasting, juist omdat prijs een ingreep is en niet slechts een inputkolom.21

Praktisch betekent dit:

• gebruik een vraagmodel om onzekerheid en verwachte verkoop te voorspellen;
• gebruik gecontroleerde prijsexperimenten of een expliciete identificatiestrategie om prijseffecten te schatten;
• behandel feature importance niet als bewijs van prijselasticiteit;
• rank producten ook op downside-risico, niet uitsluitend op gemiddelde marge.

Een veilige technische route voor dataverzameling

De technische architectuur moet betrouwbaarheid boven volume zetten.

Aanbevolen route per bron

1. Eigen winkels en geautoriseerde leveranciers: API’s, exports en feeds.
2. Catalogi met expliciete integratiemogelijkheden: batch-import plus periodieke afstemming.
3. Publieke informatie als aanvulling: beperk frequentie, respecteer voorwaarden en meet datakwaliteit.
4. Browseruitvoering: alleen voor rechtmatige, noodzakelijke taken met duidelijke foutafhandeling en budgetten.

Cloudflare documenteert dat JA3/JA4-velden niet in alle situaties beschikbaar hoeven te zijn en dat bepaalde paden of challengepagina’s een afwijkende behandeling kunnen krijgen.22 Dat is een extra reden om infrastructuursignalen niet te verwarren met betrouwbare productdata.

Operationele regels

• Isoleer sessies, foutbudgetten en limieten per domein en toegangscontext.
• Classificeer fouten: netwerkprobleem, rate limit, sessieverloop, challenge, parsingfout of bronwijziging.
• Gebruik een circuit breaker bij herhaalde afwijzingen; schakel dan terug naar een feed, API of menselijke workflow.
• Meet kosten per bruikbaar, controleerbaar productrecord, niet per succesvolle request.
• Versieer parsers en datamodellen zodat regressies zijn terug te draaien.

pSEO en Shopping: pas schalen na kwaliteitscontrole

Programmatic SEO is waardevol wanneer pagina’s unieke, correcte en bruikbare informatie toevoegen. Het wordt riskant wanneer duizenden vrijwel gelijke pagina’s worden gepubliceerd op basis van onzekere voorraad, gekopieerde tekst of incomplete varianten.

Gebruik een publicatiepoort met minimaal deze voorwaarden:

• voorraad en prijs zijn recent geverifieerd;
• productidentiteit en varianten zijn voldoende zeker;
• specificaties en levertijd zijn volledig;
• beeld- en tekstrechten zijn beoordeeld;
• netto marge voldoet aan je drempel;
• de pagina heeft een eigen informatieve reden om te bestaan.

Maak zoekwoordideeën uit specificaties, compatibiliteit, afmetingen, gebruikssituaties en klantvragen. Behandel ze eerst als hypotheses. Combineer ze pas met pagina’s nadat je vraag, intentie, taal en markt hebt gecontroleerd met data die je rechtmatig mag gebruiken.

Voor Google Shopping is ook de integratielaag aan verandering onderhevig. Google meldt dat de Content API for Shopping op 18 augustus 2026 wordt uitgefaseerd en verwijst integraties naar de Merchant API.15 Bouw daarom één productwaarheidsbron waaruit storefront, feed en Merchant API worden gevoed, in plaats van drie losstaande datasets te onderhouden.

Prioriteiten voor de eerste 90 dagen

Fase 1: beperk de scope

Kies één doelmarkt, één categorie en één geautoriseerde databron. Leg vast welke prijs- en voorraadveroudering acceptabel is.

Fase 2: maak productfeiten reproduceerbaar

Bouw het product-, variant- en offermodel. Sla ruwe brondata en parsermetadata op. Maak een kleine, handmatig gecontroleerde dataset voor SKU-matching.

Fase 3: reken echte marge uit

Definieer landed cost, retourkosten, fulfilment en CAC volgens één boekingslogica. Start met een uitlegbaar vraagmodel voordat je complexere ML inzet.

Fase 4: valideer commercieel

Test een beperkte selectie op conversie, leverbaarheid, retouren en netto contributiemarge. Vergroot pas daarna het aantal bronnen, modellen en SEO-landingspagina’s.

Wat de beschikbare bronnen wel en niet onderbouwen

De bronnen ondersteunen het idee dat multimodale signalen, entity resolution, globale forecasting en causale prijsmodellen nuttige bouwstenen kunnen zijn.34521 Ze ondersteunen niet de claim dat een generiek open-sourcepakket langdurig alle botbescherming kan omzeilen, of dat een marktplaatsrang automatisch kan worden omgerekend naar stabiele omzet of winst.

De meest duurzame voorsprong zit daarom niet in het agressief ophalen van meer data, maar in beter bewijs: correcte SKU-koppelingen, actuele fulfilmentkosten, expliciete onzekerheid en een feedbacklus van order tot retour.