Cuando Data Cloud fue anunciado, el mercado lo clasificó como "el CDP de Salesforce". Era una lectura razonable en 2023 — perfil unificado, segmentación, activación. Pero lo que pasó desde entonces cambió el juego, y muchas empresas todavía implementan con la cabeza antigua.
La frase corta: Data Cloud en 2026 es la capa de contexto sobre la cual el resto de la plataforma decide. CDP es una de las funciones, no la definición.
El salto más allá del CDP
Un CDP clásico resuelve tres cosas: ingesta, unificación de identidad y activación a canales de marketing. Útil, pero estrecho. Data Cloud hoy lleva:
- Modelos de datos armonizados (Customer 360 Data Model) — no solo perfiles, sino pedidos, casos, contactos, productos, dispositivos, conversaciones.
- Pipeline analítico incorporado — capacidad de computar métricas, modelar features, entrenar modelos sobre el propio dato vivo.
- Capa de activación universal — no solo martech: alimenta Service Cloud, Sales Cloud, Commerce, Marketing Cloud en casamiento natural y lo que aparezca.
- Contexto para agentes — es de aquí que Agentforce extrae lo que necesita para decidir en tiempo real.
La diferencia es arquitectónica, no comercial. Un CDP es un sistema; Data Cloud es una fundación. El debate "Customer 360 vs CDP" se volvió pregunta de vendor — la decisión real es qué capa de dato de cliente necesita tu operación primero.
Tratar Data Cloud como CDP es como usar un data warehouse solo para correr reportes. Funciona, pero cuesta el futuro.
Por qué Agentforce sin Data Cloud es ciego
Los agentes necesitan contexto. Un agente de atención que no sabe el historial del cliente, el estado de los pedidos, el valor del contrato y los tickets anteriores responde rápido — cosas equivocadas. Ese contexto puede venir de mil lugares, pero si viene fragmentado, el agente se vuelve lento (latencia de API) o impreciso (datos desactualizados).
Data Cloud resuelve esto con perfiles materializados en tiempo real que el agente consulta como una sola fuente. Sin joins, sin ETL nocturno, sin cache desincronizado. El agente toma el contexto y actúa.
¿Sin Data Cloud, se puede hacer? Se puede. Pero estás construyendo un ETL informal debajo del agente, que se convertirá en deuda técnica en el segundo trimestre.
Tres trampas comunes en la implementación
Veo el mismo conjunto de errores repetirse. Vale catalogarlos.
1. Implementar Data Cloud sin revisar la arquitectura de identidad
La unificación que Data Cloud hace depende de reglas de matching bien configuradas. Los equipos saltan esta etapa, encienden la ingesta de todo, y quedan con perfiles fragmentados. Resultado: el agente ve tres "Juan Pérez" y no sabe cuál es el cliente al frente. Invertir 3–4 semanas en el diseño de identidad al inicio ahorra meses de retrabajo.
2. Tratar Data Cloud como destino, no como fuente
La tentación es importar todo a Data Cloud y parar ahí. Pero el valor real está en activar de vuelta — segmentos en Marketing, listas en Sales, contexto en Service. Si la empresa no diseña los flujos de activación desde la fase de discovery, el proyecto se vuelve un data warehouse caro.
3. Mezclar datos calientes y fríos en el mismo modelo
Data Cloud es poderoso, pero no es el lugar para historial de 10 años de transacción. Úsalo para datos calientes (operacionales, en tiempo real, contexto de cliente vivo). El historial va al lake/warehouse que ya tienes. Trying-to-replace-everything siempre falla.
Cómo empezar bien
Si estás evaluando Data Cloud, tres movimientos que separan proyectos que prosperan de los que se atascan:
- Empieza por el caso de uso de activación, no por la ingesta. Define dónde Data Cloud va a entregar valor (un agente, una jornada, una segmentación) y solo ingiere lo que ese caso de uso necesita. Como en cualquier rollout Salesforce serio, el discovery del proceso viene antes de la configuración — Data Cloud no escapa de la regla.
- Trata identidad como proyecto separado. El diseño de identity resolution merece su propio sprint, con QA dedicado. No lo intentes hacer junto.
- Conecta a tu data stack existente, no la sustituyas. Snowflake, BigQuery, Databricks continúan. Data Cloud es la capa de contexto operacional, no el sustituto del warehouse analítico.
Quien acepte este diseño hoy, en 2027 va a tener una plataforma que sirve agentes, activación y analítica sobre una sola fundación. Quien aún implementa Data Cloud como "CDP" estará revisando arquitectura el año que viene.