Skip to main content

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.

Marco de decisión·Actualizado 2026-06-01·Escrito por Lira · Editado por German Medina

Esta es la página donde Cleon deja de describir qué es la identity resolution y empieza a decir cómo la afinamos. Salesforce define las superficies. Las páginas de referencia de esta subcategoría documentan cada una — el unified individual que produce, las match rules que deciden quién es la misma persona, las reconciliation rules que eligen qué valor gana, las claves sobre las que resolvés, y cómo la identidad resuelta alimenta todo lo de abajo — y los gotchas documentan dónde la resolución silenciosamente falla. Este Style Guide es la disciplina que mantiene confiable a un ruleset el día que corre sobre una org entera y decide qué humanos son el mismo humano.

Usalo como checklist antes de que cualquier ruleset se cree o cambie. Las reglas son cortas a propósito — cuando una regla necesita explicación, la explicación está en la página que linkea. Una decisión está por encima de todas las demás, así que va primero.

La decisión central: ¿qué tan estricto debería ser el match?

Casi toda elección de identity resolution en Data 360 (antes Data Cloud) se reduce a una bifurcación: ¿afinás las reglas hacia la consolidación — sueltas, para que más registros de origen colapsen en un unified individual — o hacia la precisión — estrictas, para que un registro solo se fusione con evidencia fuerte? Aflojá demasiado y dos personas distintas se fusionan en un perfil y pueden ver la data una de la otra; apretá demasiado y una persona se fragmenta en varios perfiles y nada reconcilia. Acertá esto y el resto de la subcategoría es detalle. Erralo y ambas fallas son silenciosas — no salta ningún error en ninguno de los dos casos — y el arreglo es un cambio de ruleset que reprocesa la org, no un setting que cambiás.

Tres preguntas lo deciden. Respondelas en orden.

1. ¿Cuál es el costo de un false merge acá versus un false split?

Los dos modos de falla no son igual de malos, y tenés que nombrar cuál puede permitirse menos esta org o este caso de uso en voz alta, primero — antes de tocar un solo criterio. Un false merge (over-merge, reglas demasiado sueltas) filtra la data de un cliente dentro del perfil de otro: ven las órdenes uno del otro, la supresión se filtra entre ellos, y en un canal que carga consent es un incidente de privacidad, no una molestia de métricas — la peor falla en la mayoría de los contextos B2C y de consent. Un false split (over-split, reglas demasiado estrictas) fragmenta una persona en varios perfiles: las métricas cuentan doble, un conjunto de supresión pierde algunos de sus registros, y la vista única silenciosamente no es una. Ambas son silenciosas. Decidí contra qué riesgo se inclinan las reglas a propósito, y dejá que esa asimetría fije la estrictez por default — la mayor parte del trabajo que carga consent se inclina hacia la precisión y trata al false merge como el inaceptable.

2. ¿Tenés una clave determinística fuerte, o solo señales probabilísticas?

La estrictez que podés permitirte está topeada por las claves sobre las que resolvés. Una clave determinística limpia y verificada — un valor de party identification como un loyalty ID o un CRM ID, un email personal confirmado, un mobile personal — te deja inclinarte más estricto y matchear sobre igualdad con confianza; el exact match sobre una clave fuerte es lo más defendible que puede hacer una regla. Solo señales fuzzy — un nombre de texto libre más geografía — te fuerzan más suelto, y un criterio fuzzy tiene que quedar anclado a una clave exacta en la misma regla (acordate que una match rule es un AND de sus criterios), nunca solo, y nunca como única base de un canal que carga consent. Si la única clave que tenés es un nombre, la respuesta honesta es que todavía no podés resolver con seguridad — arreglá la clave, no aflojes la regla.

3. ¿El negocio firmó las reglas contra datos reales — y está presupuestado el reprocesamiento?

La identity resolution es una decisión de negocio, no un checkbox — principio 4. Qué origen es autoritativo para email, si un match solo por nombre es alguna vez aceptable, qué cuenta como clave fuerte acá: estas se responden solo con alguien que es dueño de la data, validadas contra registros reales, no con láminas de best practices. Y el costo tiene una segunda mitad. Cambiar match rules o reconciliation rules dispara reprocesamiento a lo largo de la org: el motor reevalúa los registros de origen, recomputa los mapeos de IndividualIdentityLink__dlm, reconstruye los unified profiles — cuesta (Data 360 factura sobre el trabajo procesado, principio 11), lleva tiempo, y los unified counts se mueven en el momento en que corre. Presupuestá el reprocesamiento y avisale a quien lee los counts antes de cambiar una regla en vivo, no después de que los números se mueven.

Este es el paralelo exacto con la decisión batch publish versus data action en tiempo real de la capa de segmentación, una capa más arriba — una bifurcación deliberada con dos modos de falla y un reprocesamiento, no un rebuild, detrás de la elección equivocada — y con la misma disciplina de firma del negocio: afiná la identidad a la falla que el negocio menos puede permitirse, nunca a lo que los defaults hayan producido.

Patrones a preferir

  • La falla inaceptable nombrada primero — false merge o false split — y la estrictez fijada para inclinarse contra ella a propósito.
  • Un criterio exacto sobre una clave determinística fuerte (party ID, email verificado, mobile personal) como columna vertebral de cada ruleset.
  • Nombre fuzzy anclado a una clave exacta en la misma regla — fuzzy-name AND phone-exact, nunca el nombre solo — y reservado para contextos donde un false merge es genuinamente barato.
  • Normalización confirmada sobre cada match key antes de que el ruleset corra, para que un over-split no venga del casing o del formato de teléfono.
  • Reconciliation elegida por atributo, con Source Priority donde existe un sistema de registro y recencia solo donde el timestamp significa una edición humana real.
  • El ruleset testeado contra datos reales con el negocio firmado — principio 4 — antes de que corra sobre la org entera.
  • El reprocesamiento presupuestado y los unified counts que se mueven anunciados antes de que una regla en vivo cambie, no explicados después.

Patrones a rechazar

  • Una regla solo de nombre fuzzy sobre una audiencia que carga consent — el over-merge clásico, dos personas fusionadas y después viendo la data una de la otra.
  • Una pasada de tuning de "aflojalo hasta que los counts se vean bien" — persiguiendo un unified count objetivo sin ninguna vista sobre si las personas correctas se fusionaron.
  • Origen-a-unified joineado directo para chequear qué hizo una regla — el camino no existe en el modelo; siempre traversá IndividualIdentityLink__dlm.
  • Una clave que parece fuerte confiada sin una auditoría de unicidad real — un loyalty ID reusado o una dirección info@ mapeada como personal fusiona personas que no son la misma.
  • El default del ruleset aceptado sobre cada atributo porque configurar cada uno es tedioso — así es como una fecha de nacimiento verificada se da vuelta cada vez que un feed de baja calidad reimporta.
  • Una regla cambiada en una org en vivo sin presupuesto de reprocesamiento y nadie avisado de que los counts están por moverse.
  • "Resolvió" tratado como "resolvió correctamente". No salta ningún error para ninguna de las dos fallas — verificá contra registros reales (debuggear identity resolution).

El chequeo de agent-readiness

Un unified individual coherente es el prerequisito para que un agente responda sobre un cliente — agent-ready es una propiedad del modelo, no una feature que enchufás al final (principio 10). El chequeo es una línea: si un analista humano no puede sacar una única foto correcta de este cliente del unified profile, tampoco puede un agente — Agentforce o un LLM externo. La identidad resuelve antes de que un perfil esté agent-ready: una persona fragmentada en tres unified rows, o dos personas fusionadas en una, rompe al analista y al agente por igual, y ningún prompt engineering arregla un perfil que resolvió mal por debajo. La decisión de estrictez de esta guía es, al final, la que decide si el modelo se puede groundear siquiera.

El checklist de pre-ship antes de que cualquier cambio de ruleset se publique

  • [ ] La falla inaceptable está nombrada — false merge o false split — y la estrictez está fijada para inclinarse contra ella a propósito, no dejada en el default.
  • [ ] Cada match rule tiene un criterio exacto sobre una clave determinística fuerte; ningún criterio fuzzy está solo, y ninguno maneja un canal que carga consent por sí mismo.
  • [ ] Las match keys están confirmadas pobladas, realmente únicas, y normalizadas antes de que el ruleset corra.
  • [ ] La reconciliation está seteada por atributo — Source Priority donde existe un sistema de registro, recencia solo donde el timestamp refleja una edición humana real — no el default del ruleset en todos lados.
  • [ ] El ruleset se testeó contra datos reales y el dueño del negocio firmó (principio 4), antes de que corra sobre la org entera.
  • [ ] El reprocesamiento está presupuestado — costo y tiempo — y a quien lee los unified counts se le avisó que se van a mover.
  • [ ] Lo que el cambio hizo se verificó inspeccionando IndividualIdentityLink__dlm, nunca un join directo de origen a unified.
  • [ ] El unified profile es lo suficientemente coherente como para que un analista — y por lo tanto un agente — pueda sacar una respuesta correcta sobre un cliente (principio 10).

Cuando todas tildan, el ruleset está listo para publicar.

Relacionado

Si encontrás una regla que falta — o una de estas reglas violada en nuestro trabajo público — escribí a hello@wearecleon.com. La agregamos, o la arreglamos y lo decimos.