Data stack moderno para médias empresas: do zero ao insight em 8 semanas

Quando começamos a trabalhar com uma nova empresa, a primeira pergunta que fazemos é: "Onde estão seus dados?" A resposta quase sempre é a mesma: "Em todo lugar."

Google Analytics aqui. CRM ali. Planilha do gestor de tráfego num Google Drive. Dashboard do financeiro em outro sistema. Relatório de performance gerado manualmente toda segunda-feira por um analista que leva três horas para consolidar os números.

E no final, ninguém consegue responder uma pergunta aparentemente simples: "Qual canal trouxe os clientes mais valiosos do último trimestre?"

Esse é o cenário típico de empresas com faturamento entre R$ 5 milhões e R$ 100 milhões por ano. Grandes o suficiente para produzir volumes relevantes de dados, mas ainda sem a infraestrutura para aproveitá-los. Neste guia, apresentamos a arquitetura que implementamos para resolver esse problema — e o que muda quando ela está no ar.

Por que a abordagem tradicional falha

Antes de falar da solução, vale entender por que as abordagens comuns não funcionam em escala:

Planilhas e relatórios manuais são o ponto de partida de quase toda empresa. O problema: são estáticas, quebram com volume, dependem de uma pessoa para atualizar e nunca refletem o momento atual — apenas o passado.

Ferramentas de BI sem camada de dados (Power BI ou Tableau conectados diretamente às fontes) geram consultas lentas, dados inconsistentes entre dashboards e nenhuma governança sobre o que "receita" ou "lead qualificado" significa para a empresa.

Data lakes sem transformação resolvem o problema de armazenamento mas criam outro: analistas passam mais tempo preparando dados do que analisando. Um data lake sem modelagem é um cemitério de dados.

O que falta em todos esses cenários é uma camada de transformação — um lugar onde os dados de diferentes fontes são limpos, padronizados e modelados segundo a lógica de negócio da empresa.

A arquitetura que funciona

Depois de implementar data stacks para dezenas de empresas, chegamos a uma arquitetura padrão que equilibra robustez, custo e velocidade de implementação:

• Ingestão: Fivetran ou Airbyte para conectar fontes sem código — Google Ads, Meta Ads, HubSpot, Shopify, Stripe, RD Station e mais de 300 conectores nativos
• Armazenamento: BigQuery (Google Cloud) como data warehouse central — serverless, sem infraestrutura para gerenciar, cobrança por consulta
• Transformação: dbt (data build tool) para modelar os dados em camadas com SQL versionado e testável
• Visualização: Looker Studio (gratuito, integrado ao BigQuery) para dashboards self-service; Metabase para analistas que precisam de SQL
• Orquestração: Cloud Scheduler para pipelines simples; Airflow ou Prefect para fluxos mais complexos

Essa stack cobre 90% dos casos de uso de médias empresas com custo mensal entre R$ 2.000 e R$ 8.000 — uma fração do custo de montar um time interno para fazer a mesma coisa manualmente.

As 4 camadas de dados

O dbt organiza os dados em camadas. Essa estrutura é o coração de qualquer data stack bem construído:

Camada 1: Raw (dados brutos)

Todos os dados chegam aqui exatamente como a fonte os enviou. Nenhuma transformação, nenhuma limpeza. É a fonte da verdade imutável.

A regra de ouro: nunca altere dados na camada raw. Qualquer bug na transformação pode ser corrigido reprocessando a partir dos dados brutos. Se você alterou o raw, perdeu essa capacidade.

Camada 2: Staging (padronização)

Aqui os dados são limpos e padronizados. Um lead do HubSpot e um lead do RD Station passam a ter o mesmo schema. Datas são convertidas para o mesmo fuso horário. Campos nulos recebem valores padrão. Colunas são renomeadas para seguir a convenção da empresa.

Cada modelo de staging corresponde a uma tabela de uma fonte específica. São transformações simples, sem joins — apenas limpeza e padronização.

Camada 3: Intermediate (lógica de negócio)

Aqui acontece a mágica. Joins entre fontes, agregações e cálculos que carregam a lógica específica do negócio:

• O que é uma "sessão" para essa empresa?
• Um lead é "qualificado" a partir de quais critérios?
• Como calcular o CAC quando o cliente veio de múltiplos canais antes de converter?

Essa camada não é exposta diretamente para os dashboards — é um passo intermediário que alimenta os marts.

Camada 4: Marts (dados prontos para consumo)

Tabelas finais, desnormalizadas e otimizadas para leitura. Cada mart tem um "dono" e responde a perguntas específicas de negócio:

• mart_marketing → performance de campanhas por canal, data e produto
• mart_vendas → funil de conversão, ciclo de vendas, performance por vendedor
• mart_financeiro → receita, margem, CAC, LTV por cohort

Ferramentas e custos reais

Uma dúvida comum: "quanto isso vai custar?"

Para uma empresa média com 5 a 15 fontes de dados e volume de 1 a 50 GB/mês:

| Ferramenta | Custo mensal estimado | |---|---| | BigQuery (armazenamento + consultas) | R$ 200 – R$ 800 | | Fivetran (5-10 conectores) | R$ 1.500 – R$ 4.000 | | dbt Cloud (até 3 desenvolvedores) | R$ 600 – R$ 1.200 | | Looker Studio | Gratuito | | Total infraestrutura | R$ 2.300 – R$ 6.000/mês |

Airbyte self-hosted reduz o custo de ingestão para próximo de zero, mas adiciona overhead de manutenção. Para equipes sem engenheiro dedicado, Fivetran tende a ser mais econômico no total.

O custo de implementação (consultoria externa ou contratação interna) é separado. Com um parceiro especializado, uma implementação completa leva de 6 a 12 semanas.

Cronograma realista: 8 semanas

Esse é o cronograma que seguimos para implementações padrão:

Semanas 1-2: Diagnóstico e setup Mapeamento de todas as fontes de dados, definição de perguntas de negócio prioritárias, setup de BigQuery, primeiras conexões via Fivetran (Google Ads + CRM como ponto de partida).

Semanas 3-4: Staging e primeira entrega Modelos de staging para as fontes prioritárias. Primeira versão dos marts de marketing e vendas. Dashboard executivo inicial no Looker Studio — já respondendo as perguntas mais críticas.

Semanas 5-6: Lógica de negócio e enriquecimento Camada intermediate com a lógica específica da empresa. Cálculo de CAC por canal, LTV por cohort, funil de conversão completo. Conexão com dados financeiros (ERP ou Stripe/PagSeguro).

Semanas 7-8: Marts finais e treinamento Marts de todas as áreas. Dashboards por área (marketing, vendas, financeiro, produto). Treinamento do time para uso autônomo. Documentação no dbt.

Esse cronograma assume dedicação de 20-30% de um ponto focal interno (geralmente um analista ou gestor de marketing/dados) para validar regras de negócio.

Erros comuns na implementação

Depois de dezenas de projetos, os erros mais frequentes são:

1. Começar pela visualização em vez da modelagem Conectar Power BI ou Looker diretamente nas fontes gera dashboards rápidos mas com dados inconsistentes. Dois analistas constroem dashboards diferentes e chegam a números diferentes para a mesma pergunta.

2. Não definir glossário de métricas antes de modelar "Receita" é bruta ou líquida? "Lead" inclui ou exclui leads duplicados? "Cliente ativo" é quem comprou nos últimos 30 ou 90 dias? Essas definições precisam existir antes de qualquer linha de SQL.

3. Tentar integrar todas as fontes ao mesmo tempo Paralisa o projeto. Começar pelas 3-4 fontes que respondem 80% das perguntas críticas. Adicionar o restante em ciclos seguintes.

4. Não versionar o código dbt com Git O dbt é código. Sem versionamento, qualquer mudança pode quebrar um modelo existente sem rastreabilidade.

O que muda depois de 90 dias

Os clientes que implementam essa arquitetura tipicamente reportam:

• Redução de 70% no tempo gasto em relatórios manuais
• Respostas em tempo real para perguntas que antes levavam dias
• Descobertas inesperadas: em 9 de cada 10 implementações, a análise revela que um canal ou produto que parecia ruim pelos dados fragmentados é na verdade o mais rentável
• Mudança cultural: a empresa passa de "achismo" para tomada de decisão baseada em dados — com o tempo, times começam a formular hipóteses e testá-las sistematicamente

Leia também como um time de marketing enxuto pode aproveitar ao máximo essa infraestrutura em nosso artigo sobre como montar um time orientado a dados.

Perguntas frequentes sobre data stack

Preciso de um engenheiro de dados para manter o stack? Não necessariamente. Com Fivetran + dbt Cloud + BigQuery, o volume de manutenção é baixo. Um analista de dados com SQL intermediário consegue manter e evoluir o stack. Para empresas sem esse perfil, um parceiro externo faz sentido.

BigQuery vs Snowflake vs Redshift — qual escolher? Para empresas no ecossistema Google (Google Ads, GA4, Google Workspace), BigQuery tem integração nativa e é a escolha mais natural. Snowflake tem melhor performance para consultas complexas. Redshift faz sentido apenas se você já está na AWS.

Quanto tempo leva para o ROI aparecer? Nos projetos que acompanhamos, as primeiras decisões orientadas por dados (que seriam impossíveis antes) acontecem já nas primeiras 4 semanas. O ROI financeiro mensurável — em horas economizadas e decisões de mídia melhoradas — aparece em 60 a 90 dias.

E se nossos dados estiverem muito bagunçados? Dados bagunçados são a norma, não a exceção. A camada de staging do dbt existe exatamente para lidar com isso. O diagnóstico inicial (semanas 1-2) mapeia o estado atual e define a estratégia de limpeza.

Próximos passos

Se você reconheceu o cenário descrito no início deste artigo — dados espalhados, relatórios manuais, perguntas sem resposta — o primeiro passo é entender quais são suas perguntas de negócio mais críticas.

A partir daí, é possível definir quais fontes priorizar, que arquitetura faz sentido para o seu volume e qual cronograma de implementação é realista para o seu contexto.

Fale com nossa equipe de Data Engineering para uma conversa inicial sem compromisso. Ou conheça em detalhes como estruturamos nossos serviços de dados.