Come funziona il monitoraggio

Page Deltas esegue i tuoi monitor con una pianificazione adattiva, recupera ogni pagina con il metodo più leggero che funziona e usa un filtro LLM così ricevi solo gli avvisi che contano.

Il ciclo di vita di un controllo

1. Pianificazione. Uno scheduler centrale seleziona i monitor il cui next_check_at è scaduto e accoda i job su una coda Postgres.
2. Recupero. Un worker prende in carico il job e recupera la pagina (HTTP semplice, poi un browser headless tramite un proxy datacenter, poi tramite un proxy residenziale — vedi sotto).
3. Estrazione. L'HTML viene ridotto al suo contenuto testuale principale. Il boilerplate (nav, footer, annunci) viene rimosso.
4. Hash e diff. Un hash normalizzato viene confrontato con l'ultimo controllo. Se identico, l'esecuzione termina qui — nessuna chiamata LLM.
5. Filtro LLM. Se l'hash è cambiato, il diff e la tua descrizione vengono inviati a un LLM che decide se il cambiamento è significativo.
6. Avviso. I cambiamenti significativi vengono scritti in monitor_changes e accodati per l'invio a ogni canale collegato al monitor.

Pianificazione adattiva

Non imposti una frequenza di controllo. Lo scheduler osserva la frequenza con cui una pagina cambia effettivamente e sposta il next_check_at di conseguenza — più veloce quando arrivano cambiamenti, più lento quando la pagina è inattiva. Anche il tuo piano influenza la cadenza: i piani superiori ottengono una priorità di pianificazione maggiore. Questo mantiene il tuo utilizzo proporzionale al valore che ottieni.

Escalation del fetcher

Ogni controllo inizia nel modo più economico e scala solo se necessario:

1. HTTP semplice. Niente JavaScript, niente browser. Veloce ed economico. Funziona per la maggior parte delle pagine renderizzate dal server e per gli endpoint JSON.
2. Browser headless tramite proxy datacenter. Usato quando la pagina è renderizzata lato client o quando il recupero semplice è bloccato. Renderizziamo con Camoufox — un Firefox patchato per l'invisibilità che aggira la maggior parte dei fingerprinting — instradato attraverso un proxy datacenter Oxylabs.
3. Browser headless tramite proxy residenziale. Usato quando il recupero tramite proxy datacenter è ancora bloccato. Instrada la stessa richiesta del browser attraverso IP residenziali Oxylabs.

I byte instradati tramite il proxy residenziale vengono tracciati per organizzazione come misura di controllo dei costi.

Il filtro LLM

Quando l'hash del testo della pagina cambia, non inviamo immediatamente un avviso. Per prima cosa inviamo il diff e la descrizione del monitor a un LLM con una domanda: data questa descrizione, questo cambiamento è significativo?

Cosa rileva

• Variazioni di prezzo su una pagina dei prezzi di un concorrente.
• Lanci di nuovi prodotti su una roadmap o un changelog.
• Cambiamenti negli annunci di lavoro su una pagina carriere che stai monitorando.

Cosa ignora

Spazi vuoti e boilerplate (nav, footer, annunci) vengono rimossi prima dell'hashing, quindi non raggiungono mai l'LLM. Inoltre, il classificatore è istruito a trattare quanto segue come non significativo:

• Testimonianze a rotazione, annunci, timestamp in stile “aggiunto 3 giorni fa” e conteggio delle visualizzazioni.
• Riordinamento senza cambiamenti semantici.
• Hash di build e identificatori di sessione.