BigQuery + Google Ads data pipeline 2026: construa o seu data warehouse de reporting

Toda operação séria de Google Ads acaba por superar a UI da plataforma e as folhas de cálculo exportadas. As perguntas de reporting que mais importam — qual o meu verdadeiro custo por negócio closed-won, que campanhas conduzem sessões que convertem 60 dias depois, como Google, GA4 e o CRM se reconciliam — não podem ser respondidas dentro do Google Ads porque os dados vivem em três sistemas diferentes. Um warehouse de reporting BigQuery é como as equipas de analytics resolvem isto em 2026, e a Google tornou a rampa de entrada dramaticamente mais fácil com o Data Transfer Service gerido.

Este é um tutorial prático para analistas e engenheiros. Vamos construir o pipeline de ponta a ponta: provisionar o projeto Cloud, configurar o Data Transfer Service, ativar a exportação GA4, desenhar um schema em camadas, juntar receita CRM pelo GCLID, agendar a atualização diária, pôr o Looker Studio em cima, e manter os custos BigQuery sob controlo. Assumimos fluência em SQL e familiaridade básica com Google Cloud. Se vem de uma fundação tracking-first, o nosso guia de configuração GA4 e import de conversões é o pré-requisito certo.

Por que construir um pipeline BigQuery para Google Ads

A UI do Google Ads é excelente para gerir campanhas e fraca para análise cross-system. Três limites estruturais empurram as equipas para um warehouse.

Primeiro, a lacuna de receita. O Google Ads sabe quanto gastou e quantas conversões contou, mas não conhece o seu pipeline closed-won, o comprimento do seu ciclo de vendas, ou a sua taxa de reembolso. Um lead que o Google conta como evento de conversão de 0 euros pode tornar-se num negócio enterprise de 40.000 euros nove meses depois. Sem juntar receita CRM de volta ao clique, otimiza para volume de conversão em vez de lucro — a falha de reporting mais comum e mais cara no PPC B2B.

Segundo, a mistura cross-channel. A aquisição moderna corre em Google, Meta, LinkedIn, e mais. Cada plataforma reporta no seu próprio walled garden com a sua própria atribuição. Um warehouse é o único sítio para construir uma única visão mista onde gasto e resultados de cada canal estão na mesma tabela com definições consistentes. O nosso guia de atribuição cross-channel cobre a metodologia; o BigQuery é onde a implementa.

Terceiro, o teto de análise. Testes de incrementalidade, modelação de customer lifetime value, retenção por cohort, e marketing mix modeling exigem todos dados ao nível do evento e históricos que a UI simplesmente não expõe. Um warehouse com dois a três anos de histórico limpo é o substrato sobre o qual assenta cada técnica avançada de medição. O próprio framework MMM open-source da Google, coberto no nosso guia Meridian, lê diretamente do BigQuery.

A economia é favorável. O Data Transfer Service é gratuito. Os primeiros 10 GB de armazenamento e o primeiro 1 TB de processamento de queries do BigQuery cada mês são gratuitos, e além disso o armazenamento corre cerca de 0,02 euros por GB por mês e as queries cerca de 5-6 euros por TB analisado. Um warehouse bem construído de conta única raramente excede 150 euros/mês e frequentemente corre abaixo de 50. Contra o custo de gasto publicitário mal alocado, isso é um erro de arredondamento. O investimento é tempo de engenharia, não faturas cloud.

O retorno é duradouro. Uma vez que o pipeline exista, cada nova pergunta torna-se uma query SQL em vez de um exercício manual de export-and-pivot. Os relatórios atualizam-se sozinhos. Novos canais ligam-se ao mesmo schema. E a fundação de dados compõe-se: quanto mais tempo o warehouse corre, mais valioso o seu histórico se torna para modelação.

Visão geral da arquitetura e as três fontes de dados

A arquitetura de referência é um warehouse em camadas alimentado por três fontes, transformado por SQL agendado, e exposto no Looker Studio.

As três fontes de dados:

A convenção de dataset em camadas mantém o warehouse mantível e custo-eficiente:

• raw_google_ads — exportações DTS intocadas. Nunca consultadas diretamente por relatórios. Tratar como zona de aterragem imutável.
• exportação raw GA4 — as tabelas events_ que o GA4 aterra no seu próprio dataset, particionadas por data de evento.
• staging — views e tabelas limpas, padronizadas. Micros convertidos para moeda, colunas renomeadas, duplicados de janela de atualização removidos, date spine e mapeamento de contas unidos.
• reporting — tabelas curadas e desnormalizadas construídas com propósito para dashboards. Esta é a única camada que o Looker Studio toca.

Esta separação importa por três razões: isola dados raw para que um bug de transformação nunca corrompa a fonte, concentra joins caros em construções agendadas em vez de por refresh de dashboard, e dá-lhe uma fronteira de permissões limpa — analistas obtêm acesso de leitura apenas a reporting.

A orquestração é deliberadamente simples. O Data Transfer Service e a exportação GA4 correm no agendamento da Google, aterrando dados frescos cada manhã. Algumas horas mais tarde, scheduled queries BigQuery reconstroem as tabelas de staging e reporting. O Looker Studio lê o resultado. Sem orquestrador externo, sem servidores, sem containers. Pode graduar para dbt e Cloud Composer mais tarde, mas não precisa deles para começar, e adicioná-los prematuramente é over-engineering.

Uma nota sobre regiões: escolha uma localização BigQuery (multi-região EU para residência de dados europeia) e use-a para cada dataset. Queries cross-região não são permitidas, portanto uma incompatibilidade de localização entre o seu dataset DTS e o seu dataset CRM quebrará joins. Decida uma vez, à partida.

Configurar o Google Ads Data Transfer Service

O Data Transfer Service (DTS) é a fundação, e é genuinamente alguns cliques de configuração mais uma espera pelo backfill.

Pré-requisitos:

• Um projeto Google Cloud com billing ativado
• A BigQuery API e a BigQuery Data Transfer API ativadas
• Uma conta Google com acesso de leitura à conta Google Ads de destino (ou MCC)
• O customer ID da conta Google Ads (10 dígitos, sem traços)

Passos de configuração:

1. Na consola BigQuery, abra Data transfers e clique em Create transfer.
2. Escolha Google Ads como fonte.
3. Nomeie a transferência, defina o schedule para diário, e escolha um horário no início da manhã.
4. Defina o destination dataset para raw_google_ads.
5. Introduza o Customer ID — use o MCC ID para puxar todas as contas filhas numa só transferência.
6. Configure a refresh window (o número de dias passados que o DTS volta a puxar a cada execução) para captar backfill de conversões e atribuição tardia.
7. Autentique com uma conta que tenha o acesso Google Ads necessário e guarde.

O DTS criará um conjunto de tabelas em raw_google_ads — campaign, ad group, ad group criteria (keywords), conversions, e mais — cada uma sufixada por data ou particionada, dependendo da tabela. A nomenclatura segue o schema documentado da Google; mantenha essa documentação aberta como referência porque os nomes das colunas são verbosos e as tabelas de stats separam métricas de atributos.

Corra um backfill imediatamente. Uma transferência fresca apenas puxa para a frente a partir de hoje. Para obter histórico, acione um backfill manual para os últimos 12 meses (ou até onde precisar e a conta suporte). Backfills correm como uma série de jobs diários e podem demorar para intervalos longos, mas só precisam de correr uma vez.

Valide a primeira carga. Após a execução inicial completar, faça uma sanity-check: some o custo (em micros, depois divida por 1.000.000) para uma semana recente e compare contra a UI do Google Ads para a mesma janela. Pequenas discrepâncias são normais por causa da janela de atualização de atribuição e fronteiras de fuso horário, mas os totais devem ser próximos. Se estiverem totalmente fora, verifique que selecionou o customer ID e fuso horário corretos.

Considerações MCC. Uma transferência MCC etiqueta cada linha com o seu customer ID. Isto é poderoso para agências mas multiplica o volume de dados. Com muitas contas, particionar por data e organizar por customer ID na sua camada de staging deixa de ser um nice-to-have e torna-se a diferença entre uma fatura mensal de 40 e 400 euros. Planeie isto desde a primeira tabela de staging.

Desenhar o schema BigQuery e a camada de staging

As tabelas raw do DTS são precisas mas desconfortáveis: custos em micros, nomes de colunas crípticos, tabelas separadas de stats e atributos, e sobreposição de janela de atualização. A camada de staging corrige tudo isto uma vez para que as queries downstream se mantenham limpas.

Transformações de staging principais:

-- staging.campaign_performance_daily
CREATE OR REPLACE TABLE staging.campaign_performance_daily
PARTITION BY date
CLUSTER BY customer_id, campaign_id AS
SELECT
  _DATA_DATE                         AS date,
  customer_id,
  campaign_id,
  campaign_name,
  metrics_cost_micros / 1000000      AS cost,
  metrics_impressions                AS impressions,
  metrics_clicks                     AS clicks,
  metrics_conversions                AS conversions,
  metrics_conversions_value          AS conversion_value
FROM `raw_google_ads.ads_CampaignBasicStats_*` s
JOIN `raw_google_ads.ads_Campaign_*` c USING (campaign_id)
WHERE _DATA_DATE = c._DATA_DATE;

As especificidades dos nomes das tabelas variam com a versão do schema DTS, mas o padrão mantém-se: converter micros, renomear para colunas legíveis, juntar stats a atributos, particionar por data, organizar pelas colunas pelas quais mais filtra.

Desduplicar a janela de atualização. Como o DTS volta a puxar dias passados, a mesma data pode aparecer em múltiplas cargas snapshot. Selecione o snapshot mais recente por data lógica usando uma window function ou lendo a partição que o DTS marca como atual. Saltar este passo conta gasto em duplicado nos seus dias mais recentes — um bug subtil que erode a confiança no warehouse.

Tabelas de apoio que vai precisar:

Particionar e organizar não são opcionais. Particione cada tabela materializada de staging e reporting por date. Organize por customer_id e campaign_id (ou qualquer que seja a coluna pela qual os seus relatórios filtram). Esta é a alavanca que controla o custo: uma query para o último mês contra uma tabela particionada por data analisa apenas os bytes do último mês, não três anos de histórico. A diferença é frequentemente 30x num warehouse maduro.

Views versus tabelas. Para transformações leves, views são boas e não incorrem custo de armazenamento — mas voltam a analisar dados fonte em cada leitura. Para qualquer coisa consultada repetidamente por dashboards, materialize uma tabela particionada via scheduled query. A regra prática: transformação barata lida uma vez é igual a view; transformação cara lida muitas vezes é igual a tabela materializada.

Mantenha a camada de staging aborrecida e determinística. Deve fazer exatamente um trabalho — transformar exportações raw DTS e GA4 em blocos de construção limpos, bem tipados, particionados — para que a camada de reporting se possa focar nos joins interessantes.

Juntar dados GA4, Google Ads e CRM

É aqui que o warehouse ganha o seu sustento. Três fontes, unidas corretamente, respondem a perguntas que nenhuma plataforma sozinha consegue.

O GCLID é a coluna vertebral da atribuição de receita. Quando alguém clica num anúncio Google com auto-tagging ligado, o Google anexa um GCLID ao URL de aterragem. Capte-o num campo de formulário oculto, persista-o no seu CRM contra o lead, e torna-se a chave de join entre cliques Google Ads e receita closed-won.

-- reporting.campaign_to_revenue
SELECT
  ga.date,
  ga.campaign_name,
  ga.cost,
  ga.conversions,
  COUNT(DISTINCT crm.deal_id)        AS deals_closed,
  SUM(crm.closed_won_amount)         AS crm_revenue,
  SAFE_DIVIDE(ga.cost, SUM(crm.closed_won_amount)) AS cost_to_revenue_ratio
FROM staging.click_with_gclid ga
LEFT JOIN crm.deals crm
  ON ga.gclid = crm.gclid
GROUP BY ga.date, ga.campaign_name, ga.cost, ga.conversions;

O LEFT JOIN é deliberado: gasto não correspondido tem de ficar visível. Se fizer inner-join, cada clique sem um negócio correspondido desaparece silenciosamente, e a sua matemática de custo por receita lisonjeia-se. Mantenha todo o gasto no resultado e trate a taxa de correspondência como a sua própria métrica de saúde.

Juntar GA4 para profundidade comportamental. A exportação GA4 aterra linhas ao nível do evento com event_params aninhados. Faça unnest deles para recuperar a campanha, qualidade de sessão e landing page, depois agregue à granularidade que precisa.

-- staging.ga4_sessions (campanha e landing page recuperadas de event_params)
SELECT
  PARSE_DATE('%Y%m%d', event_date) AS date,
  (SELECT value.string_value FROM UNNEST(event_params) WHERE key = 'campaign') AS campaign,
  COUNTIF(event_name = 'session_start') AS sessions,
  COUNTIF(event_name = 'sign_up')       AS signups
FROM `analytics_XXXXXX.events_*`
WHERE _TABLE_SUFFIX BETWEEN '20260101' AND '20261231'
GROUP BY date, campaign;

Restrinja sempre o _TABLE_SUFFIX do GA4 a um intervalo de datas — as tabelas de events são grandes e uma análise wildcard sem limite é a clássica armadilha de custo do GA4.

Carregar o CRM. Coloque negócios no BigQuery com o que se adequar ao seu stack: um conector gerido como Fivetran, uma Cloud Function agendada a bater na API do seu CRM, ou uma carga CSV noturna. As colunas mínimas são deal ID, GCLID, montante closed-won, data de fecho, e fase. Atualize diariamente para que a receita se mantenha atual.

Quando a cobertura GCLID for fraca, as taxas de correspondência sofrem e a receita parece subestimada. As correções upstream são enhanced conversions e import de conversões offline, que ambas melhoram quão fiavelmente os cliques se ligam de volta aos resultados — ver o nosso guia de configuração de enhanced conversions. Como fallback no warehouse, um join baseado em UTM recupera algumas linhas não correspondidas, mas trate-o como suplemento de menor confiança, não substituto para GCLID.

A saída desta secção é uma única tabela unificada que carrega gasto, conversões Google, engagement GA4, e receita CRM lado a lado — a tabela sobre a qual cada relatório PPC significativo é construído.

Scheduled queries e a atualização diária

Com a lógica de staging e reporting escrita, automatize a construção diária para que o warehouse se mantenha sozinho.

Scheduled queries nativas são a ferramenta de início certa. O BigQuery permite-lhe agendar qualquer instrução SQL numa cadência tipo cron sem custo extra além do processamento de query que consome. Agende primeiro a construção de staging, depois a construção de reporting, ambas com tempo algumas horas depois do DTS e da exportação GA4 tipicamente completarem de manhã. Essa ordenação garante que cada camada lê dados upstream frescos.

Use a semântica de escrita certa:

Para a maioria do reporting PPC, reconstruir as últimas N partições com WRITE_TRUNCATE com âmbito nessas partições é a abordagem correta mais simples — absorve naturalmente o backfill da janela de atualização do DTS sem duplicar dados mais antigos.

Adicione uma verificação de frescura. Uma pequena scheduled query que compara a data máxima em cada tabela fonte contra hoje e escreve um alerta (ou falha ruidosamente) apanha o modo de falha silenciosa onde o DTS ou a exportação GA4 saltam um dia e os seus dashboards mostram silenciosamente números obsoletos. Esta única guard previne a classe mais embaraçosa de incidente de reporting.

-- monitoring.freshness_check
SELECT
  'google_ads' AS source,
  MAX(date)    AS latest_date,
  DATE_DIFF(CURRENT_DATE(), MAX(date), DAY) AS days_behind
FROM staging.campaign_performance_daily
HAVING days_behind > 1;

Se essa query retornar linhas, algo a montante está obsoleto e precisa de atenção.

Quando graduar para dbt. Scheduled queries lidam confortavelmente com um warehouse de conta única por muito tempo. Mude para dbt quando a lógica de transformação exceder cerca de 10-15 modelos interdependentes, quando quiser testes automatizados e documentação ao nível de coluna, ou quando vários analistas editarem o mesmo SQL e precisarem de controlo de versões e lineage. dbt orquestrado pelo Cloud Composer (Airflow gerido) é o próximo passo comum — mas adopte-o porque a complexidade o exige, não porque está na moda.

Disciplina de backfill. Quando muda uma transformação, volte a executá-la pelo histórico para que as partições antigas reflitam a nova lógica. Parametrize as suas scheduled queries por data para que o mesmo SQL sirva tanto a execução incremental diária como um backfill manual completo.

Reporting Looker Studio e gestão de custos

O warehouse só é útil se as pessoas o conseguirem ler, e o Looker Studio é o frontend natural para BigQuery.

Ligue apenas a tabelas curadas. Aponte cada fonte de dados Looker Studio para o dataset reporting, nunca para exportações raw ou tabelas de staging largas. Esta é a decisão de custo mais importante em todo o pipeline. O Looker Studio atualiza queries em interação e num schedule de cache; se um dashboard popular consultar uma tabela não particionada de histórico completo, os bytes analisados — e a fatura — compõem-se rapidamente.

Um conjunto prático de dashboard inicial:

• Visão geral executiva — gasto misto, conversões e receita CRM entre canais, em tendência ao longo do tempo.
• Visão geral de conta — desempenho por conta para configurações MCC, usando os nomes amigáveis do mapeamento de contas.
• Drill-down por campanha — gasto, CPA, custo por receita, e engagement GA4 por campanha e ad group.

Controlos de custo que realmente importam:

Monitorize as queries mais caras. A view INFORMATION_SCHEMA.JOBS expõe cada query, quem a correu, e quantos bytes processou. Uma olhada semanal aos maiores consumidores expõe o um relatório ou scheduled query silenciosamente a dominar a sua fatura, para que o possa otimizar — geralmente acrescentando um filtro de partição ou materializando um join.

SELECT
  user_email,
  query,
  total_bytes_processed / POW(10, 12) AS tb_processed
FROM `region-eu`.INFORMATION_SCHEMA.JOBS
WHERE creation_time > TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 7 DAY)
ORDER BY total_bytes_processed DESC
LIMIT 20;

Defina um orçamento de billing e alerta no projeto Cloud independentemente de quão cuidadoso seja. É o backstop que transforma uma query descontrolada de uma surpresa de fim de mês numa notificação do próprio dia.

Com tabelas curadas, filtros de partição, BI Engine para dashboards hot, e monitorização de custo semanal, um warehouse de conta única fica confortavelmente no intervalo de 30-150 euros/mês enquanto serve relatórios rápidos e confiáveis.

Padrões SQL para fundações de incrementalidade e LTV

O warehouse não é apenas reporting mais bonito — é o substrato para o trabalho de medição que conduz decisões reais de orçamento. Eis os padrões fundacionais.

Incrementalidade geo-holdout. O teste de incrementalidade pergunta que conversões teriam acontecido sem os anúncios. O warehouse torna a análise trivial uma vez que um experimento geo corra: etiquete regiões como teste ou controlo, depois compare taxas de conversão entre os dois grupos para a janela de teste.

-- lift de incrementalidade por grupo de região
SELECT
  geo_group,
  SUM(conversions) / SUM(sessions) AS conversion_rate
FROM reporting.geo_experiment
WHERE date BETWEEN @test_start AND @test_end
GROUP BY geo_group;

O lift entre teste e controlo, normalizado por tamanho de grupo, estima a contribuição incremental. A metodologia e o design do teste vivem no nosso guia de testes de incrementalidade; o BigQuery é onde o calcula em escala e o volta a executar a cada trimestre sem esforço manual.

Retenção por cohort e LTV. A modelação de lifetime value começa por dividir clientes em cohorts pelo mês de aquisição e seguir a receita para a frente.

-- cohorts mensais de aquisição com receita cumulativa
SELECT
  DATE_TRUNC(first_close_date, MONTH) AS cohort_month,
  DATE_DIFF(revenue_month, first_close_date, MONTH) AS month_index,
  SUM(revenue) AS cohort_revenue
FROM reporting.customer_revenue_monthly
GROUP BY cohort_month, month_index
ORDER BY cohort_month, month_index;

Esta matriz de cohort é a matéria-prima para curvas LTV, análise de payback period, e rácios CAC para LTV por canal de aquisição — as métricas que devem governar a alocação de orçamento. Unidas de volta à campanha que produziu o GCLID de cada cliente, pode computar LTV por campanha, não apenas CPA por campanha, que é um alvo de otimização muito melhor. A nossa análise de CAC payback por vertical mostra os benchmarks que estas queries alimentam.

Reporting cross-channel misto. Uma vez que Meta, LinkedIn, e outros canais aterrem no mesmo warehouse com definições consistentes, um único UNION ALL da tabela diária de cada canal seguido de GROUP BY channel com SAFE_DIVIDE(SUM(revenue), SUM(cost)) para ROAS misto produz a visão cross-channel que nenhuma UI de plataforma consegue. A parte difícil são definições consistentes, não o SQL.

Input de marketing mix modeling. Equipas avançadas alimentam o warehouse diretamente num MMM. O framework open-source Meridian da Google lê gasto semanal agregado e resultados — exatamente a forma que as suas tabelas de reporting já produzem. Uma única scheduled query pivota dados diários na matriz semanal por canal que o Meridian espera, fechando o ciclo de dados de clique raw para modelação estatística de orçamento.

Estes padrões são fundações, não modelos acabados, mas são a parte difícil de acertar estruturalmente. Com dados limpos, unidos, particionados no BigQuery, sobrepor incrementalidade, LTV, e MMM em cima torna-se um exercício de analytics em vez de um pesadelo de data-plumbing.

Para contexto mais amplo sobre as mudanças de privacidade e tracking que tornam um warehouse first-party cada vez mais essencial, ver o nosso guia de estratégia first-party data e a análise do futuro cookieless.

Um warehouse de reporting diz-lhe para onde o dinheiro foi; uma camada de otimização decide para onde vai a seguir. Se quiser otimização Google Ads AI-driven que pode agir sobre os sinais de custo por receita que o seu pipeline BigQuery expõe, a SteerAds executa uma auditoria gratuita de 14 dias em contas Google e Microsoft Ads.

Fontes

• cloud.google.com/bigquery/docs/google-ads-transfer — documentação do Google Ads Data Transfer Service
• cloud.google.com/bigquery/docs — documentação BigQuery
• support.google.com/analytics — documentação de exportação BigQuery do GA4
• cloud.google.com/looker/docs/studio — documentação Looker Studio
• cloud.google.com/blog/products/data-analytics — blog de data analytics Google Cloud

FAQ