Data Graph no Salesforce Data Cloud: o que é, para que serve e exemplos práticos

Introdução

Se você já trabalhou com Data Cloud, conhece a sensação: o perfil unificado do cliente está lá, lindo, distribuído em vários DMOs com Calculated Insights atrelados, segmentos calculados, identidade resolvida. Aí o time de produto chega e pergunta: “como o app mobile consome isso em tempo real, com latência abaixo de 300ms ?”.

Fazer JOIN relacional em runtime cruzando 8 DMOs diferentes a cada abertura de tela? Inviável em escala. É exatamente esse problema que o Data Graph resolve.

Este post explica o que é um Data Graph, qual problema arquitetural ele endereça e mostra exemplos práticos — desde a personalização da home do app até o atendimento omnichannel.

O que é um Data Graph

Um Data Graph é uma fotografia pré-computada e materializada de um perfil unificado (Unified Individual) e todos os seus dados relacionados em um único objeto JSON aninhado, otimizado para acesso em baixíssima latência (sub-segundo).

Em vez de o consumidor (app, site, agente de atendimento, Agentforce) precisar fazer múltiplas chamadas para reconstruir o contexto do cliente, o Data Cloud entrega tudo “mastigado” via uma única chamada à Connect API.

Em uma frase

Data Graph é a camada operacional de baixa latência do Data Cloud — a ponte entre a parte analítica (DMOs, Calculated Insights, segmentação) e os canais que precisam de resposta em tempo real.

O problema que ele resolve

Imagina o seguinte cenário no Data Cloud “tradicional”:

O perfil unificado do cliente está distribuído em vários DMOs
Transações, produtos, interações, atributos, tudo espalhado e relacionado
Calculated Insights pré-calculam métricas como LTV, churn score, frequência de compra
Segmentos calculam booleanos como “Cliente VIP” ou “Recém-cadastrado”

Quando o app mobile do varejo abre a home personalizada do cliente, ele precisa dessas informações em menos de 300ms para não atrapalhar a experiência. Sem Data Graph, o backend do app teria que orquestrar:

Uma chamada ao CRM para dados cadastrais
Uma chamada ao sistema de fidelidade para pontos
Uma chamada ao DW para histórico recente
Uma chamada ao Data Cloud para checar segmentos
Uma chamada ao motor de cupom para verificar elegibilidade

Cinco chamadas, cinco pontos de falha, latência somada acima de 1 segundo. Péssima UX.

Anatomia de um Data Graph

Todo Data Graph tem três camadas conceituais:

Primary DMO

DMO raiz, geralmente Unified Individual ou Account. É o ponto de entrada e a chave de busca.

→

Related DMOs

DMOs ligados ao raiz por relacionamentos 1:N ou N:1 (pedidos, transações, casos, produtos).

→

Calculated Insights

Métricas pré-computadas que viajam junto no payload (LTV, churn score, frequência).

A grande vantagem é que tudo é materializado e mantido atualizado pelo próprio Data Cloud conforme os DMOs subjacentes recebem novos dados. O consumidor externo só precisa fazer uma chamada e recebe o pacote completo.

Caso de uso: personalização da home do app de varejo

Imagina uma rede de varejo de moda — pense em algo, sim essa mesmo que veio a sua mente agora. O time de produto quer que, ao abrir o app, o cliente veja:

Saudação personalizada com o primeiro nome
Tier do programa de fidelidade (Bronze / Prata / Ouro)
Saldo de pontos atual
Última categoria comprada (para sugerir itens complementares)
Cupom ativo se o cliente está no segmento “alto valor + sem compra há 30 dias”
Loja favorita (para mostrar estoque local)

Modelando o Data Graph

O Customer_360_Retail_DG ficaria assim:

Primary DMO: Unified Individual
Campos: FirstName, LastName, Email, Phone, BirthDate

Related DMO 1: Loyalty Program Member (1:1)
Campos: Tier, PointsBalance, EnrollmentDate

Related DMO 2: Sales Order (1:N, limitado aos últimos 5 pedidos)
Campos: OrderDate, TotalAmount, StoreId
Sub-related: Order Product → Product (categoria, marca)

Related DMO 3: Engagement (1:N, últimas 10 interações)
Campos: Channel, ActionType, Timestamp

Calculated Insights atrelados:

LTV_12M (Lifetime Value dos últimos 12 meses)
Days_Since_Last_Purchase
Favorite_Category
Favorite_Store_Id
Churn_Propensity_Score

Segmentos atrelados (membership booleano):

High_Value_Lapsed
Premium_Tier_Active

O que o app recebe em uma única chamada

GET /services/data/v60.0/ssot/data-graphs/Customer_360_Retail_DG/Maria_CPF_12345

{
  "FirstName": "Maria",
  "LastName": "Silva",
  "Email": "maria@email.com",
  "LoyaltyMember": {
    "Tier": "Ouro",
    "PointsBalance": 4820
  },
  "RecentOrders": [
    {
      "OrderDate": "2026-04-22",
      "TotalAmount": 389.90,
      "StoreId": "SP_MORUMBI",
      "Products": [
        { "Category": "Vestidos", "Brand": "Marca X" }
      ]
    }
  ],
  "Insights": {
    "LTV_12M": 3450.00,
    "Days_Since_Last_Purchase": 14,
    "Favorite_Category": "Vestidos",
    "Favorite_Store_Id": "SP_MORUMBI",
    "Churn_Propensity_Score": 0.23
  },
  "Segments": {
    "High_Value_Lapsed": false,
    "Premium_Tier_Active": true
  }
}

Latência típica: abaixo de 300ms. Uma chamada. Tudo coeso. O time de app não precisa orquestrar nada — só renderizar.

Caso de uso 2: atendimento omnichannel

O mesmo Data Graph alimenta outro cenário comum no varejo: a tela 360 do agente de atendimento.

Cliente liga na central reclamando de uma troca. O agente abre o Service Cloud e o componente de tela faz uma chamada ao mesmo Customer_360_Retail_DG. Em menos de um segundo o atendente já enxerga:

Cliente Ouro com LTV de R$ 3.450 nos últimos 12 meses
Última compra há 14 dias na loja Morumbi
Categoria favorita: Vestidos
Score de churn baixo (cliente engajado)

Com isso, o playbook de atendimento muda em tempo real:

Cliente Ouro com baixo churn → o agente tem alçada para oferecer cupom de R$ 50 e reter a satisfação
Cliente Bronze com alto churn → script diferente, foco em resolução técnica sem desconto

A mesma estrutura também alimenta Agentforce: o agente de IA consulta o Data Graph para entender o contexto antes de responder ao cliente no chat. Sem isso, a resposta do agente seria genérica.

Data Graph vs. Segmentação tradicional

Uma confusão comum é tentar usar segmentação tradicional para resolver problemas que pedem Data Graph (ou vice-versa). A regra prática é olhar para o canal e a latência exigida:

Cenário	Segmentação	Data Graph
Audiência para campanha de email batch	✓	—
Personalização de home no app em tempo real	—	✓
Tela 360 do cliente no atendimento	—	✓
Contexto para Agentforce/Copilot responder	⚠	✓
Relatório analítico de coorte	✓	—
Trigger de jornada no Marketing Cloud	✓	⚠

Resumindo: sempre que um canal precisa de “me dá o perfil completo desse cliente AGORA”, a resposta é Data Graph.

Pontos de atenção arquiteturais

Antes de sair criando Data Graph para tudo, alguns guardrails importantes que aprendi na prática:

Limites da plataforma

Existe limite de número de Data Graphs por org, de profundidade de relacionamentos (geralmente até 5 níveis) e de tamanho de payload (~2MB por registro). Modelar mal = payload gigante = latência ruim. Inclua só o que realmente é usado em runtime.

Frescor dos dados. Data Graphs são materializados e atualizados conforme os DMOs subjacentes recebem novos dados. Não é “tempo real puro” — há uma janela de propagação que pode variar de minutos. Para casos de fraude ou limite PIX em tempo real estrito, considere streaming insights combinados.

Governança de PII. O Data Graph herda as permissões dos DMOs. Cuidado ao expor campos sensíveis (CPF, dados de saúde, score de crédito) via API. Use Data Spaces para segregar contextos e Field-Level Security religiosamente.

Versionamento. Trate o schema do Data Graph como contrato de API. Alterar campos quebra consumidores downstream. Tenha processo de change management e versionamento explícito quando possível.

Custo de consumo. Cada chamada à Connect API conta para os limites de credit consumption do Data Cloud. Em apps de alto volume, avalie cache em CDN/edge para dados que não mudam a cada segundo.

Conclusão

Data Graph é um dos recursos mais transformadores do Salesforce Data Cloud para quem precisa operacionalizar os dados unificados — não só analisá-los. Ele resolve um problema concreto de arquitetura: como entregar contexto rico de cliente em latência sub-segundo, sem orquestração custosa no consumidor.

Se você está modelando perfis no Data Cloud e ainda não pensou em quais Data Graphs vai expor, vale parar e listar: quais canais consomem perfil de cliente em tempo real? Cada um deles é candidato natural a um Data Graph dedicado.

No próximo post pretendo entrar em como modelar bem um Data Graph desde o dia 1 — escolha de Primary DMO, profundidade ideal de relacionamentos e como evitar payloads gigantes que matam a latência. Se tiver dúvidas ou cenários específicos que quer ver cobertos, me chama no LinkedIn.