Ocupación Tulum/Bacalar — proxy confirmado + modelo de demanda descartado

Fecha: 2026-09-17

Qué se corrió

1. Verificación de la cobertura de ocupacion_hotelera en la base.
2. Modelo de demanda (scripts/ocupacion_bacalar.py, nuevo): ocupación ~ log(vistas_wikipedia) + log(reviews) + rating.

Resultado 1 — Tulum ya estaba resuelto

Tulum tiene ocupación vía proxy “RIVIERA MAYA, Q. ROO” (agregado regional del Monitoreo Hotelero, marcado n=0 en ocupacion_desde_monitoreo.py). No es medición propia, pero es la señal regional correcta y ya corre 2023-01→2026-07.

Resultado 2 — Bacalar: el modelo de demanda NO sirve

• Entrenado en 8 destinos con ocupación real (excluido Tulum-proxy).
• R² 0.413 · LOO MAE 0.152 (±15 pp de ocupación) → demasiado débil para imputar.
• El coeficiente de vistas_wikipedia sale negativo (-0.079): misma trampa que el clustering snapshot — CDMX domina por tamaño, no por ocupación. Popularidad no predice ocupación.

Decisión

• Bacalar: NO imputar ocupación. Se mide con índice de demanda propio: vistas_wiki relativo (1.00, en la mediana) + reviews (0.32, bajas) — señal ya leída en el cruce: “interés desproporcionado a su volumen”, candidato a recibir campaña. Su rol en el plan es capacidad disponible (receptor), no saturado, así que la ausencia de ocupación no bloquea el argumento.
• El hueco #2 queda cerrado como decisión, no como dato: Tulum=proxy, Bacalar=índice de demanda.

Estado del índice tras esta corrida

Con precio (10/10, Booking) + rating (10/10) + ocupación (9/10: 8 reales + Tulum proxy; Bacalar por demanda), el Burbuja_Index ya es calculable para el panel. Único dato aún pendiente: SESNSP (seguridad, hueco #3, trivial).

Scripts nuevos

• scripts/hedonico.py — precio por features (descartado, R² 0.167).
• scripts/ocupacion_bacalar.py — ocupación por demanda (descartado, LOO 0.152).