O que é um Composable CDP

Um Composable CDP não é um produto único. É uma abordagem arquitetural que monta as capacidades típicas de um Customer Data Platform, unificação de perfis, segmentação e ativação, sobre a infraestrutura de dados que a empresa já opera, em vez de delegar tudo a um sistema fechado de um fornecedor.

A ideia central é tratar o data warehouse ou lakehouse da empresa como fonte única de verdade e acrescentar camadas especializadas para coleta, transformação, resolução de identidade e ativação. Cada camada pode ser ocupada pela ferramenta mais adequada ao contexto, trocada de forma independente e evoluída conforme a maturidade do time cresce.

A diferença em relação ao CDP tradicional, também chamado de packaged CDP, está em onde os dados residem e quem controla o modelo de perfil. Em um packaged CDP, os dados são copiados para o banco de dados proprietário do fornecedor, que também impõe sua estrutura de perfil. No modelo composable, os dados permanecem no ambiente da empresa e o modelo de perfil é construído e mantido internamente, geralmente por um time de engenharia ou dados.

O termo foi popularizado a partir de 2022, impulsionado pela consolidação do data warehouse moderno como hub central de dados nas empresas. Com plataformas como BigQuery, Snowflake e Databricks ganhando escala e reduzindo barreiras de adoção, ficou viável manter perfis de clientes atualizados e ativáveis diretamente no warehouse, sem precisar replicar tudo para um sistema externo.

Como funciona a arquitetura de um Composable CDP

A arquitetura de um Composable CDP se organiza em camadas funcionais que se comunicam de forma orquestrada, mas podem ser implantadas e evoluídas de modo independente.

Data warehouse como espinha dorsal

O warehouse, seja BigQuery, Snowflake, Databricks ou equivalentes, funciona como a fonte única de verdade para todos os dados de clientes: comportamento digital, transações, atendimento, dados de CRM e qualquer outra origem relevante. O perfil unificado não existe em uma base paralela; ele é construído e atualizado dentro do próprio warehouse por meio de transformações agendadas ou em tempo quase real.

Isso elimina a inconsistência clássica entre “o número que o marketing vê” e “o número que a engenharia puxa”: qualquer consulta de BI, modelo de propensão ou segmento de marketing parte dos mesmos dados e da mesma lógica de negócio.

Camada de ingestão e coleta

Eventos de comportamento digital, dados transacionais e feeds de sistemas legados precisam chegar ao warehouse de forma confiável. Aqui entram SDKs de rastreamento de eventos, conectores de fontes SaaS, pipelines de streaming (Kafka, Pub/Sub, Kinesis) e ferramentas de ingestão batch. A escolha depende da latência necessária: ativações de abandono de carrinho exigem streaming; campanhas de retenção mensais toleram batch.

Transformação e modelagem de perfil

Com os dados brutos no warehouse, o próximo passo é transformá-los em perfis acionáveis. Ferramentas SQL-first como dbt são amplamente usadas para definir modelos de identidade, calcular atributos agregados (LTV, frequência de compra, dias desde o último evento) e manter histórico de comportamento. Essa camada define a lógica de negócio que, em um packaged CDP, ficaria trancada dentro do fornecedor.

Resolução de identidade

Associar eventos anônimos, IDs de dispositivos, e-mails e CPFs a um único perfil de cliente é uma das partes mais complexas. No modelo composable, essa lógica pode ser implementada diretamente em SQL dentro do warehouse ou delegada a ferramentas especializadas que escrevem o resultado de volta ao warehouse. Não existe um único caminho certo; o que importa é que as regras de matching sejam auditáveis e governadas internamente.

Camada de ativação reversa (Reverse ETL)

Uma vez que os segmentos e atributos existem no warehouse, é preciso enviá-los para as plataformas de engajamento, como CRM, ESP, plataformas de mídia e ferramentas de suporte, sem duplicar os dados em silos separados. Esse papel é cumprido por ferramentas de reverse ETL, que leem queries ou tabelas do warehouse e sincronizam os resultados com sistemas downstream de forma agendada ou em resposta a eventos. O dado continua sendo governado no warehouse; a ferramenta de ativação é apenas um canal de saída.

Composable CDP vs. CDP tradicional: principais diferenças

Propriedade e portabilidade dos dados

Em um packaged CDP, os dados de perfil de clientes ficam no banco de dados do fornecedor. Sair da plataforma implica migração de dados, potencial perda de histórico e renegociação de contratos. No modelo composable, os dados nunca saíram do warehouse da empresa. Trocar uma ferramenta de ativação ou de transformação não afeta o ativo principal.

Flexibilidade e integração com o ecossistema existente

Times de ciência de dados que já trabalham no Snowflake ou BigQuery continuam usando as mesmas ferramentas para consumir perfis de clientes. Dashboards de BI, notebooks de machine learning e modelos de churn se alimentam diretamente do warehouse, sem precisar de exportações ou APIs proprietárias. Essa integração natural é um dos maiores ganhos práticos do modelo composable.

Curva de implantação e dependência de engenharia

Aqui está o maior trade-off. Um packaged CDP entrega uma interface de segmentação pronta, conectores pré-construídos e suporte do fornecedor. A implantação é mais rápida para times pequenos ou com pouca maturidade técnica. O Composable CDP exige um time de engenharia de dados capaz de construir e manter pipelines, modelos dbt, regras de identidade e integrações de ativação. Sem esse time, a arquitetura vira um projeto inacabado.

Custo total de propriedade

Comparar custos diretos é enganoso. O packaged CDP tem licença previsível, mas muitas vezes cobra por volume de perfis, eventos ou destinos de ativação, o que pode escalar rapidamente. O modelo composable tem custos de computação do warehouse, licenças de ferramentas best-of-breed e custo de time de engenharia. Em volumes altos e com infraestrutura já amortizada, o composable costuma ser mais barato. Em volumes baixos ou sem infraestrutura prévia, o packaged CDP frequentemente sai mais em conta quando se considera o custo total, incluindo horas de engenharia.

Quando o Composable CDP faz sentido e quando não faz

Cenários favoráveis

A abordagem composable faz mais sentido quando a empresa já opera um warehouse consolidado com dados de múltiplas fontes, tem um time de engenharia de dados com pelo menos dois a três profissionais dedicados e lida com volumes de dados que tornam as licenças de packaged CDP proibitivas. Empresas de e-commerce, fintechs e operações de mídia digital com alta frequência de eventos são candidatas naturais.

Faz sentido também quando a empresa quer reutilizar atributos e segmentos já calculados para BI e ciência de dados, evitando duplicar lógica em sistemas separados. Se o time de dados já calcula LTV, score de churn e segmentos de comportamento no warehouse, recalcular tudo dentro de um CDP proprietário agrega pouco.

Quando o CDP tradicional ainda é mais adequado

Equipes pequenas sem engenharia de dados dedicada dificilmente conseguirão sustentar um Composable CDP sem acumular dívida técnica. Empresas sem um warehouse centralizado ou com dados fragmentados em planilhas e sistemas legados desconectados enfrentarão um problema de dados antes mesmo de pensar em ativação, e um packaged CDP com conectores prontos pode resolver mais rápido.

Times de marketing que precisam de autonomia para criar segmentos e campanhas sem depender de squads de dados também tendem a se beneficiar mais das interfaces visuais dos packaged CDPs.

Considerações para o mercado brasileiro

No Brasil, três fatores merecem atenção específica. Primeiro, o custo de cloud em reais: instâncias de warehouse e processamento são cobradas em dólar, e variações cambiais afetam o TCO de forma significativa, especialmente em modelos de consumo variável. Segundo, a disponibilidade de profissionais de engenharia de dados ainda é limitada em relação à demanda, o que eleva o custo e o risco de dependência de pessoas-chave. Terceiro, a maturidade de dados das empresas brasileiras é heterogênea: grandes varejistas e fintechs têm infraestrutura comparável a qualquer operação global, mas médias empresas frequentemente ainda estão consolidando fontes básicas.

Armadilha comum: subestimar governança e qualidade de dados

O erro mais frequente em projetos composable é construir a arquitetura técnica sem resolver problemas anteriores de qualidade de dados. Perfis unificados no warehouse são tão bons quanto os dados que os alimentam. Duplicatas de cadastro, eventos sem ID consistente e ausência de processos de validação transformam o warehouse em um repositório de dados sujos com aparência sofisticada. Governança de dados não é opcional nesse modelo: é pré-requisito.

Componentes e ferramentas que formam um Composable CDP

Coleta e ingestão

Essa camada precisa cobrir eventos digitais (web e mobile), dados de sistemas transacionais e fontes SaaS. Ferramentas de coleta de eventos com SDK próprio e encaminhamento direto ao warehouse, conectores de pipelines de dados e soluções de streaming compõem essa categoria. O critério de avaliação mais importante é a confiabilidade da entrega e a latência aceitável para os casos de uso de ativação pretendidos.

Transformação e modelagem

Frameworks SQL-first para transformação de dados no warehouse dominam essa camada. A capacidade de versionar modelos, documentar lógica de negócio e testar transformações automaticamente é fundamental para sustentar perfis de clientes que evoluem ao longo do tempo. Ferramentas de definição de métricas semânticas complementam essa camada ao padronizar definições compartilhadas entre times.

Ativação reversa

Ferramentas de reverse ETL sincronizam segmentos e atributos do warehouse para CRMs, ESPs, plataformas de anúncio e ferramentas de suporte. Ao avaliar essas ferramentas, verifique: quais destinos são suportados nativamente, qual a granularidade de agendamento (tempo real, minutos, horas), como são tratados erros de sincronização e se a ferramenta permite lógica de sincronização condicional, como enviar apenas registros alterados.

Evitando dependência excessiva de um único fornecedor

A promessa do modelo composable é flexibilidade, mas ela só se mantém se as interfaces entre camadas forem padronizadas. Prefira ferramentas que leem e escrevem em tabelas nativas do warehouse em vez de formatos proprietários. Documente as queries e modelos que definem segmentos e atributos de forma independente das ferramentas que os executam. Trocar uma ferramenta de ativação, assim, não exige reescrever a lógica de segmentação.

Próximos passos para avaliar a adoção

Checklist de pré-requisitos

Antes de iniciar qualquer projeto composable, valide os seguintes pontos com honestidade:

• Warehouse operacional: existe um warehouse centralizado com dados de pelo menos duas fontes críticas (comportamento digital + transacional)?
• Cobertura de coleta: eventos de comportamento digital estão sendo capturados com IDs consistentes e sem gaps significativos?
• Capacidade do time: há engenheiros de dados disponíveis para construir e manter pipelines, modelos de transformação e integrações de ativação?
• Governança básica: existem processos de validação de qualidade de dados e ownership definido para cada fonte?
• Casos de uso prioritários: há pelo menos um caso de uso de ativação com ROI estimado que justifique o investimento inicial?

Prova de conceito recomendada

Não tente migrar toda a operação de uma vez. Escolha um caso de uso de ativação simples e de alto impacto, como reativação de clientes inativos, personalização de e-mail baseada em comportamento recente ou sincronização de segmentos de alto LTV para plataformas de mídia. Construa o pipeline completo: coleta → warehouse → transformação → ativação. Meça o resultado e use esse ciclo para validar a arquitetura e identificar gaps antes de escalar.

Como calcular o ROI comparativo

Monte uma planilha com dois cenários de custo total de propriedade para três anos. No cenário packaged CDP, inclua: licença anual, custo de implementação, custo de conectores adicionais e estimativa de crescimento por volume. No cenário composable, inclua: custo incremental de computação no warehouse, licenças das ferramentas de cada camada, horas de engenharia para construção e manutenção estimada. Compare com o valor gerado pelos casos de uso de ativação planejados. A decisão raramente é técnica: é financeira e organizacional.

Recursos para aprofundamento

Para ir além deste artigo, algumas referências úteis:

• Documentações técnicas das plataformas de warehouse (BigQuery, Snowflake, Databricks) têm guias específicos sobre modelagem de dados de clientes e padrões de ativação.
• A comunidade dbt (getdbt.com/community) tem discussões ativas sobre modelagem de perfis de clientes em SQL, incluindo padrões para resolução de identidade.
• O CDP Institute (cdpinstitute.org) publica relatórios vendor-neutral sobre o mercado de CDPs, incluindo comparações entre modelos packaged e composable.
• No Brasil, comunidades como o Data Hackers e grupos de Slack e Discord voltados a engenharia de dados têm debates práticos sobre implementações locais, incluindo considerações de custo em reais e disponibilidade de profissionais.

A decisão por um Composable CDP não é sobre tecnologia de ponta: é sobre alinhar arquitetura à capacidade real do time e à estratégia de dados da empresa. Começar pelo checklist de pré-requisitos com honestidade costuma economizar meses de retrabalho.