El dataset de MercaFresh ya está limpio y sin huecos, pero "correcto" no es lo mismo que "útil". El gasto total de los clientes tiene una cola larguísima hacia la derecha (recuerda los histogramas del módulo 2), las fechas de alta son solo etiquetas de calendario que ningún modelo sabe interpretar, y la información más rica —los pedidos individuales— está a nivel de pedido cuando el modelo de churn necesita una fila por cliente. En esta lección aprenderás a remodelar variables: transformaciones matemáticas que corrigen la asimetría, discretización en tramos, descomposición de fechas en componentes con significado y agregaciones que convierten miles de pedidos en un perfil por cliente. Cerraremos con los pipelines de scikit-learn, la herramienta que ordena todos estos pasos en una cadena reproducible.

1. Por qué transformar: cuando la forma de los datos estorba
2. Transformaciones matemáticas: log, raíz y potencias
3. Box-Cox y Yeo-Johnson: la transformación que se ajusta sola
4. Binning: discretizar variables continuas
5. Fechas: de texto muerto a componentes útiles
6. Agregaciones por entidad: de pedidos a clientes
7. Pipelines: encadenar transformaciones con orden

Muchos modelos rinden mejor —o directamente asumen— que las variables tienen distribuciones razonablemente simétricas y relaciones aproximadamente lineales. Pero las variables de negocio rara vez nacen así:

• Importes y gastos: la mayoría de clientes de MercaFresh gasta poco y unos pocos gastan muchísimo. Es la asimetría positiva que viste en 02-01 (media > mediana) y una distribución parecida a la exponencial de 02-02.
• Recuentos: número de pedidos, de visitas, de incidencias — colas largas a la derecha.
• Fechas: un datetime no dice nada por sí mismo; lo que predice es lo que la fecha implica (¿fin de semana?, ¿cuánto hace?).
• Granularidad equivocada: tenemos 80.000 pedidos, pero el churn se predice por cliente.

Transformar es cambiar la representación de los datos sin cambiar su significado, para que los patrones queden más a la vista del modelo.

El logaritmo comprime los valores grandes mucho más que los pequeños, así que "recoge" la cola derecha de una distribución asimétrica:

Detalles que importan:

• Usamos np.log1p(x) (que calcula log(1 + x)) en lugar de np.log(x) porque el logaritmo de 0 es menos infinito, y en MercaFresh hay clientes con gasto 0. log1p maneja el 0 con elegancia (log1p(0) = 0).
• skew() mide la asimetría numéricamente: ~0 es simétrica, > 1 es sesgo fuerte a la derecha. Es la traducción a número de lo que el histograma muestra a ojo.
• Tras el logaritmo, la distribución se parece a la normal de 02-02, y las herramientas que asumen normalidad (z-scores incluidos) vuelven a funcionar bien.

El logaritmo no es la única opción; hay una "escalera" ordenada por agresividad:

Regla práctica: prueba de menos a más agresiva y comprueba con skew() y el histograma cuál deja la distribución más simétrica sin retorcerla.

En vez de elegir a mano entre raíz y logaritmo, Box-Cox busca automáticamente el exponente óptimo (llamado λ, lambda) que hace la variable lo más parecida posible a una normal. λ = 0 equivale al logaritmo; λ = 0,5, a la raíz; λ = 1, a no hacer nada.

Limitación: Box-Cox solo admite valores positivos. Para variables con ceros o negativos (un saldo de puntos que puede ser negativo, una variación de gasto), existe Yeo-Johnson, su generalización. En scikit-learn ambas viven en PowerTransformer, con la ventaja del patrón fit/transform que ya conoces de la lección anterior (aprende λ en train, lo aplica a datos nuevos):

(El reshape(-1, 1) convierte el vector en una matriz de una columna: los transformadores de scikit-learn siempre esperan datos en 2D, filas × columnas.)

Una advertencia de legibilidad: tras transformar, los valores ya no están en euros. Un coeficiente sobre log(gasto) se interpreta en términos multiplicativos, no aditivos. Ganamos rendimiento del modelo a cambio de interpretación menos directa; conviene guardar siempre la variable original al lado.

