Cómo medir la calidad de un conjunto de datos

Introducción

La completitud, la validez, la unicidad, la consistencia y la actualidad son dimensiones que ayudan a responder una pregunta decisiva: ¿hasta qué punto podemos confiar en un conjunto de datos para realizar el análisis previsto?

Un archivo puede abrirse sin errores, contener miles de filas y producir gráficos aparentemente convincentes, pero seguir siendo inadecuado. Quizá le falten fechas de cierre a las incidencias resueltas, los identificadores estén repetidos, se mezclen distintas unidades de medida o solo se hayan recogido datos de una parte de la población que interesa estudiar. Tener datos no equivale a disponer de evidencia suficiente para decidir.

Medir la calidad de un dataset consiste en convertir esas dudas en comprobaciones explícitas, cifras interpretables y criterios de aceptación. El objetivo no es declarar que los datos son «buenos» o «malos» de forma abstracta, sino determinar qué se puede hacer con ellos, con qué limitaciones y qué riesgos se asumen.

Esta guía desarrolla un procedimiento aplicable a ficheros CSV, hojas de cálculo, bases de datos y conjuntos de datos utilizados en proyectos de Ciencia de Datos. Incluye fórmulas, criterios para elegir denominadores, consultas SQL, un ejemplo numérico y una forma de comunicar los resultados sin esconder los problemas detrás de una nota global.

Índice de contenidos

Qué significa medir la calidad de un dataset

La calidad de los datos es su grado de adecuación a un uso concreto. Un conjunto con códigos postales incompletos podría servir para estudiar tendencias generales por provincia, pero no para calcular rutas de reparto a direcciones precisas. Un histórico de ventas con algunos importes pendientes de conciliación puede ser útil para una exploración preliminar y, al mismo tiempo, resultar insuficiente para un informe financiero definitivo.

Por eso conviene distinguir tres actividades que a menudo se confunden:

  • Detectar problemas: identificar campos vacíos, valores imposibles, contradicciones, duplicados y otras situaciones que necesitan revisión.
  • Medir la calidad: cuantificar esos problemas, establecer su alcance, comparar resultados y estimar su impacto sobre un uso determinado.
  • Corregir los datos: investigar causas, recuperar información, aplicar transformaciones autorizadas y prevenir recurrencias.

Este artículo se centra en la segunda actividad. Para profundizar en la identificación de fallos concretos puede consultarse cómo detectar errores frecuentes en los datos empresariales; si el objetivo es preparar un proceso automático después del diagnóstico, resulta útil cómo mejorar la calidad de los datos antes de automatizar procesos.

Una evaluación rigurosa debe responder al menos a cuatro cuestiones: qué se ha medido, cómo se ha medido, contra qué criterio se ha comparado y qué decisión permite tomar. Un porcentaje sin esas cuatro piezas es difícil de interpretar y todavía más difícil de reproducir.

Definir el uso, la población y la unidad de análisis antes de medir

Empezar por una decisión, no por una lista genérica de controles

Supongamos que una empresa quiere analizar el tiempo medio que tarda en resolver incidencias. Las variables críticas serán el identificador de la incidencia, su estado, la fecha de apertura y la de cierre, además de la definición de qué significa «resuelta». Que falte el teléfono de contacto puede ser irrelevante para ese cálculo, mientras que una fecha de cierre incorrecta puede invalidarlo.

La calidad no debe evaluarse otorgando el mismo peso a todos los campos por costumbre. Es preferible partir de una pregunta concreta: «¿Con estos registros puedo calcular el tiempo de resolución de las incidencias cerradas durante el trimestre?».

Precisar qué representa cada fila

Antes de contar duplicados hay que definir la granularidad: una fila puede representar una incidencia, una intervención sobre ella, una actualización de estado o una fotografía diaria. Dos filas con el mismo identificador de incidencia serían sospechosas en una tabla que promete una fila por incidencia, pero podrían ser legítimas en un histórico de cambios.

Conviene documentar, por escrito y de forma breve:

  • Objeto: qué entidad o evento describe cada registro.
  • Población: qué unidades deberían estar presentes, incluso aquellas que no llegaron al dataset.
  • Periodo: a qué fechas corresponde la información y cuándo se obtuvo la extracción.
  • Fuentes: de qué aplicaciones, documentos o sistemas procede.
  • Identidad: qué campo o combinación de campos identifica un registro.
  • Uso permitido: análisis, informe, comparación, entrenamiento de un modelo o decisión operativa.

Conservar una fotografía de los datos examinados

Una evaluación necesita una referencia estable. Si hoy se mide un CSV y mañana se repite la comprobación sobre un archivo actualizado sin conservar la primera versión, es imposible saber si una variación se debe a cambios en la información o en las reglas de medición.

La ficha de evaluación debería registrar la fecha de extracción, el nombre o identificador de la versión, el número de filas, el esquema de columnas y la versión de las reglas empleadas. Para organizar este contexto, puede servir la metodología descrita en cómo documentar correctamente los datos de una empresa.

Dimensiones de calidad: qué medir y qué significa cada resultado

No existe un único indicador que describa por sí solo toda la calidad de un dataset. Es más útil construir un conjunto reducido de métricas que revelen defectos distintos. Las seis dimensiones siguientes cubren buena parte de las evaluaciones iniciales, siempre que se adapten al tipo de información.

Dimensiones de calidad y forma habitual de medirlas
Dimensión Pregunta Ejemplo de métrica
Completitud ¿Están presentes los datos que se necesitan? Valores obligatorios informados / valores obligatorios esperados × 100
Validez ¿Los valores cumplen el tipo, formato, dominio y reglas definidos? Valores válidos / valores comprobados aplicables × 100
Unicidad ¿Existen registros de más para una identidad que debería ser única? (Filas totales − filas duplicadas excedentes) / filas totales × 100
Consistencia ¿Los campos y fuentes se contradicen? Casos que cumplen una regla de coherencia / casos aplicables × 100
Exactitud ¿El dato coincide con un hecho o referencia suficientemente fiable? Valores correctos verificados / valores contrastados × 100
Actualidad ¿La información es suficientemente reciente para su uso? Registros dentro del plazo de actualización / registros sujetos a ese plazo × 100

Las fórmulas son patrones de trabajo, no definiciones universales. Por ejemplo, una tasa de unicidad calculada sobre identificadores de cliente no sirve para valorar una tabla de movimientos en la que el mismo cliente aparece muchas veces. Del mismo modo, la completitud de un campo opcional no debe compararse sin más con la de uno obligatorio.

Completitud: cuánto falta y dónde falta

Si 1.200 incidencias deberían tener un identificador de cliente y solo 1.140 lo tienen, la completitud de ese campo es 1.140 / 1.200 × 100 = 95 %. Esa cifra permite dimensionar el problema, pero no revela por qué faltan los 60 valores ni si se concentran en un departamento o periodo.

Resulta conveniente calcular, además, la proporción de filas completas en el subconjunto de campos imprescindibles. No es lo mismo que contar celdas rellenadas: una tabla podría tener un 99 % de celdas informadas y, sin embargo, carecer de un identificador esencial en demasiados registros.

Validez: cumplir un contrato verificable

Un dato válido satisface una regla declarada: una fecha es interpretable, un importe usa una unidad conocida, una categoría pertenece al catálogo aprobado y un porcentaje cae dentro del intervalo que corresponde a su significado. Un valor como 31/02/2026 no representa una fecha del calendario; un estado Finalizado puede ser inválido si el catálogo solo admite Abierta y Cerrada.

Validez no significa necesariamente verdad. Una fecha perfectamente formateada puede ser incorrecta respecto al suceso real. Asimismo, un identificador de cliente puede cumplir el formato y no existir en la tabla de clientes: en ese caso también interesa medir la integridad referencial.

Unicidad: controlar duplicados según la unidad de análisis

Cuando una tabla representa una incidencia por fila, las repeticiones del identificador requieren investigación. Para medirlas conviene separar grupos duplicados de filas excedentes. Si un identificador aparece tres veces donde debería aparecer una, hay un grupo duplicado y dos filas excedentes.

Esta distinción impide inflar o reducir el problema al comparar informes. También evita confundir los duplicados exactos con entidades repetidas que tienen atributos ligeramente diferentes.

Consistencia: comprobar relaciones entre campos y sistemas

Las reglas de consistencia expresan relaciones esperadas. Por ejemplo, si una incidencia está cerrada debería tener una fecha de cierre; esa fecha no debería preceder a la apertura; y el estado registrado en un informe consolidado debería corresponder al estado de referencia en el sistema de origen, según el momento de comparación definido.

Es útil distinguir la coherencia interna de la conciliación entre fuentes. Dos sistemas pueden discrepar legítimamente durante un periodo de sincronización, por lo que la regla tiene que especificar el retraso admisible.

Exactitud: contrastar con evidencia independiente

Un dataset puede superar todas las validaciones automáticas y seguir reflejando información falsa. Para evaluar exactitud hay que recurrir, cuando exista, a una fuente autorizada, documentos de soporte o una revisión controlada de casos. Por ejemplo, un importe puede tener formato correcto y estar dentro de un rango razonable, pero diferir de la factura original.

La exactitud suele necesitar muestreo o conciliación. No debe declararse como 100 % por el simple hecho de que no se hayan detectado anomalías.

Actualidad: medir contra el ritmo real del proceso

