El individuo unificado: cómo Data 360 resuelve muchos perfiles en uno | Cleon

La resolución de identidad en Data 360 (antes Data Cloud) tiene un solo trabajo y una sola salida: tomar los muchos registros de origen que describen a la misma persona y producir un único perfil resuelto — el individuo unificado. Todo lo demás en esta subcategoría — match rules, reconciliation rules, las keys sobre las que resolvés — existe para hacer que esa única salida sea correcta. Esta página es la columna vertebral: qué es el individuo unificado, cómo se relaciona con los registros de origen de los que se construyó, y la única regla de traversal que no podés equivocar.

Si venís de Marketing Cloud, el instinto es imaginar una tabla deduplicada. No lo es. Los registros de origen no se borran, ni se mergean, ni se sobrescriben. Quedan exactamente como aterrizaron, y la resolución de identidad construye un objeto nuevo al lado de ellos que apunta de vuelta a todos. Entender esa forma de dos capas — origen abajo, unificado arriba, un puente en el medio — es toda la página.

Dos objetos, no uno: origen vs unificado

Hay dos DMOs de individuo, y confundirlos es el error más caro de la subcategoría.

ssot__Individual__dlm — el individuo de origen. Una fila por individuo por origen. Si la misma persona existe en tu CRM, tu plataforma de e-commerce y una lista de newsletter, eso son tres filas acá. Los DMOs estándar cargan el namespace ssot__ y el sufijo __dlm; este es uno de ellos.
UnifiedIndividual__dlm — el individuo resuelto. Una fila por persona real, producida por la resolución de identidad después de decidir qué filas de origen son el mismo humano. Deja caer el prefijo ssot__ a propósito — el nombre señala que es post-resolución, no alineado al origen.

La capa de origen es lo que ingeriste. La capa unificada es lo que concluyó la resolución de identidad. Responden preguntas distintas — "¿cuántos registros tenemos?" frente a "¿cuántas personas conocemos?" — y devuelven números distintos por diseño.

La relación de counts: unificado es siempre ≤ origen

Como las filas de origen que matchean colapsan en un individuo unificado, la aritmética corre siempre en una sola dirección:

count de UnifiedIndividual__dlm ≤ count de ssot__Individual__dlm

Son iguales solo en el caso degenerado donde cada registro de origen es una persona distinta y nada matcheó. En el momento en que dos registros cualesquiera resuelven al mismo humano, el count unificado cae por debajo del count de origen — y ese gap es la deduplicación que hizo la resolución de identidad.

Por eso contar el objeto equivocado no es un error de redondeo. Si tu métrica de "clientes activos" cuenta individuos de origen, silenciosamente cuenta dos veces a cualquiera que exista en dos sistemas. Cambiala a individuos unificados y el número baja — no porque perdiste clientes, sino porque dejaste de contar a la misma persona dos veces. Las métricas que mezclan los dos objetos entre reportes nunca reconcilian, y la discrepancia parece un bug de datos mucho antes de que alguien sospeche del grain (principio 4 — la identidad es una decisión de negocio, y el count es el primer lugar donde esa decisión se ve).

El puente: `IndividualIdentityLink__dlm`

El individuo unificado no guarda de qué filas de origen se construyó. Ese mapeo vive en un objeto aparte: IndividualIdentityLink__dlm, el puente que mantiene la resolución de identidad. Cada fila del objeto link ata un individuo de origen al único individuo unificado en el que resolvió.

Esa forma — muchas filas de origen, cada una enlazando hacia arriba a una fila unificada — es lo que permite que el count unificado quede por debajo del count de origen. También significa que la relación está modelada a través del link, no guardada como foreign key en ninguno de los dos lados. No hay columna en ssot__Individual__dlm que nombre a su individuo unificado, ni columna en UnifiedIndividual__dlm que liste sus orígenes. El objeto link es la relación.

El patrón de traversal

Para ir de un individuo de origen a su individuo unificado — o al revés — hacés join a través del objeto link en dos saltos. Los nombres exactos de los campos siguen el modelo de tu org; la forma es la constante:

-- Individuo de origen -> su individuo unificado, traversado a través del link.
-- Dos saltos, nunca un join directo. Aliaseá y calificá cada columna.
-- 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 corre en la otra dirección. Para ver qué registros de origen colapsaron en un individuo unificado — la query que agarrás cuando un perfil parece sobre-mergeado — arrancás desde la fila unificada y abrís en abanico a través del link:

-- Un individuo unificado -> todos los registros de origen que resolvieron en él.
-- Más de un puñado de orígenes distintos para una persona es un olor que vale revisar.
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;

Contar filas de origen por individuo unificado es también cómo medís la deduplicación: un individuo unificado con un solo registro de origen enlazado nunca matcheó con nada; uno con cinco significa que la resolución de identidad plegó cinco filas de origen en una sola persona. (Para el comportamiento completo de las cláusulas y el join de keys nullable con IS NOT DISTINCT FROM, ver Data Cloud SQL.)

Qué agrega el perfil unificado

Una vez que los registros de origen resuelven en un individuo unificado, el perfil se vuelve el único lugar desde donde un consumidor aguas abajo lee a la persona — pero no copia físicamente cada campo. Pasan dos cosas:

Los atributos se reconcilian. Cuando dos filas de origen no coinciden — emails con distinto last-modified, dos direcciones postales — las reconciliation rules deciden qué valor gana en el individuo unificado. Esa selección es su propia superficie; ver reconciliation rules para cómo Most Recent, Source Priority y el resto eligen al ganador.
Los contact points se adjuntan al individuo unificado. El email y el teléfono viven en sus propios DMOs — ssot__ContactPointEmail__dlm, ssot__ContactPointPhone__dlm — y una vez que los individuos de origen dueños resuelven, esos contact points pertenecen al individuo unificado. Una persona con tres registros de origen puede cargar cada dirección de email que los tres aportaron, ahora alcanzable desde un perfil resuelto. Por eso un segmento construido sobre el individuo unificado puede apuntarle a una persona a través de cada canal que cualquier origen conoció, en vez de tratar la copia de cada origen como un miembro de audiencia separado.

El individuo unificado es, en otras palabras, la única respuesta coherente sobre una persona ensamblada a partir de fragmentos que llegaron por separado. Esa coherencia es exactamente lo que hace al modelo agent-ready (principio 10): si un analista humano puede sacar una imagen única y correcta de un cliente desde el perfil unificado, también puede un agente apoyado sobre él. Si la identidad está rota — la persona fragmentada en tres filas unificadas, o dos personas mergeadas en una — ni el analista ni el agente pueden responder, y ninguna cantidad de prompt engineering arregla un perfil que resolvió mal por debajo.

Relacionado

Match rules — cuándo Data 360 decide que dos registros de origen son la misma persona
Reconciliation rules — una vez que matchean, qué valor de atributo gana en el individuo unificado
Data Cloud SQL — el dialecto con el que traversás el objeto link y contás el perfil unificado
Principios de Data 360 — por qué la identidad es una decisión de negocio (4) y agent-ready es una propiedad del modelo (10)

Referencia: