Calidad de los datos: el enemigo silencioso que todo el mundo ignora 

Hoy, el acceso a datos ya no es un problema. En minutos, cualquier profesional del marketing digital puede obtener información de las principales plataformas. Sin embargo, el reto real no está en la cantidad, sino en la calidad: datos precisos, consistentes y útiles son la base para tomar decisiones informadas y efectivas.

En este artículo, te explico cuáles son los problemas más frecuentes que afectan la calidad de los datos y, sobre todo, qué estrategias puedes implementar desde ya para garantizar que los tuyos sean confiables y accionables.

¿Qué es la calidad de los datos? 

Cuando hablamos de calidad de datos, es común pensar en procesos de normalización: agrupar valores similares para evitar inconsistencias. Un ejemplo típico es el campo “país” en un formulario, donde los usuarios pueden introducir “España”, “ESP”, “Espana”, “Reino de España”, etc. Aunque este problema es conocido y muchas empresas ya lo anticipan al diseñar campos libres, la calidad de los datos va mucho más allá.

En mi experiencia, los principales (no los voy a listar todo) desafíos que realmente impactan en la toma de decisiones son:

Integridad: cuando tu base de datos es incompleta 

Aunque no lo parezca, es un problema muy común y que no es tan fácil de detectar. Te voy a dar un ejemplo que nos ha pasado hace poco. En mi empresa actual (Doctoralia) y para analizar el tráfico, recibimos cada día datos de Google Search Console y Google Analytics 4. Como tenemos varios dominios, usamos lógicas incrementales dónde miramos la última fecha disponible en todas las tablas. 

Si tenemos:

• Los datos de Brasil hasta el 21/10 
• Los datos de España hasta el 21/10
• Los datos de Chile hasta el 20/10 

Procesaremos únicamente los datos hasta el 20/10. Ahora este proceso asume que los datos llegan de forma cronológica, algo que suele ocurrir siempre. Pues resulta que no siempre es así, y te muestro un ejemplo:  

Como puedes ver, hemos recibido los datos del 21/10 después los datos del 22/10. Con cualquier lógica incremental, eso significa que los datos del 21/10 nunca se procesarán. Obviamente no suele pasar, pero lo que te quiero transmitir es que tienes que cubrir tu espalda frente a estos casos, porque si tienes varios dominios, te puede costar identificarlos. 

Precisión: cuando tus datos no reflejan la realidad

Los datos tienen que reflejar la realidad que pretenden representar. Un problema muy común son los eventos en plataformas como Google Analytics 4. 

Te voy a dar un ejemplo de un proyecto en el cuál trabajé hace unos años. Un cliente (E-commerce) tenía un proceso de compra bastante estándar: agregas tus productos al carrito, introduces tus datos, pagas y listo. La primera vez que miré los datos, me sorprendió la tasa de conversión de un canal. No por el valor como tal, sino porque en mi experiencia era un canal que convertía bastante mal. Y en este caso no. 

Después de una pequeña investigación, nos dimos cuenta de que el evento de compra se disparaba cuando el usuario abría el enlace de la pasarela de pago, no después del pago exitoso. Únicamente para este canal.  

Detrás de esta anécdota está una realidad: tienes que asegurarte de que tus datos reflejan lo que realmente pretenden representar, sino te podrás llevar sorpresas. 

Unicidad: cuando tus datos se duplican y no te das cuenta 

Comprobar la unicidad de los datos es fácil, pero muchas veces no se hace dónde toca. Me explico. 

Cuando piensas en la unicidad, piensas en asegurarte que no tengas más de una sesión con el mismo session_id por ejemplo. Porque sino puedes acabar con dos páginas de entradas diferentes para una misma sesión, lo cuál no tendría mucho sentido. 

Estos problemas se suelen solventar de una forma sencilla: una prueba SQL dónde cuentas los valores únicos de la columna de una tabla. Si hay más de una fila con el mismo session_id, tienes un problema. Simple y sencillo, ¡perfecto! 

El problema es que esta prueba no se hace nunca en TODAS las tablas, y el problema acaba llegando en las tablas que usas para tus informes. 

• Cuando haces un JOIN entre dos tablas en SQL, las filas se pueden duplicar si hay más de una coincidencia entre las tablas que estás uniendo. Esto ocurre porque el JOIN combina cada fila de la primera tabla con todas las filas coincidentes de la segunda tabla.
• En función de tu lógica incremental, puedes también acabar duplicando datos si vuelves a ejecutar un modelo sin eliminar los datos primero 

Si en la tabla que conectas con tu herramienta favorita de visualización (Looker Studio, PowerBI …) no tienes ninguna prueba y por mucho que tengas pruebas otras tablas, puedes acabar con filas duplicadas inflando tus métricas. ¿Por qué? Porque estas tablas suelen incluir datos pre-agregados y no cuentan con una columna como el session_id. 

¿La solución? Asegurarse de que las combinaciones de las dimensiones son únicas. Esta tabla cumpliría … 

country	user_type	sessions
esp	logged_in	150
esp	premium	100

… pero esta no.  

country	user_type	sessions
esp	premium	150
esp	premium	100

¿Cómo identificar los problemas? 

No hay una solución universal para solventar un problema de calidad de datos, porque depende de varios factores incluyendo el origen de estos datos. Por ejemplo, si nos falta un día en los datos de Google Analytics 4 porque Google no nos ha mandado el dato, no hay gran cosa que podamos hacer aparte de esperar. 

Ahora, el problema es que la gran mayoría de las empresas ni saben que tienen un problema de calidad con los datos. O no saben muy bien dónde. 

Y eso sí que suele tener una solución simple: implementar pruebas. 

¿Qué es una prueba? 

Una prueba es un código SQL que se ejecuta de forma automática para comprobar, por ejemplo, la unicidad de los datos. Pero puedes implementar soluciones similares para los otros problemas que mencionamos en la primera sección. 

Suele tener la siguiente estructura: 

select 
session_id, 
count(*) as n 
from my_table 
group by session_id 
having n > 1 

Si este código no devuelve una tabla vacía, significa que tenemos duplicidad y hay que encontrar el problema. Tenemos que vincular la ejecución del código a un sistema de alertas (e-mail, Slack …) para asegurarnos de que el problema se solvente cuanto antes. 

¿Cómo implementar una prueba? 

Si tu empresa gestiona datos, es probable que use una herramienta como DBT o un equivalente, y puedes usar pruebas que son fáciles de diseñar siguiendo la documentación. 

Por ejemplo: 

version: 2

models:
  - name: orders
    data_tests:
      - dbt_utils.unique_combination_of_columns:
          arguments:
            combination_of_columns:
              - country
              - user_type

Si esta prueba tuviera un error, recibiréis un error similar al siguiente: 

Completed with 1 error, 0 partial successes, and 0 warnings:
[2025-10-12, 09:05:35 CEST] {subprocess.py:106} INFO - 07:05:35
[2025-10-12, 09:05:35 CEST] {subprocess.py:106} INFO - 07:05:35  Failure in test dbt_utils_unique_combination_of_columns_country__user_type (models/misc/seo/gold/gold.yml)
[2025-10-12, 09:05:35 CEST] {subprocess.py:106} INFO - 07:05:35    Got 109770 results, configured to fail if != 0

Lo cuál me indica que tengo 109770 líneas que no han pasado mi prueba. ¡Algo estaré haciendo mal! Si estás usando DataForm, el equivalente de Google, puedes echar un vistazo a su documentación para implementar algo similar. 

¿Ahora qué? 

Si trabajas en una empresa que tiene flujos de datos para tomar decisiones, acércate a las personas que los gestionan y pregunta cuáles son las pruebas que actualmente hacéis. Si no hay ninguna y sobre todo si usáis DBT o Dataform, implementad algunas para ver lo que os devuelven. Podríais llevaros algunas sorpresas.