O que é modelagem de dados no contexto de um CDP

Modelagem de dados, no sentido amplo, é o processo de definir como informações são estruturadas, armazenadas e relacionadas. No contexto de um CDP, o objetivo muda: o modelo precisa ser centrado na identidade do cliente, não nos sistemas de origem que geram os dados.

Em um ERP ou num data warehouse tradicional, o modelo gira em torno de transações, produtos ou pedidos. No CDP, esses mesmos dados precisam ser reorganizados para que qualquer consulta parta do perfil do cliente e chegue aos eventos, compras ou interações, e não o contrário.

Essa distinção tem impacto direto na capacidade de ativação. Um modelo mal desenhado força joins complexos a cada consulta de segmentação, aumenta latência e limita o que o time de marketing consegue fazer sem depender de engenharia. Um modelo identity-centric reduz essa fricção.

Principais estruturas de dados em um CDP

Perfil unificado do cliente

O perfil unificado, ou unified customer profile, é a entidade central do modelo. Ele agrega identificadores, atributos descritivos e métricas calculadas em um único registro por indivíduo real. Cada outra estrutura do CDP existe para enriquecer ou atualizar esse perfil.

Na prática, o perfil contém campos como nome, e-mail, telefone e endereço, além de atributos derivados como segmento de valor, data da última compra e canal preferido. A chave primária desse registro é geralmente um ID interno gerado pelo próprio CDP, distinto dos identificadores externos.

Eventos comportamentais

Eventos são registros imutáveis de ações do usuário: página visitada, produto adicionado ao carrinho, e-mail aberto. Eles seguem uma estrutura de série temporal, com timestamp, tipo de evento e um conjunto de propriedades variável em cada registro.

A granularidade importa. Registrar cada scroll de página gera volume sem valor analítico. O recomendado é modelar eventos no nível de intenção do usuário, como clique em produto, início de checkout e conclusão de compra, e definir desde o início quais eventos serão usados em segmentação.

Atributos calculados

Métricas como LTV, RFM, frequência de compra e ticket médio não chegam prontas das fontes. Elas precisam ser modeladas como computed traits: campos derivados, atualizados periodicamente a partir dos eventos brutos e materializados no perfil do cliente.

O modelo deve distinguir claramente entre atributos brutos (vêm da fonte) e atributos calculados (gerados pelo CDP). Misturar os dois sem nomenclatura clara é uma das causas mais comuns de inconsistência entre relatórios de CRM e marketing.

Tabelas de relacionamento

Pedidos, itens de pedido, tickets de suporte e interações de atendimento são entidades relacionadas ao perfil, mas não fazem parte dele diretamente. O modelo precisa de tabelas de relacionamento que conectem essas entidades ao ID do cliente sem duplicar dados no perfil.

Esse design preserva a integridade do perfil central e facilita consultas como “clientes que compraram categoria X mais de duas vezes nos últimos 90 dias” sem necessidade de desnormalização total.

Resolução de identidade e seu impacto no modelo de dados

Identificadores primários e secundários

Todo CDP precisa lidar com múltiplos identificadores para o mesmo indivíduo: e-mail, cookie de navegador, device ID, número de telefone e, no Brasil, CPF e CNPJ. O modelo deve classificar cada identificador como primário ou secundário e definir regras de precedência para resolução de conflitos.

O identificador primário é o mais confiável e estável, geralmente e-mail autenticado ou CPF. Identificadores secundários, como cookies, são temporários e sujeitos a rotação. O modelo precisa tratar essa hierarquia explicitamente, não implicitamente.

Merge e split de perfis

Quando dois identificadores diferentes são associados ao mesmo indivíduo, o CDP precisa fazer o merge dos perfis. O modelo deve suportar esse processo sem perder o histórico de eventos de nenhum dos registros originais. O contrário, o split, ocorre quando um perfil mergeado incorretamente precisa ser separado.

Implementar isso requer uma tabela de mapeamento de identidades (identity graph) separada do perfil em si, o que permite auditar o histórico de merges sem alterar os dados de eventos já gravados.

LGPD e armazenamento de identificadores no Brasil

A LGPD classifica CPF, e-mail e telefone como dados pessoais. O modelo de dados precisa refletir isso: campos que armazenam identificadores pessoais devem ser marcados no catálogo de dados, ter política de retenção definida e suportar exclusão mediante solicitação do titular.

Uma boa prática é pseudonimizar identificadores sensíveis na camada de eventos, armazenando um hash do CPF em vez do valor original, e manter o mapeamento hash-para-CPF em uma camada controlada com acesso restrito.

Namespaces para evitar colisões

Quando múltiplas fontes enviam o campo user_id, é comum que os valores colidam entre sistemas diferentes. Um user_id: 1042 do e-commerce não é o mesmo que user_id: 1042 do ERP. Namespaces resolvem isso: cada identificador é prefixado pela fonte de origem, como ecommerce:1042 e erp:1042.

Schemas mais usados: comparativo prático

Schema plano versus normalizado

Um schema plano (flat) armazena todos os atributos de um perfil em uma única linha com muitas colunas. É rápido para leitura e fácil de consultar, mas dificulta a adição de novos atributos sem alterar a estrutura da tabela. Funciona bem quando o conjunto de atributos é estável e previsível.

O schema normalizado distribui os dados em tabelas relacionadas, reduzindo redundância e facilitando a evolução do modelo. O custo é a necessidade de joins em consultas de segmentação, o que pode aumentar a latência dependendo do volume de dados.

Padrão de eventos estilo Segment Spec

O padrão popularizado pela especificação de eventos da Segment, com chamadas track, identify e page, é uma referência vendor-neutral amplamente adotada. Ele define estruturas consistentes para os três tipos de interação mais comuns e é suportado por ferramentas como mParticle, RudderStack e Snowplow, entre outras.

Adotar esse padrão como base reduz o esforço de integração entre fontes e facilita a portabilidade dos dados caso a plataforma de CDP seja trocada no futuro.

JSON aninhado versus colunas tipadas

JSON aninhado oferece flexibilidade para capturar propriedades variáveis de eventos sem alterar o schema da tabela. É útil para a camada bruta de ingestão. O problema aparece na consulta: extrair campos de dentro de um JSON em escala é consideravelmente mais lento do que consultar colunas tipadas.

A recomendação prática é usar JSON na camada de staging e promover os campos mais consultados para colunas tipadas na camada analítica. Isso equilibra flexibilidade de ingestão com performance de segmentação.

Erros comuns na modelagem de dados para CDP

Modelar em torno dos sistemas de origem. Replicar a estrutura do ERP ou do e-commerce dentro do CDP é o erro mais frequente. O resultado é um modelo que responde bem perguntas sobre pedidos, mas mal perguntas sobre clientes. A reorganização posterior custa caro.

Falta de versionamento de schema. Quando o schema de um evento muda sem controle de versão, pipelines downstream quebram silenciosamente. Dashboards passam a exibir dados incorretos sem alerta visível. Ferramentas como Schema Registry ou convenções simples de versionamento no nome do evento evitam esse problema.

Granularidade excessiva sem política de retenção. Capturar todos os eventos possíveis sem definir por quanto tempo eles serão retidos leva ao acúmulo de dados sem uso, aumento de custo de armazenamento e degradação de performance nas consultas de segmentação.

Ausência de dicionário de dados. Quando cada time define seus próprios nomes para os mesmos eventos, com marketing chamando de purchase e engenharia chamando de order_completed, a inconsistência se multiplica a cada nova integração. Um dicionário de dados centralizado, mesmo que simples, é indispensável.

Boas práticas para times de dados no mercado brasileiro

Definir ownership antes de implementar. A modelagem de dados para CDP envolve engenharia de dados, CRM e marketing. Sem definir quem é responsável por cada decisão, como quais eventos capturar, quais atributos são obrigatórios e quem aprova mudanças no schema, o modelo se fragmenta rapidamente.

Criar um catálogo de eventos padronizados. Antes de conectar qualquer nova fonte, o time deve ter um catálogo com todos os eventos aceitos pelo CDP, suas propriedades obrigatórias e opcionais e exemplos de payload. Isso evita que cada fonte invente sua própria taxonomia.

Considerar identificadores brasileiros no esquema. CPF tem formato específico (11 dígitos, com ou sem máscara), CNPJ tem 14, telefones variam entre 8 e 9 dígitos e precisam de DDD. O schema deve ter campos tipados e validados para esses identificadores, não campos de texto genérico que aceitam qualquer valor.

Revisar o modelo a cada novo canal integrado. Cada canal novo, como WhatsApp, app mobile ou PDV físico, traz identificadores e eventos que o modelo atual pode não contemplar. Uma revisão estruturada do schema a cada integração, antes do go-live, é mais barata do que corrigir inconsistências depois que os dados já estão em produção.

Como avaliar a maturidade do seu modelo de dados para CDP

Antes de iniciar ou revisar uma implementação, responda estas perguntas sobre o modelo atual:

• O perfil unificado tem um ID interno próprio, independente dos sistemas de origem?
• Existe uma hierarquia documentada de identificadores primários e secundários?
• Os atributos calculados (LTV, RFM) estão separados dos atributos brutos no schema?
• Há versionamento de schema implementado para os principais eventos?
• O modelo suporta exclusão de dados pessoais em conformidade com a LGPD?
• Existe um catálogo de eventos acessível a engenharia, CRM e marketing?
• CPF, CNPJ e telefone com DDD têm campos tipados e regras de validação definidas?

Cada resposta negativa indica um ponto de risco concreto na operação do CDP. Priorize os itens relacionados à resolução de identidade e à conformidade com LGPD: eles têm o maior impacto em qualidade de perfil e em exposição regulatória.