Discretizar (o binning) es convertir una variable continua en tramos: la edad exacta en franjas de edad, el gasto en niveles bajo/medio/alto. ¿Para qué?

• Capturar relaciones no lineales sencillas ("los menores de 30 y los mayores de 65 compran distinto").
• Robustez frente a outliers: el cliente de 15.400 € cae en el tramo "alto" y deja de distorsionar.
• Comunicación con negocio: "clientes de gasto alto" se entiende mejor que un coeficiente.

El precio: se pierde información (todos los del tramo se vuelven indistinguibles). Es un intercambio, no un truco gratis.

cut corta donde tú dices: los límites tienen significado de negocio (mayoría de edad, jubilación). Cada intervalo incluye su límite derecho por defecto: (18, 30], (30, 45], etc.

qcut corta por percentiles (los de 02-01): cada tramo tiene el mismo número de observaciones, aunque sus límites en euros salgan "feos". Es la elección natural para variables asimétricas: con cut a intervalos iguales, el 90 % de los clientes caería en el primer tramo.

strategy acepta "uniform" (anchos iguales, como cut automático), "quantile" (como qcut) y "kmeans". Su valor añadido es el de siempre: los límites se aprenden en fit y se reaplican idénticos a datos nuevos, evitando que cada mes los tramos se muevan.

En 03-01 convertimos las fechas de texto a datetime. Ahora las exprimimos: un modelo no puede usar "2024-06-05", pero sí las señales que esa fecha esconde.

¿Por qué funciona? Porque para predecir demanda o churn en MercaFresh, lo relevante no es el 5 de junio en sí, sino que era lunes, que era festivo o que fue hace 80 días. Cada componente extraído convierte conocimiento del calendario en una columna que el modelo puede usar.

Dos matices:

• dayofweek y month son numéricos pero cíclicos: el domingo (6) está "al lado" del lunes (0), y diciembre al lado de enero. Muchos modelos los tratan bien como categorías (lección 03-04); las codificaciones trigonométricas seno/coseno existen para modelos sensibles al orden, y basta con saber que ese matiz está ahí.
• La "fecha de referencia" de la recencia debe ser una fecha fija del análisis (la de corte del dataset), no Timestamp.now(): si no, el mismo código da resultados distintos cada día.

El modelo de churn necesita una fila por cliente, pero la información viva está en la tabla de pedidos. La solución es agregar: resumir el historial de cada cliente en estadísticos.

La sintaxis agg(nombre_nuevo=("columna", "funcion")) (agregación con nombre) produce columnas con nombres limpios en un solo paso. Observa qué hemos conseguido: el cliente 101, con tres pedidos repartidos entre mayo y agosto, queda descrito por su frecuencia, su ticket medio y —oro puro para el churn— cuántos días lleva sin comprar.

El último paso es unir este perfil a la tabla de clientes limpia de las lecciones anteriores:

Con how="left" conservamos también a los clientes sin pedidos (sus agregados quedarán como NaN... que ya sabes tratar de la lección anterior: aquí un 0 en num_pedidos y un indicador sin_pedidos serían imputaciones con pleno sentido de negocio). Estas agregaciones son la antesala del análisis RFM que completaremos en 03-06.

Llevamos ya varios pasos encadenados: imputar, transformar con logaritmos, discretizar... y cada uno con su fit sobre train y su transform sobre el resto. Hacerlo a mano, en orden, sin olvidar ninguno y sin fugas, es frágil. scikit-learn ofrece dos piezas para ensamblarlo:

Un Pipeline es una lista de pasos con nombre que se ejecutan en orden: la salida de cada uno alimenta al siguiente. Al llamar a fit_transform, cada paso hace su fit y su transform en cadena; al llamar después a transform sobre datos nuevos, todos aplican lo aprendido sin reaprender nada. Un solo objeto encapsula todo el preprocesamiento.

No todas las columnas necesitan lo mismo: las numéricas quieren imputación y logaritmos; las categóricas, otras técnicas (las de la próxima lección). ColumnTransformer aplica a cada grupo de columnas su propio tratamiento y junta los resultados:

Cada tupla es (nombre, transformador, lista_de_columnas); "passthrough" deja las columnas pasar tal cual. De momento quédate con la idea introductoria: el preprocesamiento completo puede vivir en un único objeto que se ajusta con fit sobre entrenamiento y se aplica con transform a cualquier dato futuro. En las próximas lecciones iremos rellenando las ramas que faltan, y en el módulo 6 el pipeline demostrará su valor definitivo al combinarse con la validación.

• Aplicar np.log a valores con ceros. Produce -inf silenciosos que revientan el modelo más tarde. Usa np.log1p, y verifica antes que no hay negativos.
• Transformar y olvidar la des-transformación. Si el modelo predice log(gasto), la predicción en euros es np.expm1(prediccion). Documenta qué variables están transformadas.
• Elegir tramos de cut que dejan grupos vacíos. Comprueba siempre value_counts() tras discretizar; un tramo con 3 observaciones no aporta nada. Con asimetría, qcut suele ser mejor punto de partida.
• Usar Timestamp.now() como referencia de recencia. El dataset debe tener una fecha de corte fija y documentada, o los resultados cambian cada día que ejecutas el código.
• Agregar con mean en columnas con outliers. El gasto medio del cliente 107 está dominado por su pedido de 15.400 €; considera añadir también la mediana por cliente.
• Ajustar transformadores con todo el dataset. PowerTransformer y KBinsDiscretizer aprenden parámetros: mismo riesgo de fuga que la imputación (03-02). Dentro de un Pipeline, este error se vuelve casi imposible de cometer — otra razón para usarlos.
• Consejo: antes y después de cada transformación, dibuja el histograma y mira skew(). Dos líneas de código que evitan transformar a ciegas.

La variable num_incidencias de MercaFresh (número de incidencias de entrega por cliente) toma valores [0, 0, 1, 0, 2, 0, 1, 9, 0, 3]. Calcula su asimetría con skew(), aplica la transformación de la escalera que consideres adecuada (justifica cuál y por qué el logaritmo simple daría problemas) y recalcula la asimetría.

Divide los importes de pedido [12, 18, 22, 25, 31, 38, 45, 60, 85, 240] en 4 niveles con qcut y en 4 tramos de igual anchura con cut. Compara los value_counts() de ambos y explica cuál es más útil aquí y por qué.

A partir del DataFrame pedidos de la lección, construye con una sola agregación el perfil por cliente con: número de pedidos, mediana de importe y días desde el último pedido (referencia: 2026-08-24). Nombra las columnas n_pedidos, importe_mediano y recencia_dias.

Ejercicio 1

Con recuentos pequeños y ceros abundantes, sqrt o log1p son las elecciones naturales; el logaritmo puro queda descartado por los ceros.

Ejercicio 2

Con cut, el outlier de 240 estira el rango y deja dos tramos vacíos: inútil. qcut reparte las observaciones por percentiles y produce niveles equilibrados: es la opción adecuada para esta distribución asimétrica.

Ejercicio 3

La mediana de importe protege el perfil del cliente 107 frente a su pedido gigante, y recencia_dias —los días sin comprar— será una de las variables estrella del modelo de churn.

Has aprendido a remodelar los datos para que muestren sus patrones: corregir asimetrías con logaritmos, raíces y las transformaciones automáticas Box-Cox/Yeo-Johnson; discretizar con cut, qcut y KBinsDiscretizer sabiendo qué se gana y qué se pierde; convertir fechas en componentes con poder predictivo (día de semana, festivo, recencia); resumir la tabla de pedidos en perfiles por cliente con groupby().agg(); y encadenar todo en Pipeline y ColumnTransformer para que el preprocesamiento sea reproducible y a prueba de fugas.

Habrás notado que el ColumnTransformer dejó una rama vacía: las columnas categóricas. La ciudad del cliente, la categoría de producto o el plan de suscripción de MercaFresh siguen siendo texto, y ningún modelo sabe multiplicar por "Barcelona". En la próxima lección resolvemos exactamente eso: la codificación de variables categóricas.