Een proefpartij (canary batch) betekent dat je een nieuwe leverancier aansluit op een bewust beperkt, observeerbaar en omkeerbaar deel van de catalogus, vóór elke grootschalige import. Selecteer producten die representatief zijn voor de moeilijkheden van de catalogus, leg de acceptatiecriteria vast, bewaar de ruwe antwoorden en voorzie stopcriteria. De test moet de geautoriseerde toegang, de structuur, de identifiers, de prijzen, de valuta, de voorraad, de actualiteit en de herhaalbaarheid van de feed controleren. Een geslaagde test garandeert geen verkopen of marge: hij toont alleen aan dat de catalogus de vastgestelde controles doorstaat voor dit deel en deze periode.
Waarom de eerste import beperkt houden
Een feed die correct antwoordt, kan nog steeds dubbelzinnige kolommen bevatten, varianten door elkaar halen, prijzen met een onbekend btw-regime of voorraden die moeilijk te interpreteren zijn. De hele catalogus in één keer importeren vermenigvuldigt het aantal te corrigeren objecten en maakt het lastiger om de oorzaak van een afwijking te isoleren. De proefpartij beperkt dit effect.
De methode is geen universele statistische steekproef. Het doel is operationeel: snel de gevallen blootleggen die het datacontract kunnen breken. De omvang van de partij hangt af van het aantal formats, categorieën, valuta's, varianten en voorraadscenario's dat gedekt moet worden. Ze moet onderbouwd zijn met een risicomatrix, niet gekozen omdat een rond getal geruststellend aanvoelt.
Loop het bestand of het antwoord, vóór elke verzameling, langs de controles die worden beschreven in de te controleren kolommen vóór import. De proefpartij mag niet dienen om achteraf te ontdekken wat price, stock, tax of updated_at betekenen.
Het testbereik bepalen per risicogeval
Selecteer regels die de situaties dekken die daadwerkelijk voorkomen in de officiële documentatie van de leverancier. Een eenvoudige matrix maakt de selectie controleerbaar:
| Te dekken geval | Voorbeeld van verwacht bewijs | Waargenomen risico | Mogelijke beslissing |
|---|---|---|---|
| Eenvoudig product | identifier, prijs, valuta, beschikbaarheid | ontbrekend veld of inconsistent type | mapping corrigeren |
| Variant | apart identifier en expliciet attribuut | samenvoegen van maten of kleuren | koppelingen isoleren |
| Nul- of niet-beschikbare voorraad | ruwe waarde en gedocumenteerde betekenis | nul verward met onbekend | publicatie blokkeren |
| Actie of staffel | data, minimumhoeveelheid en eenheid | prijs buiten voorwaarden | prijs uitsluiten van berekening |
| Product zonder GTIN | ander stabiel identifier en herkomst | onzekere matching | verplichte menselijke controle |
| Herhaalde update | twee tijdgestempelde ophalingen | overschrijving of onverklaarde verdwijning | verschil analyseren |
Dit rooster moet de geteste bron weerspiegelen. Als de leverancier geen staffels of varianten hanteert, creëer deze gevallen dan niet kunstmatig. Kies omgekeerd ook niet alleen de meest complete regels: de proefpartij zou dan zijn vermogen verliezen om de randen van het contract bloot te leggen.
Het protocol schrijven vóór je test start
Een bruikbaar canary-protocol past op een herzienbaar formulier. Het bevat:
1. De identiteit van de bron. Domein, endpoint of geautoriseerd pad, type feed, betrokken account en verwijzing naar de officiële documentatie. 2. De juridische en contractuele basis. Licentie, algemene voorwaarden, handelsovereenkomst of schriftelijke toestemming, toegestane doeleinden en bewaartermijn. Technische toegang vervangt deze rechten niet. 3. Het bereik. Selectiecriteria voor producten, opgenomen categorieën, gedekte gevallen en bekende uitsluitingen. 4. De mapping. Bronkolom, doelveld, type, eenheid, transformatieregel en behandeling van ontbrekende waarden. 5. De controles. Regel, bewaard bewijs, ernst en verantwoordelijke voor de beslissing. 6. De stopcriteria. Toegangsincident, wijziging van format, dubbelzinnig identifier, onbekende valuta of elke andere kritieke afwijking die het team definieert. 7. De terugdraaimogelijkheid. Partij-ID, aangemaakte objecten, manier om ze te deactiveren en bewaring van het logboek.
Het protocol mag geen sleutel, token of persoonlijk identificatiegegeven bevatten. Geheimen blijven in de opslag die de infrastructuur daarvoor voorziet. Het logboek mag een technisch verbindings-ID bewaren zonder het geheim zelf bloot te geven.

De proefpartij uitvoeren in vier stappen
Stap 1: ophalen zonder te transformeren
Bewaar het ruwe antwoord, de tijdstempel, de fingerprint, de transportstatus en de relevante headers. Voor HTTP geeft RFC 9110 de semantiek van statuscodes en velden zoals ETag of Last-Modified. Deze metadata documenteren de uitwisseling; ze bewijzen niet dat de prijs in het antwoord zojuist herzien is.
Stap 2: valideren zonder te publiceren
Pas de mapping toe en classificeer elke regel: geaccepteerd, afgewezen of te herzien. Vervang een ontbrekende valuta, onbekende voorraad of ongeldige GTIN nooit stilzwijgend. Bewaar de brontwaarde en de reden. GS1-sleutels identificeren specifieke handelsobjecten; een identifier die qua vorm correct is, bewijst niet dat het ontvangen product overeenkomt met de juiste fiche.
Stap 3: herhalen onder dezelfde omstandigheden
Herhaal het ophalen volgens de geplande frequentie en vergelijk de versies. Zoek naar verschenen of verdwenen kolommen, typewijzigingen, volumeschommelingen en interne datums. Het doel is niet absolute stabiliteit te eisen, maar te controleren of veranderingen verklaarbaar zijn en of de verwerking idempotent is: dezelfde invoer opnieuw verwerken mag geen fiches vermenigvuldigen.
Stap 4: beslissen op basis van bewijs
Lever een overzicht per regel, niet alleen een algemeen oordeel. Eén kritieke afwijking kan voldoende zijn om de test te verlengen, zelfs als het merendeel van de regels correct is. Omgekeerd hoeven een paar ontbrekende optionele velden niet noodzakelijk tot stopzetting te leiden. De beslissing moet de regel, de observatie en de persoon die deze heeft gevalideerd vermelden.
De betrouwbaarheidsscore van de leverancier kan de resultaten na de test samenvatten, mits elke component raadpleegbaar blijft. Deze vervangt de stopcriteria van de proefpartij niet.
Technische en contractuele grenzen respecteren
Een robots.txt-bestand betreft het gedrag van geautomatiseerde clients op URI's. RFC 9309 stelt dat de regels aan robots worden gevraagd en geen vorm van toegangsautorisatie vormen. Een Allow-regel is dus geen hergebruikslicentie; het ontbreken van een regel vervangt de voorwaarden van de leverancier niet. Het canary-protocol moet zowel de technische beperkingen, de frequentielimieten als de contractuele rechten respecteren.
Vermijd ook dat de test onbedoeld belasting veroorzaakt. Gebruik het officiële exportmechanisme wanneer dat bestaat, respecteer de gedocumenteerde quota's, voeg vertraging toe en stop bij herhaalde fouten. Een incident mag geen agressieve lus veroorzaken. Elke uitbreiding van volume of frequentie vereist een nieuwe validatie van het bereik.
Wat ArbitragePro+ kan automatiseren / wat de verkoper zelf moet controleren
De functie canary-lancering die hier beschreven wordt, is een voorgestelde specificatie, geen functie die als beschikbaar wordt gepresenteerd. Ze zou een geïsoleerde partij kunnen aanmaken, de geversioneerde regels kunnen koppelen, de stappen kunnen loggen, publicatie standaard kunnen blokkeren en een overzicht met terugdraaimogelijkheid kunnen opleveren. Het verwachte scherm zou de bron, het bereik, elke controle, de afwijkingen en de beslissing moeten tonen, zonder geheimen of persoonsgegevens te tonen.
De verkoper blijft verantwoordelijk voor de gebruikstoestemming, de keuze van representatieve gevallen, de betekenis van de velden, de stopcriteria en de eindvalidatie. Hij moet met name de controle uitvoeren die wordt beschreven in de gebruiksrechten van een productfeed voordat hij een geautomatiseerde verzameling start.
Checklist bij afsluiting van de proefpartij
- De toepasselijke officiële documentatie en toestemming zijn gearchiveerd.
- Het bereik dekt de daadwerkelijk aanwezige risicogevallen.
- De ruwe data, datums en fingerprints zijn bewaard.
- Elke regel heeft een raadpleegbare status en reden.
- Kritieke velden worden nooit aangevuld op basis van veronderstellingen.
- Een tweede ophaling bevestigt dat de mapping herhaalbaar is.
- Herhaalde fouten stoppen de test zonder verzoeklus.
- De terugdraaimogelijkheid is getest op de geïsoleerde partij.
- Het overzicht onderscheidt blokkerende zaken, waarschuwingen en optionele velden.
- Uitbreiding is een gedateerde menselijke beslissing, geen automatisch gevolg van een score.
De te testen bron voorbereiden
Open het bronnenbeheer in ArbitragePro+
Officiële bronnen
- IETF, RFC 9110 — HTTP Semantics: https://www.rfc-editor.org/rfc/rfc9110.html (geraadpleegd op 17-08-2026).
- IETF, RFC 9309 — Robots Exclusion Protocol: https://www.rfc-editor.org/rfc/rfc9309.html (geraadpleegd op 17-08-2026).
- GS1, Global Trade Item Number (GTIN): https://www.gs1.org/standards/id-keys/gtin (geraadpleegd op 17-08-2026).
