Día 1 — Primer contacto con los datos

### La carpeta compartida y sus siete ficheros

Terminada la reunión de arranque, abres la carpeta compartida que te ha dejado Álex y te encuentras lo de siempre: siete ficheros CSV con nombres que prometen orden y un contenido que ya sospechas que no lo tendrá. De tus seis encargos anteriores sales con una costumbre que aquí vale oro: no calcular nada el primer día. Antes de sumar un euro de prima o contar una póliza hay que saber qué hay dentro de cada fichero, cómo se relacionan y por dónde vienen sucios. Un análisis que arranca sin ese vistazo es un análisis que a media semana descubre que llevaba dos días sumando primas que eran texto, o contando pólizas por un canal escrito de cuatro maneras distintas. Hoy la jornada es solo para mirar.

1Alex Cordero  10:34
2Buenas! Te dejo en la carpeta compartida las exportaciones de los ultimos ~18 meses:
3canales, productos, mediadores, clientes, polizas, siniestros y campanas
4Te adelanto el titular: los COMPARADORES son el numero UNO 🙌
5Mas polizas que ningun canal, la prima media mas alta, la mayor prima suscrita, y el CAC mas bajo. Clarisimo
6Si me confirmas el CAC por canal ya me vale para llevar el presupuesto al comite del viernes
7Corre un poco que quiero cerrar el reparto para el año que viene 🙏

Fíjate en lo que Álex pide y en lo que no pide. Pide el CAC por canal —el coste por póliza captada—, que es exactamente la métrica que le da la razón. No pide el loss ratio, ni la renovación, ni el margen. No porque sea deshonesto, sino porque en su cabeza el trabajo ya está hecho: los comparadores son el ganador, solo falta ponerle el número al lado. Tu tarea de esta semana empieza por no aceptar ese marco, pero hoy ni siquiera eso: hoy solo abres los ficheros y miras.

Y llega el segundo mensaje, el de Hugo, que conoce las trampas de las exportaciones porque las ha sufrido todas. Léelo con atención, porque los dos vacíos que menciona son los que pueden invertir tu análisis, y hoy tu único objetivo de verdad es confirmar que existen y medir cuántos son.

1Hugo Ferrer  10:52
2jaja bienvenido/a a las exportaciones del core + siniestros + Stripe + captacion 🙃
3la fecha en 3 formatos (una trae el mes en INGLES, "12 Mar 2024", cuidado al parsear), prima e importe con €
4y coma, el descuento como "15 %" en texto, y el canal / el ramo / el estado cada uno como le suena
5tres avisos que nadie escucha nunca:
61) el webhook de Stripe a veces manda el MISMO cobro dos veces, y a veces un siniestro se reabre y se
7   duplica. dedup por poliza_id y por siniestro_id antes de sumar nada
82) la poliza con mediador_id vacio NO es un nulo que falte: es una venta DIGITAL (comparador, web, app),
9   sin mediador. son polizas reales, no las tires (y si haces INNER con mediadores te cargas los
10   comparadores enteros, que es justo lo que quieres mirar)
113) el siniestro sin fecha_cierre NO es que falte el dato: es que sigue ABIERTO (en tramite, aun no
12   cerrado). y ojo, esos son de los que mas cuestan. si los tiras, subestimas lo que cuesta un canal
13hoy solo enterate de que hay, manana lo limpias

Antes de abrir el primer fichero, ten en la cabeza de dónde viene cada uno, porque eso explica por qué vienen sucios y por qué vienen sucios de formas distintas. Los siete CSV no salen de un sitio: salen de cinco sistemas que no se hablan entre sí. El core de pólizas exporta las pólizas, los clientes y los productos; la plataforma de siniestros exporta los siniestros; Stripe mete la mano en los cobros y duplica; las herramientas de captación exportan las campañas y los mediadores; y todo pasa por el almacén antes de llegar a ti. Cada sistema escribe las fechas a su manera, los canales con su vocabulario y los importes con su formato. Cuando entiendes que un dataset es la costura de cinco fuentes, dejas de sorprenderte de que el canal esté escrito de veintidós formas: es que veintidós formas es lo que pasa cuando cinco equipos distintos nombran la misma cosa sin ponerse de acuerdo.

### Pandas, tu banco de trabajo para mirar datos

La herramienta con la que vas a explorar y limpiar estos días es Pandas, una librería de Python pensada para trabajar con datos en forma de tabla. La pieza central se llama DataFrame, y no es más que eso: una tabla con filas y columnas, como una hoja de cálculo, pero manejada con código en lugar de con el ratón. Cargas un CSV con pd.read_csv() y obtienes un DataFrame; a partir de ahí le preguntas cosas a la tabla con métodos, que son órdenes que se escriben con un punto detrás del nombre. Si has usado una hoja de cálculo, ya tienes la intuición: una columna es una columna, una fila es un registro, y lo que en la hoja harías con menús, aquí lo pides con una línea.

¿Y por qué código en lugar de la hoja de cálculo, si al final es lo mismo? Por tres razones que vas a agradecer esta semana. La primera, el tamaño: 96.000 pólizas y 123.000 siniestros hacen sudar a cualquier hoja de cálculo, y Pandas los mueve sin pestañear. La segunda, la repetición: la limpieza que hoy escribes se puede volver a ejecutar el mes que viene sobre datos nuevos con un clic, mientras que en la hoja tendrías que rehacerlo a mano cada vez. Y la tercera, la trazabilidad: el código deja escrito exactamente qué hiciste, así que cualquiera —incluido tu yo de dentro de tres meses— puede ver y comprobar cada decisión de limpieza.

### El modelo: la póliza en el centro, todo cuelga de ella

Antes de mirar los ficheros uno a uno, quédate con la forma del modelo, porque es lo que te dirá qué tabla contesta qué pregunta. En el centro está la póliza. De ella cuelga todo lo demás: su canal (por dónde entró), su producto y por tanto su ramo (auto, hogar, salud, vida o mascotas), su cliente (con su edad y su provincia), su mediador si lo hubo (y si no lo hubo, es una venta digital), sus siniestros (que dicen cuánto cuesta cubrirla) y su renovación (que dice si el cliente se queda, porque una renovación es una póliza que apunta a la póliza original). Aparte, las campañas guardan el coste de captación de cada canal. El margen de un canal no vive en ninguna tabla: se construye juntando la póliza (canal, prima) con los siniestros (loss ratio), con las campañas (CAC) y con las renovaciones. Cuatro fuentes que ninguna contesta sola.

Ya sabes de tus encargos anteriores que el primer vistazo se hace con cuatro herramientas: .head() para ver las primeras filas, .shape para saber cuántas filas y columnas hay, .info() para ver los tipos de cada columna, y .isnull().sum() para contar los vacíos de cada columna. Con esas cuatro te haces una foto de un fichero en treinta segundos. Empieza por lo más básico y lo más revelador: cuántas filas trae cada uno de los siete ficheros.

Hay una disciplina detrás de este «mirar antes de calcular» que conviene hacer explícita, porque es lo que separa un análisis que aguanta de uno que se derrumba a media semana. Explorar no es curiosear: es responder tres preguntas concretas sobre cada fichero antes de fiarte de él. ¿Cuántas filas tiene, y cuántas esperaba? ¿Qué tipo tiene cada columna, y coincide con lo que debería ser? ¿Dónde están los vacíos, y qué significan? Si respondes esas tres antes de sumar nada, cazas la mayoría de los desastres en su origen: la columna que es texto y creías número, el identificador con vacíos, la tabla que trae el triple de filas de lo esperado. Es media hora que ahorra dos días.

Y hay una tentación que hay que resistir el primer día: la de empezar a limpiar según encuentras la suciedad. Ves que el canal está sucio y te lanzas a normalizarlo, ves las fechas y te pones a parsear. Error. Hoy solo se mira y se anota; mañana se limpia con un plan. Mezclar exploración y limpieza lleva a limpiar cosas que no vas a usar y a olvidar comprobar el resultado de lo que sí. La secuencia sana es primero un inventario completo de qué hay y qué está mal (hoy), y después una limpieza ordenada y comprobada (mañana). El analista con prisa que limpia mientras explora acaba con un cuaderno lleno de arreglos a medias y sin una foto clara de a qué se enfrentaba.

Con la foto de tamaños hecha, baja al detalle donde está lo interesante: los vacíos de las pólizas. Hay tres columnas con huecos, y no significan lo mismo. El mediador_id vacío es la venta digital (dos tercios de las pólizas, ya lo verás). El poliza_origen_id vacío es lo esperado: solo las renovaciones apuntan a una póliza original, así que las nuevas lo tienen vacío por diseño, no por error. Y el descuento_pct vacío es simplemente una póliza sin descuento. Tres vacíos, tres significados: distinguirlos es la mitad del trabajo de mañana.

Después llega el campo del que depende todo el análisis: el canal. Es la dimensión sobre la que Distribución quiere decidir el presupuesto, así que si viene sucio, todo lo demás se tuerce. Y viene sucio: el mismo canal está escrito de varias formas, con mayúsculas, con sinónimos («comparador», «Comparadores», «Rastreator», «agregador» son el mismo). Cuenta cuántas grafías distintas hay y verás el tamaño del problema de mañana. Lo mismo con el ramo, que no vive donde parece: la columna que se llama «ramo» en productos trae agrupaciones raras, y el ramo de verdad (auto, hogar, salud, vida, mascotas) está escondido en la columna «nombre», también sucia.

### Las tablas pequeñas también cuentan cosas

Es fácil obsesionarse con las tablas grandes —pólizas y siniestros— y pasar por encima de las pequeñas, pero las de contexto (canales, productos, mediadores, campañas) esconden pistas y trampas. Ábrelas también. La de canales tiene cinco filas y te dice cuáles son los cinco canónicos a los que tendrás que mapear las 22 grafías sucias: comparadores, directo, mediadores, banca y referido. La de campañas, con sus 40 filas, es la que te dará el coste de captación; fíjate en que su columna de canal viene escrita distinto que la de las pólizas (verás «agregador», «ads», «acuerdo», «recompensa»), porque son sistemas distintos que exportan con vocabularios distintos. Ese detalle, que hoy solo anotas, mañana será clave: el mapa que uses para normalizar el canal de las campañas no es exactamente el mismo que el de las pólizas.

La de mediadores tiene 50 filas, una por corredor o agente, con su zona y su tipo. La usarás para cruzar con las pólizas que sí pasaron por un mediador, y ahí está la trampa de la que te avisó Hugo: como dos tercios de las pólizas no tienen mediador (son ventas digitales), ese cruce tiene que ser un LEFT JOIN, o perderás justo los comparadores. Y la de productos, que ya miraste, tiene la sorpresa del ramo escondido en la columna «nombre». Ninguna de estas tablas pequeñas se cruza sin haberla mirado antes: una clave que no case, una grafía que no esperabas, una fila de más, y el JOIN te devuelve un resultado que parece bueno y está mal. Mirar las dimensiones antes de cruzarlas es tan importante como mirar los hechos.

Hay una pregunta que un buen analista se hace el primer día y que aquí es especialmente reveladora: ¿cuántas filas debería tener cada cosa, y cuántas tiene? Sabes que Ampara tiene una cartera de unas 90.000 pólizas vigentes y ha dado de alta unas 60.000 nuevas en los últimos 18 meses. Pero el fichero de pólizas trae 96.015 filas. ¿Por qué más de 90.000? Porque incluye las renovaciones (que son pólizas nuevas apuntando a su original) y los duplicados por doble alta. Ese desajuste entre lo que esperas y lo que ves no es un error: es información. Te dice que en ese fichero conviven altas, renovaciones y duplicados, y que antes de contar «pólizas nuevas» tendrás que separar los tres. Comparar el número que esperas con el que sale es una de las comprobaciones más baratas y más útiles que existen.

Cierra el día con lo que Hugo te pidió confirmar: los siniestros abiertos (sin fecha de cierre) y los duplicados. Mira cuántos siniestros no tienen fecha de cierre —son los que siguen costando— y cuántas filas están repetidas por poliza_id y por siniestro_id. Y de paso, la provincia de los clientes, que trae un vacío distinto: cuando falta, es un dato realmente desconocido (no se registró), no un vacío con significado como los otros dos. Saber distinguir un vacío que significa algo de un vacío que solo falta es, esta semana, la diferencia entre acertar y equivocarte.