Actualiteit van prijzen en voorraad: een betrouwbaarheidstermijn bepalen

Een prijs of voorraadstatus is alleen betrouwbaar als je weet wanneer die is gegenereerd, wanneer die is verzameld en of de verzameling volledig was. Definieer afzonderlijke betrouwbaarheidstermijnen per leverancier, veldtype en gebruik: automatische aankoop, handmatige alert of eenvoudige historische analyse. Er bestaat geen universele duur. Voorraad kan sneller veranderen dan productkenmerken, en een oude prijs kan contractueel nog geldig zijn. Vervang een waarde na het verstrijken van de gekozen termijn niet door nul: markeer haar als "te bevestigen" of "verlopen", blokkeer acties die niet passen bij dat bewijsniveau en vraag een recente observatie vóór een bestelling.

Drie tijdstempels in plaats van een vage "laatst bijgewerkt"

Actualiteit wordt vaak herleid tot de uitvoeringsdatum van het script. Dat is onvoldoende. Een geslaagde verzameling om 10 uur kan een bestand downloaden dat de dag ervoor is geproduceerd, zelf gebaseerd op een bedrijfssysteem dat op een onbekend ritme wordt bijgewerkt. Bewaar zo mogelijk drie afzonderlijke tijdstippen:

• source_generated_at: de door de leverancier opgegeven datum van de data of het bestand;
• observed_at: het moment waarop je systeem de respons ontving;
• validated_at: het moment waarop de inhoud de controles doorstond en bruikbaar werd.

Als de eerste tijdstempel niet bestaat, vervang die dan niet door het downloadtijdstip. Noteer expliciet source_generated_at=onbekend. De HTTP-validators ETag en Last-Modified, beschreven in RFC 9110, kunnen helpen om te weten of een representatie is veranderd wanneer de server ze correct levert. Ze bewijzen op zichzelf echter niet wanneer de zakelijke prijs of voorraad is bijgewerkt.

Elke gegevensfamilie afzonderlijk behandelen

Een productfiche bundelt elementen die niet even snel veranderen. Merk, titel of GTIN worden doorgaans als identiteitsdata gebruikt; prijs, beschikbaarheid, levertijd en korting zijn aanbiedingsdata. Eén globale datum verhult deze verschillen.

De status InStock verdient bijzondere aandacht. Schema.org definieert hem als een aanduiding dat het artikel op voorraad is, maar deze conventie geeft geen hoeveelheid en geen tijdstempel. De leeftijd van de observatie blijft dus essentieel. Het onderscheid tussen booleaanse voorraad en exacte hoeveelheid moet naast de actualiteit bewaard blijven.

Een betrouwbaarheidsbeleid opbouwen zonder een standaard te verzinnen

Begin bij het risico van de actie. Een zoekpagina die door een mens wordt bekeken, kan oudere data tonen met een duidelijke waarschuwing. Een bestelling die zonder controle wordt geactiveerd, vereist recenter bewijs en sterkere contractuele garanties. Definieer vervolgens een interne termijn voor elke combinatie bron × veld × gebruik, en documenteer wie die heeft goedgekeurd.

Hier volgt een volledig hypothetisch voorbeeld dat de structuur toont, geen aanbevolen duur. Een team zou kunnen beslissen dat voorraad die minder dan twee uur geleden is waargenomen "recent" is voor een alert, dat die tussen twee en acht uur "te bevestigen" is, en dat die daarna "verlopen" is. Voor een maandelijkse contractprijs zou een andere regel kunnen gelden. Deze cijfers komen uit geen enkele norm: vervang ze door drempels op basis van je waargenomen ritme, je contract en je risicotolerantie.

De kalibratieprocedure is belangrijker dan het begincijfer:

1. Registreer elke geslaagde, onvolledige of mislukte verzameling. 2. Meet, veld per veld, de intervallen tussen werkelijk waargenomen wijzigingen. 3. Noteer geweigerde bestellingen, prijsverschillen en uitverkocht-meldingen na observatie. 4. Kies een voorzichtige en expliciete beginwaarde voor het bestudeerde gebruik. 5. Toon de datum en status aan de gebruiker, niet enkel een score. 6. Herzie de drempel op basis van incidenten en nieuw bewijs.

Een beleid mag een waarde nooit als vers verklaren enkel omdat de job is gestart. Het hangt af van een geldige, volledige respons die aan de juiste bron kan worden toegeschreven.

Omgaan met gedeeltelijke verzamelingen en stiltes

Een kleiner bestand dan gebruikelijk kan een echte inkrimping van de catalogus zijn of een onderbroken export. Een API kan 200 OK teruggeven terwijl ze door een verkeerd beheerde cursor een lege pagina levert. Actualiteit moet daarom een volledigheidscontrole omvatten: verwacht volume als waargenomen bereik, aantal pagina's, aanwezigheid van kritieke velden en stabiliteit van ID's.

Als de controle mislukt, bewaar dan de laatst gevalideerde waarde met haar oude tijdstempel. Koppel het foutmoment niet aan de bewaarde data. Registreer apart last_attempt_at, last_success_at en de exacte reden. Zo kun je een stille bron onderscheiden van een product dat écht uitverkocht is.

De keuze van het CSV-, XML-, API- of FTP-feedformaat beïnvloedt de hervattingsstrategie, maar niet de fundamentele regel: je zet de tijdstempel van data alleen vooruit wanneer een relevante, gevalideerde observatie dat rechtvaardigt.

Onzekerheid tonen zonder misleidende score

Een globale score kan helpen bij het sorteren, mits die uitlegbaar blijft. Toon de werkelijke leeftijd, de beschikbare tijdstempel, het type voorraadbewijs en de laatste incidenten naast elke kleurcode. Een groene meter zonder detail maakt van een interne keuze een impliciete belofte.

Geef de voorkeur aan drie operationele statussen: bruikbaar_voor_analyse, bevestiging_vereist en geblokkeerd_voor_actie. De regels die tot deze statussen leiden, moeten leesbaar zijn. De betrouwbaarheidsscore van een leverancier kan actualiteit meenemen, maar mag nooit een kritieke fout of een ontbrekend veld wegpoetsen.

Actualiteitschecklist

• ☐ Brondatum, observatiedatum en validatiedatum zijn gescheiden.
• ☐ Prijs en voorraad hebben elk hun eigen status.
• ☐ Een ontbrekende tijdstempel wordt als onbekend gemarkeerd.
• ☐ Een ETag wordt niet gepresenteerd als een zakelijke datum.
• ☐ De drempels zijn intern, goedgekeurd en herzienbaar.
• ☐ Volledigheid wordt gecontroleerd vóór de verzameling als geslaagd wordt beschouwd.
• ☐ Een fout ververst de laatst geldige waarde niet.
• ☐ De werkelijke leeftijd blijft zichtbaar naast de score.
• ☐ Een recente bevestiging wordt gevraagd vóór een bestelling.
• ☐ Incidenten voeden de herziening van het beleid.

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

De voorgestelde specificatie score-fraicheur zou de leeftijd van observaties kunnen berekenen, geconfigureerde drempels kunnen toepassen, gedeeltelijke verzamelingen kunnen signaleren en het gebruik van een verlopen waarde kunnen blokkeren. Ze zou altijd de tijdstempels en de regel die tot de status leidde moeten tonen.

De verkoper moet termijnen bepalen die passen bij zijn contract en risico, prijs en beschikbaarheid vóór aankoop bevestigen, en beslissen over gevallen waarin de bron geen zakelijke tijdstempel biedt.

De status van bronnen bewaken

Bekijk de gezondheid van bronnen om de huidige verzamelinformatie en meldingen te bekijken.

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.