La antigüedad de un dato no indica por sí sola que sea inservible. Una fecha de nacimiento correcta no necesita actualizarse diariamente; el estado de una incidencia abierta quizá sí deba revisarse en las últimas 48 horas. Por tanto, la métrica debe definir un plazo por clase de información y evaluar únicamente los registros sujetos a ese plazo.

Cuando resulta útil, pueden medirse también la latencia de disponibilidad —tiempo entre el suceso y su llegada al sistema analítico— y los percentiles de esa latencia. Así se evita que un promedio aceptable oculte retrasos extremos.

Cómo calcular porcentajes de calidad que no resulten engañosos

El numerador identifica los casos que cumplen una condición. El denominador define sobre qué población se hace la afirmación. Elegir mal el denominador puede convertir un informe técnicamente calculado en una conclusión equivocada.

Registrar la condición, el universo y las exclusiones

Para cada métrica conviene escribir una ficha con el siguiente patrón:

  • Nombre: completitud de cliente_id.
  • Condición de éxito: identificador informado y no equivalente a un valor vacío.
  • Universo: todas las incidencias incluidas en la extracción evaluada.
  • Exclusiones: ninguna; el campo es obligatorio para todas.
  • Cálculo: registros con cliente informado / registros del universo × 100.
  • Unidad: porcentaje, acompañado de ambos conteos.

Si el campo fuera obligatorio solo para incidencias facturables, el universo ya no serían todas las incidencias. La diferencia debe aparecer en el informe, no quedar escondida en el código.

Separar valores ausentes de valores incorrectos

Supongamos que hay 1.200 filas, 1.140 identificadores de cliente informados y 1.110 que, además, existen en el catálogo de clientes. Podemos comunicar dos medidas diferentes:

  • Completitud: 1.140 / 1.200 = 95 %.
  • Integridad referencial entre los valores informados: 1.110 / 1.140 ≈ 97,37 %.

También podríamos calcular la proporción de todas las filas con un cliente informado y reconocido: 1.110 / 1.200 = 92,5 %. Esta tercera cifra responde a otra pregunta. Las tres son correctas si se identifican con precisión y no se presentan como si fueran intercambiables.

No sumar defectos que pueden coincidir

Una incidencia puede tener a la vez un identificador duplicado, una fecha incoherente y un cliente desconocido. Sumar las filas afectadas por cada control contaría varias veces el mismo registro. Para saber cuántas filas incumplen al menos una regla hay que calcular la unión de los casos fallidos, no sumar los totales de cada regla.

De igual forma, no debe promediarse sin más el porcentaje de calidad de dos conjuntos de 50 y 50.000 registros. Si realmente procede una agregación, hay que justificarla y utilizar los conteos y universos pertinentes.

Distinguir lo no aplicable de lo desconocido

Una fecha de cierre vacía puede ser perfectamente válida para una incidencia abierta. La misma ausencia es un defecto para una incidencia declarada cerrada. Mezclar ambos casos en un porcentaje global de «fechas de cierre informadas» penalizaría incorrectamente al dataset.

En una evaluación madura se registran por separado los casos válidos, inválidos, ausentes, no aplicables y no evaluables. Los no evaluables —por falta de fuente de contraste o de regla clara— no deberían convertirse automáticamente en correctos.

Cómo medir la calidad de un conjunto de datos con herramientas habituales

Primero, elaborar un perfil mínimo de la tabla

Antes de aplicar reglas complejas, conviene obtener una fotografía cuantitativa: número de registros, columnas, tipos detectados, valores nulos, valores distintos, máximos, mínimos, rangos temporales y frecuencias de categorías. Esta inspección preliminar permite descubrir errores de esquema e inconsistencias de codificación.

Para cada columna crítica puede prepararse una tabla de control con estos campos: nombre, significado, tipo esperado, obligatoriedad, regla de validación, cantidad evaluada, cantidad conforme, cantidad defectuosa y responsable de interpretación.

Una primera revisión con Excel

En una hoja de cálculo estructurada pueden utilizarse filtros, tablas dinámicas, formato condicional y funciones de conteo. Por ejemplo, si los identificadores de cliente están en B2:B1201, =CONTAR.BLANCO(B2:B1201) ayuda a contar celdas vacías; para revisar repeticiones de un identificador en una fila, =CONTAR.SI($A$2:$A$1201;A2) permite conocer cuántas veces aparece.

Estas comprobaciones requieren precauciones: una celda aparentemente vacía puede contener espacios o una fórmula que devuelve una cadena vacía; una misma fecha puede estar almacenada como texto o como valor de fecha; y los filtros visuales no sustituyen la conservación de resultados y reglas. La solución no es confiar en el color de una celda, sino guardar los conteos y sus criterios.

Un ejemplo reproducible mediante SQL

Si las incidencias se almacenan en una tabla llamada incidencias y cliente_id es un campo que admite valores nulos, la consulta siguiente permite obtener la completitud básica del identificador de cliente:

SELECT
    COUNT(*) AS total_registros,
    COUNT(cliente_id) AS con_cliente,
    COUNT(*) - COUNT(cliente_id) AS sin_cliente,
    ROUND(
        100.0 * COUNT(cliente_id) / NULLIF(COUNT(*), 0),
        2
    ) AS completitud_pct
FROM incidencias;

La consulta considera informado cualquier valor no nulo. Si el campo es de texto y puede contener cadenas vacías o espacios, habrá que tratarlas expresamente como ausencias. El uso de NULLIF evita dividir entre cero en una tabla vacía, aunque ese caso debe notificarse como ausencia de población y no interpretarse como calidad igual a cero.

Para detectar identificadores repetidos en una tabla que debe contener una fila por incidencia, puede utilizarse una segunda consulta:

SELECT
    id_incidencia,
    COUNT(*) AS apariciones,
    COUNT(*) - 1 AS filas_excedentes
FROM incidencias
WHERE id_incidencia IS NOT NULL
GROUP BY id_incidencia
HAVING COUNT(*) > 1
ORDER BY apariciones DESC, id_incidencia;

La suma de filas_excedentes cuantifica registros sobrantes bajo la regla de unicidad adoptada. Los identificadores nulos se deben medir en un control separado; filtrarlos para comprobar duplicados no significa que sean aceptables.

Las consultas son ejemplos de diagnóstico, no órdenes de eliminación. No se deben borrar registros hasta comprobar si representan duplicaciones reales o eventos legítimos. Si el dataset proviene de uniones entre tablas, también conviene verificar que la propia consulta de integración no haya multiplicado las filas.

Cuándo conviene utilizar Python

Python puede resultar útil cuando se comparan varios archivos, se necesitan reglas condicionales complejas o se quiere repetir la evaluación con cada nueva extracción. Bibliotecas de análisis tabular permiten generar resúmenes de nulos, categorías, fechas y cruces entre columnas. La aportación principal no está en elegir una biblioteca concreta, sino en convertir las reglas en pruebas reproducibles.

Una salida automatizada útil debe contener, para cada regla, el identificador de la evaluación, la fecha, el universo, los registros conformes, los no conformes, los excluidos y una muestra localizable de excepciones. El reporte agregado no debería contener datos personales innecesarios ni exponer registros individuales a personas que no deban consultarlos.

Distribuciones, cobertura y cambios que las tasas de errores no muestran

Los registros que faltan por completo también importan

Las tasas calculadas dentro de un CSV solo describen las filas que llegaron al CSV. Si una sucursal no exportó sus operaciones, el conjunto puede tener el 100 % de sus campos obligatorios informados y seguir siendo incompleto respecto al universo real.

Para evaluar la cobertura hace falta un recuento independiente: número de expedientes esperados, transacciones registradas en origen, establecimientos activos, periodos incluidos o cualquier referencia que permita estimar qué unidades deberían existir.

Por ejemplo, si se esperan 1.250 incidencias y el dataset contiene 1.200, la cobertura aparente es del 96 %. Pero antes de aceptarla es necesario comprobar si hay duplicados y si ambos recuentos utilizan el mismo periodo y las mismas reglas de inclusión. La cobertura del universo y la completitud de campos son dos medidas diferentes.

Examinar grupos, periodos y valores extremos

Un porcentaje global puede ocultar un problema grave concentrado. Una completitud del 95 % parece aceptable a primera vista, pero quizá sea del 99 % en la oficina principal y del 55 % en una oficina pequeña. La segmentación debe hacerse por variables que tengan sentido: fecha, fuente, delegación, tipo de operación o proceso de captura.

Además de los nulos, resulta útil comparar distribuciones: proporción de categorías, medianas, percentiles, rangos, volumen diario y tasas por grupo. Un aumento brusco de valores cero puede indicar un fallo de captura, una modificación del proceso o un cambio real. La métrica señala dónde investigar; no demuestra por sí sola que exista un error.

Distinguir deterioro de calidad y cambio legítimo de distribución

En proyectos de Ciencia de Datos, la composición del dataset influye en su utilidad. Si el conjunto histórico recoge sobre todo solicitudes de clientes antiguos y el uso futuro incluye muchos clientes nuevos, puede faltar representatividad aunque los campos sean válidos.

La comparación de distribuciones y la cobertura de grupos relevantes ayudan a descubrir este riesgo. No conviene confundir una variación estadística con una falta de calidad: un aumento verdadero de la demanda también altera una serie temporal. Para interpretarlo se necesita contexto de negocio, trazabilidad de cambios y, cuando proceda, contrastes estadísticos apropiados.

Cómo evaluar la exactitud cuando no se puede comprobar todo el dataset

La exactitud es una de las dimensiones más difíciles de automatizar porque requiere saber qué ocurrió realmente. Una regla puede comprobar que el importe es positivo, pero no demostrar que coincide con una operación concreta. Por eso es fundamental diferenciar validación sintáctica de verificación contra evidencia.

Elegir una fuente de referencia con criterio

Una referencia adecuada puede ser el registro original de una operación, un documento firmado, una medición contrastada o el sistema designado como maestro para el dato. La elección debe justificarse: comparar dos copias de la misma información no proporciona una verificación independiente de su exactitud.

En las conciliaciones también hay que especificar la tolerancia. Dos importes pueden diferir por redondeos admisibles, mientras que una discrepancia mínima en un identificador fiscal podría exigir revisión. La tolerancia pertenece a la regla de calidad y debe quedar documentada.

Revisar muestras sin confundir muestra con totalidad

Cuando revisar todas las filas resulta inviable, puede seleccionarse una muestra aleatoria y, si conviene, estratificarla por tipo de operación, fecha o fuente. En cada caso se verifica el valor frente a la referencia prevista y se registra la conclusión.

Si 94 de 100 casos revisados son correctos, puede comunicarse una exactitud observada en la muestra del 94 %. No significa que exactamente el 94 % de todos los registros sean correctos: existe incertidumbre de muestreo, y esta será mayor si la muestra es pequeña. Si además la muestra se eligió solo entre casos fáciles de comprobar, puede estar sesgada.

Para decisiones importantes, el informe debe indicar tamaño de la muestra, método de selección, grupos representados y, cuando sea pertinente, un intervalo de confianza calculado con el diseño de muestreo utilizado. Cuando no exista una referencia fiable, la dimensión puede figurar como no verificada en lugar de recibir una puntuación inventada.

Definir umbrales útiles sin convertir la calidad en una nota arbitraria

Obtener porcentajes es solo la mitad del trabajo. La otra mitad consiste en decidir qué significan para el análisis. No existe un umbral universal que convierta el 95 % o el 99 % en una garantía automática de calidad.

Establecer objetivos por campo, uso y consecuencia

Los criterios de aceptación deberían tener en cuenta la importancia del campo, el impacto de un fallo, la posibilidad de detectar el error después y el coste de una decisión incorrecta. Para una segmentación exploratoria puede admitirse cierta incompletitud. Para calcular pagos o asignar actuaciones críticas puede exigirse una validación mucho más estricta en variables específicas.

La recomendación práctica es definir de antemano, para cada regla crítica:

  • Un objetivo cuantitativo y el universo al que se aplica.
  • Un nivel de aviso que obligue a investigar el deterioro.
  • Una condición de bloqueo si el incumplimiento impide utilizar el dataset con seguridad.
  • Una persona o función responsable de aceptar una excepción y dejar constancia de ella.

Como ejemplo ilustrativo, una organización podría exigir que las incidencias analizadas no tengan identificadores duplicados, que las fechas de apertura sean válidas en todos los registros usados para medir tiempos y que al menos el 95 % de los registros sujetos a revisión se hayan actualizado dentro del plazo. Estos porcentajes no son estándares generales: solo expresan un posible acuerdo para un caso específico.

Evitar que una puntuación compuesta esconda defectos críticos

La media simple de completitud, validez, unicidad y actualidad puede producir una calificación atractiva aunque un único campo esencial esté gravemente deteriorado. Si se utiliza una puntuación global con pesos, estos deben justificarse, conservarse y presentarse junto con las métricas individuales.

Una alternativa más transparente es combinar un cuadro de métricas por dimensión con reglas de aceptación: un conjunto es utilizable para un análisis concreto solo cuando supera los controles críticos de ese análisis; los problemas secundarios se describen como limitaciones. Es más informativo que decir «calidad: 92 puntos» sin explicar cómo se obtuvo ese número.

Clasificar el resultado por posibilidad de uso

Una conclusión operativa puede distinguir entre:

  • Apto: supera los controles definidos para el uso previsto.
  • Apto con restricciones: permite determinados análisis si se excluyen o identifican los casos problemáticos y se documentan los sesgos posibles.
  • No apto por ahora: presenta fallos críticos que pueden invalidar los resultados.
  • Calidad no evaluable: falta evidencia suficiente para afirmar que cumple uno o varios criterios esenciales.

Esta clasificación obliga a relacionar la medición con una decisión y facilita comunicar por qué el mismo dataset puede ser apto para un informe descriptivo y no apto para entrenar un modelo predictivo.

Caso práctico: evaluar 1.200 registros de incidencias

Imaginemos una extracción de 1.200 filas procedentes de un sistema de gestión de incidencias. La tabla debería contener una fila por incidencia e incluye identificador, cliente, estado, fecha de apertura, fecha de cierre y fecha de última actualización. Hay 480 filas marcadas como cerradas y 720 como abiertas. Los números siguientes son ficticios y sirven para mostrar el cálculo y la interpretación.

Resultados de la primera evaluación

Ejemplo de cuadro de calidad con conteos y denominadores explícitos
Control Resultado observado Indicador
Cliente informado 1.140 de 1.200 filas 95,00 % de completitud
Cliente reconocido en el catálogo 1.110 de 1.140 valores informados 97,37 % de integridad referencial
Unicidad del identificador de incidencia 18 filas duplicadas excedentes de 1.200 98,50 % de unicidad bajo esta regla
Última actualización no anterior a la apertura 1.174 de 1.200 filas cumplen la regla 97,83 % de consistencia temporal
Fecha de cierre en incidencias cerradas 458 de 480 filas cerradas 95,42 % de completitud condicional
Actualización de incidencias abiertas dentro de 48 horas 612 de 720 filas abiertas 85,00 % de actualidad
Exactitud contrastada en una muestra 94 de 100 casos revisados 94,00 % observado en la muestra

Los resultados muestran varios problemas diferentes. El 95 % de completitud del cliente no garantiza su existencia en el catálogo: 30 de los 1.140 identificadores informados no encuentran correspondencia. Además, el 85 % de actualidad de las incidencias abiertas apunta a un retraso de actualización que puede afectar al seguimiento operativo, incluso aunque los demás campos sean correctos.

Comprobar el conjunto de reglas simultáneamente

Supongamos que, al aplicar de forma conjunta los controles indispensables para un informe sobre el estado y tiempos de las incidencias, 1.056 de las 1.200 filas superan todas las reglas exigidas. La proporción de registros inicialmente aptos para ese informe sería:

1.056 / 1.200 × 100 = 88 %.

El 88 % no es una media de los porcentajes anteriores. Representa las filas que cumplen simultáneamente el conjunto de condiciones; los defectos que coinciden en una misma fila se cuentan una sola vez. Tampoco demuestra que el 88 % restante esté libre de errores no detectados.

Para calcular correctamente tiempos de resolución sería preciso definir primero la población pertinente —por ejemplo, incidencias cerradas en el periodo— y repetir el control sobre esa población concreta. No sería riguroso utilizar el 88 % como si fuera automáticamente la proporción de incidencias cerradas válidas para calcular duraciones.

Pasar del diagnóstico a una decisión defendible

Un informe de evaluación podría concluir lo siguiente:

  • El conjunto sirve para una exploración descriptiva preliminar si se indican sus limitaciones.
  • El cálculo de tiempos de resolución debe restringirse a registros cerrados cuyas fechas cumplan las reglas y debe investigarse si las exclusiones introducen sesgos.
  • La cantidad de identificadores repetidos requiere comprobar el origen y la granularidad antes de contar incidencias únicas.
  • El seguimiento de incidencias abiertas necesita revisar por qué parte de los estados supera las 48 horas sin actualización.
  • La exactitud general no puede afirmarse con precisión únicamente a partir de 100 casos; la revisión muestral proporciona evidencia parcial.

La ventaja de este enfoque es que transforma una etiqueta vaga —«los datos parecen bastante buenos»— en decisiones explícitas. Si se desea preparar el análisis posterior, puede ser útil estudiar cómo preparar los datos para proyectos de inteligencia artificial, donde aparecen requisitos adicionales de representatividad y separación temporal que van más allá de una tabla técnicamente válida.

Convertir la medición en un control periódico

Repetir las mismas reglas sobre cortes comparables

Una evaluación aislada describe un momento. Para controlar la calidad a lo largo del tiempo hay que repetir reglas estables, identificar la versión del dataset y conservar los resultados. Un informe semanal puede revelar, por ejemplo, que la completitud de clientes cae del 98 % al 93 % después de modificar un formulario de captura.

Las comparaciones deben respetar la misma población y el mismo significado. Si la primera semana se incluyen solo incidencias cerradas y la siguiente todas las incidencias, la diferencia puede ser consecuencia del cambio de universo y no de un deterioro real.

Guardar tanto métricas como evidencia de excepciones

Una ficha o registro de mediciones puede contener:

  • Identificador del dataset y de la extracción.
  • Fecha de evaluación y periodo al que corresponden los datos.
  • Reglas aplicadas y versión de cada regla.
  • Numerador, denominador, porcentaje y exclusiones.
  • Umbral, resultado de aceptación y responsable.
  • Referencia a la lista de casos no conformes, almacenada con acceso limitado.
  • Explicación de los cambios importantes respecto a la medición anterior.

Con esta estructura se puede repetir el diagnóstico y saber si una supuesta mejora es real o procede de modificar las reglas. Cuando los datos llegan por procesos programados, los controles pueden integrarse en una cadena de procesamiento; crear pipelines sencillos de datos empresariales ofrece el contexto para organizar ese flujo sin perder trazabilidad.

Definir alertas proporcionadas a la consecuencia

Las alertas más útiles no son las que se disparan por cualquier fluctuación, sino las que identifican incumplimientos relevantes: aparición de identificadores repetidos donde la unicidad es obligatoria, ausencia repentina de una fuente, aumento sostenido de registros sin fecha o desviación importante respecto al volumen esperado.

Conviene distinguir un cambio del proceso de captura, un cambio del propio dato y un cambio de la definición de la métrica. De lo contrario, una gráfica descendente puede provocar correcciones innecesarias o esconder un problema real.

Errores frecuentes al medir la calidad de los datos

Medir solo los campos vacíos

La completitud es fácil de calcular y por eso suele dominar los informes. Pero una tabla sin nulos puede contener identificadores falsos, fechas imposibles o filas duplicadas. El conjunto de controles debe cubrir las dimensiones pertinentes para su uso.

Confundir formato correcto con dato correcto

Un correo electrónico con estructura válida no demuestra que exista o corresponda a la persona adecuada. Un importe numérico no demuestra que coincida con la operación real. Las validaciones automáticas son necesarias, pero no sustituyen el contraste de exactitud cuando este importa.

Utilizar el mismo umbral para todos los campos

Exigir un 99 % a todas las columnas no tiene sentido si unas son optativas y otras críticas. La exigencia debe relacionarse con el impacto del fallo y las decisiones que dependen de cada variable.

Evaluar filas existentes e ignorar las que nunca llegaron

Un conjunto puede estar impecablemente formateado y omitir meses completos, sucursales o categorías enteras. La cobertura requiere información externa sobre el universo esperado.

Promediar métricas sin explicar las reglas

Una media de porcentajes procedentes de universos distintos no representa automáticamente la calidad de todas las filas. Los indicadores deben presentarse por separado y, si se crea una medida compuesta, su construcción debe justificarse.

Tratar todos los valores atípicos como errores

Una venta excepcional, un plazo muy largo o una categoría poco frecuente pueden representar hechos reales. Antes de considerar una anomalía como incumplimiento, hay que comprobar qué regla se ha vulnerado. La distribución estadística no sustituye la evidencia.

Modificar datos mientras se intenta medir su estado inicial

Si durante la evaluación se eliminan duplicados o se completan valores sin guardar la extracción original, se pierde la línea de partida. La medición inicial y cualquier versión transformada deben poder distinguirse y compararse.

Declarar aptitud general a partir de una sola necesidad

Superar los controles necesarios para construir un resumen comercial no convierte automáticamente el dataset en apto para elaborar estados financieros, realizar inferencias causales o entrenar un modelo. Cada uso puede necesitar controles adicionales, poblaciones distintas y evidencias independientes.

Método de trabajo para una primera evaluación fiable

Una microempresa o un equipo pequeño no necesita empezar comprando una plataforma compleja de calidad de datos. Puede obtener un diagnóstico útil con una extracción estable, una hoja de control y unas pocas consultas bien diseñadas.

  1. Definir el análisis previsto. Escribir la pregunta que se pretende responder y la decisión que dependerá del resultado.
  2. Fijar el universo y la granularidad. Precisar periodo, fuentes, entidad representada por cada fila y registros esperados.
  3. Conservar la versión original. Registrar fecha de corte, volumen, columnas y referencia de la extracción.
  4. Seleccionar variables críticas. Distinguir campos obligatorios, condicionales, auxiliares y no relevantes para ese uso.
  5. Definir reglas verificables. Especificar éxito, fallo, no aplicabilidad, casos no evaluables y denominador de cada prueba.
  6. Calcular conteos y porcentajes. Medir al menos completitud, validez, unicidad y consistencia cuando resulten pertinentes; añadir exactitud, actualidad y cobertura cuando el uso lo exija.
  7. Investigar grupos y excepciones. Revisar los defectos por origen, fecha o categoría, y comprobar posibles sesgos.
  8. Comparar con criterios previos. Identificar reglas críticas que se incumplen y decisiones afectadas.
  9. Emitir una conclusión delimitada. Declarar si el conjunto es apto, apto con restricciones, no apto o no evaluable para el objetivo concreto.
  10. Preparar la siguiente evaluación. Guardar reglas, métricas, resultados y responsables para repetir el proceso.

El resultado mínimo que debería conservarse es una matriz de calidad en la que cada fila sea una regla y sus columnas incluyan descripción, campo, población, numerador, denominador, porcentaje, umbral, estado y observaciones. No hace falta que sea sofisticada; sí tiene que ser comprensible para alguien que no participó en la primera revisión.

