Precios de vuelos: fijar cuatro entradas

Recolectar precios de vuelos solo produce una serie utilizable cuando el entorno detrás de cada petición se mantiene constante. Una tarifa se cotiza para una moneda, una configuración regional, un punto de venta y un dispositivo, y cambiar cualquiera de ellos puede cambiar la cifra sin que nada cambie en el mercado. BotBrowser documenta entradas de configuración regional, zona horaria e idiomas respaldadas por perfil, junto con salida alineada geográficamente, de modo que una captura puede declarar el entorno que representa. No suministra tarifas, no reserva, no controla la lógica de precios de una aerolínea y no garantiza que un precio cotizado se repita. Donde exista un feed de tarifas con licencia o una API de agencia, esa es la vía a usar.

Resumen

• Una tarifa se cotiza para una moneda, una configuración regional, un punto de venta y un dispositivo concretos. Fije los cuatro, o la diferencia que mida será en parte una diferencia de entorno.
• La moneda es un ajuste de la petición o de la cuenta, no un valor del perfil del navegador. La configuración regional y los idiomas sí vienen del perfil. El punto de venta es un parámetro del sitio que debe concordar con la región de salida y con la cuenta.
• Registre las cuatro entradas junto a cada tarifa cotizada, no una vez por ejecución.
• Clasifique una diferencia por las entradas que cambiaron. Un cambio de moneda no es un movimiento de tarifa, por grande que sea la cifra.
• Prefiera un feed de tarifas con licencia o una API de agencia cuando existan. Una ejecución de navegador no crea permiso para monitorizar y no puede reservar.

Contenido

• Cuatro entradas que mueven una tarifa
• Cuáles de las cuatro mantiene realmente un perfil
• Registrar las cuatro entradas por captura
• Leer una diferencia por la entrada que cambió
• Cuándo un feed de tarifas con licencia es la respuesta
• Conclusión práctica

Cuatro entradas que mueven una tarifa

Una búsqueda de vuelo lleva más que un origen, un destino y una fecha. Lleva una moneda, una preferencia de idioma, un mercado para el que se cotiza el itinerario y una clase de dispositivo que puede seleccionar otro conjunto de ofertas. Esas cuatro no son intercambiables, y una serie de monitorización que las varía mide su propia configuración tanto como mide tarifas.

Entrada	Dónde se fija	Qué puede cambiar
Moneda	Parámetro de la petición o ajuste de la cuenta	El importe cotizado y su redondeo
Configuración regional	Configuración regional e idiomas del perfil	Idioma de la página, formato, a veces la oferta
Punto de venta	Parámetro del sitio, región de salida y cuenta	El mercado cuyas reglas e inventario aplican
Dispositivo	Viewport y valores de dispositivo del perfil	Diseño y, a veces, una oferta solo para móvil

El tipo Offer de schema.org da aquí una forma útil al vocabulario. Define price y recomienda acompañarlo de priceCurrency con un código ISO 4217 en lugar de un símbolo ambiguo, y advierte contra el uso de separadores dentro del valor numérico. Esa guía trata de publicar una oferta y encaja directamente en el problema de la captura: una tarifa registrada como $412 no es un hecho, mientras que 412 USD es una observación comparable.

La segunda y la tercera entrada son las que se confunden. Una configuración regional es lo que el navegador declara. Un punto de venta es el mercado para el que el sitio pone precio, y a menudo se deriva de la combinación de un parámetro del sitio, la región aparente de la petición y el ajuste de la cuenta. Hacer que el navegador declare alemán no convierte por sí solo la tarifa en una tarifa alemana, y salir desde una dirección alemana no fija por sí solo la moneda.

La moneda merece su propio párrafo porque es la entrada que más a menudo queda implícita. Un sitio puede aceptar un parámetro de moneda explícito, derivarla del punto de venta o leerla de una preferencia de cuenta, y las tres vías pueden discrepar. Cuando lo hacen, la página suele mostrar una moneda y el pago otra, o la misma moneda con otro tipo de conversión aplicado. Registre la moneda que mostró la página, no la que pidió la petición, y registre el punto de venta junto a ella, porque ese par es lo que hace reproducible el importe.

El redondeo es una fuente de ruido más pequeña pero persistente. Una tarifa convertida de una moneda a otra se redondea con una precisión específica de la moneda, y algunas redondean a unidades enteras mientras otras conservan dos decimales. Dos capturas de la misma tarifa en la misma moneda deberían coincidir exactamente; si difieren en una fracción de unidad, la diferencia suele venir de una conversión y no de un cambio de tarifa, y el registro debe decirlo en lugar de tratar la fracción como movimiento.

Impuestos y tasas pertenecen a la misma familia de problemas. Un importe mostrado puede incluirlos, excluirlos o incluir un subconjunto que depende del punto de venta, y un cambio en el conjunto incluido se ve exactamente igual que un cambio de precio. Registre qué incluye el importe mostrado cuando la página lo indique, y mantenga ese campo junto al importe. Una serie que pasa de una visualización con impuestos a una sin ellos mostrará un salto que nada tiene que ver con la tarifa.

Cuáles de las cuatro mantiene realmente un perfil

La documentación de BotBrowser sobre zona horaria, configuración regional e idiomas describe la derivación automática a partir de la IP de salida del proxy cuando hay un proxy configurado, y las anulaciones manuales de zona horaria, configuración regional e idiomas, con las anulaciones manuales sujetas a una licencia ENT Tier1. La documentación de GeoIP describe la traducción de la dirección de salida en valores geográficos y enuncia con claridad el límite de precisión: la asignación por país suele ser sólida mientras la de ciudad puede resolverse a una ciudad o región cercana.

Eso cubre la mitad de configuración regional de la tabla y parte del punto de venta. No cubre la moneda, y tampoco cubre del todo el punto de venta, porque un sitio puede aceptar un parámetro de moneda independientemente del idioma que sirve, un comportamiento del sitio y no una entrada documentada del navegador. Un diseño de monitorización que suponga que el perfil lo mantiene todo mantendrá dos de las cuatro entradas y creerá mantener cuatro.

Entrada	La mantiene el perfil	Necesita comprobación explícita
Moneda	No	El parámetro de la petición o el ajuste de cuenta
Configuración regional	Sí, si se configura	La lista declarada que la página reporta realmente
Punto de venta	En parte	La indicación del propio sitio sobre el mercado
Dispositivo	Sí, si se configura	El viewport y los valores que la página reporta

La consecuencia práctica es que la comprobación debe ser por captura, no por configuración. Una ejecución configurada correctamente al inicio se desviará en cuanto alguien edite un parámetro de la petición, añada una anulación o cambie un proxy para una región. Registrar las cuatro entradas en el momento de la cotización es la única forma de saber cuáles se aplicaron.

La clase de dispositivo es la entrada que mejor se esconde. Un viewport de escritorio y uno móvil pueden devolver conjuntos de ofertas distintos, y algunas aerolíneas exponen una tarifa solo para móvil que sencillamente no existe en la ruta de escritorio. Eso no es un cambio de precio entre dos observaciones de la misma oferta, es otra oferta. Registre el viewport junto a la clase de dispositivo para que un lector posterior pueda ver si las dos capturas usaron el mismo, y trate un cambio del conjunto de ofertas como efecto del dispositivo y no como movimiento de tarifa.

También hay una dimensión temporal dentro del propio entorno. Una captura tomada durante una ventana de oferta y otra tomada una hora después pueden diferir porque la oferta terminó, que es un cambio del lado de la fuente que las cuatro entradas reportan correctamente como sin cambios. Es el resultado correcto: el registro hace su trabajo al descartar la captura como explicación. El error a evitar es el inverso, culpar a la fuente de una diferencia que explica un cambio de moneda.

Un último hábito vale la pena por su bajo costo. Capture las cuatro entradas antes de que cargue la página de tarifas, no después, y guarde los valores previos en el registro. Una página puede cambiar una configuración regional o una moneda durante su propia inicialización en el cliente, así que un valor leído después de la cotización puede describir el estado final en lugar del estado que llevaba la petición. Registrar ambos, cuando difieren, convierte una diferencia confusa en una transición documentada.

Registrar las cuatro entradas por captura

Un registro de captura para monitorizar tarifas es pequeño. Necesita el itinerario, el importe cotizado con su moneda, las cuatro entradas y la hora de observación. Todo lo demás es detalle de apoyo.

Campo	Contenido	Por qué está en el registro
itinerary_key	Ruta, fechas y clase solicitadas	Define qué se compara
amount	Valor numérico con punto decimal	Comparable solo con una moneda
currency	Código ISO 4217	Evita que un símbolo se lea como importe
accept_language	Lista de idiomas declarada en la captura	Muestra qué configuración regional aplicó
point_of_sale	Mercado que el sitio indicó	Separa el mercado del idioma
device_class	Escritorio o móvil, con viewport	Separa el diseño de la tarifa
observed_at	Hora de captura en UTC	Ordena observaciones y expone cambios de horario
alignment	aligned o la entrada que difirió	Mantiene fuera de la serie una fila incomparable

Dos entradas de esa tabla son fáciles de registrar mal. amount debería ser un número con punto decimal y no una cadena formateada, porque una cadena lleva la convención de separadores de la configuración regional y se vuelve ambigua en cuanto la serie abarca dos configuraciones. point_of_sale debería ser lo que el sitio indicó, no lo que el operador pretendía: una intención que el sitio no honró es exactamente el caso que vale la pena detectar.

El constructor de registros siguiente compara dos capturas del mismo itinerario e informa qué entradas se mantuvieron. El caso es construido.

// Constructed fixture: two captures of one itinerary, one input changed.
const captureA = {
  itineraryKey: 'YYZ-LHR 2026-12-10 Y',
  amount: 812.4,
  currency: 'CAD',
  acceptLanguage: 'en-CA,en',
  pointOfSale: 'CA',
  deviceClass: 'desktop',
  observedAt: '2026-11-10T09:00:00Z',
};
const captureB = {
  itineraryKey: 'YYZ-LHR 2026-12-10 Y',
  amount: 512.1,
  currency: 'EUR',
  acceptLanguage: 'en-CA,en',
  pointOfSale: 'CA',
  deviceClass: 'desktop',
  observedAt: '2026-11-10T09:00:30Z',
};

const FIELDS = ['currency', 'acceptLanguage', 'pointOfSale', 'deviceClass'];
const changed = FIELDS.filter(f => captureA[f] !== captureB[f]);
const alignment = changed.length === 0 ? 'aligned' : `input_changed:${changed.join(',')}`;

const lines = [
  `itinerary=${captureA.itineraryKey}`,
  `a=${captureA.amount} ${captureA.currency} b=${captureB.amount} ${captureB.currency}`,
  `currency=${captureA.currency}->${captureB.currency} locale=${captureA.acceptLanguage}`,
  `pos=${captureA.pointOfSale} device=${captureA.deviceClass}`,
  `changed=${changed.join(',') || 'none'} alignment=${alignment}`,
  `observed_at=${captureA.observedAt}->${captureB.observedAt}`,
];
console.log(lines.join('\n'));

La salida construida siguiente es el objetivo del ejercicio. El importe cayó cerca del 37 por ciento y la clasificación dice que esa caída no es en absoluto un movimiento de tarifa.

itinerary=YYZ-LHR 2026-12-10 Y
a=812.4 CAD b=512.1 EUR
currency=CAD->EUR locale=en-CA,en
pos=CA device=desktop
changed=currency alignment=input_changed:currency
observed_at=2026-11-10T09:00:00Z->2026-11-10T09:00:30Z

Leer una diferencia por la entrada que cambió

El tamaño de una diferencia no dice nada sobre su causa. La pregunta útil es qué entradas se mantuvieron, porque eso determina qué puede sostener el par de capturas.

Entradas mantenidas	Observación	Qué sostiene la diferencia
Las cuatro idénticas	El importe difiere	Un cambio de precio comparable en ese entorno
Cambia la moneda, el resto igual	El importe difiere	Una conversión o un reprecio, no un movimiento
Cambia el punto de venta	El importe difiere	Dos mercados observados; ninguno es la base del otro
Cambia la clase de dispositivo	El importe o la oferta cambian	Una oferta dependiente del dispositivo, no una tarifa

La primera fila es la única que sostiene una serie de tarifas. La segunda es el error más común en la práctica, porque un cambio de moneda altera la cifra por un factor grande y el gráfico resultante parece un movimiento dramático. La tercera fila es una comparación de mercados que debe construirse como dos series y no como una. La cuarta es donde una oferta solo para móvil puede hacerse pasar por un cambio de precio.

Dos advertencias más pertenecen a la lectura y no al registro. Primero, una cotización no es un precio reservable: impuestos, tasas y disponibilidad pueden cambiar entre la cotización y la página de pago. Segundo, una captura repetida en un entorno sin cambios puede diferir igualmente porque cambió el inventario o las reglas tarifarias de la aerolínea, lo cual es una observación real y debe etiquetarse como cambio del lado de la fuente y no como error de captura.

La arquitectura de monitorización de precios cubre la programación y la detección de cambios de una serie general. Lo que añade el viaje es que las cuatro entradas son más independientes entre sí de lo que son en el comercio minorista, donde una sola página de producto suele implicar una moneda y una configuración regional. Un registro de consistencia entre perfil y ruta es el complemento adecuado para la mitad de salida del punto de venta. Un calendario de disponibilidad necesita una clave por fecha en lugar de una clave por producto, y el modelo de disponibilidad expone cómo mantener ese calendario comparable entre capturas.

Cuándo un feed de tarifas con licencia es la respuesta

La mayoría de las aerolíneas y grandes agencias ofrecen una vía con licencia: un feed de distribución de tarifas, una API de agencia o una exportación de datos acordada. Esas vías dan los mismos itinerarios con un esquema definido, una cadencia de actualización declarada y una licencia que dice para qué pueden usarse los datos. Cuando existe una, una ejecución de navegador suele ser el instrumento equivocado, porque produce una serie menos estable con más exposición legal para una fuente que ya ofrecía un camino soportado.

Donde no existe tal vía, la pregunta honesta es qué autoriza la observación. Una sesión de navegador que funciona no es esa respuesta. Deciden los términos aplicables de la aerolínea o la agencia, y con frecuencia restringen el acceso automatizado, la reventa de datos de tarifas y la visualización de precios en caché. Registre la base de la ejecución junto a las capturas para que un lector posterior herede la respuesta y no la suposición.

El tipo FlightReservation de schema.org recuerda la misma frontera desde el otro lado. Define un vocabulario para una reserva, con bookingTime, campos de pasajero y reservationFor apuntando al vuelo. Describe cómo puede representarse una reserva; no dice nada sobre si una tarifa puede monitorizarse ni sobre cuál será el precio cotizado al pagar.

El vocabulario sigue siendo útil para nombrar las cosas que una captura mantiene separadas. Una reserva no es una oferta, y una oferta no es una regla tarifaria. Cuando un registro mezcla las tres, una comparación posterior no puede decir si la aerolínea cambió un precio, el itinerario o las condiciones asociadas. Mantenga la clave del itinerario describiendo lo solicitado, el importe y la moneda describiendo lo cotizado, y las cuatro entradas de entorno describiendo cómo se obtuvo la cotización.

Preguntas frecuentes

¿Un cambio de moneda es un cambio de precio?

No. Cambia la unidad del importe y normalmente el redondeo. Una serie que cambia de moneda a mitad de camino mide el cambio, así que mantenga una moneda por serie o convierta con una tasa declarada y registre la conversión.

¿Puede un perfil de navegador mantener el punto de venta?

Solo en parte. El perfil controla configuración regional, idiomas y, a través del proxy, la región aparente. El punto de venta de un sitio suele ser un parámetro o un ajuste de cuenta aparte, así que verifique lo que el sitio indicó y no lo que el operador pretendía.

¿El mismo itinerario devuelve siempre el mismo precio?

No. El inventario y las reglas tarifarias cambian, y la cotización no es el total del pago. Una captura repetida en un entorno sin cambios puede diferir igualmente, y esa diferencia pertenece a la fuente.

¿BotBrowser suministra tarifas o reserva vuelos?

No. Proporciona entradas de navegador documentadas para que una captura declare su entorno. No suministra datos de tarifas, no reserva y no garantiza un precio cotizado.

Fuentes

• schema.org FlightReservation
• schema.org Offer
• MDN Accept-Language
• Zona horaria, configuración regional e idiomas en BotBrowser
• Base de datos GeoIP de BotBrowser

Conclusión práctica

Decida qué moneda, configuración regional, punto de venta y dispositivo representa la serie antes de la primera captura. Verifique las cuatro por captura, porque un perfil mantiene dos por completo y una solo en parte, y regístrelas junto al importe cotizado y la hora de observación. Clasifique cada diferencia por la entrada que cambió y trate un cambio de moneda como cambio de entorno y no como movimiento de tarifa. Donde exista un feed de tarifas con licencia o una API de agencia, úselo y mantenga la ejecución de navegador fuera del diseño.