Aktualität von Preisen und Beständen: eine Vertrauensfrist definieren

Ein Preis oder ein Bestand ist nur verlässlich, wenn Sie wissen, wann er erzeugt, wann er erfasst wurde und ob die Erfassung vollständig war. Definieren Sie getrennte Vertrauensfristen nach Lieferant, Feldtyp und Anwendungsfall: automatischer Kauf, manueller Alarm oder reine historische Analyse. Es gibt keine universelle Dauer. Der Bestand kann sich schneller ändern als Produktmerkmale, und ein älterer Preis kann vertraglich weiterhin gültig sein. Ersetzen Sie einen Wert nach Ablauf der gewählten Frist nicht durch null: Markieren Sie ihn als „zu bestätigen" oder „veraltet", verhindern Sie mit diesem Nachweisgrad unvereinbare Aktionen und fordern Sie vor der Bestellung eine aktuelle Beobachtung an.

Drei Zeitstempel statt eines vagen „letzten Updates"

Aktualität wird oft auf das Ausführungsdatum des Skripts reduziert. Das reicht nicht aus. Eine um 10 Uhr erfolgreiche Erfassung kann eine am Vortag erzeugte Datei herunterladen, die selbst auf einem Handelssystem mit unbekanntem Aktualisierungsrhythmus basiert. Bewahren Sie so weit wie möglich drei getrennte Zeitpunkte auf:

• source_generated_at: vom Lieferanten angegebenes Erstellungsdatum der Daten oder Datei;
• observed_at: Zeitpunkt, zu dem Ihr System die Antwort erhalten hat;
• validated_at: Zeitpunkt, zu dem der Inhalt die Kontrollen bestanden hat und nutzbar gemacht wurde.

Falls der erste Zeitstempel nicht existiert, ersetzen Sie ihn nicht durch die Download-Uhrzeit. Vermerken Sie ausdrücklich source_generated_at=unbekannt. Die in RFC 9110 beschriebenen HTTP-Validatoren ETag und Last-Modified können helfen zu erkennen, ob sich eine Repräsentation geändert hat, sofern der Server sie korrekt liefert. Sie beweisen jedoch für sich genommen nicht, wann der fachliche Preis oder Bestand aktualisiert wurde.

Jede Datenfamilie getrennt behandeln

Ein Produktdatenblatt vereint Elemente, die sich unterschiedlich schnell ändern. Marke, Titel oder GTIN werden meist als Identitätsdaten genutzt; Preis, Verfügbarkeit, Lieferfrist und Rabatt sind Angebotsdaten. Ein einziges globales Datum verdeckt diese Unterschiede.

Der Status InStock verdient besondere Aufmerksamkeit. Schema.org definiert ihn als Angabe, dass der Artikel vorrätig ist, doch diese Konvention liefert weder Menge noch Zeitstempel. Das Alter der Beobachtung bleibt daher entscheidend. Die Unterscheidung zwischen booleschem Bestand und exakter Menge muss zusätzlich zur Aktualität erhalten bleiben.

Eine Vertrauensrichtlinie aufbauen, ohne einen Standard zu erfinden

Beginnen Sie mit dem Risiko der Aktion. Eine von einem Menschen konsultierte Suchseite kann einen älteren Wert mit klarem Hinweis anzeigen. Eine ohne Prüfung ausgelöste Bestellung erfordert einen aktuelleren Nachweis und stärkere vertragliche Absicherungen. Definieren Sie dann eine interne Frist für jede Kombination aus Quelle × Feld × Anwendungsfall und dokumentieren Sie, wer sie genehmigt hat.

Hier ein vollständig hypothetisches Beispiel zur Veranschaulichung der Struktur, keine empfohlenen Fristen. Ein Team könnte entscheiden, dass ein vor weniger als zwei Stunden beobachteter Bestand für einen Alarm „aktuell" ist, dass er zwischen zwei und acht Stunden „zu bestätigen" ist und danach als „veraltet" gilt. Für einen monatlichen Vertragspreis könnte eine andere Regel gelten. Diese Zahlen stammen aus keiner Norm: Sie müssen durch Schwellenwerte ersetzt werden, die sich aus Ihrem beobachteten Rhythmus, Ihrem Vertrag und Ihrer Risikotoleranz ergeben.

Das Kalibrierungsverfahren ist wichtiger als der Ausgangswert:

1. Jede erfolgreiche, unvollständige oder fehlgeschlagene Erfassung protokollieren. 2. Die Intervalle zwischen tatsächlich beobachteten Änderungen je Feld messen. 3. Abgelehnte Bestellungen, Preisabweichungen und Ausverkäufe nach der Beobachtung erfassen. 4. Für den untersuchten Anwendungsfall einen anfänglich vorsichtigen, klaren Schwellenwert wählen. 5. Datum und Status dem Nutzer anzeigen, nicht nur einen Score. 6. Den Schwellenwert anhand von Vorfällen und neuen Nachweisen überarbeiten.

Eine Richtlinie sollte einen Wert niemals allein deshalb als aktuell erklären, weil der Job gestartet wurde. Sie hängt von einer gültigen, vollständigen und der richtigen Quelle zuordenbaren Antwort ab.

Umgang mit unvollständigen Erfassungen und Funkstille

Eine kleinere Datei als üblich kann eine echte Katalogverkleinerung oder ein abgebrochener Export sein. Eine API kann 200 OK liefern und dennoch wegen eines fehlerhaften Cursors eine leere Seite zurückgeben. Aktualität muss daher eine Vollständigkeitsprüfung einschließen: erwartetes Volumen als beobachtete Spanne, Seitenanzahl, Vorhandensein kritischer Felder und Stabilität der Kennungen.

Schlägt die Prüfung fehl, behalten Sie den letzten validierten Wert mit seinem alten Zeitstempel. Verknüpfen Sie die Uhrzeit des Fehlschlags nicht mit dem beibehaltenen Wert. Erfassen Sie getrennt last_attempt_at, last_success_at und den genauen Grund. So lässt sich eine stille Quelle von einem tatsächlich ausverkauften Produkt unterscheiden.

Die Wahl des Feed-Formats CSV, XML, API oder FTP beeinflusst die Wiederaufnahmestrategie, nicht aber die Grundregel: Der Zeitstempel eines Datenpunkts wird nur vorgerückt, wenn eine relevante, validierte Beobachtung dies rechtfertigt.

Unsicherheit darstellen, ohne einen irreführenden Score zu erzeugen

Ein Gesamtscore kann bei der Sortierung helfen, sofern er erklärbar bleibt. Zeigen Sie das tatsächliche Alter, den verfügbaren Zeitstempel, die Art des Bestands und die letzten Vorfälle neben jeder Farbmarkierung an. Ein grüner Balken ohne Details verwandelt eine interne Entscheidung in ein implizites Versprechen.

Bevorzugen Sie drei Betriebszustände: nutzbar_fuer_analyse, bestaetigung_erforderlich und blockiert_fuer_aktion. Die zu diesen Zuständen führenden Regeln müssen nachvollziehbar sein. Der Zuverlässigkeits-Score eines Lieferanten kann die Aktualität einbeziehen, darf aber nie einen kritischen Fehler oder ein fehlendes Feld überdecken.

Aktualitäts-Checkliste

• ☐ Quell-, Beobachtungs- und Validierungsdatum sind getrennt.
• ☐ Preis und Bestand haben eigene Status.
• ☐ Ein fehlender Zeitstempel wird als unbekannt markiert.
• ☐ Ein ETag wird nicht als fachliches Datum dargestellt.
• ☐ Die Schwellenwerte sind intern, genehmigt und überarbeitbar.
• ☐ Die Vollständigkeit wird geprüft, bevor die Erfassung als erfolgreich gilt.
• ☐ Ein Fehler aktualisiert nicht den letzten gültigen Wert.
• ☐ Das tatsächliche Alter bleibt neben dem Score sichtbar.
• ☐ Vor der Bestellung wird eine aktuelle Bestätigung angefordert.
• ☐ Vorfälle fließen in die Überarbeitung der Richtlinie ein.

Was ArbitragePro+ automatisieren kann / was der Verkäufer prüfen muss

Die vorgeschlagene Spezifikation score-fraicheur könnte das Alter der Beobachtungen berechnen, konfigurierte Schwellenwerte anwenden, unvollständige Erfassungen melden und die Nutzung eines veralteten Werts blockieren. Sie sollte stets die Zeitstempel und die Regel offenlegen, die zum Status geführt hat.

Der Verkäufer muss die zu seinem Vertrag und Risiko passenden Fristen definieren, Preis und Verfügbarkeit vor dem Kauf bestätigen und Fälle klären, in denen die Quelle keinen fachlichen Zeitstempel liefert.

Den Zustand der Sources überwachen

Den Zustand der Sources ansehen, um verfügbare Erfassungsinformationen und Warnungen zu prüfen.

Offizielle Quellen

• IETF, RFC 9110, „HTTP Semantics", https://www.rfc-editor.org/rfc/rfc9110.html — abgerufen am 17.08.2026.
• Schema.org, „ItemAvailability", https://schema.org/ItemAvailability — abgerufen am 17.08.2026.
• Schema.org, „InStock", https://schema.org/InStock — abgerufen am 17.08.2026.