O CRM diz 'A', o GA diz 'B': Como o Data Vault resolve conflitos de identidade sem quebrar seu pipeline

Se você ainda tenta consolidar dados de marketing vindo de diversas fontes distintas e usa aquela consulta SQL gigante cheia de CASE WHEN para decidir se o e-mail do CRM vale mais que o e-mail do Google Analytics, sinto informar: você tem em mãos uma bomba-relógio.

No dia em que o time de CRM decidir mudar o ID único do usuário ou o Facebook Ads mudar o formato dos metadados, seu pipeline vai pro espaço.
‍

Porém, existe solução e ela se chama: Data Vault

O Data Vault não é um "capricho" de engenharia. É um seguro contra a volatilidade. Em MarTech, as APIs mudam, as ferramentas de automação são trocadas e o consentimento do usuário (LGPD) é fluido.

O Data Vault é uma metodologia de modelagem de dados focada em escalabilidade e rastreabilidade. Diferente do Kimball (Star Schema), onde você achata tudo em dimensões e fatos, o Vault separa a identidade dos atributos.

Seus três pilares são simples, mas poderosos:

• Hubs: Representam o conceito de negócio (ex.: Hub_Cliente, Hub_Produto). Aqui só mora a chave de negócio (E-mail, CPF, ID do CRM). É a sua âncora.
• Links: São o tecido conjuntivo. Eles mapeiam a relação entre os Hubs (ex.: qual cliente comprou qual produto).
• Satélites: É onde a "fofoca" acontece. Aqui ficam os atributos que mudam com o tempo (nome, endereço, status de opt-in). Se o dado veio do Facebook, ele ganha um Satélite; se veio do Salesforce, outro.

Os Princípios Inegociáveis

Para quem vai modelar, o Data Vault não é sobre "organizar tabelas", é sobre isolamento de carga. O princípio mestre é: os dados de origem nunca são alterados.

1. Carga Passiva (Insert Only): Esqueça o UPDATE. No Data Vault, você só insere. Se o status do lead mudou, você insere uma nova linha no Satellite com um novo timestamp. Isso te dá uma máquina do tempo nativa.
2. Separação de Estrutura e Atributo: A estrutura do seu negócio (clientes, produtos, transações) é estável; os detalhes (e-mail, preço, score de propensão) são voláteis.
3. Agnosticismo de Fonte: O modelo não se importa de onde o dado vem. Se o dado do TikTok Ads é bagunçado e o do Google Ads é limpo, por exemplo, ambos coexistem em satélites distintos sem poluir a chave de identidade do Hub.

Como Implementar (Sem morrer no processo)

Não tente migrar tudo de uma vez. Comece pelo Identity Hub.

• Passo 1: Identifique os Business Keys. O que identifica seu cliente em todos os sistemas? E-mail? CPF? ID do CRM? Crie seu Hub_Individuo aqui.
• Passo 2: Mapeie as fontes para Satellites. Crie um satélite com CRM_Infos e um satélite com marketing_Analytics_Infos. Use hashes (MD5 ou SHA1) para gerar as chaves primárias. Isso permite cargas paralelas sem depender de IDs sequenciais do banco.
• Passo 3: Construa a Ponte. Use os Links para conectar o cliente às transações ou aos eventos de conversão.
• Passo 4: A Camada de Saída (Business Vault). Aqui você cria as regras do "Golden Record". Se o e-mail no CRM for diferente do e-mail no GTM, qual ganha? Essa regra vive em uma View ou tabela de saída, nunca na estrutura do Vault.

Porém, automação é a chave

Aqui é onde muitos projetos morrem. Tentar modelar um data vault na mão, escrevendo DDL por DDL, é assinar um atestado de óbito técnico.

Como o data vault multiplica o número de tabelas (para cada entidade você terá pelo menos um Hub e vários satélites), a carga operacional explode. Se o seu engenheiro precisar de dois dias para criar a estrutura de uma nova fonte de dados de Ads, o time de Growth já vai ter contornado o DW e feito uma planilha para resolver o problema.

Você precisa de ferramentas como dbt (especialmente pacotes como dbt vault ou automação baseada em metadados). A lógica deve ser: você define o mapeamento de metadados e o código SQL das cargas é gerado automaticamente. Se não for assim, você terá um exército de engenheiros fazendo trabalho braçal, enquanto a liderança reclama que "os dados nunca estão prontos".

Os prós e contras

E para a liderança que quer saber se o ROI fecha, aqui estão os benefícios e os malefícios.

Os Benefícios 

• Auditoria Nativa: Se o jurídico perguntar por que um usuário recebeu um e-mail marketing, você tem o histórico exato do consentimento naquele minuto.
• Escalabilidade Infinita: Você pode adicionar 50 novas fontes de dados simultâneas sem tocar no código das fontes antigas.
• Fim do Refactoring: O schema de uma API mudou? Você só cria um novo Satellite. O resto do seu DW permanece intacto.

Os Malefícios 

• Explosão de Joins: Para pegar o nome de um cliente e o valor de uma compra, você pode precisar de 5 ou 6 JOINS entre Hubs, Links e Satellites. A performance sofre se você não souber usar Point-in-Time (PIT) tables.
• Complexidade de Armazenamento: Você vai guardar muito dado repetido. Em tempos de BigQuery e Snowflake, o custo de storage é baixo, mas o custo de gerenciar a linhagem aumenta.
• Curva de Aprendizado: Explicar para um analista de marketing que ele não pode simplesmente dar um SELECT * FROM clientes porque a tabela agora está espalhada em 4 lugares é um desafio cultural imenso.

Vale a pena usar? 

Implementar Data Vault "puro" em MarTech é como construir um prédio com isolamento sísmico: é caro e demora mais no início, mas quando o terremoto (mudança de API ou troca de stack) vem, seu prédio é o único que fica de pé.

Se o seu volume de dados é baixo ou sua stack é estática, o Data Vault é um excesso de engenharia. Mas se você está jogando o jogo de First-Party Data em escala, a automação do DV (via dbt) não é uma opção, é a única forma de não se tornar um gargalo para o time de negócios.

Só não esqueça: o Vault é o seu cofre (seguro e organizado), mas o marketing precisa de uma vitrine. Nunca exponha os satélites brutos para o usuário final; entregue para eles uma camada de Business Vault bem mastigada.

Você não precisa erguer esse prédio sozinho

Estruturar um Data Vault em MarTech exige maturidade técnica, mas a recompensa é a paz de espírito de ter uma estratégia de First-Party Data inabalável. Como consultoria de marketing analytics, a DP6 une engenharia de dados de ponta e inteligência de negócio para automatizar seus pipelines e entregar a "vitrine" perfeita para o time de marketing.

Não espere a próxima API mudar para descobrir que a sua fundação cedeu. Fale com a DP6 e saiba como podemos desenhar a arquitetura de dados ideal para o futuro do seu negócio.