Un coche de choque de un parque polaco tenía, según mis datos, una cola de sesenta y siete minutos. Todos los días. Exactamente sesenta y siete, ni uno más ni uno menos, durante meses.
Yo había estado en ese parque tres días con mi familia, montándolo todo, y la cola más larga que vi fue de veinte minutos.
Uno de los dos mentía. Este artículo va de averiguar cuál, y de las otras tres veces que mis propios datos me engañaron antes de que publicara nada.
El punto de partida
Llevo meses construyendo un estudio de colas de veintisiete parques europeos. La materia prima son datos abiertos: el registro histórico de tiempos de espera que publican los propios parques a través de sus aplicaciones, recogido atracción por atracción durante un año.
Es una fuente estupenda. Es pública, es masiva, y es de los propios operadores.
También viene sucia, y nadie te avisa de en qué.
Lo que sigue son los cuatro defectos que encontré en mi propia base antes de publicar. Los cuento con nombre y apellidos porque creo que es la parte más útil de todo el trabajo, y porque cualquiera que vaya a montar algo sobre datos abiertos se los va a encontrar.
Defecto uno: los feeds congelados
Cuando terminé el primer ranking, un parque me salió el cuarto peor de Europa. Era justo el parque donde yo había estado y donde no había visto una sola cola larga.
Fui a mirar sus filas una a una. Aparecieron estas tres:
| Atracción | Espera media | Espera máxima media |
|---|---|---|
| Un tren infantil | 150 min | 152 min |
| Los coches de choque | 67 min | 67 min |
| Unas sillas voladoras | 44 min | 44 min |
Míralas despacio, porque lo raro no es que las cifras sean altas. Lo raro es que la media y la máxima son la misma cifra.
Una cola real respira. Está vacía al abrir, sube a media mañana, hace pico después de comer y se desinfla al cierre. Su media histórica y su máxima histórica no pueden coincidir. Si coinciden, es que el valor no cambia nunca.
Un coche de choque no tiene una cola de sesenta y siete minutos exactos trescientos días seguidos. Lo que tiene es un sensor, o un campo de una base de datos, atascado en un valor que se ha estado registrando durante meses como si fuera una medición.
Eso no es una cola. Es un número muerto.
Cómo se arregla sin hacer trampa
Aquí está la parte incómoda: la tentación es borrar esas tres filas y seguir. Y no se puede, porque si yo elijo a mano qué datos quito parque por parque, el ranking entero deja de valer nada. Habría estado ajustando la realidad hasta que me diera la razón.
Así que la corrección tenía que ser una regla ciega:
Se descarta una atracción si:
espera máxima media > 25 min
Y espera media ≥ 90% de la espera máxima media
El primer umbral protege a las atracciones pequeñas, donde una cola constante de cinco minutos sí es real: hay atracciones que efectivamente no tienen cola nunca. El segundo captura el patrón del feed atascado.
Es una regla tosca. Puede estar tirando alguna cola real muy estable y puede estar dejando pasar algún feed congelado por debajo de los veinticinco minutos. Pero es objetiva y ciega al parque, que es lo único que importa. Se aplica a los veintisiete sin mirar a quién beneficia.
Y aquí está la señal de que el problema era real
Al aplicar el filtro, la capacidad del modelo para explicar la realidad subió:
| Antes | Después | |
|---|---|---|
| Varianza explicada por la afluencia | 17,4% | 20,1% |
Cuando quitas datos y el modelo mejora, es que los datos que quitaste eran basura. Si hubieran sido buenos, quitarlos habría empeorado el ajuste.
Y al parque polaco le pasó esto:
| Antes | Después | |
|---|---|---|
| Puesto europeo | 4º peor | 24º de 27 |
De estar entre los cuatro peores del continente a estar entre los cinco mejores. Tres filas.
Lo digo claro porque es lo que más me importa de todo esto: el trabajo de campo tenía razón y el dato estaba roto. Tres filas de un feed automático, propagadas sin mirarlas, habrían publicado exactamente lo contrario de la verdad. Y habría sido una mentira con tabla, con fuente y con aspecto de rigor.
Defecto dos: las filas que no son atracciones
Segundo hallazgo, y este me dolió más porque llevaba semanas sin verlo.
Muchos parques publican en su feed una entrada separada para la cola de pasajero suelto, la que usas cuando vas solo y te encajan en el hueco libre de un vagón. Es la misma atracción, con otra puerta.
Mi código las contaba como atracciones distintas.
Dieciséis filas, en tres parques. Y el efecto es doble y va en la misma dirección:
- Infla el catálogo: un parque parece tener más atracciones de las que tiene.
- Ensucia la media: la cola de pasajero suelto es sistemáticamente más corta, así que baja la media del parque.
Cuando añadí el filtro, el ranking cambió de líder. El parque que salía peor de Europa pasó a segundo, y otro ocupó su sitio.
La lección aquí no es técnica, es de actitud: el feed no está pensado para ti. Está pensado para que un visitante abra la aplicación y sepa dónde ponerse. Que una fila represente «una atracción» es una suposición tuya, no una promesa suya.
Defecto tres: la métrica que medía otra cosa
Este es el más sutil de los cuatro y el que más me costó aceptar.
Yo calculaba, entre otras cosas, una media de espera sobre todo el catálogo registrado de cada parque. Parecía la métrica más honesta de todas: no se queda con las atracciones estrella, mira el parque entero.
El problema es que cada parque registra un número distinto de atracciones. Uno publica el dato de cuarenta y uno, otro de veintiocho.
Y no varía al azar. Los feeds incorporan primero las atracciones grandes; las pequeñas se añaden después, o nunca. Así que un parque con poca cobertura tiene su media calculada sobre una submuestra escorada hacia las colas largas.
Lo medí:
La cobertura del feed explicaba el 23% de la variación de esa métrica.
Casi una cuarta parte de lo que yo creía estar midiendo sobre los parques era, en realidad, una medida de cuántas atracciones había metido cada operador en su aplicación. Un artefacto, no una señal.
Comprobé la métrica de las cinco peores colas contra el mismo sesgo: 0,010. Prácticamente cero. Esa estaba limpia.
Podía haber tirado la métrica sucia y no contarlo. Decidí lo contrario: publicar las tres métricas en cada análisis, con el sesgo declarado, para que se vea qué mide cada una y dónde discrepan. Cuando dos métricas discrepan, esa discrepancia es el hallazgo.
Defecto cuatro: la cifra de afluencia de un parque
El cuarto no es de los datos de cola, es de los de público, y lo pongo porque es el error más fácil de cometer y el más difícil de detectar.
Un parque nórdico llevaba en mi base una afluencia que arrastré de una fuente agregada. Cuando fui a la memoria del propio operador para verificarla antes de escribir su análisis, la cifra buena era un 39% menor que la que yo tenía. La mía correspondía a un año prepandemia; la del operador, a la temporada real que yo estaba midiendo.
Un parque con la afluencia inflada un 64% sobre la real parece muchísimo más eficiente de lo que es: le estás atribuyendo colas cortas con un público que no tuvo.
Lo saqué del ajuste y el modelo volvió a mejorar.
Regla que me llevé de aquí, y que ya no me salto: una cifra leída en un resumen, en una tabla agregada o en un artículo que la cita no es una fuente. Hay que abrir el documento original del operador. Cuesta veinte minutos y es la diferencia entre un estudio y una opinión con números.
Lo que me llevo de los cuatro
Uno. Los datos abiertos no vienen etiquetados como sucios. Vienen con el mismo aspecto que los limpios, en la misma tabla, con la misma cara de dato.
Dos. Los defectos no son ruido aleatorio que se cancele con volumen. Son sesgos, y empujan en una dirección concreta. Tres filas movieron a un parque veinte puestos.
Tres. La única defensa que me ha funcionado es tener una expectativa independiente del dato. Detecté el feed congelado porque había estado allí. Sin esos tres días, aquel número habría pasado el corte y se habría publicado.
Cuatro, y es mi conclusión de verdad. El instinto cuando encuentras un defecto es arreglarlo en silencio y publicar la versión buena. Creo que es un error, y no por moral: porque el defecto suele ser más interesante que el resultado. Que la cobertura de un feed explique el 23% de una métrica dice más sobre la fragilidad de los estudios con datos abiertos que cualquier ranking que yo pueda montar.
Cada uno de estos cuatro cambió alguna conclusión. Ninguno se descubrió después de publicar.
Ride Intelligence: análisis de parques temáticos con criterio de ingeniería, aforo y economía. El estudio completo de los veintisiete parques, con el ranking y el método, está en mi Patreon.
👏 Si te ha gustado, compartirlo ayuda a que llegue a más gente.
Suscríbete para no perderte el resto de la serie, y dime en los comentarios si has encontrado basura parecida en algún dataset público con el que hayas trabajado.