Gotchas de arquitectura de Data 360: las decisiones de modelo que sobreviven a todo
El modelo de datos de Data 360 parece un wizard de setup — conectás un stream, mapeás unos campos, listo. La realidad de producción es la opuesta: el modelo es la única decisión que heredan todos los segmentos, Calculated Insights, activaciones y agentes fundamentados, y es la más difícil de cambiar después de que la data fluye. Diez decisiones de arquitectura de modelo que muerden, cada una con la pregunta que tenés que responder primero y el costo de equivocarte.
La mayoría de la documentación de Data 360 (antes Data Cloud) trata el modelo de datos como un wizard que corrés una vez: conectás un Data Stream, aceptás los data lake objects que crea, mapeás unos campos a objetos estándar, listo. La realidad de producción es la opuesta — el modelo es la única decisión que heredan todas las demás superficies. Los segmentos, los Calculated Insights, las activaciones, la resolución de identidad, y cualquier agente que fundamentes sobre el perfil leen todo lo que decidiste cuando el modelo estaba vacío y era fácil de cambiar.
Diez decisiones de modelo de datos que mordieron a los builds de Data 360 de Cleon, sintetizadas con la guía oficial de Salesforce y las correcciones que la comunidad de práctica aprendió a los golpes. Cada una viene con la pregunta a responder antes de la decisión y el costo de equivocarte. El framing no es "cuál es la respuesta correcta" — es "cuál es la pregunta que tenés que estar listo para defender".
Los gotchas
1. El DLO y el DMO no son la misma capa — confundirlos filtra el lago en tu modelo
Un Data Lake Object (DLO) es el aterrizaje crudo de un stream ingerido — la forma del sistema origen, tal cual. Un Data Model Object (DMO) es la vista armonizada y con significado de negocio de la que lee todo lo de abajo; los DMOs son vistas sobre los DLOs. El error es tratarlos como intercambiables: construir segmentos o Calculated Insights directo contra DLOs, o mapear un DLO a un DMO uno-a-uno sin armonizar nada.
El costo llega después: cada consumidor downstream hereda la forma y el naming crudos del origen, así que el día que un origen cambia una columna, los segmentos y los insights se rompen en silencio. Antes de aceptar el modelo que propone un Data Stream, respondé: para cada objeto ingerido, ¿cuál es su significado armonizado, y qué DMO lo expresa?
2. El mapping es donde se asigna el significado — un mapping equivocado está mal en todos lados, en silencio
El mapping conecta campos del DLO con atributos del DMO. Es el paso más consecuente del modelo y el menos visible: un campo mapeado al atributo equivocado, o sin mapear, no tira ningún error. Simplemente produce valores equivocados o vacíos en cada segmento, Calculated Insight y activación que lee ese atributo.
Esta es la falla que se descubre semanas después, cuando una campaña apunta a la gente equivocada y alguien lo rastrea hasta un campo state mapeado a country. La pregunta a responder: ¿quién revisa cada mapping contra la semántica real del origen — lo que el campo significa — y no solo si el nombre de la columna parece correcto?
3. La primary key de un DMO es casi permanente — elegila como elegís SubscriberKey
La primary key de un DMO determina cómo deduplican sus registros y cómo se le unen los otros objetos. Una vez que la data está ingerida y la resolución de identidad corrió contra ella, cambiar la key es un rebuild, no una edición — cada relación y cada join downstream dependen de ella. Los veteranos de Marketing Cloud reconocen la forma: es la decisión de SubscriberKey, una capa más arriba.
El costo de equivocarte es re-keyear el modelo cuando ya está en producción. La pregunta: ¿qué identifica de forma única y estable a una fila de este DMO durante toda la vida del registro — no qué es cómodo en el origen hoy?
4. Un DMO custom arranca con cero significado incorporado — mapeá a estándar salvo que puedas defenderlo
Salesforce trae DMOs estándar — Individual, Contact Point Email, Party Identification, y el resto del modelo de datos de Customer 360 — y cargan semántica que la resolución de identidad, la segmentación y Einstein ya entienden. Un DMO custom a veces es lo correcto, pero arranca sin significado incorporado y te quedás dueño de cada integración que lo toque alguna vez.
El costo es el comportamiento prefabricado que resignás y el cableado que heredás. Antes de crear un DMO custom, respondé una pregunta: ¿qué no logra expresar el modelo estándar que este objeto sí necesita? Si no podés nombrarlo, mapeá a estándar.
5. Los data spaces son particiones que construís una sola vez — particioná por un límite, no por conveniencia
Un data space aísla la data de una org por un límite real — marca, región, régimen regulatorio. Lo que vive en un espacio está mayormente amurallado del resto, y mover data a través de esa pared después es un rebuild, no un setting.
El costo de una partición hecha por conveniencia es una pared permanente alrededor de la cual ingenierás durante años. La pregunta antes de crear un espacio: ¿es un límite que vas a seguir teniendo en tres años, y su audiencia es genuinamente disjunta de la de cualquier otro espacio? Si dos espacios candidatos comparten una audiencia, probablemente quieran ser uno.
6. Las relaciones que no modelás son joins que no podés hacer downstream
Las relaciones entre DMOs son lo que deja a un segmento o a un Calculated Insight traversar de un objeto a otro — individuos a sus órdenes, órdenes a sus ítems. Una relación que no modelaste es un traversal que la segmentación silenciosamente no puede hacer: el día que alguien necesita "individuos cuyas órdenes este trimestre superan un umbral", el filtro no está disponible.
El costo es descubrir el hueco a mitad del build, y entonces cambiar el modelo con todo ya dependiendo de él. La pregunta: ¿qué traversals van a necesitar los segmentos y los insights, y esas relaciones están modeladas antes de construir los consumidores?
7. Sobre-normalizar el modelo convierte cada segmento en un join multi-salto
Un modelo partido en muchos DMOs chiquitos es prolijo en el pizarrón y lento en producción: cada query útil traversa varias relaciones, lo que cuesta tiempo y consumo en cada refresh. La lección de la comunidad, aprendida contra cargas reales, es modelar para cómo se consulta la data de verdad, no para la normalización de manual.
El costo son refreshes de segmento lentos y una factura de consumo que escala con la profundidad del join. La pregunta: ¿cuál es el camino de query común que toman tus segmentos e insights, y el modelo lo mantiene corto?
8. Ingerir PII sin un plan de consentimiento y uso de datos hornea un hueco de compliance en el modelo
Data 360 unifica todo lo que sabés de una persona, lo que lo vuelve el punto de enforcement natural del consentimiento y el propósito de uso — y el peor lugar para dejarlos como un después. Modelar el consentimiento después de que la PII ya está ingerida, unificada y activando es al revés.
9. No tener convención de naming para DLOs y DMOs es la misma deriva que cincuenta Data Extensions sin prefijo
Sin una convención escrita, una org de Data 360 acumula docenas de objetos cuyo propósito es una adivinanza y cuyo dueño es desconocido — la misma deriva exacta que los equipos de Marketing Cloud conocen de tenants llenos de Data Extensions sin prefijo. Compone porque cada objeto nuevo hace más difícil nombrar el siguiente de forma consistente.
El costo es una org que se vuelve permanentemente más difícil de operar. La pregunta a responder antes de que exista el primer objeto: ¿cuál es la convención de naming, y quién tiene la autoridad para hacerla cumplir en cada DLO y DMO nuevo?
10. "Agent-ready" no es un estado por defecto — un modelo fragmentado o sin documentar no puede fundamentar un agente
La versión más moderna de este error: asumir que una vez que la data está en Data 360, un agente — Agentforce o un LLM externo — simplemente puede usarla. Pero un agente lee el mismo modelo que un humano. Si la identidad no resuelve, las relaciones no están modeladas, y ningún objeto está documentado, el agente hereda el mismo lío fragmentado, y responde con seguridad igual.
El costo es un agente que se equivoca con seguridad, lo cual es peor que uno que no puede responder. La pregunta es la honesta: ¿puede un analista humano sacar una respuesta coherente y completa sobre un cliente del perfil unificado hoy? Si no, ningún agente puede tampoco.
El hilo conductor de los diez: un modelo limpio, bien mapeado y documentado es la precondición del grounding. Un agente — Agentforce o un LLM externo — solo puede recuperar lo que el modelo expone con coherencia, así que cada gotcha de arriba es también un gotcha de agent-readiness. El trabajo que vuelve productivo a un analista humano sobre el perfil unificado es el mismo que vuelve seguro apuntarle un agente.
Cierre
Estos diez son las decisiones de arquitectura de modelo que Cleon vio morder más fuerte en builds de Data 360. El tema compartido hace eco de la configuración de Marketing Cloud: la plataforma hace fácil la decisión fácil y deliberada la decisión durable. Aceptar el modelo autogenerado, saltarse la revisión de mapping, diferir el consentimiento, postergar la convención de naming — ninguna es difícil en el momento, y cada una es una corrección de varias semanas una vez que la data fluye y los segmentos están vivos.
La disciplina que previene la mayoría es la misma que previene las versiones de MC: un modelo diseñado en papel y revisado por alguien que ya corrió un build de Data 360 antes, con la autoridad de frenar un go-live hasta que el modelo esté bien.
Si un gotcha de modelo de datos mordió a tu equipo y no está acá, escribí a hello@wearecleon.com — lo agregamos, con crédito.
Referencia: