Debuggear identity resolution: ¿es over-merge u over-split? | Cleon

Un perfil unificado en Data 360 (antes Data Cloud) está mal y nada te avisó. Capaz un cliente entró y vio un pedido que no era suyo. Capaz "clientes activos" cayó un tercio de un día para el otro después de que alguien cambió una regla. Capaz una persona que sabés que existe es de algún modo tres personas en la data. El match ruleset parecía razonable, el reprocesamiento reportó éxito, y la identity resolution nunca tira error por estar equivocada — solo por no correr. Así que el diagnóstico tiene siempre la misma forma: nombrá la falla primero, porque cada otro paso depende de cuál tenés. Hay solo dos, y son opuestas.

Over-merge — dos (o más) personas distintas fusionadas en un solo UnifiedIndividual__dlm. Las reglas estaban demasiado flojas. Esta es la falla peor, la asimétrica: las personas mergeadas pueden ver los datos del otro, la supresión se filtra entre ellas, y la personalización le habla a la persona equivocada. En un canal con consentimiento es un incidente de privacidad, no una molestia de métricas.
Over-split — una persona real fragmentada en varias filas UnifiedIndividual__dlm. Las reglas estaban demasiado estrictas, o una key estaba sucia. Las métricas duplican el conteo, un set de supresión se pierde algunos de los registros de la persona, y la "vista única" calladamente no es una.

Todo lo de abajo pasa por el objeto puente. Source-a-unificado nunca es un join directo — no hay camino modelado de ssot__Individual__dlm directo a UnifiedIndividual__dlm; siempre traversás a través de IndividualIdentityLink__dlm, el link que mantiene la identity resolution. Cada query de esta página va origen → link → unificado (o al revés), y la tuya también.

Los pasos

[ PASO 1 — Nombralo: ¿over-merge u over-split? (inspeccioná el objeto link) ]
        ↓
[ PASO 2 — ¿Qué criterio de match disparó para causarlo? ]
        ↓
[ PASO 3 — Validá la normalización sobre las keys sospechosas ]
        ↓
[ PASO 4 — Cambiá una regla, después verificá que el reprocesamiento realmente aterrizó ]

A diferencia de un número de query equivocado, donde bajás desde el modelo, un síntoma de identidad apunta a una dirección. "Un cliente vio los datos de otro" es over-merge; "el count se duplicó" o "esta persona es varios perfiles" es over-split. El Paso 1 confirma cuál, en la data, antes de que toques una regla — porque el arreglo del over-merge (endurecer) es el opuesto exacto del arreglo del over-split (aflojar), y adivinar mal lo empeora. Los Pasos 2 y 3 encuentran por qué pasó la decisión equivocada; el Paso 4 es cómo cambiás la regla y confirmás que el cambio hizo lo que pretendías sin romper la mitad que estaba bien.

Paso 1 — Nombralo: ¿over-merge u over-split?

Antes de cambiar nada, probá en la data qué falla tenés. Las dos se miden igual: contá cómo se distribuyen los registros de origen entre los individuos unificados a través de IndividualIdentityLink__dlm. El over-merge es demasiados registros de origen distintos — claramente personas diferentes — colapsando en un individuo unificado. El over-split es los registros de una persona desparramados en demasiados individuos unificados. Lo primero lo leés abriendo en abanico desde la fila unificada; lo segundo lo leés agrupando los registros de origen que deberían ser una persona y contando los individuos unificados distintos en los que aterrizaron.

El chequeo (over-merge) — arrancá desde el individuo unificado sospechoso y abrí en abanico a través del link hacia cada registro de origen que resolvió en él. Un individuo unificado que enlaza a un registro de origen nunca matcheó con nada; uno que enlaza a cinco significa que la resolución plegó cinco filas de origen en una persona. Un puñado de sistemas genuinamente distintos es normal; docenas, o un count que sigue trepando, es el olor.

-- Sonda de OVER-MERGE: ¿cuántos registros de origen distintos resolvieron en un
-- individuo unificado? Traversá unificado -> link -> origen. Nunca un join directo.
-- Un count alto para lo que debería ser una persona es la firma del over-merge.
-- los nombres de los campos de join del link/source dependen del modelo de tu org
SELECT
  uni.ssot__Id__c                        AS unified_individual_id,
  COUNT(DISTINCT link.SourceRecordId__c) AS source_record_count
FROM UnifiedIndividual__dlm uni
JOIN IndividualIdentityLink__dlm link
  ON link.UnifiedRecordId__c = uni.ssot__Id__c
GROUP BY uni.ssot__Id__c
ORDER BY source_record_count DESC;

Un source_record_count alto por sí solo no es prueba — una persona genuinamente bien conectada puede legítimamente abarcar muchos orígenes. Confirmá que el merge está mal leyendo los atributos identificatorios de los registros de origen enlazados (nombre, email, party ID) y viendo si describen humanos distintos. Recorré los orígenes de un individuo unificado sospechoso a través del link y leelos:

-- Confirmar un over-merge: listá los registros de origen detrás de UN individuo
-- unificado sospechoso e inspeccioná sus atributos identificatorios. Personas
-- distintas compartiendo un unified_individual_id es over-merge, en la data.
SELECT
  src.ssot__Id__c          AS source_individual_id,
  src.ssot__FirstName__c   AS first_name,
  src.ssot__LastName__c    AS last_name,
  src.DataSourceId__c      AS data_source
FROM UnifiedIndividual__dlm uni
JOIN IndividualIdentityLink__dlm link
  ON link.UnifiedRecordId__c = uni.ssot__Id__c
JOIN ssot__Individual__dlm src
  ON src.ssot__Id__c = link.SourceRecordId__c
WHERE uni.ssot__Id__c = 'PASTE_SUSPECT_UNIFIED_ID'
ORDER BY src.ssot__LastName__c;

El chequeo (over-split) — andá en la otra dirección. Tomá una key que debería identificar a una persona — un email verificado, un loyalty / party ID — agrupá los registros de origen por ella, y contá los individuos unificados distintos en los que resolvieron a través del link. La respuesta esperada es exactamente uno. Dos o más significa que los registros de esa única key se fragmentaron en múltiples perfiles unificados: over-split.

-- Sonda de OVER-SPLIT: para una key que debería ser UNA persona, ¿en cuántos
-- individuos unificados distintos resolvieron sus registros de origen? Origen ->
-- link -> unificado. Cualquier cosa arriba de uno para una persona real es over-split.
SELECT
  src.ssot__LastName__c                  AS family_key,
  COUNT(DISTINCT link.UnifiedRecordId__c) AS unified_individual_count
FROM ssot__Individual__dlm src
JOIN IndividualIdentityLink__dlm link
  ON link.SourceRecordId__c = src.ssot__Id__c
GROUP BY src.ssot__LastName__c
HAVING COUNT(DISTINCT link.UnifiedRecordId__c) > 1
ORDER BY unified_individual_count DESC;

En producción agruparías sobre la key fuerte que esperás única por persona — un party ID o un email verificado unido a través de su DMO de contact point — no un apellido; el apellido de arriba es ilustrativo porque no necesita join extra. La forma es lo que importa: agrupá los registros de origen que deberían ser una persona, contá los individuos unificados distintos, y cualquier cosa arriba de uno es fragmentación.

El arreglo — nombrá la falla, después comprometete con su dirección. Over-merge significa que las reglas matchearon dos personas que no son una: el remedio es endurecer (sacar una regla demasiado floja, o anclar un criterio fuzzy a una key exacta). Over-split significa que las reglas no matchearon a una persona que sí lo es: el remedio es aflojar o reparar la key que alimenta la regla. Son movimientos opuestos; el Paso 1 existe para que hagas el correcto. (Qué tan estricto debería ser el ruleset en primer lugar es el Style Guide de Identity Resolution; esta página es lo que corrés una vez que ya está mal.)

Una vez que sabés qué falla tenés y sobre qué registros, sabés para qué lado moverte. La próxima pregunta es por qué el motor decidió mal. Seguí.

Paso 2 — ¿Qué criterio de match disparó?

Confirmaste un over-merge (o un over-split) sobre registros específicos. Ahora encontrá la regla responsable, porque un ruleset es un OR de grupos-AND — varias reglas, cualquiera de las cuales alcanza para declarar un match — y solo una causó esto. Endurecer la regla equivocada no arregla nada y puede romper un match que funcionaba.

El chequeo — para un over-merge, leé el ruleset y preguntá qué única regla podrían satisfacer ambos registros sospechosos con su grupo-AND completo. Tomá los dos registros de origen que no deberían haber mergeado, alineá sus valores identificatorios normalizados lado a lado, y recorré cada regla: una regla dispara solo si cada criterio en ella se cumple para el par. La regla cuyo grupo-AND completo ambos registros satisfacen es la que los mergeó. Normalmente es una regla con un criterio fuzzy que se para demasiado solo — fuzzy-name con un ancla débil o ausente — dejando pasar a "J. Pérez" y "Juan Pérez". Para un over-split, la lógica se invierte: leé por qué ninguna regla disparó para dos registros que son la misma persona — típicamente cada regla dependía de una key que un registro no tenía o tenía en otra forma.
El síntoma — over-merge: dos registros que ves que son personas distintas comparten un unified_individual_id, y exactamente el grupo-AND de una regla se satisface entre ellos. Over-split: dos registros que son la misma persona quedan bajo unified_individual_id distintos, y el grupo-AND de ninguna regla abarca ambos — cada regla queda derrotada por un criterio faltante o que no coincide.
El arreglo — cambiá esa regla, no el ruleset entero. Over-merge por un criterio fuzzy solitario: anclalo a una key exacta en el mismo grupo-AND (fuzzy-name AND phone-exact) para que la similitud de nombre por sí sola no pueda mergear. Over-split porque las reglas se apoyaban en una key que un registro no tenía: agregá una regla que pueda matchear sobre una key que los registros fragmentados sí compartan, o arreglá la key (Paso 3). Una regla cambiada deliberadamente le gana a un ruleset reescrito en pánico. (Ver match rules sobre cómo se combinan los criterios y por qué un criterio fuzzy rara vez es seguro solo.)

Si la regla responsable está clara y entendés por qué disparó (o no), la lógica está diagnosticada. Pero una regla puede estar escrita perfecta y aun así fallar si los valores que compara nunca se normalizaron igual. Seguí.

Paso 3 — Validá la normalización sobre las keys sospechosas

Cada criterio de match compara valores normalizados, no crudos — email en minúsculas, espacios y puntuación sacados, teléfono empujado hacia una forma canónica. Una regla correcta sobre keys sin normalizar produce las dos fallas: una regla de email exacto que ve Jane@Example.com y jane@example.com como distintos pierde el match y hace over-split; una regla fuzzy sobre keys basura encuentra similitud espuria y hace over-merge. Antes de culpar a la lógica de la regla, probá que las keys que lee están limpias.

El chequeo — traé los valores crudos de la key sospechosa para los registros en cuestión y mirálos como strings, exactamente como se ingirieron. Para un over-split que esperabas que matcheara: ¿son los dos emails el mismo una vez que mentalmente los pasás a minúsculas y los recortás, pero distintos en crudo — queriendo decir que la normalización debería haberlos unificado pero los valores llegaron en una forma que no agarró? Para un over-merge: ¿la key compartida está realmente compartida, o dos valores meramente parecen iguales para una comparación fuzzy siendo personas distintas? Leé las keys directo del DMO de origen, incluidos los DMOs de contact point donde viven el email y el teléfono:

-- Inspeccioná los valores crudos de la key para dos individuos de origen que estás
-- comparando. El email y el teléfono viven en sus propios DMOs, unidos desde el
-- individuo de origen. Leelos como strings: case, espacios al final, puntuación, drift de formato.
SELECT
  src.ssot__Id__c          AS source_individual_id,
  email.ssot__EmailAddress__c AS raw_email,
  phone.ssot__PhoneNumber__c  AS raw_phone
FROM ssot__Individual__dlm src
LEFT JOIN ssot__ContactPointEmail__dlm email
  ON email.ssot__PartyId__c = src.ssot__Id__c
LEFT JOIN ssot__ContactPointPhone__dlm phone
  ON phone.ssot__PartyId__c = src.ssot__Id__c
WHERE src.ssot__Id__c IN ('SOURCE_ID_A', 'SOURCE_ID_B');

El síntoma — over-split con keys que son "obviamente" la misma para un humano: un email tiene un espacio al final o case mezclado, un teléfono es +1 (555) 010-0199 y el otro 5550100199, y el criterio de match exacto correctamente los trató como desiguales porque la normalización no reconcilió los formatos. Over-merge con un criterio fuzzy: dos personas genuinamente distintas cuyos nombres normalizan lo bastante cerca como para que la similitud fuzzy disparara sin un ancla fuerte que la frenara.
El arreglo — arreglá la normalización en la key, no aflojando la regla para tapar data sucia. Si los formatos de teléfono varían por origen, normalizalos a una forma canónica (E.164) antes de matchear; si un email llega con case o espacios que la regla debería ignorar, asegurate de que la normalización lo cubra. Una regla es tan buena como las keys que compara — reparar la key es el arreglo durable, y aflojar una regla para que trague valores sin normalizar solo convierte un over-split en un over-merge futuro. (Ver match keys y normalización sobre qué normalizar y qué keys son lo bastante estables para matchear.)

Una vez que las keys están limpias y la regla está bien, el diagnóstico está hecho — pero el arreglo solo cuenta una vez que se reprocesa en toda la org. El último paso es cambiar la regla y probar que el cambio aterrizó. Seguí.

Paso 4 — Cambiá una regla, después verificá que el reprocesamiento realmente aterrizó

Las match rules no entran en vigor cuando las guardás en aislamiento — guardar un ruleset cambiado dispara reprocesamiento de identity resolution en toda la org: el motor reevalúa los registros de origen afectados, recomputa los mapeos de IndividualIdentityLink__dlm, y reconstruye los perfiles unificados. Eso cuesta, lleva tiempo, y mueve counts. Así que no verificás un cambio de regla releyendo la regla; lo verificás confirmando que el objeto link se movió como predijiste — y un status verde de "reprocesamiento completo" no es esa confirmación.

El chequeo — predecí la dirección antes de cambiar la regla, después medí después. Endurecer para arreglar un over-merge debería subir el count unificado (menos registros de origen colapsan juntos) y bajar el source_record_count por unificado en los perfiles que estabas separando. Aflojar para arreglar un over-split debería bajar el count unificado (más registros colapsan) y llevar el unified_individual_count de tu key sospechosa a uno. Capturá el número de antes, esperá a que termine el reprocesamiento, y volvé a correr la sonda exacta del Paso 1. ¿Se movió el count en la dirección predicha, por aproximadamente la magnitud que esperabas?

-- ANTES y DESPUÉS de un cambio de regla: el count unificado para la población que tocaste.
-- Capturá este número antes de guardar la regla, después volvé a correrlo cuando el
-- reprocesamiento complete. La dirección del movimiento es tu verificación, no el badge de status.
SELECT COUNT(ssot__Id__c) AS unified_individuals
FROM UnifiedIndividual__dlm;

El síntoma de que estás leyendo demasiado temprano — volvés a correr la sonda y los counts no se movieron, o se movieron a medias. El reprocesamiento no es instantáneo; los perfiles unificados que consultás justo después de guardar pueden seguir asentándose, así que un número que parece "sin cambios" puede simplemente estar en vuelo. Igualmente, un status que lee completo mientras tu count apuntado no se movió en absoluto significa que la regla que cambiaste no era la que disparaba (volvé al Paso 2) — el motor corrió, pero sobre lógica que nunca tocó estos registros.
El arreglo — tratá al objeto link como la fuente de verdad de si el cambio funcionó, y reconfirmá sobre los perfiles específicos del Paso 1, no solo el count global. Volvé a correr el abanico de over-merge: ¿se separó el individuo unificado sobre-mergeado en personas distintas? Volvé a correr el group-by de over-split: ¿resuelve ahora la key sospechosa a exactamente un individuo unificado? Que el count global se mueva en la dirección correcta es necesario; que los perfiles específicos resuelvan correctamente es suficiente. Y presupuestá el reprocesamiento — es trabajo facturable (principio 11) y desplaza cada reporte de abajo que se apoya en UnifiedIndividual__dlm, así que avisale a quien lee esos números antes de que se muevan bajo sus pies.

Un diagnóstico que podés correr

Cuando el reporte es "este perfil está mal" y todavía no sabés la dirección, el triage más rápido es dos conteos a través del objeto link, leídos a ojo — sin cambio de regla, sin join directo. Los dos traversan IndividualIdentityLink__dlm; solo arrancan desde puntas opuestas.

Registros de origen por individuo unificado (la sonda de over-merge). Abrí en abanico desde un individuo unificado sospechoso a través del link y contá registros de origen distintos. Un count muy por encima de lo que una persona plausiblemente podría poseer — y cuyos orígenes enlazados, cuando los leés, describen humanos distintos — es over-merge. La dirección del arreglo es endurecer.
Individuos unificados por key que debería ser una persona (la sonda de over-split). Agrupá los registros de origen por una key que debería ser única para una persona, y contá individuos unificados distintos en los que resolvieron a través del link. Cualquier cosa arriba de uno para una persona real es over-split. La dirección del arreglo es aflojar o reparar la key.

La dirección que encontrás dicta todo lo que viene después: endurecer para over-merge, aflojar para over-split, y nunca adivines, porque las dos fallas pueden coexistir en un ruleset y un solo count global esconde ambas. Un individuo unificado que enlaza a quince registros de origen que son claramente tres familias distintas es un over-merge que localizaste a un perfil — sin cambiar una regla, y sin jamás unir origen a unificado directo.

Síntomas comunes mapeados a pasos

| Síntoma | Causa probable | Dónde mirar | |---|---|---| | Un cliente vio los datos de otra persona | Over-merge | Registros de origen por individuo unificado (Paso 1) | | "Clientes activos" saltó después de un cambio de regla | Over-merge u over-split | Dirección del count unificado vs. lo que cambiaste (Paso 4) | | Una persona conocida aparece como varios perfiles | Over-split | Individuos unificados por key que debería ser una persona (Paso 1) | | Dos registros que deberían matchear nunca lo hacen | Over-split — lógica o key | Qué regla no disparó (Paso 2); valores crudos de la key (Paso 3) | | Dos personas claramente distintas mergearon | Over-merge — un criterio fuzzy solitario | Qué grupo-AND de regla satisfacen ambos (Paso 2) | | La regla de email exacto pierde matches obvios | Brecha de normalización | Case / espacios del email crudo en el DMO de origen (Paso 3) | | Cambié la regla, pero el count no se movió | Leyendo demasiado temprano, o regla equivocada | Volvé a correr la sonda del Paso 1 tras reprocesar (Paso 4) |

Relacionado

El individuo unificado — los dos objetos y el puente IndividualIdentityLink__dlm que traversa cada sonda de esta página
Match rules — la lógica de OR-de-grupos-AND que leés en el Paso 2, y por qué un criterio fuzzy rara vez es seguro solo
Gotchas de identity resolution — over-merge, over-split, y las fallas silenciosas que esta página diagnostica, en forma de producción
Debuggear resultados de query — cuando el número equivocado es un bug de query, no de identidad (la capa de arriba)

Referencia: