Dos sistemas describen al mismo cliente con nombres diferentes. Otro cliente comparte dirección con él. Sin un identificador común fiable, eliminar duplicados deja de ser una simple operación de filas iguales y se convierte en una decisión sobre identidad.
El proceso debe conservar la evidencia que justifica cada unión y una vía para corregirla. Una fusión incorrecta puede contaminar informes, permisos o actuaciones posteriores incluso si reduce el número de registros.
Distingue copia repetida e identidad compartida
Si dos filas proceden de la misma entrega y tienen la misma clave de origen, puede tratarse de una repetición de transporte. Ese caso requiere idempotencia en la ingesta.
Resolver si dos registros de fuentes diferentes representan la misma entidad es otro problema. La igualdad de algunos atributos aporta evidencia, pero no establece siempre una identidad. Tampoco una diferencia demuestra necesariamente que sean entidades distintas.
Define antes qué quieres identificar: una empresa, una sede, una cuenta comercial o una persona de contacto. Dos sedes de la misma empresa pueden necesitar miembros separados en el modelo.
Conserva el original junto a la representación normalizada
Normaliza formatos cuando tenga sentido: espacios, representación de teléfonos o componentes de dirección. Documenta cada transformación. Quitar caracteres indiscriminadamente puede convertir valores distintos en una misma cadena.
Mantén el valor original y su procedencia. La persona que revise una coincidencia debe poder ver qué cambió la normalización y de qué sistema provino el dato.
Distingue un campo ausente de una discrepancia. Que dos registros no tengan teléfono no es evidencia de que compartan teléfono, y completar valores faltantes con una etiqueta común puede crear coincidencias artificiales.
Un ejemplo con señales contradictorias
Los siguientes registros son ficticios:
| Registro | Nombre | Dirección | Teléfono |
|---|---|---|---|
| A | Comercial Delta | Calle Norte, 12 | T-01 |
| B | Com. Delta | Calle Norte, 12 | T-01 |
| C | Distribuciones Delta | Calle Norte, 12, oficina 2 | T-01 |
A y B presentan varias coincidencias compatibles con una misma entidad, pero C podría ser otra empresa que comparte centralita y edificio. La tabla no contiene evidencia suficiente para declarar automáticamente que los tres registros deben fusionarse.
Una referencia adicional validada o una revisión de la fuente puede resolverlo. La similitud del nombre, por sí sola, no debe convertirse en una conclusión irreversible.
Genera candidatos sin comparar todo indiscriminadamente
En conjuntos grandes, comparar cada registro con todos los demás puede resultar inviable. Las reglas de bloqueo seleccionan pares candidatos mediante atributos o combinaciones que reducen la búsqueda.
Comprueba qué coincidencias reales quedan fuera de esos bloques. Si exiges el mismo código postal, no compararás una entidad que cambió de dirección. Utilizar varias rutas de candidatura puede ayudar, siempre que se evalúe su coste y cobertura.
La documentación del modelo Fellegi-Sunter en Splink explica cómo combinar evidencia de acuerdo y desacuerdo entre campos para vincular registros. No convierte cualquier puntuación de similitud en una certeza de identidad. La interpretación depende del modelo y de los datos con los que se ha ajustado.
Separa coincidencias claras, descartes y revisión
Define una política con ejemplos etiquetados por personas que conozcan el dominio. Incluye coincidencias difíciles y pares parecidos que correspondan a entidades distintas.
Evalúa falsos positivos y falsos negativos según el uso. Una unión incorrecta puede tener consecuencias diferentes de mantener temporalmente dos registros separados. No elijas un umbral solo para obtener una reducción llamativa del tamaño del fichero.
Conserva una zona de revisión para los casos ambiguos. Presenta acuerdos, discrepancias, fuentes y cambios históricos, en lugar de una cifra aislada que invite a aceptar sin contexto.
Comprueba los grupos después de comparar pares
Que A se parezca a B y B se parezca a C no demuestra que A y C sean la misma entidad. La agrupación necesita comprobar incompatibilidades y reglas del dominio.
Registra qué relación originó cada grupo y cómo puede deshacerse. Separar más tarde un grupo mal formado exige saber qué hechos procedían de cada registro original.
La asignación de claves sustitutas debe conservar esas correspondencias. Generar un identificador interno facilita relacionar tablas, pero no valida la decisión de identidad que lo produjo.
Valida el efecto sobre los consumidores
Comprueba qué cambia en recuentos, segmentos y relaciones. Un total de clientes menor puede ser correcto, pero también puede ocultar fusiones erróneas. Revisa casos rastreables antes de publicar una nueva versión del maestro.
Para preparar una integración y depuración de datos, comparte con Nexeus Big Data ejemplos de coincidencias confirmadas y de registros parecidos que deban permanecer separados. Esa evidencia permite diseñar una deduplicación que explique sus decisiones y admita correcciones.