Data 360: principios desde producción
Los principios que Cleon aplica en cada build de Data 360 — el modelo primero, la identidad como decisión de negocio, la frescura como feature, agent-ready como propiedad del modelo. Una síntesis de la guía oficial, la práctica de la comunidad y la experiencia de producción de Cleon.
Los principios que Cleon aplica cuando modelamos una org de Data 360 (antes Data Cloud), conectamos un stream, escribimos una match rule, o firmamos que un segmento está listo para activar. Cada uno está anclado en trabajo de implementación, no en slides de best-practice — una síntesis de la guía oficial de Salesforce, lo que la comunidad de práctica aprendió a los golpes, y dónde la experiencia de producción de Cleon se aparta de ambas.
El hilo conductor: en Data 360 el modelo de datos es el producto. Todo lo que viene después — segmentos, Calculated Insights, activaciones, y los agentes que fundamentás sobre él — hereda las decisiones que tomaste cuando el modelo estaba vacío y era fácil de cambiar.
Los principios
1. El modelo de datos es un contrato — diseñalo antes de conectar el primer stream.
Una org de Data 360 con treinta DMOs y sin modelo documentado no se edita, se migra. El modelo es la única decisión de la que dependen todas las demás superficies, y es la más difícil de cambiar justo cuando más importa — después de que la data ya fluye y los segmentos están vivos.
Dibujá el modelo en papel antes de conectar el primer Data Stream: los objetos, su grano, sus keys, sus relaciones. La hora que invertís ahí es la migración de varias semanas que no corrés más adelante.
2. El DLO es crudo, el DMO es significado — no dejes que el lago se filtre al modelo.
Un Data Lake Object es la forma cruda de lo que sea que ingeriste. Un Data Model Object es lo que esa data significa en tu negocio. El error es mapear un DLO a un DMO uno-a-uno y llamarlo modelar — eso solo reubica el desorden del sistema origen en la capa de la que todo lo demás lee.
Mapeá con intención: renombrá, tipá y reformá en el camino del DLO al DMO para que el modelo se lea como tu negocio, no como un export de base de datos.
3. Mapeá a DMOs estándar salvo que puedas defender uno custom.
Salesforce trae DMOs estándar — Individual, Contact Point Email, Party Identification, y el resto — y cargan semántica que las features downstream y los agentes ya entienden. Un DMO custom a veces es lo correcto, pero arranca con cero significado incorporado y te quedás dueño de cada integración que lo toca.
Antes de crear un DMO custom, respondé una pregunta: ¿qué no logra expresar el modelo estándar que esto sí necesita? Si no podés nombrarlo, mapeá a estándar.
4. La resolución de identidad es una decisión de negocio, no un checkbox.
Las match y reconciliation rules deciden cuándo dos registros son la misma persona. Las consecuencias son asimétricas y las fallas son silenciosas.
5. Los data spaces son paredes que construís una sola vez.
Un data space particiona la data de una org por un límite real — marca, región, régimen regulatorio. Lo que vive en uno está mayormente aislado de los demás, y mover data a través de esa pared después no es un setting, es un rebuild.
Particioná por un límite que vas a seguir teniendo en tres años, nunca por conveniencia de corto plazo. Si dos espacios candidatos comparten una audiencia, probablemente quieran ser un solo espacio.
6. La frescura es una feature.
Un insight computado sobre la data de la semana pasada es una respuesta equivocada con seguridad. El valor de Data 360 es que el perfil unificado refleja lo que es verdad ahora — y eso solo se sostiene si tu cadencia de ingesta coincide con las decisiones que tomás sobre la data.
Un stream que refresca a diario alimentando una activación real-time es un bug de latencia esperando para sorprender a alguien. Decidí la frescura que necesita cada consumidor, hacé que la ingesta la cumpla, y dejá la cadencia por escrito para que el próximo no asuma real-time donde hay un lag de 24 horas.
7. Los Calculated Insights son verdad pre-computada — computá una vez, recuperá muchas.
Un Calculated Insight corre la agregación una vez y sirve el resultado en todos lados. La alternativa — recomputar la misma métrica de lifetime-value o engagement al vuelo en cada segmento y cada consumidor — es más lenta, cuesta más, y deriva, porque dos consumidores la computan apenas distinto y ahora no coinciden.
Definí la métrica una vez como un CI; dejá que los segmentos, las activaciones, y sobre todo los agentes la recuperen en vez de re-derivarla.
8. La activación es donde el modelo se encuentra con el mundo.
Todo lo de arriba — modelo, ingesta, identidad, insights — es energía potencial hasta que un segmento se activa en algún lado donde hace trabajo. Para Cleon ese lado es muy seguido Marketing Cloud: un segmento de Data 360 activándose hacia un Journey de MC es el puente que conecta las dos plataformas que la mayoría de los clientes ya corre.
Diseñá el target de activación con tanta intención como el segmento. Un segmento perfecto activado al lugar equivocado es solo una query cara.
9. El consentimiento viaja con la data.
Data 360 es la capa que sabe todo sobre una persona, lo que la vuelve el lugar correcto para hacer cumplir lo que tenés permitido hacer con ese conocimiento — y el peor lugar para olvidarlo.
10. Agent-ready es una propiedad del modelo, no una feature que le atornillás.
Si un analista humano no puede sacar una respuesta coherente sobre un cliente del perfil unificado, un agente tampoco — Agentforce o un LLM externo. "Agent-ready" no es un toggle que activás al final; es lo que ya tenés si el modelo está limpio, la identidad resuelve, los insights están definidos, y todo está documentado.
El agente es apenas el lector más exigente que tu modelo va a tener. Construí para él construyendo bien el modelo.
11. El costo escala con lo que procesás, no con lo que guardás.
Data 360 factura por el trabajo — las filas que escanea un segmento, la data que recomputa un Calculated Insight — mucho más que por lo que está en reposo. Un segmento desprolijo que escanea el perfil entero cada hora es una decisión de costo disfrazada de decisión de lógica.
Diseñá los segmentos y los CIs por cuánto procesan, y revisá los caros. La query más barata es la que no necesitaste correr.
12. Documentá el modelo como una API.
El próximo equipo — y el próximo agente — lee tu modelo en frío. Cada DMO debería cargar una línea que diga qué contiene, cuál es su key, de dónde viene su data, y qué tan fresca es.
Un modelo sin esa doc es una situación de rehén: el conocimiento vive en la cabeza de una persona y la org paga alquiler por él para siempre. Los builds de Data 360 de Cleon salen con una doc del modelo que el equipo del cliente puede leer un lunes a la mañana.
Cierre
Estos no son reglas para memorizar; son el músculo que construís después de que los mismos errores de Data 360 muerden a escala. Son una síntesis — la guía oficial de Salesforce donde acierta, las correcciones que la comunidad ganó a los golpes donde los docs son optimistas, y la experiencia de producción de Cleon donde ambas dejan huecos.
Si encontrás una violación de cualquiera de ellos en nuestro trabajo, escribí a hello@wearecleon.com — lo arreglamos y lo decimos.