Hoe monitoring werkt

Page Deltas voert uw monitors uit volgens een adaptief schema, haalt elke pagina op met de lichtste methode die werkt en gebruikt een LLM-filter zodat u alleen meldingen krijgt die ertoe doen.

De levenscyclus van een controle

1. Planning. Een centrale planner kiest monitors waarvan de next_check_at verschuldigd is en plaatst taken in een Postgres-wachtrij.
2. Ophalen. Een worker neemt de taak over en haalt de pagina op (gewone HTTP, daarna een headless browser via een datacenterproxy, daarna via een residentiële proxy — zie hieronder).
3. Extraheren. De HTML wordt teruggebracht tot de belangrijkste tekstinhoud. Standaardelementen (navigatie, voettekst, advertenties) worden verwijderd.
4. Hashen en vergelijken. Een genormaliseerde hash wordt vergeleken met de laatste controle. Als deze identiek is, eindigt de run hier — geen LLM-aanroep.
5. LLM-filter. Als de hash is gewijzigd, worden de wijzigingsvergelijking en uw beschrijving naar een LLM gestuurd die bepaalt of de wijziging betekenisvol is.
6. Melding. Betekenisvolle wijzigingen worden weggeschreven naar monitor_changes en in de wachtrij geplaatst voor verzending naar elk kanaal dat aan de monitor is gekoppeld.

Adaptieve planning

U stelt geen controlefrequentie in. De planner observeert hoe vaak een pagina daadwerkelijk wijzigt en past next_check_at dienovereenkomstig aan — sneller wanneer er wijzigingen binnenkomen, trager wanneer de pagina rust. Uw abonnement beïnvloedt ook het ritme: hogere abonnementen krijgen een hogere planningsprioriteit. Zo blijft uw verbruik in verhouding tot de waarde die u krijgt.

Escalatie van de fetcher

Elke controle begint goedkoop en escaleert alleen wanneer het moet:

1. Gewone HTTP. Geen JavaScript, geen browser. Snel en goedkoop. Werkt voor de meeste server-gerenderde pagina's en JSON-endpoints.
2. Headless browser via datacenterproxy. Wordt gebruikt wanneer de pagina client-gerenderd is of wanneer het gewone ophalen geblokkeerd wordt. We renderen met Camoufox — een stealth-gepatchte Firefox die de meeste fingerprinting omzeilt — gerouteerd via een Oxylabs-datacenterproxy.
3. Headless browser via residentiële proxy. Wordt gebruikt wanneer het ophalen via de datacenterproxy nog steeds geblokkeerd wordt. Routeert hetzelfde browserverzoek via residentiële IP's van Oxylabs.

Bytes die via de residentiële proxy worden gerouteerd, worden per organisatie bijgehouden als kostenbeheersingsmaatregel.

Het LLM-filter

Wanneer de hash van de paginatekst wijzigt, sturen we niet meteen een melding. Eerst sturen we de wijzigingsvergelijking en uw monitorbeschrijving naar een LLM met één vraag: is deze wijziging betekenisvol, gezien deze beschrijving?

Wat dit opvangt

• Prijswijzigingen op een prijzenpagina van een concurrent.
• Nieuwe productlanceringen op een roadmap of changelog.
• Wijzigingen in vacatures op een carrièrepagina die u volgt.

Wat dit negeert

Witruimte en standaardelementen (navigatie, voettekst, advertenties) worden vóór het hashen verwijderd, zodat ze nooit bij de LLM terechtkomen. Daarnaast krijgt de classifier de instructie om het volgende als niet betekenisvol te behandelen:

• Roterende getuigenissen, advertenties, tijdstempels in de trant van “3 dagen geleden toegevoegd” en weergavetellingen.
• Herordening zonder semantische wijziging.
• Build-hashes en sessie-identificatoren.