La respuesta corta
La deduplicación falla cuando se considera una operación de limpieza única. En realidad, son tres decisiones: qué define una identidad, quién prevalece cuando hay un conflicto y cómo se evita que el problema se repita. La herramienta técnica es la parte más fácil.
El error común es ejecutar la correspondencia aproximada (Fuzzy Matching) en nombres, obtener una lista de 12 mil posibles coincidencias e intentar resolverlas manualmente bajo la presión de un plazo. Lo que funciona es lo contrario: primero se reduce el espacio de decisión utilizando claves robustas y se deja para revisión humana solo la zona gris.
La planificación integral de la migración se describe en Guía de Migración de Datos a Salesforce.
Tres Capas de Correspondencia
| Capa | Basada en | Acción |
|---|---|---|
| Clave Robusta | ID fiscal, ID de sistema fuente, email verificado | Fusión automática |
| Clave Compuesta | Nombre normalizado + ciudad + teléfono normalizado | Fusión automática con alta puntuación |
| Similitud Textual | Solo nombre, dirección libre | Solo revisión humana |
La proporción que caracteriza un proyecto bien gestionado es: aproximadamente el 70% de los duplicados se resuelven en la primera capa, el 20% en la segunda y el 10% restante llega a una persona. Si la mayoría de las coincidencias llegan a la tercera capa, es señal de que no se trabajó en la normalización, y no necesariamente de que los datos sean especialmente deficientes.
Normalización antes de la Comparación
Antes de cualquier comparación, se generan columnas de ayuda normalizadas sin modificar el dato original: eliminación de sufijos corporativos (S.A., Ltd.), uniformidad de espacios y comillas, teléfono a formato E.164, email a minúsculas con eliminación de etiquetas después del signo más, y dirección dividida en calle/número/ciudad. En español, se añade el tratamiento de grafías completas o abreviadas y siglas.
La normalización por sí sola suele reducir entre un tercio y la mitad de los duplicados "difíciles" antes incluso de aplicar cualquier algoritmo de similitud.
Golden Record a Nivel de Campo
La decisión de "qué registro sobrevive" no es la más importante. La clave es "qué valor sobrevive en cada campo". Se establece una política concisa: datos de facturación del ERP, datos de contacto del sistema donde se registró la última actividad, estado del cliente del sistema operativo. Cada campo tiene una fuente preferente, y se mantiene un registro del valor descartado.
Sin esta política, cada fusión es una decisión de quien la ejecuta en ese momento, y luego no se puede explicar por qué desapareció una dirección.
Qué Sucede con las Relaciones y el Historial
La fusión de registros afecta actividades, oportunidades, Casos, archivos y permisos. Antes de una ejecución masiva, se define explícitamente: a dónde van las actividades, qué ocurre con las oportunidades abiertas para el mismo cliente de dos registros, y quién es el propietario después de la fusión, ya que el cambio de propietario (Owner) modifica tanto la visibilidad como los informes de comisiones.
La regla práctica es: no hay fusión antes de que exista un informe de "qué cambió" que pueda restaurarse, y los identificadores de origen se guardan en un campo separado para permitir investigaciones meses después.
Escenario: un Importador con 210 Mil Contactos
Un importador B2B abordó la migración con 210 mil Contactos de tres sistemas. La primera ejecución de la herramienta de similitud arrojó 31 mil pares sospechosos, un número que nadie podía revisar.
El equipo se detuvo e invirtió el orden. Primero se normalizaron el email y el teléfono: 14 mil pares se resolvieron automáticamente por clave robusta. Luego, se determinó que la unidad de negocio era la ubicación del cliente y no la corporación, lo que eliminó 6 mil pares legítimos de la lista, sucursales separadas de la misma cadena. Quedaron 4,200 pares para la capa intermedia, de los cuales 3,800 se resolvieron con una alta puntuación. Para revisión humana llegaron 400 pares, y dos personas los resolvieron en tres días.
La lección no fue la elección de la herramienta. Fue que la definición de la unidad de negocio, sitio versus corporación, eliminó más "ruido" que cualquier mejora algorítmica.
Prevención: Por Qué Vuelven los Duplicados
Tres fuentes principales reintroducen duplicados después del Go Live: entrada manual sin Matching Rules activas, integraciones que crean un registro en lugar de actualizar (Upsert en External ID resuelve la mayoría), y formularios Web-to-Lead sin verificación de existencia. Si no se cierran estas tres, la tasa de duplicidad vuelve a su nivel original en uno o dos años.
Riesgos Comunes y Acciones Preventivas
| Riesgo | Cómo se Manifiesta en la Práctica | Acción Preventiva |
|---|---|---|
| Fusión Agresiva | Se unificaron clientes diferentes y no se pueden separar | Umbral de puntuación alto + revisión en la zona gris |
| Falta de Definición de Identidad | Discusión recurrente sobre qué se considera el mismo cliente | Decisión documentada a nivel de entidad |
| Pérdida de Historial | Actividades y oportunidades desaparecieron en la fusión | Informe "qué cambió" y conservación de IDs de origen |
| Limpieza sin Prevención | Los duplicados vuelven en pocos meses | Matching Rules, Upsert y formularios protegidos |
| Limpieza después de la Carga | Cada fusión impacta relaciones activas | Limpiar en la etapa de Staging |
Cómo Medir el Éxito
| Área | Qué Medir | Frecuencia de Verificación |
|---|---|---|
| Unicidad | Tasa estimada de duplicidad por entidad | Semanal durante la migración, trimestral después |
| Precisión de Fusión | Porcentaje de fusiones canceladas o corregidas manualmente | Con cada ola de fusión |
| Prevención | Nuevos registros bloqueados como duplicados en la entrada | Mensual |
| Impacto Comercial | Contactos duplicados con el cliente, precisión de informes de cliente | Trimestral |
El acompañamiento profesional en la construcción de reglas de identidad y prevención se ofrece como parte de nuestro servicio de Integraciones y Datos.
Lista de Verificación Antes de Ejecutar una Fusión
- ☐ Se definió la unidad de negocio: corporación, sitio o contrato.
- ☐ Se construyeron columnas de normalización sin modificar el origen.
- ☐ Se establecieron tres capas de Matching con umbrales numéricos documentados.
- ☐ Se definió la política de Golden Record a nivel de campo, aprobada por el negocio.
- ☐ Se decidió qué ocurre con actividades, oportunidades y propiedad.
- ☐ Se conservan los IDs de origen después de la fusión.
- ☐ Es posible generar y restaurar un informe de "qué cambió".
- ☐ Se realizó una prueba en una muestra con verificación manual.
- ☐ Matching Rules y Upsert están activos para la prevención.
- ☐ Se asignó un propietario permanente para el proceso después del Go Live.
Fuentes Profesionales
- Salesforce Data 360 — https://www.salesforce.com/data/
- Salesforce Data 360 Architecture — https://architect.salesforce.com/docs/architect/fundamentals/guide/data-360-architecture.html
- HPI Pro – Integraciones y Datos — https://hpi.pro/integrations-data