Lista de comprobación antes de utilizar el dataset

  • ¿Se conoce qué representa cada registro y qué población debería estar incluida?
  • ¿Se han identificado los campos imprescindibles para la pregunta analítica?
  • ¿Las tasas de calidad muestran sus conteos y sus denominadores?
  • ¿Los duplicados se han interpretado conforme a la unidad de análisis?
  • ¿Se distingue entre valor ausente, inválido, no aplicable y no verificable?
  • ¿Se ha comprobado la cobertura de fuentes, periodos y grupos relevantes?
  • ¿Se han revisado posibles errores que no pueden detectarse solo con reglas de formato?
  • ¿Los umbrales se han definido conforme al riesgo y al uso previsto?
  • ¿Se pueden localizar las excepciones sin exponer innecesariamente datos sensibles?
  • ¿La conclusión deja claras las limitaciones y las condiciones de uso?

Preguntas frecuentes sobre la medición de calidad de datasets

¿Qué métricas conviene calcular primero para un conjunto de datos pequeño?

Es razonable empezar por el número de filas, la completitud de campos críticos, la validez de sus valores, la unicidad de la clave y las reglas de coherencia necesarias para el análisis. Después se añaden controles de actualidad, cobertura y exactitud según el riesgo. El objetivo es medir lo relevante, no acumular decenas de indicadores sin uso.

¿Un dataset con un 95 % de completitud puede considerarse de buena calidad?

Depende de qué campo falta, en qué registros, para qué se utilizarán los datos y si el porcentaje describe el conjunto completo o solo una parte. Un 95 % puede ser suficiente para una exploración general e insuficiente si las ausencias afectan a una variable imprescindible o se concentran en un grupo clave.

¿Qué diferencia hay entre validez, consistencia y exactitud?

La validez comprueba que un valor respeta reglas de tipo, formato o dominio. La consistencia comprueba que no contradiga otras variables o fuentes según las relaciones esperadas. La exactitud contrasta si coincide con el hecho real o una referencia fiable. Un valor puede ser válido y consistente, pero inexacto.

¿Puede medirse la calidad sin disponer de Python o herramientas especializadas?

Sí. Una hoja de cálculo y consultas SQL sencillas permiten crear mediciones iniciales sólidas, siempre que las reglas, poblaciones y resultados queden documentados. La automatización se vuelve especialmente útil cuando crece el volumen o las evaluaciones se repiten con frecuencia.

¿Cómo se mide la calidad si hay millones de registros?

Las reglas deterministas de formato, nulidad o unicidad pueden evaluarse mediante procesos adecuados al volumen y a la infraestructura. Las comprobaciones de exactitud que requieran una referencia externa pueden basarse en muestras diseñadas cuidadosamente. Debe indicarse qué controles se ejecutaron sobre toda la población y cuáles solo sobre una muestra.

¿Hay que conseguir un 100 % de calidad antes de analizar?

No siempre. La decisión depende del objetivo y del coste de los errores. Sin embargo, algunos controles críticos pueden exigir cumplimiento completo para el subconjunto utilizado. Lo esencial es que las limitaciones sean conocidas, cuantificadas y compatibles con el análisis previsto, en lugar de quedar ocultas.

¿Medir calidad equivale a hacer un análisis exploratorio de datos?

No exactamente. El análisis exploratorio estudia patrones, relaciones y distribuciones para comprender la información y formular hipótesis. La evaluación de calidad comprueba de manera explícita si los datos son suficientemente completos, válidos, coherentes, exactos y actuales para un uso. Ambos trabajos se complementan, pero responden a preguntas diferentes.

Conclusión: la calidad se demuestra con pruebas, no con impresiones

La pregunta «¿es bueno este conjunto de datos?» resulta demasiado amplia para recibir una respuesta útil. Una evaluación profesional necesita definir primero la población y el propósito, establecer reglas comprensibles, calcular métricas con denominadores correctos y contrastar el resultado con el riesgo de la decisión.

La completitud revela ausencias, la validez descubre incumplimientos de reglas, la unicidad identifica posibles repeticiones indebidas, la consistencia detecta contradicciones, la exactitud exige evidencia y la actualidad comprueba si la información llega a tiempo. A estas dimensiones hay que añadir la cobertura de la población y la representatividad cuando el objetivo analítico lo necesite.

El mejor informe de calidad no es el que presenta el porcentaje más alto, sino el que permite saber qué conclusiones están justificadas y cuáles todavía no. Convertir esta disciplina en una revisión periódica mejora la fiabilidad de los informes, facilita detectar deterioros y crea una base técnica más sólida para proyectos de Ciencia de Datos que deban mantenerse durante años.

Desarrollar competencias para evaluar datos antes de analizarlos

Aprender a definir reglas, calcular indicadores de calidad y justificar la aptitud de un dataset ayuda a pasar de la simple manipulación de archivos a un análisis de datos más riguroso y reproducible. Si quieres profundizar de forma estructurada en estas competencias y en otras técnicas de informática y gestión de datos, puedes consultar la oferta de programas online de ESTUDIO METADATOS.

Ver programas de formación relacionados

Written by