La ingesta y el ciclo de vida: lo que hereda cada capa de abajo | Cleon

La ingesta es el frente del ciclo de vida de Data 360 (antes Data Cloud), y el ciclo de vida es una herencia de una sola dirección: ingerir → modelar → resolver identidad → consultar → segmentar y activar, con el agente leyendo todo al final. Cada capa se construye sobre la anterior, lo que significa que cada capa hereda la anterior — incluidos sus errores. Un Data Stream aterriza un origen como un Data Lake Object (DLO) — los API names terminan en __dll — y todo lo que pasa después de eso está aguas abajo de una decisión que tomaste en el frente.

Esta página es el hilo conductor de la subcategoría Ingesta: no cómo configurar un stream — eso es data streams y refresh modes — sino por qué la ingesta es la capa que pone el techo de todas las demás. El argumento es simple y es la razón por la que esta subcategoría existe: hacé mal la ingesta y el síntoma aparece a tres capas de distancia, disfrazado de otro.

El ciclo de vida es una cadena de herencia

Pensá las cinco capas como una cadena, donde cada eslabón solo puede ser tan fuerte como el que lo alimenta.

INGERIR         MODELAR            RESOLVER         QUERY / SEGMENTAR    AGENTE
(esta           (Arquitectura      IDENTIDAD        & ACTIVAR           (lee
 subcategoría)   de datos)                                              todo)
   │                │                  │                   │               │
 DLO (__dll) ──map──▶ DMO (__dlm) ──unif.──▶ individuo ──preguntar /──▶ respuestas
 aterrizaje       significado        resuelto      apuntar             fundamentadas
 crudo            armonizado

Nada en esta cadena repara lo que vino antes. La resolución de identidad unifica los registros que ingeriste; no inventa los que te olvidaste de transmitir. Una query cuenta lo que el modelo contiene; no recupera un campo que nunca aterrizó. Una activación manda el segmento que construiste; no se da cuenta de que el perfil detrás está un día viejo. El ciclo de vida se mueve en una sola dirección, y la ingesta es su origen.

Esa es toda la razón por la que "el modelo de datos es el producto" (principio 1) empieza en el stream. El modelo es un contrato, pero el contrato es tan bueno como lo que volcás en él — y lo que volcás es trabajo de la ingesta.

El handoff de DLO a DMO

Lo primero que entrega la ingesta es el DLO, y la entrega es a Arquitectura de datos, no a un consumidor de aguas abajo. La responsabilidad de un Data Stream para en aterrizar el objeto crudo; convertir ese DLO en un Data Model Object (DMO) — los API names terminan en __dlm, los estándar en el namespace ssot__ — es el paso de modelado, y está documentado en mapping. Esta página no lo redefine.

Lo que importa para el ciclo de vida es la costura. El DLO es lo que ingeriste, en la forma del origen. El DMO es lo que significa, en la forma de tu negocio. El mapping es la traducción deliberada entre los dos — qué campo carga qué significado, cuál es la key, cómo se relacionan los objetos — y es el primer lugar donde un consumidor de aguas abajo ve tus datos. Así que en el handoff tienen que ser ciertas dos cosas:

El DLO tiene que cargar de verdad lo que el DMO necesita. El mapping puede renombrar, retipar y reformar un campo, pero no puede conjurar uno que nunca transmitiste. Si el individuo resuelto necesita un email y la ingesta nunca aterrizó un campo de email, ninguna cantidad de modelado lo produce.
El grain y la categoría tienen que coincidir con la intención del modelado. Aterrizá datos de evento como un stream Profile en vez de Engagement (ver data streams) y la capa de modelado hereda una serie temporal sin línea de tiempo — un defecto que no existía en la ingesta y que no se puede reparar del todo después.

La frescura y la corrección fluyen aguas abajo

Dos propiedades de una ingesta se propagan por toda la cadena: qué tan fresco está el dato y si es correcto. Las dos se fijan en el frente, y las dos aparecen lejos de donde se fijaron.

La frescura es un feature (principio 6), y se hereda. Un DLO está exactamente tan fresco como su schedule de refresh, y todo lo construido sobre él también. Un perfil está tan fresco como su stream contribuyente más lento; un segmento está tan fresco como ese perfil; una activación está tan fresca como ese segmento. Un stream que refresca a diario detrás de una activación en tiempo real no es un bug de stream que vas a encontrar en el stream — es un bug de latencia que aparece como un cliente recibiendo el mensaje de ayer, tres capas aguas abajo, donde nadie está mirando la ingesta. La cadencia tiene que coincidir con la decisión más fresca que el dato alimenta, y tenés que anotarla para que el próximo no asuma tiempo real donde hay un retraso de 24 horas.

La corrección también se hereda, y en silencio. La decisión de corrección que define la ingesta es full refresh versus upsert (ver refresh modes). La trampa es que una primary key equivocada o no única en un upsert no da error — duplica o sobrescribe registros en silencio, y la duplicación fluye hacia adelante. La resolución de identidad después intenta unificar un perfil que ya tiene registros fantasma adentro; la query los cuenta; el segmento los apunta. Los números dejan de significar lo que pensás, y la causa raíz es una decisión de key tomada en el frente que ninguna capa de abajo puede ver.

Rastreá los síntomas hasta el origen y el patrón es consistente:

La resolución de identidad produce demasiados o demasiado pocos perfiles unificados. Muchas veces la match rule está bien y el problema es la ingesta: registros duplicados de una mala key de upsert, o un campo de contact point que nunca aterrizó, así que dos personas reales no se pueden enlazar. La capa de resolución solo puede trabajar con lo que llegó — ver el individuo unificado.
Un segmento cuenta mal o corre sobre datos viejos. La lógica del segmento es correcta; el perfil debajo heredó una ingesta vieja o duplicada. El arreglo está en el stream, no en el constructor de segmentos — ver construir segmentos.
Un agente da una respuesta segura pero equivocada sobre un cliente. Agent-ready es una propiedad del modelo (principio 10), y el modelo es una propiedad de la ingesta. Si un analista humano no puede confiar en el perfil unificado, tampoco puede Agentforce ni un LLM externo — y la desconfianza se rastrea hasta lo que el frente del ciclo de vida dejó pasar. El agente es solo el lector más exigente de todo lo que la ingesta decidió.

Todo empieza acá

La consecuencia práctica es un instinto de debugging: cuando un número está mal a tres capas de profundidad, sospechá del frente del ciclo de vida antes de sospechar de la capa en la que estás parado. Una porción sorprendente de los problemas de "la resolución de identidad está rota", "el count del segmento está mal" y "el agente está alucinando" son problemas de ingesta disfrazados de aguas abajo — un refresh viejo, un upsert mal-keyeado, un campo faltante, un stream mal categorizado.

Ese es el hilo del que cuelga toda esta subcategoría. La ingesta no es un paso de setup que completás y olvidás; es la capa de la que cada otra capa depende en silencio por el resto de la vida de la org. Aterrizala deliberadamente, hacé coincidir la cadencia con la decisión, nombrá la key, y entregá un DLO que el modelo pueda usar de verdad — porque todo lo de abajo lo hereda, lo hayas diseñado para eso o no.

Relacionado

Mapping — el handoff de DLO a DMO en detalle: dónde termina la ingesta y empieza el modelo
El individuo unificado — qué puede y qué no puede recuperar la resolución de identidad de lo que ingeriste
Construir segmentos — por qué un segmento es tan fresco y correcto como la ingesta debajo
Principios de Data 360 — la frescura como feature (principio 6) y agent-ready como propiedad del modelo (principio 10)

Referencia: