Comprensión y calidad de datos en Ciencia de Datos: exploración, limpieza y documentación

Proceso de comprensión de datos: del “qué hay” al “qué significa”

Antes de modelar o visualizar, necesitas entender la forma real de tus datos: su estructura, calidad, limitaciones y señales. Este proceso suele iterar entre perfilado (medir), validación (comparar contra reglas) y limpieza (intervenir con cuidado), dejando evidencia de cada decisión para que el análisis sea reproducible y auditable.

1) Perfilado inicial (profiling): distribuciones, nulos y duplicados

El perfilado es una radiografía cuantitativa del dataset. El objetivo no es “arreglar” todavía, sino detectar patrones y riesgos.

• Dimensiones y granularidad: número de filas/columnas, unidad de análisis (¿una fila es un cliente, una transacción, un día?), claves candidatas.
• Nulos y faltantes: porcentaje por columna, patrones (¿faltan juntos?), faltantes por segmento (por ejemplo, por país o canal).
• Duplicados: filas idénticas, duplicados por clave (mismo ID con múltiples registros), duplicados “casi iguales” (mismo cliente con nombre levemente distinto).
• Distribuciones: para numéricas (media, mediana, percentiles, asimetría), para categóricas (frecuencias, cardinalidad, categorías raras).

Ejemplo de tabla de perfilado (resumen por columna):

2) Consistencia de tipos (schema) y parsing

Un problema común es que el “tipo” real no coincide con el tipo esperado: fechas como texto, números con separadores, booleanos como “Sí/No”. La consistencia de tipos reduce errores silenciosos.

• Define un esquema esperado: nombre de columna, tipo (int/float/string/date/bool), si permite nulos, formato (por ejemplo, fecha ISO YYYY-MM-DD).
• Parseo explícito: convierte con reglas claras y registra fallos (cuántos valores no pudieron convertirse).
• Normaliza representaciones: “sí/Sí/TRUE/1” a booleano; moneda con símbolos; decimales con coma vs punto.

Ejemplo de regla práctica: “si una columna debería ser numérica, cualquier valor no parseable se convierte a nulo y se contabiliza; si el porcentaje supera un umbral (p.ej. 1–2%), se investiga la causa antes de continuar”.

Continúa en nuestra aplicación.

• Escuche el audio con la pantalla apagada.
• Obtenga un certificado al finalizar.
• ¡Más de 5000 cursos para que explores!

O continúa leyendo más abajo...

Descargar la aplicación

3) Rangos válidos y reglas de negocio

Los rangos válidos combinan lógica general (edad no negativa) y reglas del dominio (un descuento no puede exceder 100%). Definirlos temprano evita que outliers “falsos” contaminen análisis.

• Reglas generales: no negativos, límites físicos, fechas no futuras (según el caso), IDs con longitud fija.
• Reglas de negocio: estados permitidos, combinaciones válidas (si tipo_cliente=empresa, entonces dni puede ser nulo y rfc requerido).
• Integridad referencial: claves que deben existir en tablas maestras (catálogos).

Recomendación: expresa reglas como validaciones automáticas (tests) y genera un reporte de violaciones con ejemplos.

4) Detección de outliers y anomalías (sin asumir que son “errores”)

Un outlier es un valor extremo; una anomalía es un patrón inusual (por ejemplo, un pico de transacciones a las 3 a.m.). Pueden ser errores, fraude, eventos reales o cambios de proceso. Detectarlos no implica eliminarlos.

• Métodos univariados: IQR (rango intercuartílico), z-score robusto (mediana y MAD), percentiles (p1–p99).
• Métodos multivariados: distancia (Mahalanobis), modelos de aislamiento (Isolation Forest), clustering para detectar puntos raros.
• Series de tiempo: cambios de nivel, estacionalidad rota, picos; comparar contra ventanas históricas.

Ejemplo práctico (IQR): si Q1 y Q3 son percentiles 25 y 75, define límites [Q1 - 1.5*IQR, Q3 + 1.5*IQR]. Marca observaciones fuera como “candidatas a revisión”, no como “a borrar”.

Estrategias de limpieza: intervenir con intención

Limpiar es modificar datos para mejorar su utilidad analítica. La clave es elegir la estrategia según el tipo de problema y el impacto en la señal. Siempre que sea posible, conserva una copia del dato original (raw) y crea columnas derivadas (clean) para trazabilidad.

1) Faltantes: imputación vs eliminación

Primero, identifica el tipo de faltante: completamente al azar, al azar condicionado, o no al azar (cuando el hecho de faltar ya es información). Esto cambia la estrategia.

• Eliminación (listwise/pairwise): útil si el porcentaje es bajo y no introduce sesgo; riesgoso si elimina sistemáticamente un segmento.
• Imputación simple: media/mediana (numéricas), moda (categóricas). Rápida, pero puede subestimar variabilidad.
• Imputación por grupos: mediana por país/segmento; suele ser mejor que global si hay heterogeneidad.
• Imputación modelada: kNN, regresión, MICE; más precisa, pero requiere validación y puede filtrar información del target si se hace mal.
• Indicador de faltante: crear col_is_missing para preservar señal cuando “faltar” es informativo.

Guía rápida: si el faltante puede ser señal (por ejemplo, “ingreso no declarado”), evita imputar sin conservar un indicador o una categoría explícita (“No informado”).

2) Duplicados: eliminar, consolidar o versionar

• Duplicados exactos: suelen eliminarse (manteniendo conteo y criterio).
• Duplicados por clave: decide regla de consolidación: último registro por fecha, promedio, suma, o priorizar fuente más confiable.
• Eventos legítimos: múltiples transacciones del mismo cliente no son duplicados; el error es confundir granularidad.

Práctica recomendada: antes de deduplicar, define la clave y la granularidad esperada; luego, produce un reporte: cuántos registros afectados y ejemplos.

3) Corrección de valores: estandarización y mapeos

Cuando hay inconsistencias (por ejemplo, “MX”, “México”, “MEX”), la limpieza típica es estandarizar.

• Normalización de texto: trim, minúsculas, quitar acentos (si aplica), reemplazar caracteres.
• Diccionarios de mapeo: tabla de equivalencias mantenida (no “hardcode” disperso).
• Validación contra catálogos: si existe un catálogo oficial, úsalo como fuente de verdad.

Ejemplo: crear una tabla pais_alias con columnas valor_original y valor_estandar, y aplicar un join para transformar de forma auditable.

4) Outliers: winsorización, recorte o tratamiento robusto

Opciones comunes:

• Winsorización: capar valores a un percentil (p.ej. p1 y p99). Reduce impacto de extremos sin eliminar filas.
• Recorte (trimming): eliminar observaciones extremas. Riesgoso si los extremos son parte del fenómeno.
• Transformaciones: log, Box-Cox (si aplica) para reducir asimetría.
• Métricas/modelos robustos: usar mediana, MAE, Huber loss, árboles; a veces evita “limpiar” agresivamente.

Regla práctica: si los outliers representan casos reales de alto valor (p.ej. clientes premium), winsorizar puede destruir señal. En ese caso, segmenta (modelo por segmento) o usa métodos robustos.

Cuándo NO limpiar (o limpiar menos)

• Cuando el “error” es el evento: picos pueden ser campañas, incidentes o fraude (señal).
• Cuando el faltante es informativo: “no declarado”, “no aplica”, “no medido”.
• Cuando la limpieza introduce sesgo: eliminar filas de un grupo específico por mayor tasa de nulos.
• Cuando no hay criterio reproducible: “borrar a ojo” sin regla formal rompe trazabilidad.

En estos casos, prioriza: etiquetar (flags), segmentar, o modelar con técnicas robustas, manteniendo el dato original.

Documentación de calidad: diccionario, supuestos, transformaciones y versiones

La documentación convierte un dataset en un activo reutilizable. Debe responder: qué significa cada campo, cómo se calculó, qué se cambió y por qué.

1) Diccionario de datos (data dictionary)

Un diccionario mínimo por columna:

2) Supuestos explícitos

• Granularidad: “una fila = una transacción”.
• Ventana temporal: “datos del 2024-01-01 al 2024-12-31”.
• Reglas de negocio adoptadas: “descuento máximo 100%”.
• Tratamiento de faltantes: “ingreso nulo se mantiene y se crea indicador”.

3) Transformaciones y linaje (lineage)

Registra transformaciones como pasos ordenados, idealmente automatizados. Ejemplo de plantilla:

• Paso 01: parseo de fechas (fecha) con formato ISO; inválidos a nulo.
• Paso 02: estandarización de pais mediante tabla pais_alias.
• Paso 03: winsorización de ingreso_mensual a p1/p99; se conserva ingreso_mensual_raw.
• Paso 04: deduplicación por id_transaccion conservando el registro con mayor updated_at.

4) Versionado de datos y reproducibilidad

• Versiona datasets: etiqueta por fecha y hash (o ID de corrida) para poder reconstruir resultados.
• Versiona reglas: cambios en mapeos, umbrales y catálogos deben tener historial.
• Separa capas: raw (sin cambios), staging (tipos/parseo), clean (reglas), features (variables derivadas).

