Qual é a diferença, em uma frase?
Uma plataforma de dados do cliente (CDP) coleta dados de clientes de todas as fontes, resolve-os em uma identidade por pessoa e sincroniza públicos com outras ferramentas: infraestrutura de dados que não envia nada aos clientes. Uma plataforma de engajamento do cliente (CEP) é a camada de ativação: seu próprio armazenamento de perfis e eventos, mais os segmentos, as jornadas e as mensagens que chegam às pessoas. Este guia compara as duas categorias; para o checklist de decisão (limites, sinais, custos), veja nosso guia Você precisa de uma CDP?.
O que uma CDP faz que uma CEP não faz?
Uma CDP coleta eventos e atributos de todas as fontes (SDKs no seu site e app, fluxos do lado do servidor, importações do seu data warehouse e das ferramentas de cobrança), resolve-os em uma identidade por pessoa e sincroniza os públicos resultantes com ferramentas de destino. O CDP Institute define uma CDP como um software que cria e mantém um registro de cliente persistente e unificado, acessível a outros sistemas, e essa última parte é a pista: o resultado é um registro que outros sistemas consomem. Uma CDP é infraestrutura de dados: coleta, resolve e roteia; o envio acontece nas ferramentas que ela alimenta. O que ela não consegue corrigir são dados de entrada malfeitos, e é por isso que um plano de rastreamento bem feito importa tanto com uma CDP quanto sem.
O que uma CEP faz com esses dados?
Uma CEP mantém seu próprio armazenamento first-party de perfis e eventos, calcula segmentos sobre ele — incluindo segmentos dinâmicos recalculados à medida que os eventos chegam — e roda as jornadas que enviam e-mail, SMS, mensagens in-app e push. Ela cuida da última milha que a CDP evita de propósito: transformar dados em uma mensagem que o cliente de fato recebe. O armazenamento não é um detalhe de implementação. Ter perfis e eventos em um sistema que você controla é boa parte do que ser dono dos dados dos clientes significa na prática.
CDP vs. CEP: frente a frente
A confusão entre CDP e CEP é comercial, não conceitual — os fornecedores de cada lado vivem absorvendo o vocabulário do outro. O mercado dá motivos para isso: a atualização setorial de julho de 2025 do CDP Institute lista 208 fornecedores de CDP, e estimativas de analistas compiladas pelo CDP.com situam o mercado de CDP em 2026 entre 4 e 10,5 bilhões de dólares, dependendo de quem mede. As funções, porém, continuam distintas. A tabela mostra a divisão que sobrevive ao marketing.
| Plataforma de dados do cliente | Plataforma de engajamento do cliente | |
|---|---|---|
| Função principal | Coletar, resolver e rotear dados de clientes | Ativar dados — segmentar, orquestrar, enviar |
| O que entra | Eventos e atributos de SDKs, backends, data warehouses, ferramentas SaaS | Eventos do próprio SDK e da própria API, além de atributos de perfil |
| O que sai | Perfis e públicos limpos, sincronizados com ferramentas de destino | E-mails, SMS, mensagens in-app, push — e as análises sobre eles |
| Resolução de identidade | Recurso central — une a mesma pessoa entre fontes e dispositivos | Básica — normalmente uma identidade por perfil dentro do próprio armazenamento |
| Envia mensagens? | Não — por definição, entrega públicos a ferramentas que enviam | Sim — enviar é o objetivo |
| Quem opera | Engenheiros de dados ou de growth | Profissionais de marketing e fundadores, com um engenheiro para a configuração |
| Quando compensa | Muitos destinos que precisam do mesmo perfil resolvido | Assim que você tem usuários para fazer onboarding e reter |
Como é um problema com cara de CDP?
- Várias ferramentas de destino (plataformas de anúncios, análises, suporte, mensagens) precisam do mesmo perfil limpo, e cada uma hoje constrói o seu.
- Sua stack de análises é centrada no data warehouse: ele é a fonte da verdade, e cada ferramenta mais adiante precisa de uma fatia governada dele.
- As identidades estão fragmentadas entre produtos: o mesmo cliente existe em dois apps com três e-mails, e nenhum sistema consegue dizer que é uma só pessoa.
- A coleta de eventos está duplicada: cada ferramenta traz o próprio snippet, o próprio schema e a própria versão do mesmo funil.
Um sistema pode fazer as duas funções?
Para uma equipe pequena, geralmente sim — a partir do lado da CEP. O armazenamento first-party da CEP já faz a metade da coleta: um SDK para eventos do lado do cliente, uma API para os do lado do servidor, perfis e segmentos no mesmo banco de dados que as jornadas. Coloque uma CDP por cima disso e você ganha uma segunda camada de dados para manter — mais um schema, mais uma sincronização para depurar — sem nenhuma capacidade nova. Para uma equipe com um produto e uma plataforma de ativação, uma CDP é uma segunda camada de dados, não uma que esteja faltando. Quando os sinais de arquitetura acima são reais, as duas se combinam bem: a CDP coleta e resolve, depois alimenta a CEP, que cuida da última milha. Saber se sua equipe já cruzou essa linha é exatamente o que nosso guia Você precisa de uma CDP? ajuda a avaliar.
Onde o fromHello se encaixa?
fromHello é um software de automação de marketing de código aberto: mensagens acionadas pelo que as pessoas fazem. Ele mantém seu próprio armazenamento first-party: o SDK JS/TS rastreia eventos no lado do cliente com uma fila offline, a API de eventos aceita eventos do lado do servidor, e perfis, segmentos, jornadas e mensagens ficam em um único banco de dados que você pode auto-hospedar ou que o fromHello Cloud roda para você, em acesso antecipado. Não é uma CDP e não finge ser: além dos públicos de anúncios e dos relays de pixel para Meta, LinkedIn e Google, e dos webhooks de saída, não há catálogo de destinos nem grafo de identidade entre ferramentas. Se sua arquitetura mostra os sinais com cara de CDP descritos acima, o fromHello ocupa a posição da CEP nesse diagrama: depois da CDP, consumindo os perfis resolvidos por ela e fazendo a ativação. Se você ainda está escolhendo qual plataforma deve ocupar esse lugar, nosso comparativo de ferramentas de automação de marketing de código aberto é o lugar para começar.