Como conectar o Facebook Ads ao Looker Studio: todos os caminhos e quanto custa cada um
Não existe conector feito pelo Google para o Facebook Ads, e nunca vai existir. Se você abriu a lista de fontes de dados do Looker Studio (que o Google renomeou para Data Studio em abril de 2026), digitou "Facebook" e recebeu uma grade de conectores de terceiros, cada um com a sua página de preços, a busca não falhou: essa é a situação real da integração. Os caminhos que existem de verdade são quatro: um conector de parceiro pago, um conector da comunidade gratuito, a exportação do Gerenciador de Anúncios para o Planilhas Google e o BigQuery como etapa intermediária. Este guia mostra quanto cada um custa em dinheiro e em manutenção, quais opções "grátis" são reais e o problema de atribuição que todos eles erram por padrão.
Por que não existe conector nativo do Facebook Ads
O catálogo do Looker Studio é, na verdade, três catálogos numa vitrine só. Os conectores do Google — Search Console, Analytics, Google Ads, Planilhas Google, BigQuery — são do próprio Google e gratuitos. Os conectores de parceiros são produtos comerciais criados e vendidos por outras empresas, normalmente cobrados por fonte de dados, por mês. Os conectores da comunidade são publicados por alguém que pode ou não continuar cuidando deles.
O Meta Ads fica no segundo e no terceiro grupos, ao lado de TikTok, LinkedIn, Shopify e Stripe. A Meta concorre com o Google em publicidade; uma integração oficial e gratuita para dentro de um produto de relatórios do Google nunca foi uma decisão de produto plausível. A versão longa desse argumento está em sem conector do Looker Studio para a sua fonte (em inglês).
A consequência prática: a partir do momento em que uma fonte precisa de conector de parceiro, o custo dela deixa de crescer com o volume de dados e passa a crescer com o número de fontes. Um relatório com cinco canais custa cinco vezes mais para manter no ar do que um relatório com um canal só, e os dados não cresceram nada.
Os quatro caminhos que existem de verdade
1. Um conector de parceiro pago
Supermetrics, Windsor.ai, Catchr, Porter, Dataslayer e outros vendem esse conector. Você autoriza, escolhe a conta de anúncios e os dados do Facebook aparecem na lista de fontes como se fossem nativos. É o caminho mais rápido até um gráfico funcionando e, para uma fonte chata que importa todo dia, é a escolha certa.
O que ele custa além da assinatura: um fornecedor para cada fonte, uma autorização OAuth que expira e precisa ser aprovada de novo, uma página de status para conferir quando o gráfico fica em branco e faixas de preço que muitas vezes dependem do número de contas de anúncios — justamente a dimensão em que uma agência cresce.
2. Um conector da comunidade
Gratuito, listado na mesma galeria e o motivo de muita gente achar que o problema está resolvido. A contrapartida é real: você entrega a um terceiro desconhecido um token da sua conta de anúncios, e ninguém tem obrigação de atualizar o conector quando a Meta lança uma versão da API de Marketing que quebra a integração. A falha não aparece como mensagem de erro — aparece como um painel que continua desenhando o formato de ontem com a data de hoje, sem trazer nada novo.
3. Exportar do Gerenciador de Anúncios para o Planilhas Google
Também é gratuito, funciona hoje e, sem alarde, é o que mais gente faz na prática. O Gerenciador de Anúncios exporta um CSV, o CSV vai para uma planilha do Google e o Looker Studio lê a planilha pelo conector do próprio Google. Com o tempo, isso quebra de três jeitos previsíveis: cada atualização depende de alguém lembrar de exportar de novo, cada mudança de coluna da Meta quebra uma fórmula três abas para dentro, e o painel não dá sinal nenhum de que os números por trás dele têm onze dias.
4. Carregar os dados no BigQuery antes
É a resposta "do jeito certo" e está correta de verdade na escala de um data warehouse. Mas ela muda o problema de lugar em vez de resolvê-lo: alguma coisa ainda precisa gravar os dados do Facebook no BigQuery, e essa coisa é um fornecedor de ELT cobrado por conector — o mesmo imposto por conector, pago de novo uma camada abaixo — ou código de pipeline que agora é seu para manter e depurar. Para uma base de marketing medida em milhões de linhas, e não em bilhões, é matar mosquito com canhão; defendemos esse ponto em o menor data warehouse de marketing que funciona (em inglês).
Instagram Ads: os mesmos quatro caminhos, com um passo a mais
Anúncios do Instagram são anúncios da Meta, então não existe um conector separado de Instagram Ads para procurar. Eles são comprados no mesmo Gerenciador de Anúncios, cobrados na mesma conta de anúncios e reportados pela mesma API de Marketing. Todos os caminhos acima que puxam o Facebook Ads já puxam os seus anúncios do Instagram, somados nos mesmos totais de campanha.
O passo a mais é separar. A Meta informa onde o anúncio rodou como um detalhamento, e não como uma conta separada. No Gerenciador de Anúncios, o caminho é Detalhamento → Por veiculação → Plataforma (na interface em inglês, Breakdown → By delivery → Platform), como mostra a Central de Ajuda da Meta. Na API de Marketing, é o detalhamento publisher_platform, que a Meta documenta como a plataforma em que o anúncio foi exibido — Facebook, Instagram ou Audience Network (referência de detalhamentos da Meta). Uma extração no nível de campanha sem esse detalhamento traz Facebook e Instagram somados, e o Looker Studio não tem como separá-los depois.
- Conector de parceiro: adicione ao gráfico a dimensão de plataforma (publisher platform). Um conector que não expõe essa dimensão não consegue separar o Instagram.
- Exportação para o Planilhas Google: aplique o detalhamento Plataforma no Gerenciador de Anúncios antes de exportar, para o CSV vir com uma linha por plataforma. Com as linhas separadas, dá para comparar o custo de cada plataforma na calculadora de CPM, que aceita uma linha por posicionamento.
- TableBI: o conector ao vivo de Meta Ads (beta) sincroniza no nível de campanha, então o investimento e os resultados do Instagram ficam dentro dos totais da campanha, sem separação por plataforma. Uma exportação do Gerenciador de Anúncios com o detalhamento Plataforma preserva essa coluna: o TableBI guarda toda coluna de CSV que não tem definição compartilhada em
meta_ads_raw, onde dá para agrupar por ela.
Insights da Página e dados públicos do Facebook são outra integração
Os dados orgânicos do Facebook — alcance, seguidores, posts e engajamento de uma Página — não vêm por nenhum conector de Facebook Ads. Eles pertencem à Página, e não à conta de anúncios, ficam atrás de outra permissão, e os fornecedores de conectores vendem isso como uma fonte separada. A Supermetrics, por exemplo, lista o Facebook Insights para Páginas que você gerencia e o Facebook Public Data para posts públicos de Páginas que você não gerencia, como dois conectores à parte do Facebook Ads.
Os "dados públicos do Facebook" são o mais restrito dos dois. Eles existem para fazer benchmarking de outras Páginas a partir do que elas publicam, e a própria documentação da Supermetrics diz que há dados de aproximadamente 600 posts publicados e ranqueados por ano, só com comentários de primeiro nível (documentação da Supermetrics).
O caminho gratuito espelha o dos anúncios: no Meta Business Suite, o botão Exportar (Export), em Insights, baixa como arquivo os insights que você está vendo (Central de Ajuda do Facebook), e uma planilha do Google com esse arquivo entra no Looker Studio como qualquer outra planilha. O TableBI não conecta os Insights da Página: o conector da Meta cobre só anúncios.
"Conectar Facebook Ads ao Looker Studio grátis": a resposta sem rodeios
Muita gente chega a esse problema com a palavra grátis grudada, então ela merece uma resposta direta, e não um funil de vendas. Dois dos quatro caminhos acima não custam nada em dinheiro: o conector da comunidade e a exportação para o Planilhas Google. Os dois são legítimos, e os dois cobram o preço em outra moeda.
O conector da comunidade cobra em confiança e fragilidade — alguém desconhecido tem um token da sua conta de anúncios, e ninguém é obrigado a corrigir nada quando a versão da API muda. O caminho das planilhas cobra em atenção — uns dez minutos por semana, para sempre, mais o risco de alguém decidir verba olhando uma aba desatualizada. Se o seu relatório é uma conta e uma apresentação por mês, o caminho das planilhas resolve de verdade e você pode parar de ler aqui. Se são várias contas, toda semana, para gente que toma decisão com esses números, os caminhos grátis são os caros.
O erro que todo caminho comete por padrão
Essa é a falha que sobrevive às quatro opções, por isso merece mais atenção do que a própria escolha do conector. A Meta reatribui conversões numa janela móvel de aproximadamente sete dias. Uma conversão que acontece hoje pode ser creditada a uma impressão de cinco dias atrás, o que significa que os números da terça passada ainda estão mudando nesta terça.
Qualquer pipeline que puxa "só ontem" e acrescenta ao histórico fica, portanto, errado para sempre no passado recente — e errado para baixo: como as revisões costumam ser para cima, os números gravados ficam abaixo da realidade, e a semana parece mais fraca do que realmente foi. O painel mostra uma semana fraca que se firmou depois, quando ninguém mais estava olhando. A correção é puxar de novo a janela móvel a cada sincronização, em vez de acrescentar uma vez só, e fazer o relatório dizer quais dias ainda não estão consolidados. A maioria das configurações de conector não faz nem uma coisa nem outra, e nada na tela do Looker Studio avisa isso.
O quinto caminho: montar o painel fora do Looker Studio
A opção que não está na lista de conectores, porque não é um item da lista: não montar o relatório no Looker Studio. Entregue os mesmos dados a um backend que os normaliza em definições compartilhadas entre canais e publique o painel a partir dali. Você abre mão do arrastar e soltar. Em troca, se livra de uma vez do preço por fonte, do ritual de atualizar na mão e dos números que a atribuição muda depois.
É isso que o TableBI faz. O caminho que funciona para todo mundo hoje é a exportação — o mesmo CSV que você colaria numa planilha, etiquetado na entrada para cair nas mesmas tabelas dos seus outros canais:
# instale uma vez npm i -g @tablebi/cli tablebi login tablebi install # a exportação do Gerenciador de Anúncios, normalizada em definições compartilhadas tablebi connect csv --file meta-ads-august.csv --platform meta_ads # confira o que entrou e como foi interpretado tablebi sources tablebi sample
A etiqueta --platform não é um metadado cosmético. É ela que coloca essas linhas na mesma tabela facts do Google Ads e do Search Console, para que investimento seja investimento e clique seja clique, seja qual for o dialeto da plataforma de origem. É isso que um conector por fonte, pela própria estrutura, não consegue entregar: os conectores trazem cada plataforma no seu próprio vocabulário e deixam a conciliação para você e para uma configuração de combinação que mente.
Também existe um conector OAuth ao vivo:
tablebi connect meta_ads tablebi sync meta_ads
O Meta Ads está em beta. Nosso app da Meta ainda não passou pela análise do app (App Review), então hoje ele só autoriza contas de anúncios que são suas ou pessoas adicionadas como usuários de teste. Se esse não é o seu caso, o caminho do CSV acima é o que funciona — e ele cai exatamente nas mesmas tabelas. Search Console, GA4 e Google Ads se conectam ao vivo, sem essa ressalva.
O que dá para perguntar quando os dados estão lá
A razão de tirar o Facebook de um painel só dele é a pergunta que antes exigia dois painéis:
# ROAS de Meta e Google Ads: uma consulta, uma definição de ROAS tablebi ask "SELECT platform, SUM(cost) AS spend, roas(SUM(conversion_value), SUM(cost)) AS roas, cpa(SUM(cost), SUM(conversions)) AS cpa FROM facts WHERE date >= (SELECT MAX(date) FROM facts) - 28 GROUP BY platform ORDER BY spend DESC"
Duas coisas ali são essenciais. roas() e cpa() são macros de definição, então a conta é feita uma vez só no backend, em vez de ser refeita em cada gráfico — é assim que você evita o erro da média de médias, que estraga a maioria dos gráficos de razão montados à mão (a versão longa, em inglês). E o filtro de data se ancora em MAX(date), e não no calendário, por causa da janela de atribuição: "hoje" não é uma linha consolidada.
Perguntas de investigação descem para o nível bruto, onde os campos originais da Meta ficam intactos:
tablebi ask "SELECT campaign, SUM(clicks) AS clicks, SUM(impressions) AS imp
FROM meta_ads_raw
GROUP BY campaign ORDER BY clicks DESC LIMIT 20"
Toda resposta vem com um bloco de confiança — o quanto cada fonte está atualizada, mais as ressalvas que se aplicam, incluindo a janela móvel de reatribuição. Para o fluxo de relatório, e não a conexão, veja relatórios de Meta Ads sem sofrer com planilha (em inglês); para o número blended que tudo isso existe para produzir, veja ROAS blended (em inglês) ou faça a conta na calculadora de ROAS.
Fixe numa URL ao vivo
Quando vale a pena guardar uma visão, fixe. O que fica salvo é a consulta, e não um retrato, então a URL se atualiza sozinha conforme os dados sincronizam:
tablebi pin --title "Paid overview — Meta + Google Ads" \ --widget "Daily spend::line=SELECT date, SUM(cost) AS spend FROM facts …" \ --widget "ROAS by platform=SELECT platform, roas(SUM(conversion_value), SUM(cost)) AS roas FROM facts …" ✓ published → https://dk.tablebi.com/d/dsh_… (public, read-only, self-refreshing)
Um de verdade, fixado exatamente assim — dados ao vivo, não um mockup: