Viajes es el vertical de precios más difícil de recolectar con precisión, y no está ni cerca. Un precio en una página de producto de retail es más o menos un hecho: es el mismo para todos en un mercado dado, y cambia lentamente. Una tarifa de vuelo no es nada de eso. El mismo asiento en el mismo vuelo puede cotizarse a precios distintos según desde dónde estés comprando, en qué moneda estás, si has buscado antes, y qué decidió el sistema de revenue de la aerolínea en los últimos minutos. Las tarifas de hotel se comportan de forma similar.
Para un equipo de agregación de tarifas o de inteligencia de viajes, este es todo el problema en una frase: la tarifa que ve un comprador depende de quién y dónde cree el proveedor que está. Recolecta esos datos desde la IP de una única oficina y no solo obtienes una imagen parcial, obtienes las tarifas equivocadas, cotizadas para un mercado en el que no estás. Este es un tratamiento más profundo del terreno cubierto en por qué la agregación de tarifas de viaje necesita proxies, centrado en la mecánica que hace de los proxies residenciales la capa de acceso correcta para datos de vuelos y hoteles.
Qué estás recolectando
La recolección de datos de viajes abarca unas cuantas superficies relacionadas:
- Tarifas de vuelo — precio por ruta, fecha, cabina, y clase de tarifa, además de disponibilidad, reglas de tarifa, y ancillaries (maletas, asientos), a través de aerolíneas y de las OTAs y metabuscadores que las revenden.
- Tarifas de hotel — precio por noche por propiedad, fecha, tipo de habitación, y ocupación, más disponibilidad y condiciones de cancelación.
- Alquiler de coches y paquetes — la misma forma, con precio por ubicación y fecha.
El hilo común es que cada una de estas se cotiza a un comprador específico en un mercado específico en un momento específico, que es exactamente por lo que es un problema de acceso.
Por qué viajes es de forma única un problema de proxy
El scraping de retail tiene una dimensión geo. Viajes tiene cuatro propiedades que se componen, y las cuatro aterrizan en la capa de proxy.
1. Las tarifas se fijan por punto de venta. Este es el rasgo definitorio. Las aerolíneas y las OTAs fijan el precio del mismo itinerario de forma distinta según el punto de venta, el mercado desde el que el comprador está reservando. Un ida y vuelta Nueva York-Londres puede llevar una tarifa distinta, en una moneda distinta, reservado desde un punto de venta de EE. UU. frente a uno del Reino Unido o de India. Esto no es un caso extremo; es el núcleo del negocio, y es la razón por la que existe siquiera la comparación de tarifas entre mercados. Para capturar la tarifa que un comprador en un mercado dado ve de verdad, tienes que parecer estar en ese mercado, lo que significa una IP residencial allí (targeting de país y ciudad).
2. Las tarifas son basadas en sesión. Una búsqueda de tarifa no es una petición, es un flujo: buscar, resultados, seleccionar itinerario, confirmar precio. Los proveedores cotizan y retienen precios dentro de esa sesión, y un cambio de identidad a mitad de flujo no se parece en nada a un comprador real. Por eso las sesiones sticky no son opcionales para viajes de la forma en que son meramente convenientes en otros lugares (sticky vs rotating): todo el flujo de tarifa tiene que venir de una identidad consistente.
3. Las tarifas son perecederas. Los sistemas de revenue-management refijan precios constantemente y la disponibilidad es en tiempo real, así que una tarifa que recolectaste hace una hora puede ya estar equivocada. La frescura es un requisito de primera clase, lo que significa recolección continua y de alto volumen en lugar de un barrido periódico.
4. Viajes está agresivamente defendido. Las aerolíneas vigilan su ratio “look-to-book”, el número de búsquedas por reserva real, y tratan el tráfico de búsqueda de alto volumen que no convierte como un coste y una amenaza. Los sistemas GDS, las OTAs, y los metabuscadores todos corren anti-bot serio. Una IP de datacenter se marca rápido y recibe un CAPTCHA, un bloqueo, o, lo peor de todo, una tarifa distinta, así que registras un precio que a ningún viajero real se le cotizaría (por qué se bloquean los scrapers).
En conjunto: para recolectar datos de viajes con precisión necesitas parecer un comprador real, en el mercado correcto, manteniendo una sesión consistente, a escala, continuamente. Ese es un problema con forma de proxy residencial.
Dónde encajan los proxies residenciales
Un proxy residencial enruta tus peticiones por IPs de consumidor reales, así que los proveedores de viajes te cotizan como lo harían a un comprador local genuino. En concreto:
La verdadera tarifa por punto de venta. Con geo-targeting hasta el país que necesitas, recolectas la tarifa como un comprador que de verdad reserva desde ese punto de venta, tarifas de EE. UU. desde EE. UU., tarifas alemanas desde Alemania, cada una etiquetada por mercado. Tu comparación entre mercados por fin descansa sobre precios reales por punto de venta en lugar de una ubicación extrapolada.
Tarifas reales, no la versión de bot. Las IPs residenciales llevan confianza de usuario real, así que capturas el precio cotizado y la disponibilidad reales, no la respuesta degradada, bloqueada, o con CAPTCHA servida al tráfico sospechoso. Para viajes, donde la “tarifa de bot” puede ser un número genuinamente distinto, esta es la diferencia entre datos usables y ruido.
Recolección consistente por sesión. Mantén una sesión sticky durante la longitud de un flujo de tarifa para que buscar, seleccionar, y precio vengan todos de una identidad, que es tanto lo que el proveedor espera como lo que mantiene coherente la cotización. Rota a una identidad fresca entre búsquedas, no dentro de una.
Cobertura completa y fresca. Un gran pool rotativo te deja correr muchas rutas, fechas, y mercados continuamente sin que un puñado de IPs dispare rate limits, que es lo que mantiene actuales los datos de tarifas perecederos en lugar de rancios (los mismos principios de calidad de recolección que en proxies residenciales para recolección de datos).
Cómo funciona
En el gateway de Shifter, apuntas a un punto de venta codificando el país en el nombre de usuario del proxy, un endpoint, sin listas de IPs:
# Recolectar una tarifa como un comprador que reserva desde EE. UU.curl -x customer-USERNAME-country-us:PASSWORD@p.shifter.io:443 https://fare-source.example
# La misma ruta, con precio desde un punto de venta del Reino Unidocurl -x customer-USERNAME-country-gb:PASSWORD@p.shifter.io:443 https://fare-source.exampleDos prácticas específicas de viajes importan más que la mecánica. Primero, alinea el locale y la moneda con el punto de venta, una petición de punto de venta del Reino Unido que envía un locale de EE. UU. o pide USD es una inconsistencia que produce resultados equivocados o bloqueados; haz coincidir Accept-Language y la selección de moneda del sitio con el mercado. Segundo, mantén una sesión sticky a lo largo del flujo de tarifa añadiendo -sid-<id>-ttl-<segundos> al nombre de usuario, para que la búsqueda de varios pasos se quede en una IP. Los bloqueos consistentes (en lugar de ocasionales) apuntan a la calidad de IP o al comportamiento de las peticiones, cubierto en cómo evitar que te bloqueen, y la calidad del pool moldea lo que se te cotiza (reputación de IP).
Considera primero las fuentes sancionadas, y recolecta de forma responsable
Dos cosas merecen énfasis en viajes específicamente.
Usa canales oficiales donde encajen. Muchas aerolíneas, cadenas hoteleras, y OTAs ofrecen APIs, feeds de afiliados, o acceso a GDS. Donde un feed sancionado cubra tu necesidad, es la mejor primera parada, estable, estructurado, y permitido. Los proxies son para datos públicos de tarifas fuera de esos canales o para amplitud a través de mercados y proveedores que un solo feed no te dará. Empezar por la API donde encaja es simplemente mejor práctica.
Ten en cuenta el look-to-book. Los proveedores de viajes son inusualmente sensibles al volumen de búsqueda que no convierte porque cada búsqueda tiene un coste real para ellos. Recolecta a un ritmo razonable, no martilles a un proveedor, honra los términos y rate limits, y recolecta datos públicos de tarifas en lugar de cualquier cosa detrás de autenticación. Esto es tanto buen civismo como autoconservación: la recolección agresiva es exactamente lo que hace que una fuente escale sus defensas. Aléjate por completo de los datos personales, y obtén asesoramiento legal para cualquier cosa incierta (¿es legal el web scraping?). Un proxy cambia desde qué IP viene una petición, no si deberías estar haciéndola; nuestra política de uso aceptable es la fuente de la verdad para lo que está permitido en Shifter.
Preguntas frecuentes
¿Por qué necesito proxies para datos de vuelos y hoteles? Porque las tarifas se fijan por punto de venta, el mismo itinerario cuesta cantidades distintas según el mercado desde el que reservas, y los proveedores se defienden con fuerza contra el acceso automatizado. Desde una ubicación ves las tarifas de un mercado, a menudo la versión de bot. Los proxies residenciales te dejan recolectar la tarifa real que a un comprador en cada mercado de verdad se le cotiza.
¿Qué es la fijación de precios por punto de venta? Las aerolíneas y las OTAs fijan el precio del mismo vuelo de forma distinta según el mercado desde el que el comprador reserva, el punto de venta. Es por lo que el mismo asiento puede costar cantidades distintas (y en monedas distintas) desde EE. UU. frente al Reino Unido, y por lo que los datos de tarifas precisos tienen que recolectarse por mercado.
¿Necesito sesiones sticky para datos de viajes? Normalmente sí. Una búsqueda de tarifa es un flujo de varios pasos (buscar, seleccionar, precio) y los proveedores cotizan dentro de una sesión, así que el flujo debería venir de una IP consistente. Usa una sesión sticky para el flujo y rota entre búsquedas, no dentro de una.
¿Debería usar una API de aerolínea u OTA en su lugar? Donde una API sancionada, feed de afiliados, o acceso a GDS cubra tu necesidad, sí, es estable y permitida. Los proxies son para datos públicos de tarifas fuera de esos canales o para amplitud entre mercados que un solo feed no proporcionará. Empieza por la API donde encaje.
¿Proxies residenciales o de datacenter para tarifas de viaje? Residenciales. Los proveedores de viajes detectan y bloquean las IPs de datacenter agresivamente y pueden servirles una tarifa distinta, así que datacenter te da un resultado equivocado o bloqueado. Las IPs residenciales ven la tarifa real y precisa por punto de venta que vería un comprador genuino.
En resumen
Los datos de tarifas de viaje son de forma única difíciles porque se fijan por punto de venta, son basados en sesión, perecederos, y están fuertemente defendidos, todo a la vez. La precisión de un producto de agregación de tarifas depende por completo de recolectar las tarifas de cada mercado como un comprador real que reserva desde ese mercado, manteniendo una sesión coherente, a una frescura que los datos exigen. Usa feeds sancionados donde encajen, y enruta el resto por IPs residenciales que coincidan con el punto de venta, con locale y moneda alineados y una sesión sticky a lo largo de cada flujo de tarifa.
Haz eso y obtienes las tarifas que a los viajeros de verdad se les cotizan, por mercado, en lugar de un número mezclado que no describe ninguna reserva real. Una red de proxies residenciales de calidad es lo que hace esa recolección precisa por punto de venta y completa, y la página de precios tiene los planes por GB para probarla contra las rutas, propiedades, y mercados de los que depende tu producto.