Een betrouwbaarheidsscore opbouwen voor een leverancierscatalogus

Een betrouwbaarheidsscore voor een leverancier moet waargenomen feiten samenvatten, geen commerciële indruk. Meet afzonderlijk de beschikbaarheid van de feed, de actualiteit ervan, de volledigheid, de stabiliteit en de consistentie van kritieke velden. Bewaar elke ruwe meting, maak de wegingen expliciet en leg blokkerende drempels op: een uitstekend responspercentage mag nooit verlopen prijzen of onbruikbare identificaties compenseren. De score dient dan om een review te prioriteren, een bron te vergelijken met zichzelf in de tijd en te beslissen of een import kan doorgaan. Hij bewijst noch de winstgevendheid van de producten, noch de algehele kwaliteit van de leverancier.

Een nuttige score begint met een operationele vraag

"Is deze leverancier betrouwbaar?" is te vaag. De echte vraag is eerder: "Kan ik deze feed vandaag gebruiken om een aankoopbeslissing voor te bereiden, en met welk niveau van menselijke controle?" Deze formulering scheidt de technische kwaliteit van de catalogus, de commerciële kwaliteit van de aanbieding en de kwaliteit van de contractuele relatie.

De score betreft dus een precies geïdentificeerde bron: API-URL, FTP-bestand, CSV-export of ander gedocumenteerd kanaal. Hij moet ook de waargenomen periode vermelden. Een score berekend op basis van één geslaagde download heeft niet dezelfde waarde als een reeks regelmatige controles. De periode, de observatiefrequentie en de uitgesloten incidenten moeten zichtbaar blijven naast het resultaat.

Bewaar vóór het beoordelen van de bron minstens: het tijdstip van elke poging, het technische resultaat, de grootte of het aantal ontvangen regels, de data in de gegevens, het aantal geweigerde regels en de exacte regel voor elke weigering. De methode voor actualiteitscontrole van prijzen en voorraad vult deze score aan zonder ermee samen te vallen, om de tijdsdimensie te verdiepen.

De vijf dimensies die je afzonderlijk moet meten

Een robuust rooster vermijdt criteria die niet controleerbaar zijn. De volgende dimensies zijn werkcategorieën, geen universele norm:

De beschikbaarheid van een artikel verdient een eigen test. Een status zoals InStock drukt beschikbaarheid uit in het Schema.org-vocabulaire, maar levert geen exacte hoeveelheid, meetdatum of reservering. Het artikel over het verschil tussen booleaanse voorraad en exacte hoeveelheid helpt te bepalen wat de feed werkelijk kan bevestigen.

Een weegschaal opbouwen zonder valse zekerheid te creëren

Er bestaat geen officiële weging die voor alle verkopers geldt. De weegschaal moet het risico van het gebruiksscenario weerspiegelen. Voor een snel roterende aankoop kan de actualiteit van de voorraad blokkerend zijn. Voor het verrijken van titels kan beschrijvende volledigheid zwaarder wegen. Twee teams kunnen dus verschillende scores krijgen op basis van dezelfde observaties, mits ze hun methode publiceren.

Hier volgt een volledig hypothetisch en reproduceerbaar voorbeeld. Aannames: een team kent 100 punten toe, verdeeld over beschikbaarheid 20, actualiteit 30, volledigheid 20, stabiliteit 15 en consistentie 15. Elke dimensie krijgt een ratio tussen 0 en 1, gedefinieerd in een versiebeheerd regelwoordenboek. Als de waargenomen ratio's respectievelijk 0,95, 0,70, 0,90, 1,00 en 0,80 zijn, is de berekening:

20 × 0,95 + 30 × 0,70 + 20 × 0,90 + 15 × 1,00 + 15 × 0,80 = 85.

Dit resultaat van 85 is geen marktwaarde en geen aankoopadvies. Het toont enkel de formule met fictieve aannames. Het detail onthult vooral dat actualiteit het zwakke punt is. Dat is nuttiger dan een globale groene kleur.

Voeg vervolgens veto-regels toe. Bijvoorbeeld, in je interne beleid, kan een bestand zonder valuta of zonder verifieerbare datum in review worden geplaatst, ook als het gewogen gemiddelde hoog blijft. Een veto is geen sanctie tegen de leverancier: het is een bescherming tegen wiskundige compensatie van een kritiek gebrek.

Reproduceerbare procedure in zeven stappen

1. Definieer de bron en het gebruik. Identificeer de feed, het geautoriseerde account, het kanaal, de verwachte frequentie en de beslissing die de data moet ondersteunen. 2. Schrijf het controlewoordenboek. Geef voor elk criterium het veld, de regel, de eenheid, de tolerantie en de verwachte reactie aan. Een onbekende regel blijft "niet beoordeeld", nooit "conform". 3. Verzamel ruw bewijs. Registreer tijdstempels, responscodes, relevante headers, bestandshash, volumes en weigeringen zonder deze te vervangen door de eindscore. 4. Bereken elke dimensie. Gebruik alleen de observaties van de weergegeven periode. Bewaar de teller, de noemer en de uitsluitingen. 5. Pas wegingen en veto's toe. Beheer versies van de weegschaal. Elke wijziging moet kunnen verklaren waarom twee opeenvolgende berekeningen verschillen. 6. Vergelijk de bron met haar eigen geschiedenis. Een plotselinge daling is vaak informatiever dan een vergelijking tussen twee leveranciers met verschillende contracten. 7. Beslis en documenteer. Sta de feed toe, beperk hem tot een testbatch, vraag een correctie of schors de import. De menselijke beslissing moet het belangrijkste bewijs vermelden.

RFC 9110 definieert onder meer de HTTP-statussen en de validatorvelden Last-Modified en ETag. Deze elementen kunnen een download documenteren, maar certificeren op zichzelf niet de zakelijke datum van een prijs. Een leverancier kan vandaag een bestand met oude data opnieuw publiceren. Bewaar dus zowel de transportmetadata als de interne catalogusdata.

De trend interpreteren in plaats van een score te heiligen

Een geïsoleerde score geeft een momentopname. Een tijdreeks toont een gedragsverandering: toenemende vertraging, meer weigeringen, wisselende patronen of herstel na een incident. Toon de globale score, maar ook de onderdelen en de gebeurtenissen die de beweging verklaren.

Vermijd een absolute rangschikking van leveranciers wanneer de reikwijdtes verschillen. Een kleine catalogus die dagelijks wordt bijgewerkt en een zeer grote database die per segment wordt ververst, beloven niet dezelfde service. Vergelijk elke bron eerst met haar eigen gedocumenteerde contract, dan met haar eigen vorige periodes. Een kruisvergelijking is alleen relevant als de criteria, de tijdvensters en de verplichte velden identiek zijn.

De score beoordeelt evenmin gebruiksrechten, kredietwaardigheid, productconformiteit, werkelijke levertijden of uiteindelijke winstgevendheid. Deze controles hebben andere bewijsvormen. Ze samenvoegen in één score zou de oorzaken onzichtbaar maken en correcties onnauwkeurig.

Wat ArbitragePro+ kan automatiseren / wat de verkoper zelf moet controleren

De functie score-sante-source is hier een voorgestelde specificatie, geen functie die als beschikbaar wordt aangeduid. Ze zou importresultaten kunnen verzamelen, dimensies volgens een versiebeheerde weegschaal kunnen berekenen, ontbrekende observaties kunnen tonen en een veto kunnen signaleren. Ze zou altijd moeten toelaten terug te keren naar de ruwe metingen en onderscheid te maken tussen "nul", "onbekend" en "niet van toepassing".

De verkoper moet het feedcontract, de toegangsrechten, de betekenis van de velden, de relevantie van de wegingen en de uiteindelijke beslissing controleren. Hij bevestigt ook dat de waargenomen periode representatief is. Vóór het uitbreiden van een bron laat een testpartij bij de leverancier toe de regels te testen binnen een beperkt en omkeerbaar bereik.

Checklist vóór gebruik van de score

• De bron, het kanaal en de periode zijn benoemd.
• Elke dimensie verwijst naar een raadpleegbare ruwe meting.
• Kritieke velden en veto's zijn vastgelegd vóór de berekening.
• De wegingen zijn gedateerd, versiebeheerd en verantwoord.
• Ontbrekende waarden worden niet omgezet in willekeurige nullen.
• Een verzameldatum wordt niet gepresenteerd als zakelijke updatedatum.
• De globale score gaat vergezeld van haar onderdelen.
• De menselijke beslissing en haar reden blijven traceerbaar.
• De score dient niet als bewijs van winstgevendheid of juridische conformiteit.

Bronsignalen bekijken

Open de gezondheid van bronnen in ArbitragePro+

Officiële bronnen

• IETF, RFC 9110 — HTTP Semantics: https://www.rfc-editor.org/rfc/rfc9110.html (geraadpleegd op 17-08-2026).
• Schema.org, ItemAvailability: https://schema.org/ItemAvailability (geraadpleegd op 17-08-2026).
• Schema.org, InStock: https://schema.org/InStock (geraadpleegd op 17-08-2026).