Cómo detectar datos duplicados entre sistemas | Acadevor
·8 min de lectura
¿Cómo detectar datos duplicados entre sistemas antes de reportar?
Aprende a detectar datos duplicados entre sistemas: señales, conteos de control y dónde se resuelven de verdad, en la capa Silver y el modelo semántico.
Los datos duplicados entre sistemas se detectan comparando la misma entidad (cliente, producto, transacción) contra una clave estable y no contra su nombre visible, porque cada sistema la escribe distinto. La señal más común es un conteo que no cuadra: más clientes de los que existen, ventas infladas o un indicador que dos áreas calculan diferente. La detección vive en la capa Silver, donde se estandarizan claves y se aplican reglas de deduplicación.
¿Qué es un dato duplicado entre sistemas y por qué aparece?
Un duplicado entre sistemas ocurre cuando la misma entidad real existe más de una vez porque cada fuente la registró a su manera. El cliente "Comercial López SA" puede estar como "Comercial Lopez S.A." en el CRM, "C. LOPEZ" en facturación y con otro identificador en el sistema de soporte. Para las personas es obvio que son el mismo; para las herramientas son tres registros distintos.
Esto no es un descuido, es la consecuencia natural de tener sistemas vivos que crecieron por separado. Cada uno tiene su propio formato de fechas, sus estados, sus categorías y sus claves. Mientras cada sistema trabaja aislado no molesta. El problema explota cuando intentas unir esas fuentes para tener una única verdad y de golpe los números dejan de cuadrar.
¿Cuáles son las señales de que tienes duplicados?
Antes de abrir cualquier tabla hay síntomas que delatan el problema desde la sala de reuniones:
Dos áreas presentan el mismo indicador con cifras distintas y nadie sabe cuál es la buena.
El total de clientes o productos es mayor que el que el negocio reconoce como real.
Demo gratuita
Mira cómo construir tu sistema de datos e IA
Un recorrido práctico de principio a fin para unificar fuentes dispersas en un modelo semántico que alimenta Excel, Power BI, Copilot y tus agentes.
Las ventas o los ingresos aparecen inflados sin una explicación de negocio.
Un filtro que debería cuadrar (por región, por estado) nunca suma el total esperado.
Aparecen medidas imposibles: promedios fuera de rango o porcentajes por encima del cien.
Cuando ves cualquiera de estas señales, casi nunca es un error de la visual ni de la fórmula. Es un problema de entidades repetidas que se arrastra desde el origen.
¿Cómo confirmar la duplicación con conteos de control?
La sospecha se convierte en evidencia con comparaciones simples de conteo. La idea es contrastar cuántos registros hay contra cuántas entidades únicas deberían existir.
Cuenta el total de filas de una entidad (por ejemplo, todos los registros de clientes).
Cuenta los valores únicos de la clave que debería identificarla (identificador fiscal, correo, SKU).
Si el total de filas supera al de claves únicas, tienes duplicados.
Repite el conteo por cada sistema por separado y luego sobre la unión de todos.
Revisa además las claves nulas o de prueba, que suelen esconder registros basura que inflan el conteo.
El punto delicado es elegir la clave correcta. Comparar por nombre es la trampa clásica, porque las mayúsculas, los acentos, los espacios y las abreviaturas hacen que dos registros iguales parezcan diferentes. Por eso se estandariza primero y se compara después.
¿Dónde se resuelven de verdad los duplicados?
Aquí está la pregunta clave. Si dos áreas calculan el mismo indicador distinto, casi nunca se arregla con una visual ni con un filtro puesto encima. Se arregla antes, en la capa donde el dato empieza a ser confiable.
En una arquitectura medallion que organiza los datos en capas confiables, esa capa es Silver. Es donde se corrigen los problemas de calidad, se homogeneizan las reglas y se unen las fuentes. Concretamente, en Silver se hace lo siguiente:
Estandarizar fechas, monedas, estados, categorías y claves para que todo hable el mismo idioma.
Eliminar duplicados y definir reglas de supervivencia (cuál registro gana cuando hay conflicto).
Unificar clientes, productos, usuarios o entidades entre sistemas bajo una clave común.
Controlar valores nulos, tipos incompatibles y registros de prueba.
El resultado son tablas limpias que todavía no están agregadas para un informe concreto, pero que ya son confiables. Sobre esa base, el modelo semántico define una sola vez cómo se calcula cada indicador, de modo que todas las áreas comparten la misma regla y desaparece la discusión de cifras.
¿Cómo se compara detectar en la visual contra corregir en Silver?
Enfoque
Dónde vive
Qué logra
Riesgo
Filtro o medida en el informe
En cada reporte
Tapa el síntoma en una visual
El duplicado sigue en el resto de informes
Reglas en la capa Silver
En la fuente confiable
Corrige la entidad una sola vez para todos
Requiere ordenar el dato antes
Definición en el modelo semántico
En el modelo semántico
Todos calculan igual el indicador
Exige acordar la regla de negocio
La comparación deja clara la diferencia de criterio: parchear en la visual multiplica el trabajo y nunca termina, mientras que resolver en la capa Silver de un lakehouse y en el modelo semántico corrige el problema en su raíz. Es criterio antes que herramienta.
¿Qué reglas de supervivencia usar cuando hay conflicto?
Cuando confirmas que dos registros son la misma entidad, hay que decidir cuál dato sobrevive. Una regla de supervivencia es el acuerdo que dicta qué fuente manda para cada campo. Algunos criterios habituales:
El registro más reciente gana para datos de contacto que cambian seguido.
El sistema oficial de esa entidad manda para su campo (facturación para el dato fiscal, CRM para el comercial).
El valor no nulo prevalece sobre el vacío cuando una fuente tiene el dato y la otra no.
Lo importante es que estas reglas se escriban y se apliquen una sola vez en Silver, no en la cabeza de cada analista. Así la deduplicación es reproducible y auditable, no un criterio que cambia según quién arme el informe.
Siguiente paso
Detectar duplicados es el primer eslabón para que todos los sistemas cuenten la misma historia y las cifras dejen de discutirse en cada reunión. El siguiente es ver, con tus propios casos, cómo se estandarizan claves, se definen reglas de supervivencia y se fija cada indicador en una sola definición compartida. Si quieres ver ese enfoque aplicado de principio a fin, mira la demo gratuita y evalúa si encaja con la situación de tus datos.
Preguntas frecuentes
¿Por qué no debo detectar duplicados comparando por el nombre?
Porque cada sistema escribe el nombre distinto: mayúsculas, acentos, espacios y abreviaturas hacen que dos registros iguales parezcan diferentes. Se compara contra una clave estable (identificador fiscal, correo, SKU) después de estandarizarla.
¿Qué señal en las reuniones indica que hay datos duplicados entre sistemas?
La más clara es que dos áreas presentan el mismo indicador con cifras distintas, o que el total de clientes, productos o ventas aparece inflado sin una explicación de negocio. Suele ser un problema de entidades repetidas, no de la visual.
¿Cómo confirmo la duplicación con un conteo simple?
Cuenta el total de filas de una entidad y luego los valores únicos de su clave. Si hay más filas que claves únicas, tienes duplicados. Conviene repetir el conteo por sistema y sobre la unión de todos, revisando claves nulas o de prueba.
¿Dónde se corrigen los datos duplicados en una arquitectura medallion?
En la capa Silver, donde se estandarizan claves, se eliminan duplicados con reglas de supervivencia y se unifican las entidades entre sistemas. La definición del indicador se fija además en el modelo semántico, con una sola regla compartida por todas las áreas.
¿Qué es una regla de supervivencia?
Es el acuerdo que decide cuál dato sobrevive cuando dos registros son la misma entidad: por ejemplo, el más reciente para contacto, el sistema oficial para su campo, o el valor no nulo sobre el vacío. Se escribe y se aplica una sola vez en Silver.
