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).
La resolución de identidad en Data 360 (antes Data Cloud) produce una sola cosa — el individuo unificado — y después se sale de escena. Las otras cuatro páginas de esta subcategoría cubren cómo se construye ese perfil: match rules, reconciliation rules, las keys sobre las que resolvés. Esta página es la otra mitad de la historia: qué lee el individuo unificado una vez que existe, y por qué cada uno de esos lectores hereda lo que la resolución de identidad decidió, correcto o no.
Ese es el hilo que vale nombrar de entrada. Query, Calculated Insights, Segmentation, la activación y los agentes que apoyás sobre el modelo no re-resuelven la identidad cada uno. Todos se apoyan sobre la única resolución que hizo el ruleset, y todos se rompen de la misma forma cuando está mal — en silencio, y aguas abajo, lejos de la regla que lo causó. "Todo depende de esto" no es un eslogan acá; es la dependencia de datos literal. Esta página la rastrea superficie por superficie, y enlaza a las subcategorías hermanas en vez de re-explicarlas.
Query: qué objeto contás es la primera herencia
La distinción unificado vs origen es más visible en el momento en que escribís SQL, porque los dos objetos de individuo quedan uno al lado del otro y devuelven números distintos a propósito.
ssot__Individual__dlm— el individuo de origen. Una fila por individuo por origen. Cuenta registros.UnifiedIndividual__dlm— el individuo resuelto. Una fila por persona real, después de la resolución de identidad. Cuenta personas.
Cada count que corrés hereda esa elección. SELECT COUNT(*) FROM UnifiedIndividual__dlm responde "¿cuántas personas conocemos?"; el mismo count sobre ssot__Individual__dlm responde "¿cuántos registros tenemos?" — y el segundo número es más grande por exactamente la duplicación que la resolución de identidad colapsó (la relación y la traversal son la columna vertebral de el individuo unificado). Elegí el objeto equivocado y la métrica está mal en todos lados donde se lee, sin ningún error que te avise.
Y no podés atajar entre los dos. Origen a unificado nunca es un join directo — no hay relación modelada desde ssot__Individual__dlm directo a UnifiedIndividual__dlm. Siempre traversás el puente IndividualIdentityLink__dlm en dos saltos, exactamente como muestra la página columna vertebral. Esa regla no se relaja porque ahora estés "solo reportando" — un = escrito a mano sobre algún campo compartido aguas abajo devuelve un mapeo sin verificar tan equivocado en un dashboard como en un pipeline.
Para el dialecto en sí — los identificadores con namespace, el join de keys nullable con IS NOT DISTINCT FROM, y cómo un join solo resuelve donde la relación está modelada — ver Data Cloud SQL. El punto acá es más acotado: la distinción de count que esa página advierte no es una rareza de la capa de query. Es la resolución de identidad, asomando en el primer lugar donde leés el dato.
Calculated Insights: la identidad es el grain de abajo
Un Calculated Insight es una agregación con un grain declarado — dimensiones por las que agrupás, measures que computás en ese grain (principio 7, computá una vez, recuperá muchas). Cuando la dimensión es la persona — lifetime value por cliente, órdenes por individuo, un engagement score por persona — el grain es el individuo unificado. El CI es solo tan correcto como esa resolución.
Acá es donde una falla silenciosa de identidad se vuelve una cara. Si una persona se fragmentó en tres individuos unificados (over-split), un CI por persona computa su lifetime value tres veces, sobre tres historiales parciales, y cada consumidor recupera tres números equivocados como si fueran tres clientes. Si dos personas se mergearon en una (over-merge), sus órdenes se suman en un único perfil inflado. El CI hizo su aritmética perfecta; el grain sobre el que corrió estaba mal antes de empezar. Recomputar el insight no lo arregla — solo arreglar la identidad lo hace, y después reprocesar.
Esa es la palanca y el riesgo de "computá una vez": toda la org recupera el mismo número, así que cuando el grain de abajo está mal, toda la org está mal en la misma dirección al mismo tiempo.
Segmentation: la membresía se cuenta en personas resueltas
Construir un segmento arranca con la elección de Segment On — el objeto que cada miembro de la lista resultante es. Para las audiencias que construye Cleon, ese es casi siempre el individuo unificado, así que "5.000 clientes" significa cinco mil personas resueltas, deduplicadas por identidad, no filas de origen crudas.
Eso hace que la membresía de un segmento sea una herencia directa de la resolución de identidad, y las fallas mapean derecho:
- El over-split infla la audiencia. Una persona fragmentada en tres individuos unificados puede satisfacer una regla tres veces y entrar al segmento tres veces — tres envíos, tres slots de frequency cap, tres de un mismo humano en un número de "alcance único" que ahora es mentira.
- El over-merge filtra entre personas. Dos humanos mergeados en un individuo unificado se vuelven un único miembro; una regla pensada para uno puede arrastrar al otro, y la personalización o la supresión construida sobre ese perfil cruza un límite que no debería.
- La supresión depende del mismo grain. "Excluí a cualquiera que se haya dado de baja" solo funciona si la baja y el target son el mismo individuo unificado. Fragmentá la persona y la supresión se pierde el fragmento que no cargó el flag.
Un segmento construido sobre el individuo unificado es la recompensa de la resolución bien hecha — una persona, cada contact point que cualquier origen aportó, alcanzable a través de canales desde un perfil. Un segmento construido sobre una resolución rota es la misma maquinaria apuntada al count equivocado, y nada en el segment builder lo marca.
Activación: keyeada sobre el individuo unificado
La activación es donde el modelo se encuentra con el mundo (principio 8), y lo que manda hacia afuera está keyeado sobre el perfil resuelto. El individuo unificado es el miembro de audiencia que se activa, cargando los contact points que aportaron sus registros de origen — así una sola persona resuelta puede ser alcanzada en cada email y teléfono que cualquier origen conoció, desde una sola entrada en la activación, en vez de como varias copias de origen desconectadas.
Lo que significa que la activación hereda la identidad al final y de la forma más visible. El over-split le manda a la misma persona el mismo mensaje varias veces, porque cada fragmento se activa como su propio miembro. El over-merge le manda a una persona contenido — o un canal — pensado para alguien con quien se la mergeó por error, que es el momento en que un error silencioso de resolución se vuelve uno visible para el cliente. El target de activación estaba configurado correcto; el individuo de abajo resolvió mal. (El consentimiento viaja sobre el mismo perfil, por eso tiene que estar modelado sobre el individuo unificado y no atornillado en el borde — ver Principios de Data 360, principio 9.)
Agent-readiness: un perfil coherente es el prerrequisito
El lector más exigente del individuo unificado es un agente (principio 10). Preguntale a un agente "¿cuál es el lifetime value de este cliente, y qué compró por última vez?" y responde desde el perfil resuelto — el mismo individuo unificado que lee cada otra superficie, con los mismos CIs recuperados y los mismos contact points adjuntos.
Así que el agent-readiness no es una feature que agregás después de que el modelo está construido; es la consecuencia aguas abajo de que la identidad esté bien. Si un analista humano puede sacar una única respuesta coherente sobre 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 — ninguno puede, y ningún prompt engineering rescata una respuesta ensamblada desde un perfil que resolvió mal por debajo. El agente hereda exactamente la misma resolución que Query cuenta, los CIs agregan, los segmentos targetean y la activación manda; solo que la hereda bajo la luz más fuerte, porque tiene que decir la respuesta de vuelta en una sola oración.
Relacionado
- El individuo unificado — qué produce la resolución, el puente
IndividualIdentityLink__dlm, y el count origen vs unificado que esta página rastrea aguas abajo - Data Cloud SQL — el dialecto donde la distinción de count asoma primero, y la traversal que nunca es un join directo
- Calculated Insights — la métrica por persona cuyo grain es el individuo unificado
- Construir un segmento — membresía contada en personas resueltas, heredando la identidad directo
- Principios de Data 360 — la identidad como decisión de negocio (4), la activación (8), el consentimiento (9), y agent-ready como propiedad del modelo (10)
Referencia: