Analytics engineering em marketing

O problema que o analytics engineer resolve

Em quase toda operação de marketing que atinge tamanho médio, repete-se a mesma cena: o CMO pergunta o custo de aquisição de cliente do trimestre, o analista de mídia responde R$ 180, o de operações responde R$ 220, e o financeiro chega com R$ 260. Os três estão certos dentro da própria lógica — usam fontes diferentes, regras de atribuição diferentes, recortes diferentes de período. Mas a empresa não sabe qual é o número real, e cada decisão estratégica se torna debate sobre metodologia em vez de debate sobre estratégia.

Esse é o sintoma clássico de ausência de camada de modelagem confiável. Cada pessoa consulta diretamente o dado bruto na origem, aplica a própria lógica e chega ao próprio número. O analytics engineer resolve isso construindo uma camada intermediária: tabelas modeladas, com regras de cálculo explícitas, documentadas, versionadas, testadas. Quando o CMO pergunta o custo de aquisição, todos consultam a mesma tabela e obtêm o mesmo valor.

O segundo problema típico: a saída de uma pessoa derruba o painel. Os relatórios principais dependiam de consultas SQL longas que só uma analista entendia, sem versionamento, sem documentação. Quando ela saiu, ninguém soube reproduzir nem manter. Analytics engineering trata o código de transformação como software — versionado em Git, revisado por pares, documentado, com testes automatizados que avisam quando algo quebra.

O que o analytics engineer faz, na prática

O trabalho cotidiano se organiza em quatro frentes principais.

Modelagem de dados. Cria as tabelas que o painel e os analistas consomem — tipicamente em estrutura dimensional, com tabelas-fato (eventos, transações, sessões) ligadas a tabelas-dimensão (cliente, campanha, produto, canal). Aplica boas práticas como uma única fonte da verdade para cada entidade, granularidade explícita por tabela, nomes padronizados. O resultado é um modelo que qualquer pessoa nova consegue entender em uma hora.

Transformação. Escreve o código SQL (ou Python, em alguns contextos) que limpa dado bruto, aplica regras de negócio e produz as tabelas modeladas. O ferramental dominante é o dbt (data build tool), que organiza transformações em modelos versionados, encadeia dependências e gera documentação automática. Cada modelo é um arquivo SQL com a definição da tabela — quem mexe, mexe em Git.

Documentação. Mantém a definição explícita de cada métrica e dimensão. O que é "cliente ativo"? Quem comprou nos últimos 90 dias? Nos últimos 180? Pagou a fatura ou só assinou o contrato? Sem essa definição escrita, cada analista decide na hora e os números divergem. Documentação não é luxo — é o que separa um painel "que funciona" de um painel "em que a empresa confia".

Manutenção e testes. Configura testes automatizados que verificam, a cada execução, se os dados batem com regras esperadas (chave primária única, valores não nulos onde não devem ser, totais consistentes entre tabelas). Quando algo quebra — uma integração mudou, um campo sumiu, um número desandou — o teste alerta antes do gestor descobrir no painel da reunião de diretoria.

Analytics engineer não é analista de dados nem engenheiro de dados

Três perfis costumam ser confundidos. Vale separar.

Engenheiro de dados. Cuida da infraestrutura — ingestão (Fivetran, Stitch, Airbyte movem dados de cada fonte para o warehouse), warehouse propriamente dito (Snowflake, BigQuery, Redshift), orquestração (Airflow, Prefect), monitoramento. Trabalha com dado bruto, em volumes grandes, com preocupações de custo de processamento e SLA de atualização. É um perfil mais técnico, com forte conhecimento de sistemas distribuídos.

Analytics engineer. Pega o dado bruto que o engenheiro de dados entrega no warehouse e transforma em modelos confiáveis. Foco em SQL avançado, dbt, modelagem dimensional, regras de negócio. Conversa com analistas, com o time de marketing, entende o que cada métrica significa do ponto de vista de negócio. É o tradutor entre dado técnico e modelo utilizável.

Analista de dados (ou de BI). Consome os modelos do analytics engineer para construir painéis (em Looker, Tableau, Power BI, Metabase) e análises ad hoc para o time de marketing. Trabalha mais perto da pergunta de negócio — "por que o custo de aquisição subiu em junho?" — e menos perto da estrutura da tabela. Em operações pequenas, esses papéis se misturam; em operações maduras, são separados.

O ferramental típico — o "stack moderno de dados"

Toda operação madura de analytics engineering em marketing usa alguma variação do mesmo conjunto de ferramentas, hoje conhecido como "stack moderno de dados":

Ingestão. Fivetran, Stitch ou Airbyte — ferramentas que conectam fontes (Salesforce, HubSpot, Google Ads, Meta Ads, Mailchimp, Shopify) ao warehouse, com sincronização automática. Custo varia de US$ 100 a US$ 10.000 mensais conforme volume de linhas movidas.

Warehouse. Snowflake, BigQuery (Google) ou Redshift (AWS) — onde os dados ficam armazenados e onde as transformações acontecem. Cobrança por uso (computação + armazenamento). Para operação média, custo mensal típico fica entre R$ 2.000 e R$ 15.000.

Transformação. dbt (data build tool) — domina o mercado. Existem alternativas (Dataform, do Google; SQLMesh; Coalesce) mas dbt virou padrão de fato. Permite escrever transformações em SQL versionado, com testes, documentação e linhagem.

BI. Looker, Tableau, Power BI, Metabase, Mode — onde os painéis vivem. A escolha depende muito do ecossistema da empresa (Power BI puxa para Microsoft, Looker puxa para Google, Tableau é independente, Metabase é mais acessível e tem versão livre).

Ativação reversa. Hightouch ou Census — categoria mais recente, que pega dados do warehouse e devolve para as ferramentas operacionais (CRM, plataforma de email, gerenciador de anúncios). Permite, por exemplo, criar segmento no warehouse e exportar como audiência no Meta Ads.

Catálogo e governança. Em operações maiores, ferramentas como Atlan, Castor, Select Star adicionam camada de descoberta, governança e linhagem além do que o dbt entrega nativamente.

Quando contratar — os sinais

Não há fórmula universal, mas alguns sinais conjuntos costumam indicar que chegou a hora.

Múltiplas fontes da verdade. A mesma métrica produz números diferentes dependendo de quem consulta. Reuniões viram debate sobre metodologia em vez de decisão.

Painel demora dias para mudar. Um pedido simples — "adiciona o canal X no painel principal" — leva semanas porque ninguém entende a consulta SQL original.

Dependência de uma pessoa. Os relatórios principais foram montados por uma analista específica e ninguém mais consegue manter. Saída dela vira crise.

Crescimento da pilha. A operação atingiu cinco ou mais ferramentas integradas, BI próprio, e a planilha mestra que conciliava tudo virou inviável.

Custo de warehouse fora de controle. Consultas mal escritas, repetidas em todos os painéis, fazem a fatura do warehouse explodir mês a mês.

Pedido de painel não para de chegar. Marketing pede, vendas pede, financeiro pede, executivos pedem — e o time atual consegue atender uma fração do que entra.

O que olhar no perfil

SQL avançado. Não é "sabe fazer SELECT" — é "domina funções analíticas (window functions), CTEs, subqueries correlacionadas, otimização de consulta, modelagem dimensional, tipos de junção". Teste técnico de SQL é obrigatório.

dbt. Experiência prática com dbt (não apenas curso). Sabe configurar projeto, escrever modelos com referências entre tabelas, configurar testes, gerar documentação. Idealmente certificação dbt Analytics Engineer.

Modelagem dimensional. Conhece a metodologia Kimball (fato/dimensão), entende quando aplicar e quando flexibilizar. Sabe a diferença entre dimensão de mudança lenta tipo 1 e tipo 2 — e quando cada uma vale a pena.

Conhecimento de negócio. Marketing tem vocabulário próprio (atribuição, taxa de abertura, custo de aquisição, valor do cliente no tempo). O analytics engineer precisa entender o que cada métrica significa para conversar com o time. Em entrevista, peça que a candidata explique como modelaria a tabela de campanhas — você descobre rapidamente se entende o domínio.

Comunicação. Trabalho expõe o analytics engineer ao time de marketing, ao financeiro, ao CMO. Precisa traduzir limitações técnicas em linguagem de negócio e exigências de negócio em modelo técnico.

Git e revisão de código. Trabalha como engenheiro — versionando código, abrindo solicitação de mesclagem, recebendo revisão. Não pode ter problema com isso.

Reporte ideal — onde o analytics engineer fica no organograma

Há três modelos válidos, cada um com vantagens:

Dentro de operações de marketing. Reporta ao líder de operações de marketing, que reporta ao CMO. Vantagem: proximidade total com o cliente interno, agilidade de prioridade, foco em marketing. Desvantagem: pode ficar isolado de boas práticas técnicas e duplicar trabalho que o time de dados central faz para outras áreas.

Em time central de dados / plataforma. Reporta a líder de dados (CDO ou diretor de dados), que atende marketing como cliente interno. Vantagem: pares técnicos, padrão único de modelagem, escala. Desvantagem: marketing pode sentir prioridade diluída entre várias áreas.

Em time de operações de receita (RevOps). Modelo crescente em empresas B2B, onde operações de marketing, vendas e sucesso do cliente são unificadas. Analytics engineer atende toda a jornada de receita. Vantagem: visão integrada do funil; desvantagem: requer maturidade organizacional já elevada.

Para empresa média começando, o modelo 1 (dentro de marketing) costuma ser o mais ágil. Para grande empresa, modelo 2 ou 3 é mais sustentável.

Anti-padrões — o que faz o analytics engineer fracassar

Virar atendente de pedidos. Se o analytics engineer recebe pedidos avulsos do time de marketing e atende cada um isoladamente, sem visão de modelo, vira analista de BI de luxo. O valor está em construir a camada — não em responder cada consulta SQL.

Sem priorização estruturada. Toda área quer "para ontem". Sem um processo de priorização (rito mensal, dono de produto interno, critérios de impacto), o analytics engineer atende quem grita mais alto e o resultado é incoerente.

Sem dono de métrica. Quando ninguém é responsável pela definição de "cliente ativo" ou "custo de aquisição", a discussão volta toda vez. Cada métrica relevante precisa ter um responsável de negócio que aprova mudanças na definição — geralmente alguém de marketing, vendas ou financeiro, conforme o caso.

Modelo sem teste. Modelos em dbt sem testes configurados quebram silenciosamente. Um dia o número errado chega ao painel da diretoria. Testes não são luxo de engenharia — são proteção contra constrangimento público.

Sem documentação. dbt gera documentação automática a partir de descrições nos arquivos. Se essas descrições não são preenchidas, o analytics engineer fica gargalo de todo entendimento.