Hotel 574 · Medellín · 12 de octubre de 2026. Investigación documental y prototipo funcional estático. No se efectuaron consultas autenticadas, compras, reservas ni conexiones a Beds24.
El tracker ahora permite consultar Google por hotel y estancia y registrar manualmente el vendedor final, total COP, habitación, desayuno, cancelación, impuestos, perfil de tarifa y enlace de evidencia. La captura es local al navegador; exportación/restauración JSON disponible. No se extraen datos automáticamente y no se han incorporado tarifas reales al conjunto inicial. Las cifras introducidas por el operador se etiquetan como manuales, sin verificación independiente.
La mediana usa el segmento elegido de desayuno/cancelación y la última observación por hotel dentro de 24 horas; requiere al menos 3 directos elegibles, con identidad no provisional y atributos completos. El grupo contiene 5 directos elegibles más SUI provisional. La equivalencia de habitaciones la confirma el operador y requiere revisión; no se presume equivalencia a partir del precio.
Los enlaces de búsqueda no garantizan las fechas ni la ocupación en Google. Verificar los controles, identidad y precio final. Ayuda oficial Google Hotels. No almacenar datos PMS o credenciales en las capturas locales.
El servicio diario ahora ejecuta Chromium en el VPS a las 1:00 a. m. de Bogotá. Consulta los hoteles y fechas futuras configurados, guarda observaciones con vendedor y hora y publica un histórico independiente de los archivos de despliegue. La cobertura y el estado vigente se consultan en el dashboard. Los datos de navegador se distinguen de las capturas manuales y no alimentan la mediana hasta revisar condiciones.
Las secciones siguientes documentan la prueba inicial y sus limitaciones. No se ha contratado una API de tarifas ni conectado Beds24; las cifras actuales provienen de páginas visibles de Google Hotels. El VPS puede recibir precios distintos por ubicación y perfil, aunque se seleccione COP. No se eluden bloqueos ni CAPTCHAs.
Conservar los diez como candidatos. La existencia de una ficha o web confirma identidad comercial, no igualdad de producto, operación física inspeccionada ni cobertura en los tres canales. Las categorías directo / referencia son inferencias por ubicación y concepto, pendientes de tarifa y revisión de habitaciones. No se trasladan puntuaciones ni reseñas del chat anterior.
| Hotel | Evidencia e identidad | Decisión provisional |
|---|---|---|
| Manila Hotel Boutique | Web propia: Cra. 43D #11A–10, Manila; estándar 13 m², desayuno. | Directo; prioridad alta. Comparar tamaño y desayuno. |
| Antípoda Hotel Boutique | Web propia: Transversal 5A #45–164. | Directo; prioridad alta por proximidad a 574. Excluir suites del estándar. |
| Vita Hotel Boutique | Ficha Booking: Cra. 43D #13–26; baño privado y aire. | Directo; identidad con evidencia OTA. Confirmar desayuno por plan. |
| Vivus / La Martina | Web de marca: Calle 13 #43D–30, Manila. Vivus declara operar La Martina. | Un solo hotel, con alias. Directo; excluir estudios y promociones de larga estancia. |
| SUI Hotel Boutique | Ficha Google: Cra. 47A #5–67; alias SUI Hotel de Diseño. | Directo provisional. Falta segunda fuente y confirmar barrio; no cerrar identidad OTA todavía. |
| Poblado Luum Boutique | Booking: Cra. 43C #7D–25. Web propia: Parque El Poblado. | Directo; afinar Astorga / Parque El Poblado y equivalencias. |
| The Art Hotel Medellín | Web propia: Cra. 41 #9–31, cerca de Parque Lleras. | Directo ampliado; reportar aparte hasta validar producto y precios. |
| Epic Boutique Hotel | Web propia: Cra. 37A #8A–38; estándar y suites. | Referencia por ahora; no hay evidencia de que siempre sea más caro. |
| Celestino Boutique Hotel & Spa | Web propia: Cra. 37 #8A–60; posicionamiento lujo y spa. | Referencia; mantener fuera de mediana directa. |
| Sites Medellín | Web propia: lofts desde 40 m², kitchenette. | Referencia de producto diferente; dirección exacta pendiente. |
Hotel 574 confirma Transversal 6 #45–50. Falta ficha técnica propia de habitación, inventario y planes. No asigné IDs numéricos de las OTAs sin evidencia.
| Escenario | Entrada → salida | Fundamento |
|---|---|---|
| Entre semana | 21 → 22 octubre 2026 | Miércoles, control operativo; no se afirma ausencia de eventos. |
| Sábado | 24 → 25 octubre 2026 | Control fin de semana. |
| Demanda potencial alta | 19 → 20 enero 2027 | Inexmoda confirma Colombiatex 19–21 enero. Demanda hotelera alta es hipótesis, no dato medido. |
Protocolo: 1 habitación, 2 adultos, 0 niños, 1 noche, mercado CO, escritorio, sin cuenta, sin Genius / One Key ni descuentos de aplicación. Solicitar COP; si solo hay otra moneda, conservar original y convertir con fuente y hora explícitas. Una noche no representa toda la feria: registrar mínimo de estancia y, si procede, agregar un escenario de varias noches independiente.
Separar desayuno incluido y no incluido, flexible y no reembolsable. Documentar plazo y penalidad de cancelación, prepago, tamaño, cama, aire y baño privado. Seleccionar la menor oferta dentro de cada segmento equivalente, nunca mezclar segmentos para obtener un “mínimo” aparente. Registrar cargos obligatorios, impuestos, condiciones fiscales y cobros en el hotel. No añadir automáticamente IVA ni asumir exención. Precio con impuestos desconocidos queda fuera del índice.
99 celdas planificadas: 10 competidores + 574 × 3 canales × 3 fechas. Son solicitudes previstas, no 99 resultados ni disponibilidad confirmada. Capturar en una ventana propuesta de 30 minutos por ronda y guardar la hora de cada observación; ese límite es de diseño y debe ajustarse al contrato. Diferencias entre octubre y enero también reflejan distinta anticipación, no únicamente demanda.
| Fuente | Vía oficial | Límite / decisión |
|---|---|---|
| Booking.com | Demand API para afiliados, con Affiliate ID y token; disponibilidad por fechas y ocupación. | FAQ actual v3 indica no cachear tarifas o disponibilidad. Reglas legacy también restringen redistribución y contenido en comparadores. No aprobar histórico competitivo por defecto: pedir permiso contractual explícito. |
| Expedia | Rapid Shopping con tasas, políticas y total property_inclusive. Onboarding y revisión del socio. | Inventario B2B de Rapid no garantiza la tarifa minorista de Expedia.com, ni descuentos One Key. Validar derechos para inteligencia, retención y origen; etiquetar “Expedia Rapid” si esa es la fuente, sin sustituir silenciosamente Expedia.com. |
| Google Hotels | Hotel Prices recibe feeds de socios; Travel Partner API gestiona Hotel Center de la cuenta. | No encontré API oficial general documentada para extraer todas las ofertas minoristas de competidores. “Pull” significa que Google solicita datos al socio. Captura manual limitada o proveedor contratado, con permisos de uso y conservación comprobados. |
| Proveedor especializado | Evaluar primero Lighthouse Rate Insight: documento propio muestra filtros de ocupación, Booking, dispositivos y exportación. | Candidato para prueba, no proveedor ya autorizado. No está demostrada cobertura de Google Hotels, API, hoteles específicos ni licencia de histórico. Pedir muestra, contrato y derechos sobre cada canal antes de adquirir. |
Selección: comenzar con un piloto de proveedor profesional contratado, condicionado a evidencia de derechos y cobertura de los tres canales. Si no cumple, conservar el dashboard con entradas autorizadas y posponer automatización. No recomiendo construir scraping sin acuerdo como base del producto. Una API comercial de terceros no acredita por sí misma autorización de Booking, Expedia o Google.
La observación manual de una página pública sirve para verificar una oferta puntual, pero no concede automáticamente permiso para recopilación sistemática o histórico. Los snippets del buscador con precios de septiembre, moneda o perfiles distintos fueron descartados. No se declara agotado ningún hotel por bloqueo o ausencia de precio.
Requisitos para aceptar un proveedor: mapa de las 11 identidades; cobertura canal por canal; derechos documentados de consulta, almacenamiento, exportación y uso interno; duración de retención; impuestos y políticas completos; hora y vendedor final; frecuencia, límites y coste escritos. Probar 99 celdas en dos rondas y auditar las discrepancias contra la oferta final sin completar reservas. Umbral propuesto: ≥90% con respuesta interpretable (disponible o no disponible explícito) y 100% de las ofertas incluidas en índices con atributos completos. Identificar mínimos de estancia y no confundir inventario cerrado con hotel lleno.
Esquema SQLite descargable y plan de 99 consultas. Modelo preparado; base productiva y recolectores aún no implementados. El dashboard lee solo identidades y escenarios de data.json.
Hotel y alias → identidad de canal → escenario → ronda → resultado de consulta → ofertas con evidencia y licencia. Los fallos van en resultados, con precio nulo; cada oferta es inmutable y lleva fecha de observación. Esquema separa precio base, impuestos, cargos y total; moneda original, conversión y completitud fiscal; procedencia real / ilustrativa. El piloto contiene cero ofertas de ambos tipos.
Un control de inserción impide almacenar cotizaciones sin permiso de histórico vigente e impide marcar como comparables datos ilustrativos o fiscalmente incompletos. En producción añadir control de acceso, borrado por retención, auditoría y revisión de renovación de permisos. Los recibos brutos o capturas solo se guardan si la licencia autoriza evidencia; eliminar cookies y datos personales.
Google guarda canal observado + vendedor final. Clave canónica: hotel, vendedor, habitación, plan, fechas, huéspedes, moneda, política y condiciones. Dedupe dentro de cada ronda, conservando linaje de ambos canales. Si no se demuestra equivalencia, no fusionar. Nunca deduplicar observaciones de rondas distintas: son el histórico.
Índice: mediana por segmento y fecha de directos confirmados; una oferta por hotel, sin referencias ni duplicados. Mostrar cobertura n/N, rango de horas y frescura. Brecha = (574 / mediana − 1) × 100. No calcular cuando falte 574, haya menos de 3 directos comparables o no coincidan condiciones. No generar recomendaciones de precio con esta muestra vacía.
Arquitectura futura: adaptadores autorizados en servidor → validación de permisos → normalización y evidencia → base de histórico → dashboard. Conector Beds24 aparte → snapshots de inventario propio. Las credenciales quedan en gestor de secretos del servidor; nunca navegador ni CSV. Scheduling aún no activado.
API V2 y scopes. Solicitar únicamente lectura de properties, inventory y bookings para la propiedad de 574. La documentación muestra variantes de notación de scope: usar exactamente los permisos que presente la consola, sin permisos write, all ni delete. Excluir bookings-personal y bookings-financial.
Endpoints documentados: GET /properties, GET /inventory/rooms/calendar, GET /inventory/rooms/availability, GET /inventory/rooms/offers y GET /bookings para fechas, unidades y estado. Validar parámetros y esquema contra la referencia vigente de la cuenta. La autenticación/renovación puede requerir su flujo propio; “solo lectura” significa que ningún endpoint de negocio puede mutar reservas, tarifas o inventario.
Mapear roomId y capacidades físicas; preservar bloqueos y unidades fuera de servicio. Ocupación = unidades reservadas confirmadas / unidades vendibles, definida por noche; no usar habitaciones publicadas como denominador sin verificar. Descartar cancelaciones y deduplicar reservas; pickup exige snapshots repetidos, no se deriva de una sola consulta. Las tarifas PMS o directas no equivalen automáticamente a la tarifa final OTA.
Cadencia inicial propuesta: inventario cada 6 horas, coherente con la guía Beds24; ajustar límites y paginación vigentes. Ofertas puntuales por estancia cuando sean necesarias. Permitir GET solo a endpoints aprobados; sin llamadas de escritura. No almacenar datos identificativos de huéspedes. Falta autorización de cuenta, ID real de propiedad, mapeo de habitaciones y token de lectura, que deben configurarse mediante un canal seguro. No se ha pedido ni inventado ninguna credencial.
Funcionan selección de escenario, filtro por grupo, búsqueda de hoteles, consulta de evidencia y descarga del plan. El esquema se ejecutó en una base temporal SQLite; se comprobaron 99 filas sin precios, cero observaciones y los días de semana. La prueba no demuestra acceso a OTAs, disponibilidad, ADR competitivo, cobertura contratada ni recomendaciones válidas. Es un piloto de interfaz y diseño de datos, no un rate shopper operativo.
Próximo hito para pasar a operación: obtener la muestra y licencia del proveedor; confirmar IDs y categorías equivalentes; cargar dos rondas reales y validar cobertura; después conectar Beds24 con scopes de lectura. No se inicia contratación ni se contacta a terceros desde este piloto.