Skip to main content

Gotchas de resolución de identidad: las fallas silenciosas

Las fallas de resolución de identidad que no tiran error. El over-merge filtra los datos de un cliente a otro; el over-split fragmenta una persona en muchas; un join directo source-a-unified devuelve un mapeo equivocado; el ganador de reconciliación equivocado manda mail a una dirección vieja; un cambio de regla reprocesa en silencio toda la org y mueve cada conteo. Siete gotchas, cada uno como el instinto, qué pasa de verdad en producción, y el fix.

Nota de producción·Actualizado 2026-06-01·Escrito por Lira · Editado por German Medina

Las match rules y las reconciliation rules son la demo fácil y el sistema de producción difícil. En un sandbox con unos miles de registros limpios, la resolución de identidad parece un checkbox: la prendés, mirás cómo se unifican los perfiles, seguís. El costo aparece después, a escala, sobre data real — y casi nunca como un error. La resolución de identidad falla en silencio. El job corre en verde, los perfiles unificados se poblan, los conteos parecen plausibles, y la falla son dos clientes que ahora pueden ver las órdenes del otro, o un cliente fragmentado en tres perfiles cuyas métricas nunca van a reconciliar.

Siete decisiones de resolución de identidad que mordieron a los builds de Data 360 (antes Data Cloud) de Cleon, sintetizadas con la guía oficial de Salesforce y las correcciones que la comunidad de práctica aprendió a los golpes. Cada una viene con el instinto que te mete adentro, qué pasa de verdad en producción, y el fix. El hilo conductor es el que esta subcategoría repite: la resolución de identidad es una decisión de negocio, no un checkbox — principio 4 — y sus dos peores fallas, el over-merge y el over-split, son silenciosas las dos. Las dos además fallan de forma asimétrica: un merge falso es un incidente de privacidad; un split falso es una molestia de métricas. Afiná contra la que menos podés permitirte, nunca partas la diferencia a ciegas.

Los gotchas

1. Aflojar las reglas para "agarrar más matches" — el over-merge fusiona dos clientes, y ven los datos del otro

El instinto es razonable y silenciosamente peligroso: se están perdiendo matches — la misma persona claramente existe dos veces — así que relajás un criterio o agregás una regla más floja para agarrarlos. Cada aflojada sí agarra duplicados reales, que es justo lo que hace que se sienta segura. Pero una match ruleset es un OR de reglas (match rules): cada regla que agregás o ensanchás es una forma más de que dos registros sean declarados la misma persona, y el motor no distingue un merge correcto de uno incorrecto. Aplica la regla y sigue.

Lo que pasa de verdad en producción es over-merge: dos personas distintas colapsan en un UnifiedIndividual__dlm. Sus contact points, atributos e historia se juntan en un solo perfil — y como todo lo de abajo lee el individuo unificado, los dos clientes ahora resuelven a la misma persona. Un segmento los targetea como uno. Una activación le manda a uno contenido basado en el comportamiento del otro. En un contexto de servicio o comercio, un cliente puede ver las órdenes del otro. Nada erroró; la regla hizo exactamente lo que le dijeron.

2. Apretar las reglas para "estar seguros" — el over-split fragmenta una persona, y las métricas cuentan doble

El instinto espejo, y se siente como el responsable: el over-merge da miedo, así que apretás — agregás un criterio a una regla, exigís una key exacta en todos lados, rechazás cualquier cosa fuzzy. Las reglas más estrictas no pueden fusionar dos personas que no son la misma, así que el riesgo de privacidad baja. La trampa es que lo estricto no es gratis; solo mueve la falla al otro lado.

Lo que pasa de verdad es over-split: una persona real que debería unificar queda fragmentada en varias filas de UnifiedIndividual__dlm, porque el AND-group completo de ninguna regla disparó a través de sus registros. El daño es el inverso del over-merge y igual de silencioso. Un conteo de individuos unificados sobreestima cuánta gente tenés. Un set de supresión construido sobre un fragmento se pierde los otros fragmentos de la persona, así que recibe el mensaje que suprimiste. La personalización corre sobre una historia parcial porque el resto de la persona vive en otro perfil. La "vista única" que prometió la plataforma en silencio no está — y ningún error lo dice.

El fix es dejar de tratar "más estricto es más seguro" como universalmente verdadero. Más estricto es más seguro contra el over-merge y peor contra el over-split; hacia cuál deberían inclinarse tus reglas es la decisión de riesgo asimétrico que enmarca el Style Guide. Probá la ruleset contra data real, contá en las dos direcciones a través del link object (próximo gotcha), y hacé que el negocio firme dónde queda la línea.

3. Contar el objeto de individuo equivocado — la confusión source-versus-unified que rompe cada métrica

El instinto es escribir FROM ssot__Individual__dlm porque es el objeto que ingestaste y aquel cuyo nombre aprendiste primero. Devuelve un número, el número parece clientes, y el reporte sale. El problema es que ssot__Individual__dlm cuenta registros de origen — una fila por individuo por origen — mientras que UnifiedIndividual__dlm cuenta personas. No son dos vistas de un conteo; son dos preguntas distintas, y la aritmética corre en una sola dirección: lo unificado siempre es menor o igual que el origen (el individuo unificado).

Lo que pasa de verdad es una métrica de "clientes" que en silencio cuenta doble a todos los que existen en dos sistemas, porque cada fila de origen duplicada se cuenta como una persona. Cambiá la misma métrica al objeto unificado y el número baja — no porque se fueron clientes, sino porque dejaste de contar a la misma persona dos veces. Los dos objetos mezclados entre reportes nunca reconcilian, y el hueco parece un bug de data mucho antes de que alguien sospeche del grain. Peor: alguien puede "arreglar" el hueco aflojando match rules para forzar que los conteos coincidan — cerrando una discrepancia que era la resolución de identidad funcionando bien, y cambiándola por over-merge (gotcha 1).

4. Joinear source directo a unified — la trampa del join directo devuelve un mapeo equivocado, no un error

El instinto viene de cualquier otro modelo de data que usaste: dos objetos que describen la misma cosa tienen que compartir una key, así que encontrás un campo compartido plausible y escribís ssot__Individual__dlm = UnifiedIndividual__dlm sobre él. Se siente como SQL común. Es el único recorrido que el modelo no soporta — y el modo de falla es del tipo peligroso, porque según el campo que elijas, puede no errar.

Lo que pasa de verdad es una de dos cosas, las dos malas. O el join no encuentra ninguna relación real y resuelve a nada, o — mucho peor — un = escrito a mano sobre algún campo que parece compartido devuelve un mapeo plausible pero equivocado, emparejando en silencio filas de origen con filas unificadas que la resolución de identidad nunca linkeó. Después construís conteos, segmentos y auditorías sobre una relación que la plataforma nunca afirmó. El individuo unificado no guarda ninguna foreign key que nombre sus orígenes, y el individuo de origen no guarda ninguna que nombre su fila unificada; la relación vive solo en IndividualIdentityLink__dlm (el individuo unificado).

El fix es no negociable y es el mismo en cada página de esta subcategoría: source-a-unified siempre recorre IndividualIdentityLink__dlm, nunca un join directo. Dos saltos, aliaseá y calificá cada columna:

-- Individuo de origen -> su individuo unificado, a través del link object.
-- Nunca joinees ssot__Individual__dlm directo a UnifiedIndividual__dlm.
-- los nombres de los campos de join del link/source dependen del modelo de tu org
SELECT
  src.ssot__Id__c            AS source_individual_id,
  uni.ssot__Id__c            AS unified_individual_id
FROM ssot__Individual__dlm src
JOIN IndividualIdentityLink__dlm link
  ON link.SourceRecordId__c = src.ssot__Id__c
JOIN UnifiedIndividual__dlm uni
  ON uni.ssot__Id__c = link.UnifiedRecordId__c;

El mismo puente corrido en la otra dirección — contando registros de origen por individuo unificado — es cómo de verdad medís el over-merge y el over-split: una fila unificada linkeada a muchos registros de origen puede estar over-merged; una persona que sabés que es un cliente desparramada en varias filas unificadas está over-split. (Para el comportamiento completo de las cláusulas y el join de keys nullables con IS NOT DISTINCT FROM, ver Data Cloud SQL.)

5. Confiar en el match e ignorar la reconciliación — el valor "equivocado" ganó por la regla que no elegiste

El instinto es tratar la resolución de identidad como terminada una vez que los registros correctos se fusionan: la gente está correcta, así que el perfil está correcto. Pero el matching solo decide qué valores de origen son candidatos; la reconciliación decide cuál gana por atributo (reconciliation rules). Salteá esa decisión y no salteás el resultado — heredás el default de la ruleset en cada atributo, y un default que nadie eligió sigue siendo una elección.

Lo que pasa de verdad es un perfil que está bien sobre la persona y mal sobre sus datos. Poné Most Recent en el atributo de email y una dirección vieja del batch import de anoche le gana a la dirección que el cliente tipeó en un formulario la semana pasada — porque el batch job es "most recent", no el humano. El perfil unificado presenta el email equivocado, el segmento filtra sobre él, y la activación le manda a él. Ningún error dispara; lo primero que escuchás es un reporte de bounces o un cliente que dejó de recibir los mensajes que espera. La misma trampa setea un birthdate que se da vuelta cada vez que una lista de baja calidad reimporta, porque la recencia dejó ganar a la escritura más nueva sin importar la calidad del origen.

El fix es elegir la reconciliación por atributo, contra cómo se comporta cada valor de verdad. Usá Source Priority apuntado al sistema de registro para los atributos que tienen uno — el CRM es dueño del email verificado, billing es dueño del estado de cuenta — para que la autoridad se sostenga sin importar qué feed escribió último. Reservá Most Recent para atributos que un cliente cambia activamente y donde el timestamp significa una edición humana, no un toque de pipeline. La reconciliación es principio 4 también: en silencio le asigna al cliente su email y dirección "verdaderos", y sus fallas son tan silenciosas como las del matching (reconciliation rules).

6. Guardar un cambio de regla como si fuera un toggle de config — reprocesa la org en silencio y mueve cada conteo

El instinto es que una match o reconciliation rule es configuración: la cambiás, guardás, seguís, como darías vuelta cualquier otra config. El editor de reglas lo refuerza — hay un botón Save, no un botón "reprocesá toda la org". Pero guardar una ruleset cambiada dispara reprocessing de resolución de identidad a través de la org: el motor reevalúa los registros de origen afectados, recomputa los mapeos de IndividualIdentityLink__dlm, y reconstruye los perfiles unificados (match rules).

Lo que pasa de verdad tiene tres bordes, todos fáciles de pisar mal. Cuesta — el reprocessing es trabajo, y Data 360 cobra sobre el trabajo procesado (principio 11), así que iterar sobre reglas no es gratis. Lleva tiempo — los perfiles que consultás justo después de guardar pueden estar todavía asentándose, así que un conteo leído demasiado temprano está a mitad de reproceso, no final. Y los conteos se mueven: una regla más floja baja el conteo unificado a medida que más registros colapsan juntos; una regla más estricta lo sube. Un reporte de abajo casado con UnifiedIndividual__dlm se mueve en el momento en que el matching reprocesa — por diseño, pero embosca a quien lee el reporte si nadie le avisó, y puede verse exactamente como un incidente de data.

El fix es tratar un cambio de regla como un deployment, no un toggle. Presupuestá el costo y el tiempo del reprocessing, anunciá el corrimiento de conteo a quien sea que consuma números de individuo unificado antes de guardar, y verificá qué hizo el cambio inspeccionando el link object — cuántos individuos de origen resuelven ahora a un individuo unificado — en vez de leyendo un dashboard a mitad de reproceso. Las reglas se validan contra data real y se firman antes de correr en toda la org (principio 4), justo porque el guardado es la parte que se siente irreversible.

7. Matchear sobre una key que nadie normalizó — la misma persona queda partida porque los valores nunca se alinearon

El instinto es agregar la key obvia a una match rule — email, teléfono, un ID de lealtad — y asumir que como dos registros contienen el mismo identificador, el motor los va a ver como iguales. Seguido no lo hace, porque cada criterio compara el valor normalizado, no el crudo (match keys y normalización). Jane@Example.com con un espacio al final y jane@example.com son la misma dirección para un humano y dos strings distintos para una regla de exact-match que nunca los normalizó.

Lo que pasa de verdad es over-split con una causa de aspecto inocente: una persona queda fragmentada no porque la regla fuera demasiado estricta en intención, sino porque la key sobre la que matcheó no se estandarizó primero, así que los valores nunca compararon iguales. Un teléfono guardado como (555) 123-4567 en un origen y +15551234567 en otro no va a matchear en una regla de exact-phone hasta que los dos se normalicen hacia una forma canónica. La regla se ve correcta en el editor; la resolución está mal en producción, y se presenta idéntica a una ruleset deliberadamente estricta — una persona, varios perfiles, ningún error.

El fix es tratar la normalización como parte de la match rule, no un detalle por debajo: la calidad de una match rule está topeada por la calidad de la normalización bajo sus keys (match keys y normalización). Pasá a minúsculas y recortá el email, reformateá el teléfono hacia una forma canónica, estandarizá el identificador de party — antes de que la regla compare nada. Cuando dos registros que sabés que son la misma persona no se fusionan, sospechá de la normalización en la key antes de agarrar una regla más floja, porque aflojar para tapar un hueco de normalización es cómo convertís un over-split silencioso en un over-merge silencioso (gotcha 1).

El hilo conductor de los siete: la resolución de identidad no te avisa cuándo está mal. Matcheá demasiado flojo y dos personas son una; matcheá demasiado estricto — o normalizá demasiado poco — y una persona son muchas; contá el objeto equivocado o joineá directo a unified y la relación que reportás nunca se afirmó; salteá la reconciliación y el perfil está bien sobre la persona y mal sobre su email; guardá una regla como un toggle y toda la org reprocesa bajo un reporte que recién se movió. Cada una de estas es silenciosa, y la palanca está en el mismo lugar siempre: las reglas, las keys bajo ellas, y el link object que es el único mapa honesto de lo que la resolución hizo de verdad. Probá contra data real, contá a través del link, y hacé que el negocio firme — porque la plataforma nunca va a levantar la mano.

Cierre

Estos siete son las fallas de resolución de identidad que Cleon vio morder más fuerte en builds de Data 360. El tema compartido hace eco del resto de este catálogo: la plataforma hace fácil el merge fácil y deliberada la resolución correcta. Dos clientes fusionados en uno, un cliente partido en tres, un conteo que no reconcilia, un join directo que devolvió un mapa equivocado, un email viejo que ganó, un cambio de regla que reprocesó la org en silencio — ninguna es ruidosa en el momento, y cada una es un perfil que le miente a todo lo de abajo hasta que alguien nota un número que no puede ser, o un cliente ve una orden que no es suya.

Si un gotcha de resolución de identidad mordió a tu equipo y no está acá, escribí a hello@wearecleon.com — lo agregamos, con crédito.

Relacionado

Referencia: