Match rules: cuándo Data 360 dice que dos registros son la misma persona | Cleon

La identity resolution en Data 360 (antes Data Cloud) corre dos tipos de regla en secuencia: las match rules deciden qué registros de origen son la misma persona, y las reglas de reconciliación deciden, una vez matcheados, qué valor de atributo gana en el perfil resultante. Esta página es la primera mitad — cómo el motor mira dos registros ssot__Individual__dlm y decide que colapsan en uno solo UnifiedIndividual__dlm. La reconciliación es su propia página (ver reglas de reconciliación).

Esta es la decisión que el resto del sistema hereda. Hacela bien y una persona que existe en tres sistemas de origen se vuelve un individuo unificado sobre el que todo lo de abajo puede razonar. Hacela mal y o bien fusionás dos personas que no son la misma, o no fusionás a una persona que sí lo es — las dos en silencio. La identity resolution es una decisión de negocio, no un checkbox (principio 4).

El match ruleset

Un match ruleset es el conjunto de match rules individuales que el motor evalúa para un DMO — típicamente el Individual. Cada regla nombra uno o más criterios de match; un ruleset suele tener varias reglas, y a un registro de origen le alcanza con satisfacer una sola de ellas para matchear. Ese "una sola" es toda la forma de cómo se combinan las match rules, y vale la pena enunciarlo con precisión antes que nada, porque es donde se deciden el over-merge y el over-split.

Cómo se combinan los criterios: un OR de grupos-AND

Leé un match ruleset como un OR de grupos-AND:

Una match rule individual es un AND de sus criterios — cada criterio de esa regla tiene que cumplirse para que la regla dispare.
El ruleset es el OR de sus reglas — que dispare cualquiera de las reglas alcanza para declarar un match.

Entonces un ruleset como "match por email exacto, O por (nombre fuzzy Y teléfono exacto)" matchea un par cuando sus emails son exactamente iguales, o cuando sus nombres son un match fuzzy y sus teléfonos son exactamente iguales. Dos registros que comparten solo un nombre fuzzy — y nada más — no matchean, porque no se satisface el grupo-AND completo de ninguna regla.

Ruleset = Regla A  OR  Regla B  OR  Regla C
Regla A = email-exacto
Regla B = nombre-fuzzy  AND  teléfono-exacto
Regla C = party-id-exacto

Agregar una regla afloja el ruleset (una manera más de matchear). Agregar un criterio dentro de una regla endurece esa regla (una cosa más que tiene que cumplirse). Tener esos dos movimientos separados en la cabeza es la diferencia entre ensanchar una red a propósito y romperla sin querer.

Match exacto vs match fuzzy

Los criterios de match vienen en dos tipos, y la distinción gobierna cuánto podés confiar en la regla.

Match exacto — los dos valores tienen que ser iguales después de normalizar. Este es el criterio para un identificador fuerte: un email verificado (ssot__ContactPointEmail__dlm), un teléfono (ssot__ContactPointPhone__dlm), o un valor de party identification (ssot__PartyIdentification__dlm) como un número de loyalty o un ID de CRM. El match exacto sobre una key limpia es lo más defendible que puede hacer una match rule.
Match fuzzy — los valores se comparan por similitud en vez de por igualdad, para absorber la variación normal en datos cargados por humanos. Data 360 ofrece match fuzzy principalmente sobre el nombre (así "Bob" y "Robert", o un typo con letras transpuestas, igual pueden matchear). El match fuzzy es tan útil como peligroso: es el criterio con más chances de fusionar dos personas distintas, por eso rara vez dejás un criterio fuzzy parado solo — lo emparejás con uno exacto en el mismo grupo-AND, como en nombre-fuzzy AND teléfono-exacto de arriba.

La normalización corre primero

Cada criterio compara valores normalizados, no crudos. Antes de evaluar cualquier regla, Data 360 estandariza las keys — pasa el email a minúsculas, saca espacios y puntuación, reformatea los teléfonos hacia una forma canónica — de modo que Jane@Example.com y jane@example.com se traten como el mismo valor y no como dos. Sin eso, una regla de email exacto pierde matches obvios y te queda over-split sin más razón que el case.

La normalización es lo que hace que tanto los criterios exactos como los fuzzy se porten, así que las keys sobre las que matcheás y cómo se normalizan es un tema propio (ver match keys y normalización). Para esta página, la regla es simple: el motor matchea sobre el valor normalizado, así que la calidad de tus match rules está topeada por la calidad de tu normalización.

Correr matching es reprocesar

Las match rules no entran en vigor calladas. Guardar un ruleset nuevo o 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 tiene tres consecuencias que conviene presupuestar:

Cuesta. Reprocesar es trabajo, y Data 360 factura sobre el trabajo procesado (principio 11) — cambiar un ruleset no es gratis para iterar.
Lleva tiempo. Reprocesar no es instantáneo; los perfiles unificados que consultás justo después de un cambio pueden seguir asentándose.
Los counts se mueven. Una regla más floja baja el count unificado (más registros colapsan juntos); una más estricta lo sube (colapsan menos). Si un reporte de abajo se apoya en UnifiedIndividual__dlm, sus números se mueven en el momento en que matching reprocesa — a propósito, pero sorprende a quien lee el reporte si nadie le avisó.

Como source-a-unificado lo media el objeto puente, confirmás qué hizo un cambio de regla inspeccionando IndividualIdentityLink__dlm — cuántos individuos de origen resuelven ahora a un individuo unificado — nunca uniendo ssot__Individual__dlm con UnifiedIndividual__dlm directo, que no es un camino que el modelo exponga.

Las consecuencias asimétricas

La razón por la que afinar las match rules merece cuidado real es que sus dos modos de falla no son igual de malos, y ninguno tira un error:

Muy floja → over-merge. Personas distintas se fusionan en un solo UnifiedIndividual__dlm. 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 esto es un incidente de privacidad, no una molestia de métricas.
Muy estricta → over-split. Una persona se fragmenta en varios individuos unificados. Las métricas duplican el conteo, un set de supresión se pierde algunos de sus registros, y la "vista única" que prometió la plataforma calladamente no está.

Las dos son invisibles hasta que alguien nota un número que no puede ser — o un cliente ve un pedido que no es suyo. Contra qué riesgo deberían inclinarse tus reglas es una decisión deliberada, enmarcada por la asimetría de arriba; ese encuadre vive en el Style Guide. Lo que esta página afirma es más acotado y no negociable: probá el ruleset contra datos reales y que el negocio dé el sí antes de que corra sobre toda la org (principio 4).

Relacionado

El individuo unificado — qué produce el matching: el perfil unificado y el puente IndividualIdentityLink__dlm
Match keys y normalización — sobre qué matcheás, y la normalización que corre antes de cada regla
Reglas de reconciliación — una vez que dos registros matchean, qué valor de atributo gana en el perfil unificado
Gotchas de identity resolution — over-merge, over-split, y las otras fallas silenciosas en producción

Referencia: