Aggiornamento di prezzi e stock: definire un tempo di fiducia

Un prezzo o uno stock è affidabile solo se sapete quando è stato prodotto, quando è stato raccolto e se la raccolta era completa. Definite tempi di fiducia separati per fornitore, tipo di campo e uso: acquisto automatico, alert manuale o semplice analisi storica. Non esiste una durata universale. Lo stock può cambiare più in fretta delle caratteristiche del prodotto, e un prezzo datato può restare valido contrattualmente. Oltre il tempo scelto, non sostituite il valore con zero: contrassegnatelo "da confermare" o "scaduto", impedite le azioni incompatibili con questo livello di prova e richiedete un'osservazione recente prima dell'ordine.

Tre timestamp invece di un vago "ultimo aggiornamento"

La freschezza è spesso ridotta alla data di esecuzione dello script. Non è sufficiente. Una raccolta riuscita alle 10 può scaricare un file prodotto il giorno prima, esso stesso basato su un sistema commerciale aggiornato a una cadenza sconosciuta. Conservate, per quanto possibile, tre tempi distinti:

• source_generated_at: data dichiarata dal fornitore per il dato o il file;
• observed_at: momento in cui il vostro sistema ha ricevuto la risposta;
• validated_at: momento in cui il contenuto ha superato i controlli ed è diventato utilizzabile.

Se il primo timestamp non esiste, non sostituitelo con l'ora di download. Annotate esplicitamente source_generated_at=sconosciuto. I validatori HTTP ETag e Last-Modified, descritti dall'RFC 9110, possono aiutare a sapere se una rappresentazione è cambiata quando il server li fornisce correttamente. Non dimostrano tuttavia da soli quando il prezzo o lo stock di business sono stati aggiornati.

Trattare separatamente ogni famiglia di dati

Una scheda prodotto riunisce elementi la cui velocità di cambiamento non è la stessa. Il brand, il titolo o il GTIN sono generalmente usati come dati di identità; il prezzo, la disponibilità, il tempo di consegna e lo sconto sono dati d'offerta. Un'unica data globale nasconde queste differenze.

Lo stato InStock merita un'attenzione particolare. Schema.org lo definisce come un'indicazione che l'articolo è in stock, ma questa convenzione non fornisce né quantità né timestamp. L'età dell'osservazione resta quindi essenziale. La distinzione tra stock booleano e quantità esatta va mantenuta oltre alla freschezza.

Costruire una politica di fiducia senza inventare uno standard

Iniziate dal rischio dell'azione. Una pagina di ricerca consultata da un umano può mostrare un dato datato con un avviso chiaro. Un ordine avviato senza verifica richiede una prova più recente e garanzie contrattuali più forti. Definite poi un tempo interno per ogni combinazione fonte × campo × uso, quindi documentate chi lo ha approvato.

Ecco un esempio interamente ipotetico destinato a mostrare la struttura, non durate raccomandate. Un team potrebbe decidere che uno stock osservato da meno di due ore è "recente" per un alert, che tra due e otto ore è "da confermare", e che oltre è "scaduto". Per un prezzo contrattuale mensile, potrebbe applicare una regola diversa. Questi numeri non provengono da alcuna norma: vanno sostituiti con soglie derivate dalla vostra cadenza osservata, dal vostro contratto e dalla vostra tolleranza al rischio.

La procedura di calibrazione è più importante della cifra iniziale:

1. Registrare ogni raccolta riuscita, incompleta o fallita. 2. Misurare gli intervalli tra i cambiamenti realmente osservati, campo per campo. 3. Rilevare ordini rifiutati, scarti di prezzo e rotture dopo l'osservazione. 4. Scegliere una soglia iniziale prudente ed esplicita per l'uso studiato. 5. Mostrare la data e lo stato all'utente, non solo un punteggio. 6. Rivedere la soglia in base agli incidenti e alle nuove prove.

Una politica non deve mai dichiarare un valore fresco solo perché il job è partito. Dipende da una risposta valida, completa e attribuibile alla fonte giusta.

Gestire le raccolte parziali e i silenzi

Un file più piccolo del solito può essere una vera riduzione del catalogo o un'esportazione interrotta. Un'API può rispondere 200 OK pur restituendo una pagina vuota a causa di un cursore mal gestito. La freschezza deve quindi integrare un controllo di completezza: volume atteso sotto forma di intervallo osservato, numero di pagine, presenza dei campi critici e stabilità degli identificativi.

Se il controllo fallisce, mantenete l'ultimo valore validato con il suo vecchio timestamp. Non associate l'ora del fallimento al dato conservato. Registrate separatamente last_attempt_at, last_success_at e il motivo esatto. È ciò che permette di distinguere una fonte silenziosa da un prodotto realmente in rottura di stock.

La scelta del formato di feed CSV, XML, API o FTP influenza la strategia di ripresa, ma non la regola fondamentale: si avanza il timestamp di un dato solo quando un'osservazione pertinente e validata lo giustifica.

Presentare l'incertezza senza un punteggio fuorviante

Un punteggio globale può aiutare a ordinare, a condizione di restare spiegabile. Mostrate l'età reale, il timestamp disponibile, il tipo di stock e gli ultimi incidenti accanto a qualsiasi colore. Un indicatore verde senza dettagli trasforma una scelta interna in una promessa implicita.

Preferite tre stati operativi: utilizzabile_per_analisi, conferma_richiesta e bloccato_per_azione. Le regole che portano a questi stati devono essere leggibili. Il punteggio di affidabilità di un fornitore può integrare la freschezza, ma non deve mai cancellare un errore critico o un campo assente.

Checklist di freschezza

• ☐ Le date di sorgente, osservazione e validazione sono separate.
• ☐ Prezzo e stock hanno i propri stati.
• ☐ L'assenza di un timestamp è contrassegnata come sconosciuta.
• ☐ Un ETag non è presentato come data di business.
• ☐ Le soglie sono interne, approvate e rivedibili.
• ☐ La completezza è controllata prima di dichiarare la raccolta riuscita.
• ☐ Un errore non aggiorna l'ultimo valore valido.
• ☐ L'età reale resta visibile accanto al punteggio.
• ☐ Una conferma recente è richiesta prima dell'ordine.
• ☐ Gli incidenti alimentano la revisione della politica.

Cosa può automatizzare ArbitragePro+ / cosa deve verificare il venditore

La specifica proposta score-fraicheur potrebbe calcolare l'età delle osservazioni, applicare soglie configurate, segnalare le raccolte parziali e bloccare l'uso di un valore scaduto. Dovrebbe sempre esporre i timestamp e la regola che ha prodotto lo stato.

Il venditore deve definire i tempi adatti al proprio contratto e al proprio rischio, confermare prezzo e disponibilità prima dell'acquisto, poi arbitrare i casi in cui la fonte non offre un timestamp di business.

Monitorare lo stato delle fonti

Consultare la salute delle fonti per esaminare le informazioni di raccolta e gli alert attualmente disponibili.

Fonti ufficiali

• IETF, RFC 9110, «HTTP Semantics», https://www.rfc-editor.org/rfc/rfc9110.html — consultato il 2026-08-17.
• Schema.org, «ItemAvailability», https://schema.org/ItemAvailability — consultato il 2026-08-17.
• Schema.org, «InStock», https://schema.org/InStock — consultato il 2026-08-17.