Lunes: montar el repo y mirar los datos

## Lunes, 11:00. Los extractos ya están en la carpeta

Ya sabes qué vas a predecir y por qué importa. Ahora toca mirar los datos de verdad. Marisol te ha dejado en la carpeta compartida seis ficheros CSV, y antes de calcular nada con ellos hay una regla que se aprende pronto y se agradece siempre: no te fíes de lo que crees que hay dentro de un fichero hasta que lo abras y lo mires. Un extracto puede traer más filas de las que esperas, columnas en un tipo raro, o un id que no casa con nada. El lunes de un proyecto es para eso: para dibujar el mapa del terreno antes de empezar a construir.

Estos son los seis ficheros, y conviene entender qué representa cada uno porque van a cruzarse entre ellos durante toda la semana. La ficha de socios tiene una fila por socio: su cuota, su canal de captación, si tiene domiciliación, su antigüedad, su edad, su provincia. Las donaciones puntuales tienen muchas filas por socio —cada aportación suelta aparte de la cuota—, y hay socios que no aparecen porque nunca han donado nada extra. Los emails traen una fila por socio con el resumen del año: cuántos boletines se le enviaron, cuántos abrió, cuántos clicó. Los eventos registran la asistencia a actos. Las renovaciones son una tabla aparte que define lo que queremos predecir: si cada socio renovó o no. Y los socios de hoy son los activos del ciclo actual, con la misma ficha pero todavía sin saber si renovarán: son los que al final tendrás que puntuar.

## Lo primero: la forma de cada tabla

La forma de una tabla —cuántas filas y cuántas columnas tiene— es la primera pregunta que se le hace a un dato nuevo, porque ya cuenta una historia. Si la ficha de socios tiene quince mil filas y las donaciones casi treinta y ocho mil, eso te dice de entrada que hay varias donaciones por socio, y que para modelar tendrás que resumir esas donaciones a una sola cifra por socio. Si las renovaciones tienen las mismas filas que los socios, confirma que hay una decisión de renovación por socio. Mirar las formas no es un trámite: es la primera comprobación de que las tablas encajan como esperas.

En pandas, la librería de Python para manejar tablas, cargar un CSV se hace con `pd.read_csv` y la forma se consulta con `.shape`, que devuelve una pareja de números: filas y columnas. En el primer ejercicio vas a cargar los seis ficheros de golpe y pedir la forma de cada uno. Es el primer bloque de tu fichero `src/01_explorar.py`.

## Lo segundo: qué tipo ve pandas, y las tres granularidades

Saber cuántas filas hay no basta: hay que entender la granularidad de cada tabla, es decir, qué representa una fila. Y aquí hay tres niveles distintos conviviendo. La tabla de socios es de SUJETO: una fila es un socio, el protagonista del problema. Las tablas de donaciones, emails y eventos son de COMPORTAMIENTO: describen cosas que el socio hizo, y pueden tener varias filas por socio (muchas donaciones) o una fila resumen (los emails del año). Y la tabla de renovaciones es la de RESULTADO: dice el desenlace que queremos predecir. Entender quién es quién es lo que te permitirá, el martes, resumir el comportamiento a una fila por socio y pegarle el resultado al lado.

De paso, mientras exploras, fíjate en los tipos que pandas asigna a cada columna, porque ahí se esconde la mitad del trabajo de limpieza. Cuando pandas lee un CSV, intenta adivinar si cada columna es un número o texto. El tipo se consulta con `.dtype`, y lo que verás es un vocabulario corto: `int64` es un entero, `float64` un número con decimales, y `object` es la etiqueta que pandas le pone al texto. La trampa está en las columnas que salen como `object` cuando esperabas un número: ahí hay suciedad escondida. En la ficha de socios, la cuota mensual sale como texto («12,89 €») en vez de como número, y eso tendrás que arreglarlo mañana.

## Contar las filas desde SQL

No todo lo vas a hacer en Python. Para cruzar y contar extractos, muchas veces es más rápido y más claro escribir una consulta SQL, el lenguaje de las bases de datos. En Donare tienes DuckDB, un motor que te deja consultar directamente los CSV como si fueran tablas: cada fichero se convierte en una tabla con el nombre del fichero sin la extensión. Así que `socios.csv` es la tabla `socios`, `donaciones.csv` es `donaciones`, y así con todas. En la carpeta `sql/` de tu repo vas a dejar las consultas de agregación, y la primera es la más sencilla: contar cuántas filas tiene cada tabla, para confirmar las formas que viste en Python pero desde el otro lado.

La función de SQL que cuenta filas es `COUNT(*)`: cuenta todas las filas de la tabla, sin mirar ninguna columna en concreto. Es distinta de `COUNT(DISTINCT algo)`, que cuenta valores diferentes de una columna. Confundir las dos es un error clásico, y precisamente ese es el defecto que vas a corregir: una línea cuenta socios distintos en las donaciones en vez de contar donaciones totales, y por eso una cifra sale mucho más baja de lo que debería.

## Y la primera pista del lunes

Mientras miras los datos, Jon te deja caer algo por Slack que de momento no significa nada para ti, pero que conviene que quede escrito. Le comentas que has visto el reparto por encima y que casi todos los socios renuevan, que esto parece fácil. Y él te responde con una de sus frasecitas: «Mmm, yo no cantaría victoria tan rápido. Que casi todos renueven es justo lo que te puede joder el modelo, no lo que te lo pone fácil. Luego lo hablamos.» Lo dejas pasar, porque suena a advertencia vaga y hoy tienes otras cosas. La pista queda sembrada. El jueves entenderás a qué se refería.

Con eso cierras el lunes: sabes qué seis tablas tienes, cómo se cruzan por socio_id, cuál es de sujeto, cuáles de comportamiento y cuál define el resultado, y qué columnas vienen sucias. No has calculado nada útil todavía, y está bien así. Mañana empiezas a limpiar y a construir el target que vas a querer predecir.