Monitoreo de precios entre regiones para viajes y SaaS

Una habitación de hotel en París listada en €200 en Booking.com desde una IP francesa cuesta €260 cuando el mismo navegador accede a la misma URL desde una IP estadounidense. Eso no es un artefacto de conversión de moneda, sino una fijación de precios dinámica deliberada basada en la geolocalización. Para SaaS, el mismo asiento en Slack o Jira puede variar un 40% entre Estados Unidos e India. Monitorear estas diferencias de precios a escala requiere una infraestructura de proxies que sobreviva a los mismos sistemas antifraude que las aerolíneas y los proveedores de nube despliegan contra los scrapers.

Por qué el mismo SKU cuesta diferentes cantidades a través de las fronteras

Tres mecanismos impulsan la fijación de precios por geo-arbitraje. Primero, la conversión de moneda con márgenes ocultos: el motor de reservas del hotel aplica un diferencial cambiario del 3-5% que varía según el país. Segundo, los regímenes fiscales locales: IVA en la UE, GST en India, impuesto a las ventas en EE. UU. Tercero, y de manera más agresiva, la fijación de precios dinámica basada en la demanda. Un vuelo de Londres a Nueva York en British Airways muestra un precio más alto cuando la solicitud se origina desde una IP del Reino Unido que desde una IP alemana, porque el algoritmo asume que los viajeros del Reino Unido tienen mayor disposición a pagar. Proveedores de SaaS como Atlassian y Salesforce mantienen listas de precios separadas por región, a menudo con descuentos del 30-50% para mercados emergentes. La única forma de capturar estos precios de manera programática es hacer que la solicitud parezca provenir de cada mercado objetivo.

Arquitectura de proxies para la captura de precios en múltiples regiones

Un único grupo de proxies residenciales no es suficiente. Necesitas un grupo de nodos de salida que coincidan con el país, la ciudad y, a veces, incluso el operador (por ejemplo, un ISP móvil francés frente a un DSL residencial francés). El enfoque estándar utiliza un intermediario de proxies que mantiene una lista rotativa de proxies autenticados. A continuación se muestra un comando mínimo curl que obtiene un precio de hotel desde un proxy francés, estableciendo el encabezado Accept-Language en fr-FR y enviando un User-Agent realista de una compilación reciente de 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":"[^"]+"'

Este único comando fallará entre el 60 y el 80% de las veces si el proxy es conocido por un servicio de detección de bots como DataDome o Akamai. La tasa de fallos solo disminuye cuando combinas la rotación de proxies con la persistencia de sesión y la huella digital de encabezados que coincida con el ISP real del proxy.

Detección de bots antifraude: el verdadero cuello de botella

Las plataformas de viajes y SaaS invierten fuertemente en la detección de bots. Verifican no solo la reputación de la IP, sino también la huella digital del handshake TLS (JA3), la configuración de HTTP/2, la fluctuación de temporización y el orden de los encabezados HTTP. Un proxy que pasa una verificación puede fallar en otra. Por ejemplo, un proxy de centro de datos con una IP limpia pero una firma JA3 que coincida con una herramienta de scraping conocida será bloqueado de inmediato. Los proxies residenciales no son inmunes: muchos provienen de dispositivos infectados y aparecen en listas negras. La estrategia más efectiva es usar un grupo de proxies dedicado que hayas probado contra la pila de detección del sitio objetivo. Espera una tasa de éxito del 10-20% por proxy incluso en condiciones ideales. Eso significa que necesitas al menos 5-10 proxies por región objetivo para mantener una tasa de scraping estable de una solicitud cada 5-10 segundos.

Aquí es donde duele el equilibrio: una mayor calidad de proxy (residencial, IPs estáticas, alta reputación) cuesta 10 veces más que los proxies de centro de datos, pero la tasa de éxito puede solo duplicarse. Para una operación de monitoreo de precios que golpea 100 SKUs por hora en 10 regiones, la factura mensual de proxies puede superar los $2,000. La alternativa — usar proxies públicos gratuitos — no es viable porque sus IPs ya están marcadas por todos los servicios importantes antibots. Una sola solicitud desde un proxy gratuito activará un CAPTCHA o una respuesta 403.

Flujo de trabajo práctico: limitación de tasa, enfriamiento de IP y manejo de errores

Tu scraper debe implementar una máquina de estados por IP de proxy. Después de una solicitud exitosa, el proxy entra en un período de enfriamiento — 30 segundos para sitios de hoteles, 60 segundos para paneles de administración de SaaS. Después de un fallo (HTTP 403, 429 o página CAPTCHA), el enfriamiento se extiende a 5 minutos y el proxy se marca para reevaluación. Usa un limitador de tasa de token bucket que imponga un límite global de, digamos, 2 solicitudes por segundo en todos los proxies. El siguiente fragmento de Python (usando asyncio y aiohttp) muestra el bucle principal:

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

Agrega retroceso exponencial para fallos consecutivos del mismo proxy — después de tres errores, retira esa IP por 24 horas. Monitorea la proporción de respuestas exitosas frente al total de intentos; si cae por debajo del 20% para una región, rota todo el grupo de proxies de ese país. Finalmente, registra cada encabezado de respuesta, especialmente Set-Cookie y X-Frame-Options, porque revelan si el sitio está ejecutando un script de detección de bots que requiere ejecución de JavaScript. Para sitios que dependen de renderizado del lado del cliente, debes cambiar a un navegador sin cabeza como Playwright o Puppeteer, lo que agrega otro orden de magnitud a la latencia y al costo de proxies. El monitoreo de precios entre regiones no es un proyecto de fin de semana — es una inversión continua de ingeniería que exige ajustes constantes contra un objetivo en movimiento.