Reverse ETL é o padrão de mover dados do seu data warehouse para ferramentas operacionais como CRM, plataformas de ads e sales engagement. É o inverso do ETL tradicional, que move dados para dentro do warehouse para análise. Reverse ETL é o que torna o warehouse usável como sistema de registro para a motion go-to-market.
Por que existe
Durante a maior parte da história de analytics, o warehouse era um beco sem saída. Data engineers carregavam comportamento de cliente, uso de produto e revenue no Snowflake ou BigQuery, analistas construíam dashboards, e as ferramentas operacionais (Salesforce, HubSpot, Marketo) viviam em um mundo separado. Quando marketing queria “usuários que logaram três vezes na semana passada”, alguém tinha que escrever uma integração custom ou esperar um CSV.
Reverse ETL fecha esse loop. Ferramentas como Hightouch, Census e Polytomic permitem que você escreva SQL uma vez contra o warehouse, defina um sync para um destino, e tenha os dados aparecendo como campos no Salesforce ou audiências no Facebook em minutos.
Quando importa
Reverse ETL é o padrão certo quando três condições se mantêm: os dados sobre os quais você quer agir já vivem no warehouse e são difíceis de recomputar em outro lugar; a ferramenta de destino tem uma API utilizável ou conector nativo; e o time operando os syncs é alfabetizado em data o suficiente para ser dono dos modelos SQL.
Os casos de uso clássicos são product-qualified leads (sincronizar sinais de uso de produto para o CRM como lead scores), targeting de audiência (empurrar segmentos do warehouse para plataformas de ads), e customer health (sincronizar dados de suporte, billing e produto para o tooling de CSM).
O que ele substitui
Reverse ETL compete com três padrões mais antigos: integrações de API feitas à mão (lentas, frágeis), iPaaS como Zapier e Workato (boas para workflows simples, caras em escala), e CDPs empacotados (mais opinativos, menos flexíveis). O padrão de CDP componível é essencialmente reverse ETL mais um modelo de identidade.
Erros comuns
- Sincronizar o grain errado. Empurrar cada evento de produto para o Salesforce vai destruí-lo. Agregue para o grain certo (account-week, user-day) antes de sincronizar.
- Deixar os modelos derivarem. Um sync de reverse-ETL depende de um modelo upstream do dbt. Quando o modelo muda, o destino quebra silenciosamente. Adicione tests e ownership.
- Ativar antes do consentimento. Reverse ETL respeita o consentimento que o warehouse conhece. Se consentimento não está modelado no warehouse, você está empurrando dados não compliant.
Relacionados
- Data warehouse vs CDP — a escolha de arquitetura
- CDP — o padrão alternativo
- RevOps tech stack — onde reverse ETL se encaixa