Chega de Data Mess: Por que sua arquitetura de MarTech precisa de donos e de dados descentralizados?

Segunda-feira, 9 da manhã, o diretor de marketing está cobrando por que o ROAS no dashboard do Looker não bate com o que o Gerente de Performance vê no Gerenciador de Anúncios. Enquanto isso, o engenheiro de dados está afogado em um pipeline de 2000 linhas de SQL tentando tratar um campo de UTM_source que o time de CRM mudou sem avisar ninguém.

Se você acha que a solução para isso é comprar uma ferramenta nova ou "centralizar tudo num Data Lake", você já perdeu a batalha.

O Data Mesh surge justamente quando a gente aceita que centralizar o dado é criar um gargalo humano. Não é software. É arquitetura organizacional. No marketing, isso significa parar de tratar o dado como um subproduto técnico e começar a tratá-lo como um Produto de Dados entregue por quem entende do negócio.

Tá, mas o que é esse bicho na prática?

Se você pesquisar no Google, vai ler que Data Mesh é um "paradigma socio-técnico". Traduzido do corporativês: é parar de tratar o dado como uma responsabilidade que uma área joga no colo da outra e passar a tratá-lo como um produto real: com dono, custo de processamento e, acima de tudo, controle de qualidade.

A arquitetura Data Mesh se apoia em quatro pilares que, se você ignorar um, o prédio cai:

1. Domínios (Domain Ownership): O time de Performance é dono dos dados de aquisição de clientes; o CRM é dono dos dados de retenção. Ser "dono" não é só ter acesso, é ter recursos técnicos (como Data Engineers) alocados no domínio. Se o schema do Salesforce muda, quem resolve é o engenheiro que está sentado com o time de Vendas e entende o impacto disso no bico da meta, não um time central que nem sabe o que é um "Lead Status". 
2. Dados como Produto (Data as a Product): O dado não "está" em algum lugar. Ele é entregue. Isso significa que ele precisa ser fácil de achar (catálogo), confiável e, principalmente, legível. Se eu preciso de um curso de 40 horas para entender a sua tabela de conversões, seu produto é ruim.
3. Infraestrutura de Autoatendimento (Self-Service Platform): Aqui entra a figura de um engenheiro de dados central, que atua como um arquiteto de soluções. Em vez de ele mesmo fazer o ETL para todos, ele constrói a ‘esteira’ tecnológica (BigQuery, dbt, Fivetran).  O segredo aqui é que esse time central não toca no dado do domínio; ele garante que a fundação seja sólida para que o Marketing tenha autonomia para plugar seus dados sem precisar de permissão ou risco de quebrar a arquitetura global. 
4. Governança Federada: São as regras globais. "Todo ID de cliente tem que ser um hash SHA-256". "Toda tabela precisa ter data de expiração." São as leis que garantem que os domínios consigam conversar entre si.

A ideia central da arquitetura é o Domínio.

Em vez de um time de dados centralizado, tentando limpar a sujeira de todo mundo, cada área assume a responsabilidade pelo que produz. O time de Performance é dono do domínio das campanhas de Ads. O time de CRM é dono das campanhas de e-mail e push.

Eles não entregam "uma planilha" ou "um acesso ao banco". Eles entregam um produto com documentação, SLA e, o mais importante: Contratos de Dados.

Se o seu Data Mesh não tem contratos bem definidos, você só tem um "Data Mess" (uma bagunça de dados) distribuído.

O Contrato de Dados é a sua única proteção

Para o engenheiro, o contrato é um arquivo YAML ou um JSON Schema que valida a entrada do dado. Se o time de Growth tentar subir um evento de conversão sem o campo transaction_id, o pipeline quebra na origem, antes de poluir as tabelas.

Para o diretor, o contrato é a garantia de que a métrica que ele vê no relatório tem um dono. Se o dado está errado, não é "culpa do TI". É uma falha no contrato do domínio de origem.

Isso resolve o maior problema de integração: a semântica. O que adianta integrar Google Ads e Salesforce se o "ID do Cliente" em um é o e-mail e no outro é um hash aleatório que ninguém mapeou? O contrato força essa conversa antes da primeira linha de código ser escrita.

Mas e como "pensar" essa arquitetura (O pulo do gato)?

Pensar em Data Mesh é parar de “SÓ” desenhar diagramas de fluxo de dados e começar a desenhar também fronteiras de responsabilidade.

Imagine que o Marketing é uma fábrica independente. Eles têm a própria matéria-prima (Ads APIs, Google Analytics, Pixel). No modelo antigo (Monolítico), eles mandavam essa matéria-prima bruta para um armazém central (o Data Lake) e esperavam que alguém lá dentro fizesse mágica. No Data Mesh, o Marketing tem sua própria linha de montagem. Eles entregam não só a esteira rodando, mas o produto (o dado limpo e modelado) para o resto da empresa consumir via Contratos de Dados.

‍

O choque de realidade para a liderança

Não existe "Data Mesh as a Service" no cartão de crédito corporativo.

Não adianta contratar a ferramenta mais cara do mercado se a sua cultura ainda é a de "armazena os dados lá e o time de analytics que se vire para limpar/consumir". Implementar essa arquitetura dói porque exige que os gestores entendam de governança e que os engenheiros parem de ser "pasteleiros" de dashboard.

O Data Mesh resolve a escala. Se você tem 5 canais, a centralização funciona no grito. Se você tem 50, ou você distribui a responsabilidade ou vai passar o resto da vida corrigindo query de atribuição que não serve para nada.

A arquitetura não é sobre "onde" o dado está

Você pode ter Data Mesh usando uma única instância de Snowflake ou separando tudo em diversas. O local físico é irrelevante. O que define se você está fazendo Mesh ou não é:

• Se o pipeline de Facebook Ads quebrar, quem recebe o alerta no Slack?
• Se a resposta for "o time de infra/dados central", você ainda está no monólito.
• Se a resposta for "o Tech Lead de MarTech", parabéns, você começou a distribuir a malha.

Dica de trincheira: Não tente implementar os quatro pilares de uma vez. Comece pelo contrato, mas, em vez de forçar uma definição única de cada métrica, foque em estabelecer padrões de interoperabilidade no contrato.

Isso significa que o domínio de CRM pode ter sua própria lógica de ativação e o time de Performance outra, desde que ambos respeitem o padrão global de Identidade (o mesmo ID de cliente, por exemplo) e exponham suas regras de forma clara no código do contrato. A autonomia do domínio termina onde começa a integração com o resto da malha. Se você quer que seu dado de marketing seja consumido por outros, ele precisa falar a língua da federação, mesmo que o sotaque (a regra de negócio) seja local.

A pergunta que fica para os líderes de MarTech é: seu time está pronto para assumir a governança e ser dono dos próprios produtos de dados, ou é mais confortável continuar culpando o TI pelo ROAS que não bate?

Na DP6, entendemos que a transição para uma arquitetura de Data Mesh não acontece da noite para o dia, é uma jornada de maturidade técnica, mas principalmente cultural. Nossa experiência mostra que o sucesso não está apenas em escolher a ferramenta certa, mas em desenhar processos de governança que realmente funcionem no dia a dia da operação.

‍

Nós apoiamos grandes empresas em todas as frentes dessa jornada: desde o desenho estratégico da governança federada e definição de contratos de dados até a implementação técnica da stack de dados (como dbt, BigQuery e ferramentas de Observabilidade). O objetivo é um só: garantir que seu time de Marketing tenha os dados que precisa, com a autonomia que deseja e a qualidade que o negócio exige.

‍

Quer transformar seu "Data Mess" em uma arquitetura escalável e orientada a resultados? Entre em contato com os especialistas da DP6 e vamos conversar sobre como estruturar seu ecossistema de dados de marketing.

‍