El dataset de churn de MercaFresh ya está limpio, completo, transformado, codificado y escalado. Con las lecciones anteriores hemos reparado y adaptado lo que había; en esta última lección del módulo damos el salto que más rendimiento suele aportar: crear información nueva. La ingeniería de características (feature engineering) consiste en construir variables que condensen conocimiento del negocio —cuánto hace que un cliente no compra, cuánto vale, si su actividad crece o se apaga— para que el modelo no tenga que descubrirlo por su cuenta. Hay un dicho muy citado en la profesión: los datos y las características fijan el techo de lo que se puede lograr; los algoritmos solo se acercan más o menos a ese techo. Aquí aprenderás a construir features de negocio (con el clásico RFM), interacciones y polinomios, y a seleccionar cuáles conservar. Cerraremos ensamblando el dataset definitivo de churn y el checklist de todo el módulo.

1. Qué es la ingeniería de características y por qué importa tanto
2. Features de negocio: el análisis RFM sobre MercaFresh
3. Ratios y tendencias: exprimir lo que ya tienes
4. Interacciones y polinomios
5. Selección de características: quedarse con lo que aporta
6. El dataset final de churn de MercaFresh
7. Checklist del preprocesamiento completo

Una característica (feature) es cada columna que el modelo recibe como entrada. La ingeniería de características es el arte de fabricar columnas nuevas a partir de las existentes, incorporando conocimiento del dominio. ¿Por qué suele aportar más que cambiar de algoritmo?

• Los modelos ven poco por sí mismos. Una regresión logística (04-02) solo combina linealmente sus entradas: si la señal del churn está en el ratio gasto/pedido y le das gasto y pedidos por separado, quizá nunca la encuentre. Si le das el ratio ya calculado, la señal está servida.
• El conocimiento de negocio no está en los datos crudos. Que "un cliente que llevaba pedidos semanales y lleva 45 días sin comprar está en riesgo" lo sabe cualquier gestor de MercaFresh; la tabla de pedidos, por sí sola, no lo dice — hay que destilarlo en una columna.
• Es la palanca más rentable. Cambiar de un algoritmo decente a otro sofisticado suele mejorar unos puntos; una buena feature nueva puede transformar el problema. Por eso los equipos experimentados dedican más tiempo a las features que a los modelos.

La materia prima ya la tenemos de las lecciones anteriores: las agregaciones por cliente de 03-03 fueron el primer paso. Ahora las convertimos en un sistema.

El marco RFM es un clásico del análisis de clientes que encaja como un guante en el churn:

La intuición de negocio: un cliente que compraba mucho, a menudo y hace poco está sano; uno cuya recencia crece mientras su frecuencia cae se está marchando — exactamente lo que el modelo de churn debe aprender. Construyámoslo desde la tabla de pedidos:

Tres detalles de oficio:

• La fecha de corte fija (no now()) hace el cálculo reproducible, como vimos en 03-03.
• El clip(lower=1) evita divisiones por cero con clientes de un solo día: las features nuevas también pueden fabricar valores imposibles, y las reglas de validación de 03-01 se les aplican igual.
• Cada feature RFM tiene una lectura de negocio directa: cuando el modelo diga "la recencia es lo que más pesa", el equipo de retención sabrá exactamente qué hacer. Las buenas features son también un canal de comunicación con el negocio.

Una variante muy usada es convertir R, F y M en puntuaciones de 1 a 5 con qcut (¡el binning de 03-03!) y hablar de "clientes 5-5-5" o "1-1-3"; la segmentación fina de estos perfiles la haremos con clustering en el módulo 5 y en el proyecto 09-05.

Un ratio pone en relación dos magnitudes y a menudo dice más que ambas por separado:

ratio_inactividad es una joya para el churn: 60 días sin comprar son alarmantes en un cliente semanal (ratio alto) y normales en uno trimestral (ratio bajo). El ratio codifica ese contexto; las columnas sueltas, no.

El churn es un proceso, no un instante: antes de irse, el cliente se enfría. Una feature de tendencia lo captura comparando su actividad reciente con la anterior:

Un cliente con tendencia = 0.25 (de 8 pedidos a 1) es un candidato a churn de libro aunque su gasto histórico sea alto. Fíjate en cómo reaparecen las lecciones anteriores: fillna(0) es una imputación con significado de negocio (03-02) y el +1 es el mismo truco de estabilidad que log1p (03-03).

A veces la señal está en la combinación de dos variables: el efecto del gasto sobre el churn puede depender del plan (perder 50 €/mes de un cliente básico no es lo mismo que de un premium). Una interacción es simplemente el producto de dos features; un polinomio añade además potencias (x², x³) para capturar curvaturas.

PolynomialFeatures las genera mecánicamente:

De 2 columnas salen 5: las originales, sus cuadrados y su producto. Dos advertencias y una preferencia:

• Explosión combinatoria: con 20 features y degree=2 salen 230 columnas; con degree=3, más de 1.700. interaction_only=True limita a los productos, pero aun así crece rápido.
• Más columnas fabricadas mecánicamente = más riesgo de que el modelo memorice ruido (el overfitting que formalizaremos en 06-05) y más necesidad de selección (siguiente apartado) o de regularización (07-01).
• Preferencia de oficio: antes que polinomios a granel, pocas interacciones elegidas con la cabeza. recencia_dias * pedidos_por_mes ("cuánto silencio acumula un cliente habitualmente activo") vale más que veinte productos ciegos.

Crear features es fácil; el peligro es acabar con 80 columnas donde 50 son ruido, redundancia o peso muerto. Más features no siempre es mejor: encarecen el entrenamiento, dificultan la interpretación y dan al modelo más cuerda para ajustarse al azar. Tres filtros introductorios, de más simple a más formal:

Una columna que apenas varía no puede distinguir a nadie. Si es_cliente_activo vale 1 para el 99,5 % de las filas, no aporta:

(Ojo: el umbral depende de la escala, así que se aplica sobre datos comparables — otro punto para el escalado de 03-05.)

Dos usos de la matriz de correlación de 02-03, ahora como herramienta de selección:

• Con el objetivo: features con correlación ~0 con el churn son candidatas a salir (con la cautela de 02-03: Pearson solo ve relaciones lineales).
• Entre sí: dos features con correlación 0,95 entre ellas (como gasto_total y num_pedidos suelen tener) son casi la misma información dos veces; conservar una simplifica sin perder señal.

Es literalmente el ranking de correlaciones con el churn que hicimos al final de 02-03, aplicado ahora a decidir qué columnas viven.

SelectKBest puntúa cada feature con un test estadístico respecto al objetivo y se queda con las k mejores:

f_classif es, en esencia, un contraste de hipótesis como los de 02-04: ¿difiere la media de esta feature entre los clientes que se van y los que se quedan? Puntuación alta = diferencia clara = feature prometedora. Es un método de filtrado (evalúa cada feature aislada, sin considerar combinaciones): rápido y útil como criba inicial, no como veredicto final. Y como todo lo que aprende del objetivo, se ajusta solo con datos de entrenamiento — a estas alturas del módulo, el reflejo ya debería ser automático.

Existen familias más sofisticadas (selección envolvente, PCA como reducción de dimensionalidad en 05-03, regularización Lasso como selección implícita en 07-01); para cerrar el preprocesamiento, estos tres filtros bastan.

Hora de ensamblar el trabajo de todo el módulo en la tabla definitiva, una fila por cliente:

Y el preprocesamiento completo, como objeto único ejecutable — el ColumnTransformer que hemos ido rellenando lección a lección, ya con todas sus ramas:

Este objeto es el resumen ejecutable del módulo: un solo fit sobre entrenamiento aprende medianas, lambdas, cuartiles y categorías; un solo transform prepara cualquier cliente futuro. Este dataset —estas features, este preprocesador— es el que usaremos conceptualmente durante el resto del curso cada vez que hablemos del churn de MercaFresh.

La lista de control del módulo, en orden de aplicación:

1. Auditar (03-01): info(), describe(), nunique(); entender qué representa cada fila.
2. Limpiar (03-01): duplicados exactos y lógicos; reglas de validez para valores imposibles; normalizar texto y categorías; corregir tipos (to_numeric, to_datetime); diagnosticar outliers (¿error o realidad?).
3. Tratar nulos (03-02): diagnosticar mecanismo (MCAR/MAR/MNAR); eliminar solo con seguridad; imputar (mediana por defecto, por grupos si hay estructura); indicadores de ausencia si la ausencia informa.
4. Transformar (03-03): corregir asimetrías (log1p, Yeo-Johnson); discretizar si conviene; descomponer fechas; agregar por entidad hasta la granularidad del problema.
5. Crear features (03-06): RFM, ratios, tendencias, interacciones elegidas con criterio de negocio.
6. Codificar (03-04): ordinal con orden explícito para ordinales reales; one-hot para nominales; cuidado extremo con target encoding.
7. Escalar (03-05): según el algoritmo; RobustScaler si hay outliers legítimos.
8. Seleccionar (03-06): varianza casi nula, redundancia por correlación, SelectKBest como criba.
9. Transversal: todo paso que aprende parámetros hace fit solo sobre entrenamiento; encapsular en Pipeline/ColumnTransformer; documentar cada decisión.

(El orden 5→6→7 no es casual: las features se crean sobre valores legibles, luego se codifican, y el escalado va al final porque cada columna nueva también necesita escala.)

• Crear features usando el futuro. Si el churn se mide a 90 días vista, ninguna feature puede calcularse con datos posteriores a la fecha de corte: es la fuga de información en su versión temporal, la más sutil de todas.
• Fabricar cientos de features mecánicas y ninguna de negocio. PolynomialFeatures(degree=3) no sustituye a una conversación con el equipo de retención de MercaFresh. Las mejores features nacen de preguntas de negocio.
• No validar las features nuevas. Un ratio puede generar infinitos (división por cero) o valores absurdos: pásale a cada feature nueva la misma auditoría de 03-01 (describe(), histograma).
• Conservar features gemelas. gasto_total, num_pedidos y gasto_medio_pedido juntas son parcialmente redundantes: revisa la matriz de correlación entre features, no solo contra el objetivo.
• Seleccionar features con todo el dataset. SelectKBest mira el objetivo: si se ajusta con datos que luego serán de test, la evaluación queda contaminada. fit en train, siempre.
• No documentar el diccionario de datos. Dentro de tres meses nadie recordará cómo se calculó tendencia. Mantén una tabla feature → definición → fórmula → lección/fecha.
• Consejo: cada vez que se te ocurra una feature, escribe primero en una frase qué historia de negocio cuenta ("cuánto silencio acumula un cliente activo"). Si no sabes formular la frase, probablemente tampoco sea buena feature.

Propón (sin código) tres features nuevas para el problema de demanda de MercaFresh (predecir cuántas unidades de cada producto se venderán mañana), inspiradas en las técnicas de esta lección. Para cada una, escribe la frase de negocio que cuenta.

Con la tabla rfm de la lección, crea la feature valor_en_riesgo = gasto_medio_pedido * pedidos_por_mes * ratio_inactividad y explica qué mide en términos de negocio. Después calcula su correlación de Spearman con recencia_dias y razona si esperabas ese signo.

Tienes 12 features numéricas y el objetivo churn. Escribe el código que: (a) elimine las de varianza < 0,01; (b) de las restantes, seleccione las 6 mejores con SelectKBest y f_classif; (c) imprima cuáles sobrevivieron. Indica sobre qué subconjunto de datos harías los fit.

Ejercicio 1

Respuestas orientativas (hay muchas válidas):

• ventas_media_ult_4_semanas (agregación temporal): "cuánto se ha vendido últimamente es el mejor punto de partida para mañana".
• es_visperas_festivo (componente de calendario, 03-03): "antes de un festivo, las compras de frescos se disparan".
• ratio_precio_vs_categoria (ratio): "un producto temporalmente más barato que su categoría roba ventas a sus sustitutos".

Lo importante: cada feature tiene fórmula clara y una historia de negocio en una frase.

Ejercicio 2

Qué mide: el gasto mensual habitual del cliente (ticket × frecuencia) ponderado por su grado de inactividad — es decir, cuántos euros al mes están en peligro de perderse. Un cliente valioso y muy inactivo puntúa alto; uno barato o plenamente activo, bajo. Es una feature de priorización: a quién llamar primero. La correlación con recencia_dias sale positiva, como cabía esperar: la recencia entra en el numerador de ratio_inactividad, así que a más días sin comprar, más valor en riesgo — Spearman (02-03) es la elección correcta porque la relación es monótona pero no lineal.

Ejercicio 3

Ejercicio de reflexión adicional: ¿por qué SelectKBest con todo el dataset contaminaría la evaluación? Porque puntúa cada feature según su relación con el objetivo; si ve las etiquetas de test, la selección resultante está optimizada también para test, y la evaluación posterior ya no mide generalización real.

Has cerrado el módulo con su lección más creativa: qué es la ingeniería de características y por qué fija el techo del modelo, cómo construir features de negocio con el marco RFM (recencia, frecuencia, valor), ratios y tendencias que capturan el enfriamiento de un cliente, interacciones y polinomios con mesura, y tres filtros de selección —varianza casi nula, correlación y SelectKBest— para quedarte con lo que aporta. Y sobre todo, has ensamblado el resultado de las seis lecciones en un producto concreto: el dataset final de churn de MercaFresh y su preprocesador ejecutable, con el checklist de nueve pasos como mapa de todo el módulo.

Ese dataset ya no es una tabla sucia exportada de un CRM: es una matriz numérica, completa, escalada y cargada de conocimiento de negocio, lista para entrenar. En el módulo 4 por fin llega el momento que llevamos tres módulos preparando: los algoritmos de aprendizaje supervisado, empezando por la regresión lineal — el modelo más simple y el mejor lugar para entender, de verdad, qué significa que una máquina aprenda de los datos de MercaFresh.