Costruire un'Infrastruttura di Monitoraggio Prezzi in Tempo Reale

Il monitoraggio prezzi in tempo reale è diventato un vantaggio competitivo fondamentale per e-commerce, brand, agenzie di pricing e piattaforme di comparison shopping. Se i tuoi concorrenti aggiornano i prezzi ogni 15 minuti e tu controlli una volta al giorno, stai già perdendo margine. Ma costruire un'infrastruttura che raccolga prezzi da decine o centinaia di siti in modo continuo, affidabile e senza blocchi richiede più di un semplice script Python: serve una pipeline completa con proxy gestiti, gestione delle rotazioni, parsing robusto e alerting.

In questa guida affrontiamo ogni componente dell'infrastruttura, dalla scelta del tipo di proxy alla scrittura del codice di estrazione, fino alla gestione dei casi limite come CAPTCHA, rate limiting e variazioni di layout. Useremo ProxyHat come provider di riferimento per gli esempi pratici.

Perché il Monitoraggio Prezzi in Tempo Reale è Tecnicamente Complesso

Il monitoraggio prezzi in tempo reale richiede di colpire ripetutamente le stesse pagine prodotto su siti di terze parti, spesso decine o centinaia di volte al giorno. Questo comportamento è indistinguibile da quello di un bot malevolo agli occhi dei sistemi anti-bot moderni. I siti e-commerce investono pesantemente in soluzioni come Cloudflare, PerimeterX (ora HUMAN), Akamai Bot Manager e DataDome, che analizzano fingerprint del browser, pattern di traffico, header HTTP e reputazione degli indirizzi IP.

Quando un singolo IP invia centinaia di richieste allo stesso dominio in pochi minuti, viene quasi sempre flaggato. Le conseguenze vanno dal throttling (HTTP 429) al blocco permanente dell'IP, fino al serving di pagine honeypot con prezzi falsi o CAPTCHA challenge. Per questo motivo, un'infrastruttura di monitoraggio prezzi non può fare a meno di una pool di proxy affidabile.

Secondo la specifica RFC 9110, il codice di stato 429 Too Many Requests indica esplicitamente che il client ha superato il limite di richieste consentito. Una pipeline di pricing deve gestire questo scenario con retry logic, backoff esponenziale e rotazione IP.

I Tre Tipi di Proxy a Confronto

Non tutti i proxy sono uguali. La scelta del tipo di proxy determina il successo rate, la latenza e il costo della tua infrastruttura.

I proxy residenziali offrono il miglior compromesso tra costo e affidabilità per il monitoraggio prezzi. Gli IP appartengono a ISP reali, quindi i sistemi anti-bot li classificano come traffico legittimo. I proxy mobile hanno il success rate più alto perché gli IP sono assegnati a operatori mobili (es. Vodafone, TIM), ma costano di più e hanno latenza maggiore. I proxy datacenter sono economici ma facilmente rilevabili: vanno bene per siti semplici o per volumi altissimi dove il success rate basso è compensato dal costo irrisorio.

Architettura di un Sistema di Monitoraggio Prezzi

Un'infrastruttura di monitoraggio prezzi in tempo reale ben progettata ha diversi strati:

1. Job Scheduler — definisce quali prodotti monitorare, con quale frequenza e su quali siti. Può essere un cron job, Airflow, o un sistema event-driven.
2. Proxy Manager — gestisce la pool di IP, la rotazione, le sessioni sticky e il geo-targeting. È il cuore della resistenza ai blocchi.
3. Fetch Layer — esegue le richieste HTTP, gestisce retry, backoff, timeout e parsing della risposta.
4. Parser/Extractor — estrae il prezzo, la disponibilità, il titolo e altri campi dalla pagina HTML o JSON.
5. Storage — salva i dati in un database time-series o relazionale per analisi storica.
6. Alerting — notifica cambiamenti di prezzo significativi via email, Slack o webhook.

La frequenza di polling dipende dalla volatilità del mercato. Per prodotti e-commerce standard, un refresh ogni 15-30 minuti può essere sufficiente. Per mercati ad alta volatilità come ticketing o sneaker drop, serve polling ogni 10-60 secondi.

Strategie di Rotazione IP

Esistono due approcci principali alla rotazione:

• Rotazione per-request: ogni richiesta esce da un IP diverso. Ideale per scraping ad alto volume dove ogni richiesta è indipendente.
• Sessioni sticky: lo stesso IP viene mantenuto per un periodo (es. 10 minuti) o per un numero di richieste. Necessario quando il sito richiede login o multi-step checkout per visualizzare il prezzo.

Con ProxyHat, puoi controllare questo comportamento tramite il parametro session nel username. Senza session, ogni richiesta usa un IP nuovo. Con session-abc123, l'IP viene mantenuto per la durata della sessione.

Implementazione Pratica con ProxyHat

Vediamo come costruire un modulo di monitoraggio prezzi usando Python e i proxy residenziali di ProxyHat. Assumeremo un target di 1000 richieste al minuto con un success rate target del 90%+.

Connessione Base

Il gateway ProxyHat utilizza un singolo endpoint con autenticazione nel username:

# HTTP proxy
http://USERNAME:PASSWORD@gate.proxyhat.com:8080

# SOCKS5 proxy
socks5://USERNAME:PASSWORD@gate.proxyhat.com:1080

# Con geo-targeting (Italia)
http://user-country-IT:PASSWORD@gate.proxyhat.com:8080

# Con sessione sticky
http://user-session-myprice123:PASSWORD@gate.proxyhat.com:8080

Esempio in Python con requests

import requests
from requests.adapters import HTTPAdapter
from urllib3.util.retry import Retry
import random
import time

PROXY_URL = "http://user-country-IT:PASSWORD@gate.proxyhat.com:8080"

session = requests.Session()

# Retry strategy con backoff
retry_strategy = Retry(
    total=3,
    backoff_factor=2,
    status_forcelist=[429, 500, 502, 503, 504],
    allowed_methods=["GET", "HEAD"]
)
adapter = HTTPAdapter(max_retries=retry_strategy)
session.mount("http://", adapter)
session.mount("https://", adapter)

proxies = {
    "http": PROXY_URL,
    "https": PROXY_URL,
}

headers = {
    "User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36",
    "Accept": "text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8",
    "Accept-Language": "it-IT,it;q=0.9,en;q=0.8",
}

def fetch_price(url):
    try:
        response = session.get(
            url,
            proxies=proxies,
            headers=headers,
            timeout=15
        )
        if response.status_code == 200:
            return parse_price(response.text)
        elif response.status_code == 429:
            time.sleep(random.uniform(5, 15))
            return fetch_price(url)
        else:
            print(f"HTTP {response.status_code} per {url}")
            return None
    except Exception as e:
        print(f"Errore: {e}")
        return None

def parse_price(html):
    # Implementa il parser specifico per il sito target
    # Es. BeautifulSoup, regex, o selettori CSS
    pass

Nota il timeout=15 secondi: è importante non lasciare richieste pendenti indefinite, perché consumano connessioni e rallidano tutta la pipeline. Un timeout di 10-15 secondi è un buon compromesso.

Rotazione con Sessioni Sticky

Per siti che richiedono sessioni persistenti (es. carrello per vedere il prezzo finale), usa sessioni sticky con un ID univoco per prodotto:

def get_proxy_for_product(product_id):
    session_id = f"prod-{product_id}-{int(time.time() / 600)}"
    return {
        "http": f"http://user-session-{session_id}:PASSWORD@gate.proxyhat.com:8080",
        "https": f"http://user-session-{session_id}:PASSWORD@gate.proxyhat.com:8080",
    }

In questo esempio, la sessione cambia ogni 600 secondi (10 minuti), garantendo che ogni blocco di 10 minuti di richieste per lo stesso prodotto esca dallo stesso IP.

Concorrenza con asyncio

Per raggiungere throughput elevato (es. 1000 richieste/minuto), l'approccio sincrono non basta. Ecco un esempio con asyncio e aiohttp:

import asyncio
import aiohttp
import random

PROXY_TEMPLATE = "http://user-country-IT:PASSWORD@gate.proxyhat.com:8080"

async def fetch_one(session, url, sem):
    async with sem:
        proxy = PROXY_TEMPLATE
        try:
            async with session.get(
                url,
                proxy=proxy,
                timeout=aiohttp.ClientTimeout(total=15),
                ssl=False
            ) as resp:
                if resp.status == 200:
                    html = await resp.text()
                    return parse_price(html)
                elif resp.status == 429:
                    await asyncio.sleep(random.uniform(5, 15))
                    return await fetch_one(session, url, sem)
        except Exception as e:
            print(f"Errore: {e}")
            return None

async def main(urls):
    sem = asyncio.Semaphore(50)  # 50 richieste concorrenti
    connector = aiohttp.TCPConnector(limit=100, force_close=True)
    async with aiohttp.ClientSession(connector=connector) as session:
        tasks = [fetch_one(session, url, sem) for url in urls]
        results = await asyncio.gather(*tasks)
        return results

# Esecuzione
urls = ["https://example.com/product/1", "https://example.com/product/2"]
results = asyncio.run(main(urls))

Il Semaphore(50) limita a 50 richieste concorrenti: questo valore deve essere calibrato in base alla capacità del tuo provider proxy e alla tolleranza del sito target. Iniziare con 20-50 connessioni concorrenti e aumentare gradualmente è la strategia più sicura.

Esempio in curl

# Richiesta singola con proxy italiano
curl -x http://user-country-IT:PASSWORD@gate.proxyhat.com:8080 \
  -H "User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64)" \
  -H "Accept-Language: it-IT,it;q=0.9" \
  "https://example.com/product/123"

# Con sessione sticky
curl -x http://user-session-pricemon01:PASSWORD@gate.proxyhat.com:8080 \
  "https://example.com/product/123"

Errori Comuni e Casi Limite

1. Non gestire il rate limiting (HTTP 429)

Molti scraper principianti non implementano retry logic e scartano le risposte 429. Questo porta a buchi nei dati. Implementa sempre backoff esponenziale con jitter casuale per evitare il thundering herd problem.

2. Usare lo stesso User-Agent per tutte le richieste

I sistemi anti-bot profilano il User-Agent. Se 1000 richieste arrivano con lo stesso User-Agent da IP diversi, è comunque sospetto. Mantieni un pool di 10-20 User-Agent realistici e ruotali.

3. Ignorare la geolocalizzazione

Molti siti e-commerce mostrano prezzi diversi per paese. Se monitori prezzi su un sito tedesco da un IP statunitense, potresti vedere prezzi diversi o essere reindirizzato. Usa il geo-targeting di ProxyHat per far corrispondere l'IP al paese del sito: user-country-DE per siti tedeschi, user-country-IT per italiani.

4. Non rispettare robots.txt

Secondo le linee guida descritte su Wikipedia sul web scraping, rispettare il file robots.txt è una buona pratica etica e legale. Anche se non è legalmente vincolante in tutte le giurisdizioni, ignorarlo può essere usato come evidenza di condotta scorretta in controversie legali.

5. Parsing fragile

I siti e-commerce cambiano layout frequentemente. Selettori CSS come .price-value possono rompersi da un giorno all'altro. Implementa parser multi-strategia: prima prova selettori CSS, poi fallback su regex, poi su pattern di prezzo generici (es. \d+[.,]\d{2}\s*€).

6. Non monitorare il success rate

Senza metriche, non sai se la tua infrastruttura sta degradando. Implementa logging di: success rate per dominio, latenza media, distribuzione dei codici di stato, numero di CAPTCHA incontrati. Se il success rate scende sotto l'80%, è ora di investigare.

Best Practice per un'Infrastruttura Robusta

Throttling per dominio

Non tutti i domini tollerano la stessa frequenza. Implementa rate limiting per dominio nella tua pipeline: un sito piccolo potrebbe reggere 5 richieste/minuto, mentre un marketplace grande può accettarne 100+.

Header HTTP realistici

Usa header completi e coerenti:

headers = {
    "User-Agent": random.choice(USER_AGENTS),
    "Accept": "text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8",
    "Accept-Language": "it-IT,it;q=0.9,en-US;q=0.8,en;q=0.7",
    "Accept-Encoding": "gzip, deflate, br",
    "Connection": "keep-alive",
    "Upgrade-Insecure-Requests": "1",
    "Sec-Fetch-Dest": "document",
    "Sec-Fetch-Mode": "navigate",
    "Sec-Fetch-Site": "none",
    "Sec-Fetch-User": "?1",
}

Cache intelligente

Se monitori 500 prodotti su 10 siti, non tutte le combinazioni cambiano prezzo ogni minuto. Implementa una cache con TTL variabile: prodotti con storico di variazioni frequenti vengono controllati più spesso, prodotti stabili meno.

Alerting su anomalie

Non basta raccogliere i prezzi: devi reagire. Configura alert per:

• Variazioni di prezzo superiori al 10% in meno di 1 ora
• Success rate che scende sotto l'85%
• Prodotti improvvisamente non disponibili (out of stock)
• Prezzi che diventano 0 o null (probabile errore di parsing)

Configurazione ProxyHat per il Monitoraggio Prezzi

Per configurare ProxyHat per la tua infrastruttura di pricing, segui questi passi:

1. Accedi al dashboard su dashboard.proxyhat.com e crea le tue credenziali.
2. Scegli il tipo di proxy: residenziale per la maggior parte dei casi, mobile per siti molto protetti.
3. Configura il geo-targeting in base ai paesi dei siti che monitori. Controlla le locazioni disponibili per assicurarti che il paese target sia supportato.
4. Imposta il formato del proxy: http://USERNAME:PASSWORD@gate.proxyhat.com:8080 per HTTP, socks5://USERNAME:PASSWORD@gate.proxyhat.com:1080 per SOCKS5.
5. Testa la connessione con curl prima di integrare nel codice.
6. Consulta la documentazione ufficiale ProxyHat per dettagli su parametri avanzati.

Per il pricing e i piani disponibili, visita la pagina prezzi di ProxyHat. Per use case specifici legati allo scraping, consulta la pagina web scraping e per il tracciamento SERP la pagina SERP tracking.

Calcolo dei Costi e ROI

Per stimare il costo della tua infrastruttura, considera questi fattori:

• Numero di prodotti monitorati: 1000 prodotti su 10 siti = 10.000 richieste per ciclo completo.
• Frequenza di polling: ogni 30 minuti = 48 cicli al giorno = 480.000 richieste/giorno.
• Success rate: con proxy residenziali al 90%, su 480.000 richieste ne falliscono 48.000, che richiedono retry.
• Traffic volume: 480.000 richieste/giorno × ~500KB per pagina = ~240 GB/mese di traffico proxy.

Il ROI del monitoraggio prezzi dipende dal margine per prodotto e dalla velocità di reazione. Se un prezzo concorrente scende del 5% su un prodotto con margine di 50€ e vendi 100 unità/giorno, un'ora di ritardo nella reazione costa 250€. Un'infrastruttura proxy che costa 200€/mese si ripaga in meno di un giorno.

Key Takeaways

I proxy residenziali offrono il miglior compromesso costo/affidabilità per il monitoraggio prezzi in tempo reale, con success rate tra 85% e 95%.

Implementa sempre retry logic con backoff esponenziale e gestione del codice HTTP 429 per evitare buchi nei dati.

Usa il geo-targeting per far corrispondere l'IP del proxy al paese del sito target: prezzi e disponibilità possono variare per geografia.

Monitora il success rate per dominio: se scende sotto l'80%, investi in rotazione IP più aggressiva o cambia tipo di proxy.

Configura alerting su variazioni anomale: un'infrastruttura di pricing senza notifiche in tempo reale perde gran parte del suo valore.

Conclusione

Costruire un'infrastruttura di monitoraggio prezzi in tempo reale è un progetto multidimensionale che richiede attenzione ai proxy, al parsing, alla concorrenza e all'alerting. La scelta del provider proxy è probabilmente la decisione più impattante: un provider con IP di bassa qualità vanifica qualsiasi ottimizzazione a livello di codice.

ProxyHat offre proxy residenziali, mobile e datacenter con geo-targeting granulare e rotazione configurabile tramite parametri nel username. Inizia con un piano di test, misura il success rate sui tuoi siti target e scala gradualmente. La documentazione completa è disponibile su docs.proxyhat.com.