Esquema de EDA reproducible: preguntas guía, tablas y gráficos

Una EDA (Exploratory Data Analysis) reproducible es un guion ejecutable que siempre produce el mismo conjunto de salidas para un dataset versionado. Debe incluir preguntas guía, tablas resumen y gráficos estándar.

Preguntas guía (checklist)

• Estructura: ¿cuál es la unidad de análisis? ¿hay claves únicas?
• Calidad: ¿qué columnas tienen más nulos? ¿hay duplicados? ¿tipos inconsistentes?
• Distribución: ¿hay asimetría fuerte? ¿valores imposibles? ¿categorías raras?
• Relaciones: ¿qué variables se asocian? ¿hay colinealidad evidente?
• Segmentos: ¿cambia el comportamiento por país/canal/periodo?
• Tiempo (si aplica): ¿hay tendencia/estacionalidad? ¿rupturas?

Tablas resumen recomendadas

• Resumen numérico: count, mean, std, min, p1, p5, p50, p95, p99, max, % nulos.
• Frecuencias categóricas: top N categorías, % “otros”, cardinalidad, % nulos.
• Duplicados: número de filas duplicadas exactas y por clave; top claves con más repeticiones.
• Validaciones: conteo de violaciones por regla (rango, formato, catálogo).

Gráficos recomendados (por tipo de variable)

• Numéricas: histograma + KDE, boxplot (idealmente por segmento), ECDF (curva acumulada) para ver colas.
• Categóricas: barras ordenadas (top N), barras apiladas por segmento.
• Relaciones: scatter con transparencia (o hexbin), pairplot para pocas variables, heatmap de correlación (con cuidado en interpretaciones).
• Tiempo: línea por periodo, descomposición simple (tendencia/estacionalidad), heatmap calendario si aplica.

Consejo de reproducibilidad: fija parámetros (bins, percentiles, top N) y guárdalos en configuración para que el reporte sea comparable entre versiones.

Plantilla de EDA en pasos (ejecutable)

1. Definir esquema esperado (tipos, nulos permitidos, rangos, catálogos).

2. Cargar datos y registrar versión (ruta, fecha, hash/ID).

3. Perfilado automático: tabla por columna + reporte de nulos/duplicados.

4. Validaciones: reglas de rango, formato, integridad referencial; exportar violaciones.

5. Exploración visual estándar: set fijo de gráficos por tipo.

6. Hallazgos y preguntas nuevas: lista priorizada (impacto/urgencia).

7. Propuesta de limpieza: opciones y riesgos; elegir estrategia.

8. Aplicar limpieza en capa “clean” y re-ejecutar perfilado/validaciones para medir mejora.

Registro de decisiones (Decision Log) para trazabilidad

Un registro de decisiones evita que la limpieza sea una “caja negra”. Cada intervención debe poder responder: qué se hizo, por qué, con qué regla, cuándo y qué impacto tuvo.

Formato sugerido de Decision Log

Buenas prácticas del registro

• Identificadores estables: cada decisión con ID único.
• Vincular evidencia: tablas/gráficos del EDA, consultas, tickets.
• Medir antes/después: % nulos, violaciones, cardinalidad, métricas de distribución.
• Separar “corrección” de “suposición”: correcciones basadas en reglas vs imputaciones basadas en estimación.

Mini-caso práctico: aplicar el proceso en un dataset de ventas

Supón un dataset con columnas: id_transaccion, fecha, monto, pais, canal, id_cliente.

Paso a paso

• Perfilado: detectas 0.8% nulos en pais, 12% nulos en canal, y 1.5% duplicados por id_transaccion.
• Tipos: fecha viene como texto con dos formatos; 0.3% no parsea.
• Rangos: monto tiene valores negativos (posibles devoluciones) y valores 999999 (posible código).
• Outliers: cola derecha muy larga; por país hay diferencias grandes.
• Decisiones: (1) mantener montos negativos si representan devoluciones y crear flag es_devolucion; (2) tratar 999999 como valor inválido y convertir a nulo (si se confirma que es código); (3) imputar canal como “Desconocido” + indicador de faltante; (4) deduplicar por id_transaccion conservando el registro con updated_at más reciente (si existe) o el de mayor completitud.
• Documentación: actualizar diccionario, registrar DL con umbrales, y versionar el dataset limpio.

Este flujo te permite mejorar calidad sin borrar señal, y deja un rastro claro de cómo se llegó a cada dataset y resultado.