Monitoraggio dei prezzi tra regioni per viaggi e SaaS

Una camera d'albergo a Parigi elencata a €200 su Booking.com da un IP francese costa €260 quando lo stesso browser accede allo stesso URL da un IP statunitense. Non si tratta di un artefatto di conversione valutaria — è una tariffazione dinamica deliberata basata sulla geolocalizzazione. Per il SaaS, lo stesso posto in Slack o Jira può variare del 40% tra Stati Uniti e India. Monitorare queste differenze di prezzo su larga scala richiede un'infrastruttura di proxy che sopravviva agli stessi sistemi antifrode che le compagnie aeree e i fornitori cloud implementano contro gli scraper.

Perché lo stesso SKU costa importi diversi oltre i confini

Tre meccanismi guidano la tariffazione da geo-arbitraggio. Primo, la conversione valutaria con markup nascosti — il motore di prenotazione dell'hotel applica uno spread FX del 3-5% che varia per paese. Secondo, i regimi fiscali locali: IVA nell'UE, GST in India, imposta sulle vendite negli Stati Uniti. Terzo, e più aggressivamente, la tariffazione dinamica basata sulla domanda. Un volo da Londra a New York su British Airways mostra un prezzo più alto quando la richiesta proviene da un IP del Regno Unito rispetto a un IP tedesco, perché l'algoritmo presume che i viaggiatori britannici abbiano una maggiore disponibilità a pagare. I fornitori SaaS come Atlassian e Salesforce mantengono listini prezzi separati per regione, spesso con sconti del 30-50% per i mercati emergenti. L'unico modo per catturare questi prezzi in modo programmatico è far sembrare che la richiesta provenga da ciascun mercato di destinazione.

Architettura proxy per la cattura dei prezzi multi-regione

Un singolo pool di proxy residenziali non è sufficiente. È necessario un pool di nodi di uscita che corrispondano al paese, alla città e talvolta anche al carrier (ad esempio, un ISP mobile francese rispetto a una DSL residenziale francese). L'approccio standard utilizza un broker di proxy che mantiene una lista rotante di proxy autenticati. Di seguito è riportato un comando curl minimale che recupera il prezzo di un hotel da un proxy francese, impostando l'header Accept-Language su fr-FR e inviando un User-Agent realistico da una build recente di Chrome:

curl -s -x "http://user:pass@fr-proxy.example.com:3128" \
  -H "Accept-Language: fr-FR,fr;q=0.9" \
  -H "User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/125.0.0.0 Safari/537.36" \
  "https://www.booking.com/hotel/fr/paris-ritz.html" | grep -oP '"price":"[^"]+"'

Questo singolo comando fallirà nel 60-80% dei casi se il proxy è noto a un servizio di rilevamento bot come DataDome o Akamai. Il tasso di fallimento diminuisce solo quando si combina la rotazione dei proxy con la persistenza della sessione e il fingerprinting degli header che corrisponde al vero ISP del proxy.

Rilevamento bot antifrode: il vero collo di bottiglia

Le piattaforme di viaggio e SaaS investono pesantemente nel rilevamento bot. Controllano non solo la reputazione dell'IP, ma anche l'impronta digitale dell'handshake TLS (JA3), le impostazioni HTTP/2, il jitter temporale e l'ordine degli header HTTP. Un proxy che supera un controllo potrebbe fallirne un altro. Ad esempio, un proxy datacenter con un IP pulito ma una firma JA3 che corrisponde a un noto strumento di scraping verrà bloccato immediatamente. I proxy residenziali non sono immuni — molti provengono da dispositivi infetti e compaiono nelle blacklist. La strategia più efficace è utilizzare un pool di proxy dedicato che hai testato contro lo stack di rilevamento del sito target. Aspettati un tasso di successo del 10-20% per proxy anche in condizioni ideali. Ciò significa che hai bisogno di almeno 5-10 proxy per regione target per mantenere un tasso di scraping stabile di una richiesta ogni 5-10 secondi.

Qui è dove il compromesso si fa sentire: una qualità proxy più alta (residenziale, IP statici, alta reputazione) costa 10 volte di più rispetto ai proxy datacenter, ma il tasso di successo potrebbe solo raddoppiare. Per un'operazione di monitoraggio prezzi che colpisce 100 SKU all'ora in 10 regioni, la bolletta mensile dei proxy può superare i $2.000. L'alternativa — utilizzare proxy pubblici gratuiti — è impraticabile perché i loro IP sono già segnalati da ogni importante servizio anti-bot. Una singola richiesta da un proxy gratuito attiverà un CAPTCHA o una risposta 403.

Flusso di lavoro pratico: limitazione della frequenza, raffreddamento degli IP e gestione degli errori

Il tuo scraper deve implementare una macchina a stati per IP proxy. Dopo una richiesta riuscita, il proxy entra in un periodo di raffreddamento — 30 secondi per i siti di hotel, 60 secondi per i pannelli di amministrazione SaaS. Dopo un fallimento (HTTP 403, 429 o pagina CAPTCHA), il raffreddamento si estende a 5 minuti e il proxy viene contrassegnato per una rivalutazione. Utilizza un limitatore di frequenza a token bucket che imponga un limite globale di, ad esempio, 2 richieste al secondo su tutti i proxy. Il seguente snippet Python (usando asyncio e aiohttp) mostra il ciclo principale:

import asyncio, aiohttp, random

PROXY_POOL = [{"url": "http://user:pass@fr1:3128", "cooldown_until": 0}]

async def fetch_price(session, proxy, url):
    now = asyncio.get_event_loop().time()
    if now < proxy["cooldown_until"]:
        await asyncio.sleep(proxy["cooldown_until"] - now)
    try:
        async with session.get(url, proxy=proxy["url"],
                               headers={"Accept-Language": "fr-FR"}) as resp:
            if resp.status == 200:
                proxy["cooldown_until"] = now + 30
                return await resp.text()
            else:
                proxy["cooldown_until"] = now + 300
                return None
    except Exception:
        proxy["cooldown_until"] = now + 300
        return None

Aggiungi un backoff esponenziale per fallimenti consecutivi dallo stesso proxy — dopo tre errori, ritira quell'IP per 24 ore. Monitora il rapporto tra risposte riuscite e tentativi totali; se scende al di sotto del 20% per una regione, ruota l'intero pool di proxy per quel paese. Infine, registra ogni header di risposta, specialmente Set-Cookie e X-Frame-Options, perché rivelano se il sito sta eseguendo uno script di rilevamento bot che richiede l'esecuzione di JavaScript. Per i siti che si basano sul rendering lato client, devi passare a un browser headless come Playwright o Puppeteer, il che aggiunge un altro ordine di grandezza alla latenza e al costo dei proxy. Il monitoraggio dei prezzi tra regioni non è un progetto da weekend — è un investimento ingegneristico continuo che richiede un costante adattamento contro un bersaglio in movimento.