Quando Data Cloud foi anunciado, o mercado classificou como "o CDP do Salesforce". Era uma leitura razoável em 2023 — perfil unificado, segmentação, ativação. Mas o que rolou de lá pra cá mudou o jogo, e muita empresa ainda implanta com a cabeça antiga.
A frase curta: Data Cloud em 2026 é a camada de contexto sobre a qual o restante da plataforma decide. CDP é uma das funções, não a definição.
O salto além do CDP
Um CDP clássico resolve três coisas: ingestão, unificação de identidade e ativação para canais de marketing. Útil, mas estreito. Data Cloud hoje carrega:
- Modelos de dados harmonizados (Customer 360 Data Model) — não só perfis, mas pedidos, casos, contatos, produtos, dispositivos, conversasções.
- Pipeline analítico embutido — capacidade de computar métricas, modelar features, treinar modelos sobre o próprio dado vivo.
- Camada de ativação universal — não só martech: alimenta Service Cloud, Sales Cloud, Commerce, Marketing Cloud em casamento natural, e o que mais aparecer.
- Contexto pra agentes — é daqui que Agentforce puxa o que precisa pra decidir em tempo real.
A diferença é arquitetural, não comercial. Um CDP é um sistema; Data Cloud é uma fundação. O debate "Customer 360 vs CDP" virou pergunta de vendor — a decisão real é qual camada de dado de cliente sua operação precisa primeiro.
Tratar Data Cloud como CDP é como usar um data warehouse só pra rodar relatório. Funciona, mas custa o futuro.
Por que Agentforce sem Data Cloud é cego
Agentes precisam de contexto. Um agente de atendimento que não sabe o histórico do cliente, status dos pedidos, valor do contrato e tickets anteriores responde rápido — coisas erradas. Esse contexto pode vir de mil lugares, mas se ele vem fragmentado, o agente fica lento (latência de API) ou impreciso (dados desatualizados).
Data Cloud resolve isso com perfis materializados em tempo real que o agente consulta como uma única fonte. Sem joins, sem ETL noturno, sem cache desincronizado. O agente puxa o contexto e age.
Sem Data Cloud, dá pra fazer? Dá. Mas você está construindo um ETL informal por baixo do agente, que vai virar dívida técnica no segundo trimestre.
Três armadilhas comuns na implantação
Vejo o mesmo conjunto de erros se repetindo. Vale catalogar.
1. Implantar Data Cloud sem revisar a arquitetura de identidade
A unificação que Data Cloud faz depende de regras de matching bem configuradas. Times pulam essa etapa, ligam ingestão de tudo, e ficam com perfis fragmentados. Resultado: o agente vê três "João Silva" e não sabe qual é o cliente em frente. Investir 3-4 semanas no design de identidade no início economiza retrabalho de meses.
2. Tratar Data Cloud como destino, não como fonte
A tentação é importar tudo pra Data Cloud e parar por aí. Mas o valor real está em ativar de volta — segmentos no Marketing, listas no Sales, contexto no Service. Se a empresa não desenha os fluxos de ativação desde a fase de discovery, o projeto vira um data warehouse caro.
3. Misturar dados quentes e frios no mesmo modelo
Data Cloud é poderoso, mas não é o lugar pra histórico de 10 anos de transação. Use-o pra dados quentes (operacionais, em tempo real, contexto de cliente vivo). O histórico vai pro lake/warehouse que você já tem. Trying-to-replace-everything sempre falha.
Como começar bem
Se você está avaliando Data Cloud, três movimentos que separam projetos que prosperam dos que travam:
- Comece pelo caso de uso de ativação, não pelo ingest. Defina onde Data Cloud vai entregar valor (um agente, uma jornada, uma segmentação) e ingira só o que esse caso de uso precisa. Como em qualquer rollout Salesforce sério, o discovery do processo vem antes da configuração — Data Cloud não foge da regra.
- Trate identidade como projeto separado. Design de identity resolution merece sprint próprio, com QA dedicado. Não tente fazer junto.
- Conecte ao seu data stack existente, não substitua. Snowflake, BigQuery, Databricks continuam. Data Cloud é a camada de contexto operacional, não o substituto do warehouse analítico.
Quem aceita esse desenho hoje, em 2027 vai ter uma plataforma que serve agentes, ativação e analítica numa só fundação. Quem ainda implanta Data Cloud como "CDP" vai estar revisando arquitetura no ano que vem.
Perguntas que sempre voltam
Antes de fechar, três dúvidas que aparecem em quase toda conversa sobre Data Cloud.
Data Cloud substitui o data warehouse (Snowflake, BigQuery)?
Não — e tentar substituir tudo sempre falha. Data Cloud é a camada de contexto operacional: dados quentes, em tempo real, do cliente vivo. Histórico de 10 anos de transação continua no lake ou warehouse que você já tem. Snowflake, BigQuery e Databricks não saem do stack; Data Cloud conecta neles.
A confusão vem de tratar Data Cloud como destino: importar tudo e parar por aí. O valor real está em ativar de volta — segmentos no Marketing, listas no Sales, contexto no Service. Sem os fluxos de ativação desenhados desde o discovery, o projeto vira um data warehouse caro.
Dá pra usar Agentforce sem Data Cloud?
Dá, mas você está construindo um ETL informal por baixo do agente — e isso vira dívida técnica no segundo trimestre. Agente precisa de contexto: histórico do cliente, status de pedidos, valor de contrato, tickets anteriores. Quando esse contexto vem fragmentado de mil lugares, o agente fica lento (latência de API) ou impreciso (dado desatualizado) — responde rápido, mas coisas erradas.
Data Cloud resolve com perfis materializados em tempo real que o agente consulta como fonte única: sem joins, sem ETL noturno, sem cache desincronizado. O agente puxa o contexto e age.
Por onde começar uma implantação de Data Cloud?
Pelo caso de uso de ativação, não pelo ingest. Defina onde Data Cloud vai entregar valor — um agente, uma jornada, uma segmentação — e ingira só o que esse caso precisa. Como em qualquer rollout Salesforce sério, o discovery do processo vem antes da configuração.
Dois complementos: trate identity resolution como projeto separado, com sprint próprio e QA dedicado — investir 3-4 semanas no design de identidade no início economiza meses de retrabalho com perfis fragmentados. E conecte ao data stack existente em vez de substituí-lo: Data Cloud é camada de contexto operacional, não o novo warehouse analítico.