Día 1 (tarde) — Primer contacto con los datos

### Siete iconos de CSV y una tentación de cinco minutos

En tus dos encargos anteriores aprendiste una lección por las malas: el fichero nunca es lo que parece. En la tienda, el importe venía como texto con el euro pegado; en el juego, el canal estaba escrito de cinco maneras. Aquí va a pasar lo mismo, y ya lo sabes. Abres la carpeta compartida de NidoHogar y ahí están: siete ficheros CSV con nombres de tabla —anuncios, agencias, visitas, contactos, contratos, productos_visibilidad, zonas—. La tentación, con el Slack de Gonzalo pidiéndote los números del destacado «para el comité del viernes 🙏», es abrir la hoja de visitas, dividir entre anuncios y contestarle en cinco minutos que sí, que el destacado tiene el doble. Resístela. Ya sabes por el encuadre de esta mañana que las visitas son el principio del embudo, no el final, y que un número sin saber sobre qué base está calculado no vale. Antes de calcular nada hay que saber qué hay en cada caja: cuántas filas, qué columnas, de qué tipo, y cuánta suciedad esconden.

La herramienta para esto es Pandas, la librería de Python para trabajar con tablas. Cargas un CSV y te devuelve un DataFrame: una tabla en memoria sobre la que preguntas su forma, sus tipos y sus huecos con una línea. Es como abrir el fichero en una hoja de cálculo y mirarlo por encima, pero programado, repetible y sin que se cuelgue con decenas de miles de filas. Y hablando de hojas de cálculo: conviene pararse un segundo en por qué las usamos o no, porque es una decisión que vas a tomar toda tu carrera.

### La regla de las dos velocidades

Hay una tensión que vas a sentir toda la semana y toda tu carrera: la velocidad que te pide el stakeholder y la velocidad que pide hacerlo bien. Gonzalo quiere el número «cuanto antes»; los datos quieren que primero los entiendas. Resolver esa tensión no es elegir un bando, es tener dos velocidades. Una velocidad rápida para responder lo que se puede responder ya y con seguridad —«sí, te confirmo que el destacado dobla las visitas, eso está claro»—, y una velocidad lenta para lo que necesita cuidado —«dame hasta el jueves para ver si eso llega a contrato»—. El error de junior es aplicar la velocidad rápida a todo por complacer, y soltar un número importante a medio cocinar. El error contrario, menos común, es aplicar la lenta a todo y no contestar nunca nada. Saber qué merece cada velocidad es criterio de oficio.

La exploración de hoy es deliberadamente de velocidad lenta, y por eso duele con Gonzalo esperando. Pero es una lentitud que ahorra tiempo, no que lo gasta: cada problema que detectas hoy explorando es un error que no cometes mañana calculando sobre datos que creías limpios. La media hora de mirar sin concluir es la inversión que hace que el resto de la semana no se construya sobre arena. Piensa en un cirujano que dedica tiempo a preparar y comprobar antes de operar: no es que sea lento, es que lo que viene después no admite errores. Tu preparación es esta: conocer el terreno antes de pisarlo. El que se salta la exploración por ir rápido acaba yendo más lento, porque descubre los problemas cuando ya ha construido encima.

### ¿Y por qué no una hoja de cálculo?

Es una pregunta honesta, y la respuesta no es «porque el código es más profesional». Una hoja de cálculo es una herramienta de primera, y buena parte de las decisiones bien tomadas del mundo se han tomado sobre una. Podrías abrir estos siete CSV en Excel o en Google Sheets, mirarlos, montar una tabla dinámica y sacar unas primeras cuentas. Para muchas preguntas esa sería la respuesta correcta y la más rápida, y no hay ningún desprecio en usarla: quien te diga que un analista «de verdad» no toca hojas de cálculo no ha trabajado en una empresa real. La hoja es donde media compañía vive, y saber moverte en ella es parte del oficio.

Dicho eso, este encargo tiene tres características que hacen que la hoja se quede corta, y son las mismas tres que empujan a cualquiera de la hoja al código. La primera es el volumen: visitas tiene más de cincuenta y cinco mil filas y contactos dieciocho mil; una hoja se arrastra, se cuelga o no las abre enteras. La segunda es la repetición: este análisis no se hace una vez, se querrá repetir cada trimestre; si lo montas a mano en una hoja, cada vez repites el clic-clic-clic y cada vez hay un paso que se te olvida. Y la tercera, la más peligrosa: la hoja se copia, y en cuanto hay dos copias hay dos versiones del mismo número. Gonzalo tendrá su hoja con sus visitas por zona, Producto la suya con otras cifras, y nadie sabrá cuál manda. Es exactamente la primera costura de NidoHogar que viste esta mañana: tres áreas midiendo «funciona» de tres formas.

### Esto tiene nombre: análisis exploratorio de datos

Esta fase de mirar los datos antes de calcular nada tiene nombre propio y una historia bonita. Se llama análisis exploratorio de datos —a menudo lo verás por sus siglas en inglés, EDA— y lo bautizó un estadístico llamado John Tukey en los años setenta. Hasta entonces, la estadística iba casi siempre en la otra dirección: tenías una hipótesis, recogías datos a propósito y hacías un test para confirmarla o descartarla. Tukey defendió algo que hoy nos parece obvio pero que entonces era casi herejía: antes de testar nada, siéntate a mirar los datos sin prejuicios, con gráficos sencillos y resúmenes, a ver qué te cuentan. No para confirmar lo que crees, sino para descubrir lo que no sabías que había. Decía que un gráfico te obliga a fijarte en lo que no esperabas ver, y esa frase es el corazón de tu primer día.

El EDA es lo contrario del atajo que te pide Gonzalo. Él quiere una respuesta ya, con una hipótesis ya formada («el destacado funciona»). El EDA dice: espera, primero deja que los datos te sorprendan. Y te van a sorprender, porque casi siempre hay algo que no encaja con la historia oficial —una columna sucia que nadie mencionó, una distribución rara, un nulo que significa algo—. En tus dos encargos anteriores ya lo viste: el hallazgo importante casi nunca estaba donde el stakeholder señalaba, sino en un rincón que apareció al explorar. Por eso esta media hora de aparente lentitud, de mirar sin calcular, no es tiempo perdido: es la inversión que hace que todo lo que venga después esté bien fundado. Quien se salta el EDA construye rápido sobre terreno que no ha pisado.

### El modelo de datos: por qué todo cuelga del anuncio

Antes de abrir los ficheros conviene ver cómo encajan entre sí, porque el modelo de un marketplace tiene una lógica muy clara una vez la ves. En el centro está el anuncio (la tabla anuncios): cada piso publicado, con su zona, su ciudad, su precio, su tipo (destacado o normal) y la agencia que lo puso. Alrededor cuelga el embudo que ya conoces: las visitas de ese anuncio, los contactos que generó y los contratos que se firmaron. Cada visita, cada contacto y cada contrato apunta a su anuncio por el identificador anuncio_id. Y hay dos cadenas más que importan: cada contrato apunta también al contacto exacto que lo originó (contacto_id), y cada anuncio apunta a su agencia (agencia_id).

Fíjate en la tabla zonas, abajo a la izquierda, porque esconde una trampa que te dará trabajo mañana. zonas es una tabla de referencia: el precio medio de mercado por metro cuadrado de cada barrio, escrito en su forma canónica —Ruzafa, Chamberí, Triana—. Para cruzarla con anuncios hay que casar anuncios.zona con zonas.zona. Y ahí está el problema: en anuncios la zona viene escrita de mil maneras (Russafa, RUZAFA, ruzafa), así que el cruce solo funcionará después de normalizar. Si no lo haces, el JOIN falla en silencio y te deja anuncios sin zona sin avisar de nada. Hoy solo tienes que verlo venir; mañana lo arreglas.

### Tablas de hechos y tablas de dimensión

Ese mapa esconde una distinción que vas a reconocer en cualquier empresa: hay dos tipos de tabla. Las tablas de hechos guardan cosas que pasan, con fecha: una visita, un contacto, un contrato. Crecen sin parar, tienen una fila por acontecimiento, y son de las que cuentas y sumas. Las tablas de dimensión describen cosas que son: qué es un anuncio (anuncios), quién es una agencia (agencias), qué barrio es una zona (zonas). Cambian poco, tienen una fila por cosa, y aportan los atributos por los que quieres agrupar: el tipo de anuncio, la ciudad, el plan de la agencia. El patrón de casi todo análisis es coger una tabla de hechos y pegarle los atributos de una de dimensión para poder agrupar por algo que el hecho no traía.

Aquí se ve clarísimo. contactos es una tabla de hechos: cada fila es un mensaje con su fecha, pero no sabe si el anuncio era destacado o normal. anuncios es la dimensión que sí lo sabe. Para responder «¿convierten mejor los destacados?» no queda otra que pegar el tipo de anuncio a cada contacto, cruzando por anuncio_id. Sin ese cruce, la tabla de hechos no puede contestar una pregunta por tipo, porque el tipo no vive en ella. Reconocer qué tabla es hecho y cuál dimensión te dice, ante cualquier pregunta, qué tienes que cruzar con qué.

Esta forma de organizar los datos —unas pocas tablas de hechos en el centro, rodeadas de tablas de dimensión que las describen— es tan común que tiene nombre: esquema en estrella, porque si lo dibujas, la tabla de hechos queda en el medio y las dimensiones alrededor como las puntas de una estrella. No hace falta que lo memorices como término, pero sí que reconozcas el patrón, porque lo vas a ver en casi todas las empresas: hay unas tablas grandes que no paran de crecer (lo que pasa) y unas tablas pequeñas que casi no cambian (lo que las cosas son). Aquí, visitas, contactos y contratos son las que crecen; anuncios, agencias y zonas son las que describen. Saber cuál es cuál te dice de un vistazo cuál vas a contar y cuál vas a usar para agrupar.

### El primer vistazo: cuatro preguntas a cada fichero

Explorar un fichero por primera vez es hacerle cuatro preguntas, siempre las mismas, en este orden. Cada una tiene su método en Pandas y cada una te dice algo distinto.

1. 01.¿Qué tamaño tiene? → .shape te da (filas, columnas). Te sitúa: no es lo mismo una tabla de 40 filas que una de 55.000.
2. 02.¿Qué pinta tienen los datos? → .head() enseña las primeras filas. Ver el dato real vale más que imaginarlo.
3. 03.¿De qué tipo cree Pandas que es cada columna? → .info() o .dtypes. Una columna que sale como texto (object) donde esperabas un número esconde suciedad.
4. 04.¿Cuántos huecos hay? → .isnull().sum() cuenta los nulos por columna. Un hueco no siempre es un error: a veces significa algo.

1import pandas as pd
2
3anuncios = pd.read_csv('datos/anuncios.csv')
4
5print(anuncios.shape)          # (filas, columnas)
6print(anuncios.dtypes)         # tipo de cada columna
7print(anuncios.isnull().sum()) # nulos por columna

### Dos piezas de Pandas que conviene tener claras: DataFrame y Series

Como vas a vivir en Pandas estos dos días, vale la pena fijar dos palabras que se repiten. Un DataFrame es la tabla entera: filas y columnas, como una hoja de cálculo en memoria. Una Series es una sola columna de esa tabla: una lista de valores con un índice. Cuando escribes anuncios["zona"] estás sacando una Series, la columna de zonas, y sobre una Series puedes preguntar cosas: .nunique() cuenta sus valores distintos, .value_counts() cuenta cuántas veces aparece cada uno, .isnull() marca los vacíos. Cuando escribes anuncios sin más, tienes el DataFrame completo, y .shape, .head() o .info() te hablan de la tabla entera. Distinguir «estoy preguntando por una columna» de «estoy preguntando por la tabla» te evita la mitad de los errores de sintaxis de un principiante en Pandas.

La mayoría de la exploración es encadenar operaciones sobre una Series, leyéndolas de izquierda a derecha como una frase. anuncios["zona"].str.strip().str.lower().nunique() se lee: «coge la columna zona, quítale los espacios, pásala a minúsculas y cuenta cuántos valores distintos quedan». Cada punto es un paso, y el resultado de un paso alimenta al siguiente. Este encadenado es cómodo y legible, pero tiene un peligro: si encadenas diez operaciones y el resultado es raro, no sabes en cuál se torció. La misma disciplina que en SQL con las CTE: cuando algo no cuadra, parte la cadena y mira el resultado a mitad de camino. La legibilidad no está reñida con poder depurar, siempre que sepas romper la cadena cuando haga falta.

### Por qué un CSV llega sucio: no es descuido, es cómo viaja el dato

Puede tentarte pensar que los datos llegan sucios porque alguien hizo mal su trabajo. Casi nunca es así, y entenderlo te ayuda a anticipar la suciedad en vez de sufrirla. Un CSV —siglas de valores separados por comas, el formato de tabla más viejo y universal que existe— es un fichero de texto plano: no guarda tipos, no guarda que una columna «es un número» o «es una fecha», solo guarda texto separado por comas. Cuando BigQuery exporta a CSV, todo se convierte en texto, y al volver a leerlo cada herramienta adivina los tipos como puede. Por eso el precio, que en el almacén quizá era un número, llega como "1.150,00 €": alguien, en algún punto, lo formateó para que se viera bonito en un informe, y ese formato se quedó pegado al viajar a CSV.

Las tres suciedades que más te vas a encontrar tienen todas el mismo origen: el dato pasó por manos o sistemas que lo pensaron para leerse, no para calcularse. Las fechas en tres formatos vienen de que distintas partes del sistema (la web, la app, una importación manual) las escribieron a su manera. Las categorías en varias grafías vienen de que las metió gente distinta en momentos distintos, cada uno como le sonaba —Gonzalo escribe «Russafa», la agencia «RUZAFA», el formulario «ruzafa»—. Y los duplicados vienen de sistemas que reintentan al fallar la conexión y registran el evento dos veces. Ninguna es un error tonto; todas son la huella de que el dato tuvo una vida antes de llegar a ti. Tu trabajo no es indignarte, es reconocer cada huella y saber limpiarla.

### Mira el dato real: no te fíes de lo que imaginas

De las cuatro preguntas, la segunda —ver las primeras filas— parece la más tonta y es la que más disgustos ahorra. Cuando abres un fichero que se llama anuncios, tu cabeza ya se imaginó lo que hay: un precio numérico, una fecha, una zona bien escrita. Y casi nunca es lo que imaginabas. El precio está como texto con el euro pegado y coma decimal, la fecha viene en tres formatos, la zona aparece escrita de seis maneras distintas para el mismo barrio. Mirar el dato real, con tus ojos, en cinco filas de ejemplo, te dice en un segundo lo que una hora de suposiciones no te habría dicho. El analista novato calcula sobre lo que cree que hay; el veterano mira primero lo que hay.

Y al mirar los tamaños de las siete tablas te vas a topar con la firma inconfundible de un marketplace de alquiler: el embudo se estrecha brutalmente. Decenas de miles de visitas, dieciocho mil contactos, y solo algo más de mil contratos. Esa desproporción no es un error del volcado: es el negocio. Te está diciendo, antes de calcular nada, que de cada mirada solo una fracción escribe y de cada mensaje solo una fracción diminuta acaba firmando. Un negocio donde todo el que mira alquilase tendría las tres tablas parecidas; que estén tan descompensadas es la huella de que el dinero está en el fondo estrecho del embudo.

### El novato calcula sobre lo que imagina; el veterano mira lo que hay

Si te llevas una sola idea de este primer día con los datos, que sea esta, porque distingue a un analista novato de uno con oficio. El novato, cuando abre un fichero llamado precio, ya tiene en la cabeza lo que hay dentro —un número— y calcula sobre esa imagen mental; cuando el número no cuadra, se pelea con la fórmula, sin sospechar que el problema era que el dato no era lo que imaginaba. El veterano hace lo contrario: antes de calcular nada, mira lo que hay de verdad, con sus ojos, en unas cuantas filas de ejemplo. Y casi siempre lo que hay le sorprende: el precio es texto con un euro pegado, la zona está escrita de seis maneras, una columna que esperaba llena está medio vacía. Esa costumbre de mirar antes de suponer es barata —cuesta treinta segundos— y ahorra horas de calcular sobre una realidad inventada.

La razón por la que cuesta tanto adoptar esta costumbre es que suponer es cómodo y mirar es aburrido. Suponer que el precio es un número te deja ir directo a la parte divertida, el cálculo; mirar las filas de ejemplo es un trámite tedioso que parece que no aporta. Pero el trámite tedioso es justo donde se cazan los problemas que, si no, aparecen mucho más tarde y mucho más caros. Es la misma sabiduría del carpintero que mide dos veces antes de cortar una: el minuto de medir ahorra la tabla estropeada. En datos, mirar el dato real antes de calcular es medir dos veces, y quien se lo salta acaba cortando mal y rehaciendo el trabajo, casi siempre con prisa y delante de un stakeholder.

### Granularidad: una visita no es un contacto no es un anuncio

Cuando cargues las tablas verás algo que conviene tener claro desde ya, porque es el error número uno al contar en un embudo. La tabla anuncios tiene una fila por piso publicado. La tabla visitas tiene una fila por cada vez que alguien abrió una ficha, así que un mismo anuncio aparece muchísimas veces. Y contactos tiene una fila por cada mensaje. Cada tabla mira el mundo a un nivel de detalle distinto —en la jerga, tiene una granularidad distinta—, y contar filas de la tabla equivocada infla la respuesta.

La analogía que mejor lo fija es la cola del supermercado. Piensa en un sábado: hay clientes (personas que entran), hay visitas al lineal (cada vez que alguien coge un producto y lo mira) y hay compras (los que pasan por caja). Un mismo cliente mira veinte productos y compra tres. Si el gerente pregunta «¿cuánta gente ha comprado hoy?» y tú cuentas miradas al lineal, le contestas «cuatro mil» cuando la respuesta eran trescientos. No has calculado mal una división: has contado la cosa equivocada. En NidoHogar, anuncios son los pisos, visitas son las miradas al lineal y contactos son quienes se acercan a preguntar. Confundir el nivel es responder «cuántos contratos» contando visitas.

Fijar la granularidad de cada tabla antes de contar te ahorra el error más caro del análisis, que además es invisible: no da error, solo da un número mal que parece bien. Si alguien pregunta «¿cuántos pisos tienen contacto?» y tú cuentas filas de contactos, cuentas mensajes, no pisos, y un piso con quince mensajes cuenta quince veces. La respuesta sale inflada, nadie salta una alarma, y esa cifra viaja a una reunión como si fuera verdad. La costumbre que te blinda es preguntarte, ante cualquier tabla, «una fila de aquí, ¿qué es exactamente?», y ante cualquier recuento, «¿estoy contando pisos, mensajes o miradas?». COUNT(DISTINCT anuncio_id) cuenta pisos; COUNT(*) cuenta filas. La diferencia entre esas dos, en una tabla de hechos, es la diferencia entre una respuesta correcta y una inflada.

### Las siete tablas, una a una

Antes de abrirlas, ten claro qué esperas encontrar en cada una, porque saber qué debería haber es lo que te permite detectar lo que no cuadra. Estas son las siete exportaciones y su papel en el modelo:

• ▹anuncios — el centro de todo, una fila por piso publicado: su zona, ciudad, tipo (destacado o normal), precio, metros, fotos, la agencia que lo puso y las fechas de alta y baja. Es la dimensión principal, la que describe qué es cada anuncio. Aquí viven casi todas las suciedades: precio como texto, zona en mil grafías, tipo sin unificar, fechas en tres formatos.
• ▹agencias — una fila por cuenta que publica: nombre, ciudad, si es agencia profesional o particular, y su plan de suscripción. Es la dimensión que describe a quién pertenece cada anuncio, y permite atribuir el comportamiento de respuesta a un actor concreto.
• ▹visitas — una fila por cada vez que alguien abrió la ficha de un anuncio. Es la primera tabla de hechos del embudo, la más grande, y trae duplicados por reintentos. Solo sabe el anuncio, la fecha y el dispositivo: para saber el tipo de anuncio hay que cruzar con anuncios.
• ▹contactos — una fila por mensaje de un inquilino a un anuncio: su fecha, el canal, el inquilino, y —la columna de oro— la fecha de respuesta de la agencia, que puede estar vacía. Es el escalón central del embudo y donde vive el hallazgo del caso.
• ▹contratos — una fila por alquiler firmado a través del portal: apunta al anuncio y al contacto exacto que lo originó, con el importe y la comisión. Es el escalón que paga, el más pequeño y el que de verdad importa.
• ▹productos_visibilidad — una fila por compra de un producto de visibilidad (destacado, subir ranking) sobre un anuncio, con su precio y sus fechas. Es lo que permite poner el gasto en visibilidad frente a lo que genera.
• ▹zonas — una tabla de referencia con las 40 zonas canónicas y su precio medio de mercado por metro. Es la que te da la grafía oficial de cada barrio y contra la que hay que casar la zona sucia de anuncios.

Fíjate en que con solo leer esta lista ya puedes anticipar los cruces que vas a necesitar y las trampas que te esperan: visitas, contactos y contratos se pegan a anuncios por anuncio_id; contratos se pega también a contactos por contacto_id; anuncios a agencias por agencia_id; y anuncios a zonas por la zona, ese cruce que solo funcionará tras normalizar. Tener este mapa en la cabeza antes de escribir una línea es lo que te permite, ante cualquier pregunta, saber al instante qué tablas hay que juntar. Quien no lo tiene cruza a ciegas; quien lo tiene va directo.

### Explorar y limpiar son dos fases, y mezclarlas te hace peor en las dos

Un error muy tentador hoy es arreglar los problemas según los encuentras: ves el precio sucio en anuncios y te pones a limpiarlo, luego ves la zona y la limpias, y así. Resístelo. Explorar y limpiar son dos fases distintas, y mezclarlas te hace peor en las dos. Cuando exploras, tu objetivo es tener la foto completa del terreno: qué hay en las siete tablas, qué está sucio, qué falta, qué no cuadra. Si te pones a limpiar la primera columna sucia que ves, pierdes esa visión de conjunto y empiezas a tomar decisiones de limpieza sin saber todavía qué te vas a encontrar en las otras seis tablas. Es como en el reconocimiento de un terreno: primero recorres el mapa entero y anotas dónde están las minas, y solo después, con el mapa completo delante, decides por dónde pasar.

Hay una razón práctica y otra de fondo. La práctica: algunas decisiones de limpieza dependen de otras tablas. Cómo normalizar la zona depende de qué zonas canónicas hay en la tabla zonas; si limpias anuncios antes de mirar zonas, limpias a ciegas. La de fondo: cuando exploras con la intención de limpiar ya, tu cabeza entra en modo «arreglar», y en ese modo ves problemas concretos y dejas de ver el patrón general. En modo «explorar», en cambio, ves la forma del conjunto —el embudo que se estrecha, la desproporción entre visitas y contratos, las columnas que sistemáticamente vienen como texto—, y esa forma te cuenta cosas del negocio que ninguna columna suelta te diría. Guarda la limpieza para mañana, con el mapa entero en la mano.

Con esas cuatro preguntas repetidas sobre las siete tablas tendrás, en media hora, un mapa completo de con qué trabajas y qué habrá que limpiar mañana. No vas a arreglar nada hoy: hoy observas y anotas. Como dice Diego por Slack, «hoy entérate de qué hay, mañana lo limpias». Vamos a hacer justo eso, fichero a fichero.