Skip to main content

Match keys y normalización: sobre qué resolvés la identidad

Qué compara realmente la resolución de identidad: los DMOs y campos que hacen de match keys — party identification, contact point email y phone, nombre y fecha de nacimiento del individuo — y la normalización que corre primero. Qué hace fuerte y estable a una key frente a una frágil, y por qué una key sin normalizar falla en silencio.

Referencia·Actualizado 2026-06-01·Escrito por Lira · Editado por German Medina

Las match rules deciden cuándo dos registros son la misma persona. Esta página es la capa de abajo de esa decisión: qué comparan las reglas. En Data 360 (antes Data Cloud), la resolución de identidad nunca matchea sobre "un registro" en abstracto — matchea sobre campos específicos, en DMOs específicos, después de que esos valores fueron normalizados. Elegí las keys equivocadas, o salteá la normalización, y las reglas que escribiste en match rules corren contra valores que nunca iban a alinear.

Esta es la referencia de las keys en sí. La mecánica de cómo se combinan los criterios vive en match rules; el modelo de datos sobre el que se apoyan esas keys vive en Data Model Objects. Acá cubrimos qué campos vale la pena matchear, qué les hace la normalización primero, y cómo distinguir una key que aguanta de una que silenciosamente no.

Sobre qué matcheás: los DMOs que cargan las keys

La resolución de identidad compara atributos que viven en los DMOs estándar de perfil. Los que cargan las keys que vale la pena matchear:

  • ssot__PartyIdentification__dlm — las keys más fuertes que tenés. Este DMO guarda identificadores que un sistema ya emitió y respalda: un número de loyalty, un ID de registro de CRM, el customer ID de un sistema externo. Cada uno, por construcción, está pensado para apuntar a exactamente un party. Un match sobre una party identification verificada es lo más cerca de la certeza que ofrece la resolución de identidad.
  • ssot__ContactPointEmail__dlm — el email como match key. Fuerte cuando es una dirección real y verificada, porque la mayoría de la gente no comparte una; más débil en el momento en que es una dirección compartida del hogar o de rol (info@, family@).
  • ssot__ContactPointPhone__dlm — el teléfono como match key. La misma lógica que el email: un celular personal es una buena key, una línea fija compartida o un número de conmutador no.
  • ssot__Individual__dlm — el registro de la persona en sí, que carga los atributos a los que recurrís cuando no hay un identificador duro: nombre (ssot__FirstName__c, ssot__LastName__c) y fecha de nacimiento. Estas son las keys probabilísticas — útiles en combinación, peligrosas solas.

El patrón en los cuatro: una key es fuerte en proporción a qué tan única y estable apunta a un humano. La party identification es fuerte por diseño. Un nombre de pila de texto libre no es una key en absoluto por sí solo — es una pista.

Normalización: lo que corre antes de la comparación

Dos registros pueden describir a la misma persona y aun así no matchear, porque los strings difieren aunque los valores no. JANE@EXAMPLE.COM y jane@example.com son el mismo buzón. +1 (415) 555-0100, 415-555-0100 y 4155550100 son el mismo teléfono. La resolución de identidad normaliza los valores de las keys a una forma canónica antes de compararlos, para que las diferencias cosméticas no se lean como personas distintas:

  • Case-folding — nombres y emails comparados sin importar mayúsculas o minúsculas.
  • Trim de whitespace — espacios al inicio, al final y colapsados en el interior removidos, así " Jane " y "Jane" son un solo valor.
  • Teléfono a un formato canónico — números reducidos a una forma consistente (estilo E.164) para que el formato, los espacios y la puntuación no fragmenten un match.
  • Email a minúsculas — la dirección plegada a minúsculas para que lo único que distinga dos emails sea la dirección real.

El punto no son las transformaciones específicas — es el orden. La normalización es el paso que convierte el valor de una key en algo comparable. Salteala y la match rule está comparando presentación, no identidad.

Keys fuertes frente a keys frágiles

La fuerza de una match key es la fuerza de la resolución que produce. Una forma útil de rankearlas:

  • Fuertes y estables — una party identification verificada (ssot__PartyIdentification__dlm), un email personal o celular confirmado. Apuntan a un party, cambian rara vez, y sobreviven la normalización limpio. Apoyate en estas; son las que te dejan matchear de forma determinística (ver match rules).
  • Usables en combinación — nombre más fecha de nacimiento, nombre más teléfono. Ninguna sola es decisiva, pero juntas restringen el match lo suficiente para ser defendible. Para esto existe el fuzzy matching.
  • Frágiles por sí solas — un nombre de texto libre solo, un email compartido del hogar, una dirección de rol. Matchear sobre un nombre por sí solo es cómo dos personas distintas que se llaman igual colapsan en un solo individuo unificado — el over-merge, la falla que filtra privacidad. Nunca resuelvas identidad sobre un nombre de texto libre como key autónoma, y menos para algo que dispara un canal sujeto a consentimiento.

Una key no es fuerte porque el campo esté poblado. Es fuerte porque el valor identifica única y durablemente a una persona y sobrevive la normalización a una forma estable. Un ssot__LastName__c perfectamente poblado sigue siendo una key frágil.

Basura entra, basura se resuelve — sin error

Las keys son el input de la resolución de identidad, y la resolución de identidad hereda su calidad exactamente. Este es el modo de falla que más sorprende a la gente: las keys malas no tiran error. Un campo de teléfono lleno de formatos inconsistentes, una columna de email con ruido de casing y whitespace, un "customer ID" que en realidad se reusa entre cuentas — ninguno de estos produce un error de validación. Producen mala resolución: over-splits donde las keys debían matchear y no lo hicieron, over-merges donde una key no-única matcheó a personas que no son la misma.

Esto es el principio 1 en su forma más literal: modelá las keys deliberadamente. Decidí, mientras el modelo todavía está vacío, qué campos son tus match keys, confirmá que están poblados y normalizados, y tratá una key no-única o sin normalizar como un defecto a arreglar antes de que corra la resolución de identidad — no un número a explicar después. Y es el principio 4: como la falla es silenciosa, las keys son parte de lo que el negocio firma contra datos reales, no un setting en el que confiás por defecto.

Relacionado

Referencia: