DATA 360 / RESOLUCIÓN DE IDENTIDAD
Resolución de identidad
Match y reconciliation rules, el individuo unificado, y la diferencia entre un perfil que resuelve limpio y uno que fusiona silenciosamente dos clientes en uno.
Fundamento · 2
Nota de producción
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.
Marco de decisión
Data 360 Identity Resolution: Style Guide
Las reglas opinadas que Cleon aplica a cada decisión de identity resolution en Data 360 — una pregunta en el centro, qué tan estricto debería ser el match, enmarcada por el costo asimétrico de un false merge versus un false split, la fuerza de la clave sobre la que resolvés, y si el negocio firmó contra datos reales con el reprocesamiento presupuestado. Patrones a preferir, patrones a rechazar, el chequeo de agent-readiness, y un checklist de pre-ship antes de que cualquier cambio de ruleset se publique. El documento de disciplina que ata la subcategoría Identity Resolution.
Referencia · 5
Referencia
El individuo unificado: cómo Data 360 resuelve muchos perfiles en uno
Qué produce la resolución de identidad: el individuo unificado. UnifiedIndividual__dlm frente al ssot__Individual__dlm de origen, el puente IndividualIdentityLink__dlm que mapea origen a unificado, por qué la traversal de origen a unificado siempre pasa por ese link y nunca es un join directo, y por qué contar el objeto equivocado rompe silenciosamente toda métrica aguas abajo.
Referencia
Match rules: cuándo Data 360 dice que dos registros son la misma persona
Cómo Data 360 decide que dos registros de origen son la misma persona: match rulesets, match rules individuales, match exacto (email / teléfono / party ID) vs match fuzzy (nombre), y cómo los criterios se combinan como un OR de grupos-AND. Qué reprocesa correr matching, y por qué las reglas flojas y las estrictas fallan ambas en silencio.
Referencia
Reconciliation rules: qué valor gana en el perfil unificado
Una vez que las match rules agruparon registros de origen en una sola persona, las reconciliation rules deciden qué valor de cada atributo gana en UnifiedIndividual__dlm — por atributo. Most Recent, Most Frequent, Source Priority, Last Updated: qué hace cada una, cuándo preferir una lista priorizada de fuentes sobre la recencia, y por qué este es el email y la dirección que la activación realmente manda.
Referencia
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
Identidad unificada aguas abajo: lo que hereda cada otra superficie
Cómo la identidad resuelta alimenta todo lo demás — y por qué todo lo demás depende silenciosamente de ella. Contar UnifiedIndividual__dlm frente al ssot__Individual__dlm de origen en Query, la identidad como el grain bajo los Calculated Insights y la membresía de Segmentation, la activación keyeada sobre el individuo unificado, y por qué un perfil unificado coherente es el prerrequisito para que un agente responda sobre un cliente (principio 10).