ETL vs ELT para marketing: qual padrão usar e quando

ETL e ELT não são sinônimos de ferramenta — são decisões de arquitetura sobre onde a transformação acontece e quem a opera. Para marketing, a escolha impacta velocidade de iteração em campanhas, custo de warehouse, dependência de engenharia e capacidade de responder ‘por que o número mudou’ sem abrir ticket. O padrão certo depende de maturidade do time, volume de fontes e tolerância a latência — não de qual vendor está na moda.

Qual a diferença real entre ETL e ELT?

ETL (Extract, Transform, Load) extrai dados das fontes, transforma em ambiente intermediário — servidor dedicado, Spark, ou engine do conector — e carrega o resultado já limpo no destino. A transformação acontece antes do warehouse; o destino recebe dados prontos para consumo.

ELT (Extract, Load, Transform) extrai e carrega dados brutos ou semi-brutos no warehouse primeiro; transformações rodam dentro do destino via SQL, dbt ou scripts. O warehouse vira engine de transformação. A fronteira entre os dois borrou com ferramentas modernas, mas a pergunta permanece: onde vive a lógica de negócio e quem consegue alterá-la?

Quando ETL ainda faz sentido para marketing?

ETL vence quando fontes exigem transformação pesada antes de entrar no warehouse: APIs paginadas com rate limit, dados aninhados complexos, PII que precisa ser mascarada antes de storage, ou volumes que tornariam raw tables proibitivamente caras. Também quando o time de engenharia centraliza pipelines e marketing consome camada gold pronta.

Stacks legados com Informatica, Talend ou pipelines Python/Airflow custom seguem ETL. Se marketing não tem SQL fluente e depende de engenharia para qualquer mudança de campo, ETL bem operado pode ser mais seguro — desde que SLAs de change request sejam realistas para a velocidade de campanha.

PII masking obrigatório antes do warehouse
Fontes com schema instável ou API frágil
Time de marketing sem capacidade SQL/dbt
Latência batch aceitável (T+1 ou mais)
Engenharia centralizada com backlog controlado

Quando ELT é a escolha natural?

ELT brilha com BigQuery, Snowflake ou Redshift como destino, time com SQL competente, e necessidade de iterar transformações rápido. Marketing muda UTM, adiciona conversão, pede novo breakdown — ELT com dbt permite que analytics engineer ou analista avançado implemente e teste sem redeployar pipeline de extração.

Fontes de marketing (Google Ads, Meta, GA4 export, HubSpot) são relativamente bem estruturadas. Carregar raw/staging e transformar in-warehouse é cost-effective e auditável. Lineage fica no dbt; rollback é git revert, não redeploy de job.

Critério	Favorece ETL	Favorece ELT	Nota prática
Velocidade de iteração	Baixa — ticket para engenharia	Alta — SQL/dbt no warehouse	Campanhas mudam rápido; ELT ganha operação
Custo de compute	ETL engine + warehouse	Warehouse only	BigQuery on-demand pode surpreender sem controle
Governança/PII	Masking upstream	Policy tags + views no destino	LGPD exige decisão consciente em ambos
Maturidade do time	Engenharia forte, marketing consumidor	Analytics engineer ou analista SQL	Não subestime curva de dbt
Auditoria/lineage	Depende da ferramenta ETL	dbt docs + git nativo	Lineage é crítico para confiar em ROAS

Como ficam as fontes típicas de marketing em cada padrão?

Google Ads, Meta Ads, LinkedIn: conectores (Fivetran, Airbyte, Stitch) extraem para staging raw; ELT transforma em fato de spend/impressões/cliques. GA4 BigQuery export já é raw no destino — ELT puro. CRM (HubSpot, Salesforce): sync via API para staging, transformação de leads/deals/stages in-warehouse.

GTM/dataLayer events: streaming ou batch para staging; sessionization e funis no warehouse. Offline conversions e CAPI: frequentemente ETL com validação upstream porque erro propaga para leilão. A regra: extração o mais fiel possível à fonte; transformação de negócio o mais perto possível do consumidor — que no ELT moderno é o warehouse.

Quais trade-offs de custo e performance?

ELT empilha compute no warehouse — queries pesadas de transformação competem com BI e podem inflar bill. Mitigue com incremental models, particionamento, schedules off-peak e slots reservados (BigQuery) ou warehouse sizing (Snowflake). ETL distribui compute mas adiciona infraestrutura de pipeline e custo de conector.

Para mid-market com BigQuery, ELT + dbt costuma ser mais barato que manter cluster ETL dedicado — desde que transformações sejam incrementais e não full-scan diário de bilhões de eventos GA4. Monitore bytes processed por model; otimize antes de reclamar de custo de warehouse.

Híbrido ETL+ELT: realidade da maioria dos stacks?

A maioria das operações maduras usa híbrido: ETL para extração e normalização mínima (conectores managed), ELT para transformação de negócio (dbt). O conector faz extract+load; dbt faz transform. Discutir ETL vs ELT como binário é menos útil que definir onde cada camada vive e quem é dono.

Camadas claras ajudam: raw (fiel à fonte) → staging (limpeza técnica) → intermediate (joins, dedupe) → marts (fatos e dimensões de negócio). Marketing consome marts; engenharia opera raw/staging; analytics engineer opera intermediate/marts. Fronteiras explícitas evitam SQL espalhado sem teste.

Raw: dados como vieram da fonte, append-only
Staging: tipagem, dedupe técnico, flatten de nested
Intermediate: joins cross-fonte, identity resolution
Marts: star schema pronto para BI
Cada camada com owner e SLA de freshness

Como decidir sem cair em moda de ferramenta?

Checklist de decisão: (1) quem vai escrever e manter transformações? (2) qual latência mínima aceitável para reporting de mídia? (3) quantas fontes e quão estáveis? (4) requisitos de PII/LGPD? (5) budget de warehouse vs pipeline? Respostas apontam para ETL-heavy, ELT-heavy ou híbrido.

Não migre para ELT porque dbt está na moda se o time não tem SQL nem analytics engineer. Não mantenha ETL legado monolítico se marketing espera 48h por cada campo novo. A decisão é organizacional tanto quanto técnica — e revisável conforme o time amadurece.

Checklist prático

Fontes de marketing mapeadas com volume e frequência
Decisão ETL/ELT/híbrido documentada com critérios
Camadas raw → staging → marts definidas com owners
SLA de latência acordado com stakeholders de mídia
Estimativa de custo de compute warehouse modelada
Capacidade SQL/dbt do time avaliada honestamente
Política de PII definida para cada camada
Plano de evolução conforme maturidade do time

Erros comuns

Escolher ELT sem time capaz de manter SQL/dbt
Full-scan diário de eventos GA4 sem incremental
Transformação de negócio escondida no conector ETL opaco
Ignorar custo de BigQuery/Snowflake em transformações pesadas
Tratar ETL vs ELT como decisão irreversível de vendor
Marketing sem acesso a camada mart e dependente de ticket eterno

Pipeline travado entre extração e BI?

A DataScroll escolhe ETL ou ELT com critério de maturidade, volume e governança — sem moda de ferramenta.

Desenhar meu pipeline Falar com a DataScroll

Perguntas frequentes

▸Fivetran/Airbyte são ETL ou ELT?

São ferramentas de EL — extract and load. Carregam dados brutos ou semi-brutos no warehouse. A transformação (T) fica a cargo de dbt, SQL ou outra engine in-warehouse. No discurso de mercado, stacks com conector + dbt são chamados de ELT mesmo que a extração seja managed.

▸Marketing consegue operar ELT sozinho?

Parcialmente. Analistas avançados com SQL podem iterar em marts e views; extração e staging continuam precisando de engenharia. dbt com documentação boa reduz dependência, mas não elimina necessidade de analytics engineer para mudanças estruturais.

▸Qual latência é realista para reporting de mídia?

T+1 (dados de ontem disponíveis hoje cedo) é o padrão mid-market viável. Intraday exige streaming ou sync frequente e custa mais. Defina expectativa antes de prometer dashboard ‘quase real-time’ que ninguém consegue manter.

▸ETL on-premise ainda existe para marketing?

Sim, em empresas com restrição de cloud ou legado forte. Tende a ser mais caro de operar e mais lento de iterar. Se possível, migre extração para cloud e mantenha transformação in-warehouse — ganho de velocidade sem abandonar governança.

▸Como migrar de ETL legado para ELT?

Paralelo: mantenha pipeline antigo rodando, replique lógica em dbt, reconcilie totais por 2-4 semanas, corte quando divergência for aceitável. Não faça big bang — marketing não perdoa buraco de dados em fechamento de mês.

▸dbt substitui o ETL?

Substitui a camada de transformação, não a extração. Você ainda precisa de conectores ou scripts para trazer dados das fontes. dbt + conector managed é o stack ELT moderno padrão para marketing analytics.

▸Como controlar custo de ELT no BigQuery?

Incremental models, particionamento por data, clustering, schedules noturnos, bytes-processed alerts e revisão mensal de queries caras. Transformação de GA4 raw em full-scan diário é a armadilha número um.

▸A DataScroll implementa ETL ou ELT?

Híbrido pragmático: conectores para extract/load, dbt para transformação de negócio, camadas claras e reconciliação. A escolha segue maturidade do time e requisitos de latência — não moda de ferramenta.