Reconciliation rules: qué valor gana en el perfil unificado | Cleon

Un ruleset de resolución de identidad en Data 360 (antes Data Cloud) tiene dos mitades. Las match rules deciden qué registros de origen son la misma persona y los agrupan; las reconciliation rules deciden, para ese grupo, qué valor de cada atributo sobrevive hacia UnifiedIndividual__dlm. Esta página es la segunda mitad. Las match rules arman el cluster; las reconciliation rules eligen el ganador dentro de él, un atributo a la vez.

La distinción es fácil de saltear y cara de saltear. Un individuo de origen carga un nombre, un email, un teléfono, una dirección desde cada sistema del que vino. Cuando tres registros de origen colapsan en un solo individuo unificado, ese perfil no puede sostener tres nombres — presenta uno. La reconciliación es la regla que dice cuál. Y ese único valor elegido es lo que lee cada consumidor downstream: el email por el que filtra un segmento, el teléfono al que la activación manda, la dirección con la que un journey personaliza.

Sobre qué corre la reconciliación

La reconciliación nunca corre sola. Corre sobre lo que las match rules ya agruparon — y solo sobre eso. El conjunto de registros de origen que alimenta a un solo UnifiedIndividual__dlm queda fijado por el matching antes de que la reconciliación mire un solo atributo. Si el matching sale mal, la reconciliación es irrelevante: si dos personas distintas se fusionaron, la reconciliación ahora está eligiendo el email "ganador" entre dos clientes, y gane cual gane, el perfil está mal sobre alguien. Si una persona se partió en tres individuos unificados, la reconciliación corre tres veces aislada y ninguno de los tres perfiles está completo.

Así que leé esta página como el segundo movimiento, nunca el primero. La traversal desde un registro de origen hacia el individuo unificado en el que aterrizó siempre pasa por IndividualIdentityLink__dlm — ese link es lo que te dice qué valores de origen eran siquiera candidatos para un atributo unificado dado. Origen y unificado nunca son un join directo; el objeto link es el único mapa honesto del cluster sobre el que operó la reconciliación.

Las cuatro opciones de reconciliación

Para cada atributo, elegís cómo se selecciona el ganador entre los valores de origen candidatos del cluster:

Most Recent — gana el valor del registro de origen con el último timestamp de modificación. El instinto "la data más nueva es la más verdadera" — correcto para un dato de contacto que una persona actualiza activamente, equivocado cuando "lo más recién tocado" es un batch job, no el cliente.
Most Frequent — gana el valor que aparece en más registros de origen. Útil cuando muchos sistemas coinciden y uno es un outlier — cinco fuentes dicen Maria, una dice Mara, la frecuencia elige Maria. Es un voto, así que hereda los sesgos de qué sistemas ingerís: tres feeds derivados de un solo import malo le ganan en votos a dos correctos.
Source Priority / Sequence — le pasás a la reconciliación una lista priorizada de fuentes de datos, y gana el valor de la fuente mejor rankeada que tenga un valor. Esta es la opción determinística: el sistema de registro para el email es el CRM, punto, y la recencia nunca lo pisa. Predecible y auditable de una forma que las otras tres no son.
Last Updated — el valor del registro de origen actualizado más recientemente. En la práctica se superpone fuerte con Most Recent; la línea que importa es si tu timestamp refleja una actualización humana o una de pipeline. Si un sync nocturno estampa cada fila como "actualizada" a las 2am, las dos opciones de recencia están midiendo el sync, no al cliente.

Selección por atributo vs el default del ruleset

La reconciliación se setea por atributo, no una vez para todo el perfil. Un ruleset carga una política default, y la sobreescribís atributo por atributo donde el default está equivocado. Esa granularidad es el punto: la regla correcta para email rara vez es la regla correcta para birthdate o para un tier de loyalty.

Un perfil casi siempre quiere una mezcla. El email y el teléfono — datos que una persona mantiene activamente — muchas veces le quedan bien a Most Recent, si tus timestamps reflejan ediciones reales. La fecha de nacimiento, que nunca debería cambiar, le queda bien a Source Priority apuntada a la fuente más confiable, para que un typo en un feed de baja calidad no pueda pisar un valor verificado solo por ser más nuevo. Un estado que es propiedad de un sistema de facturación le queda bien a Source Priority con facturación rankeada primero. Seteá el default a tu política general más segura, después sobreescribí los atributos donde "más seguro" y "correcto" se separan.

La falla a vigilar: aceptar el default del ruleset en cada atributo porque configurar cada uno es tedioso. Así es como un perfil termina con un email correcto y una fecha de nacimiento que se da vuelta cada vez que una lista de marketing re-importa — nadie eligió eso, el default lo hizo.

Cuándo preferir una lista priorizada de fuentes sobre la recencia

La recencia responde "qué es lo más nuevo". La prioridad de fuente responde "en quién confiamos". Se separan justo cuando lo más nuevo y lo más confiable no son el mismo registro — que es la mayoría de las veces a escala.

Preferí una lista priorizada de fuentes cuando:

Un sistema es el sistema de registro genuino para el atributo — el CRM es dueño del email verificado, la plataforma de facturación es dueña del estado de cuenta — y querés que esa autoridad se sostenga sin importar qué feed escribió último.
Una fuente de baja calidad o alto volumen ganaría de otro modo solo por recencia. Un feed de enriquecimiento nocturno que toca cada fila es "el más reciente" cada noche; la prioridad deja que una fuente más callada y limpia le gane.
El resultado tiene que ser auditable. "El valor del CRM ganó porque el CRM está rankeado primero" es una respuesta que podés defender ante un dueño de negocio. "Ganó el valor del pipeline que corrió último" no lo es.

Preferí la recencia cuando el atributo es algo que el cliente cambia y el cambio debería propagarse rápido — un número de celular recién actualizado, una nueva dirección postal por una mudanza — y confiás en que el timestamp signifique una actualización real. La mayoría de los atributos de contact-point están sobre esta línea, que es justo por qué la pregunta de higiene del timestamp lo decide.

Por qué esto es el principio 4, no configuración

La reconciliación es la mitad de la resolución de identidad que silenciosamente le asigna al cliente su email, nombre y dirección "verdaderos" — y como las match rules, sus fallas son silenciosas. No salta ningún error cuando gana el valor equivocado. El perfil simplemente presenta un email viejo, y lo primero que sabés de eso es un reporte de bounce o un cliente que dejó de recibir mensajes que espera.

Eso hace de la reconciliación una decisión de negocio, no un checkbox — principio 4. Qué fuente es autoritativa para el email, si la fecha de nacimiento debería cambiar alguna vez, qué mide realmente "most recent" en tus pipelines: esto solo se responde con alguien que es dueño de la data. Y como cada regla del ruleset, cambiar la reconciliación dispara reprocesamiento en toda la org — los valores unificados se mueven para cada individuo afectado, así que se presupuesta y se valida, no se togglea.

Relacionado

Match rules — la primera mitad: cómo los registros de origen se agrupan en una sola persona antes de que la reconciliación elija un ganador dentro del grupo
El individuo unificado — sobre qué escribe la reconciliación: UnifiedIndividual__dlm y el puente IndividualIdentityLink__dlm
Gotchas de resolución de identidad — la versión de producción, incluida la sorpresa del "ganó el valor equivocado" y la reconciliación bajo reprocesamiento

Referencia: