Como construir pipelines confiáveis com BigQuery: coleta, limpeza e versionamento de métricas

BigQuery é a única forma de construir métricas auditáveis, histórico imutável e pipelines consistentes em 2025.

Se você trabalha com GA4, Ads, Meta, CRM, SGTM, ou múltiplas fontes, não existe governança real sem BigQuery.

Este post explica como construir pipelines confiáveis, como padronizar dados, como atualizar métricas e como evitar erros que distorcem relatórios e decisões de negócio.

1. O que é um pipeline de dados confiável?

Um pipeline confiável precisa cumprir três requisitos:

1) Integridade

Os dados precisam chegar completos, com todos os campos críticos.

2) Consistência temporal

Métricas precisam ser comparáveis entre dias, semanas e meses (evitando retrabalho).

3) Imutabilidade + versionamento

Cada alteração em métricas deve ser rastreável.

Sem esses três elementos, qualquer relatório no Looker ou Data Studio vira decoração — não decisão.

2. As 4 camadas oficiais de um pipeline moderno no BigQuery

O pipeline ideal segue a estrutura:

Raw → Clean → Model → Analytics

Raw → Clean → Model → Analytics

Raw → Clean → Model → Analytics

Vamos detalhar cada uma.

A) Raw Layer — Dados crus, sem limpeza

Aqui entram:

• Export do GA4

• Logs do servidor

• Dados do CRM

• Conversions API

• Dados de Ads (Google, Meta, LinkedIn, etc.)

Regra de ouro:

Raw Layer nunca deve ser editado.

Exemplo de consulta simples:

SELECT *
FROM `project.dataset.ga4_raw`
WHERE event_date = '20251114'
LIMIT 1000;

SELECT *
FROM `project.dataset.ga4_raw`
WHERE event_date = '20251114'
LIMIT 1000;

SELECT *
FROM `project.dataset.ga4_raw`
WHERE event_date = '20251114'
LIMIT 1000;

B) Clean Layer — Deduplicação + padronização

É aqui que você corrige:

• conversões duplicadas

• campos faltando

• emails inválidos

• UTMs quebradas

• parâmetros desalinhados

SQL para deduplicação por event_id:

CREATE OR REPLACE TABLE clean.purchase AS
SELECT
  event_id,
  ANY_VALUE(event_timestamp) AS event_timestamp,
  ANY_VALUE(transaction_id) AS transaction_id,
  ANY_VALUE(value) AS value,
  ANY_VALUE(currency) AS currency
FROM raw.events
WHERE event_name = "purchase"
GROUP BY event_id;

CREATE OR REPLACE TABLE clean.purchase AS
SELECT
  event_id,
  ANY_VALUE(event_timestamp) AS event_timestamp,
  ANY_VALUE(transaction_id) AS transaction_id,
  ANY_VALUE(value) AS value,
  ANY_VALUE(currency) AS currency
FROM raw.events
WHERE event_name = "purchase"
GROUP BY event_id;

CREATE OR REPLACE TABLE clean.purchase AS
SELECT
  event_id,
  ANY_VALUE(event_timestamp) AS event_timestamp,
  ANY_VALUE(transaction_id) AS transaction_id,
  ANY_VALUE(value) AS value,
  ANY_VALUE(currency) AS currency
FROM raw.events
WHERE event_name = "purchase"
GROUP BY event_id;

C) Model Layer — Métricas de negócio

Aqui você cria:

• Leads válidos

• Conversões qualificadas

• Funil de vendas

• Atribuição proprietária

• Métricas de LTV

Exemplo:

CREATE OR REPLACE TABLE model.leads_valid AS
SELECT *
FROM clean.generate_lead
WHERE email IS NOT NULL 
  AND phone IS NOT NULL 
  AND form_id IS NOT NULL;

CREATE OR REPLACE TABLE model.leads_valid AS
SELECT *
FROM clean.generate_lead
WHERE email IS NOT NULL 
  AND phone IS NOT NULL 
  AND form_id IS NOT NULL;

CREATE OR REPLACE TABLE model.leads_valid AS
SELECT *
FROM clean.generate_lead
WHERE email IS NOT NULL 
  AND phone IS NOT NULL 
  AND form_id IS NOT NULL;

D) Analytics Layer — Relatórios

Aqui entram visões formatadas para:

• Looker Studio

• Superset

• Metabase

• Painéis de cliente

Exemplo:

CREATE VIEW analytics.leads_daily AS
SELECT
  DATE(event_timestamp) AS date,
  COUNT(*) AS leads
FROM model.leads_valid
GROUP BY date
ORDER BY date;

CREATE VIEW analytics.leads_daily AS
SELECT
  DATE(event_timestamp) AS date,
  COUNT(*) AS leads
FROM model.leads_valid
GROUP BY date
ORDER BY date;

CREATE VIEW analytics.leads_daily AS
SELECT
  DATE(event_timestamp) AS date,
  COUNT(*) AS leads
FROM model.leads_valid
GROUP BY date
ORDER BY date;

3. Como corrigir dados quebrados (referrers, UTMs e SGTM)

A) Reconstrução de UTMs

Quando o site perde parâmetros, reconstruímos UTMs com heurísticas:

CASE
  WHEN medium IS NULL AND page_location LIKE '%utm_medium=email%' THEN "email"
  WHEN medium IS NULL AND source LIKE '%facebook%' THEN "paid_social"
  ELSE medium
END AS medium_fixed

CASE
  WHEN medium IS NULL AND page_location LIKE '%utm_medium=email%' THEN "email"
  WHEN medium IS NULL AND source LIKE '%facebook%' THEN "paid_social"
  ELSE medium
END AS medium_fixed

CASE
  WHEN medium IS NULL AND page_location LIKE '%utm_medium=email%' THEN "email"
  WHEN medium IS NULL AND source LIKE '%facebook%' THEN "paid_social"
  ELSE medium
END AS medium_fixed

B) Correção de referrer ausente

Para reduzir falsos “direct”:

CASE
  WHEN referrer IS NULL AND page_referrer LIKE '%google%' THEN 'google'
  ELSE referrer
END AS referrer_fixed

CASE
  WHEN referrer IS NULL AND page_referrer LIKE '%google%' THEN 'google'
  ELSE referrer
END AS referrer_fixed

CASE
  WHEN referrer IS NULL AND page_referrer LIKE '%google%' THEN 'google'
  ELSE referrer
END AS referrer_fixed

C) Deduplicação de Eventos SGTM

SELECT
  event_id,
  MIN(event_timestamp) AS canonical_timestamp
FROM raw.events_server
GROUP BY event_id;

SELECT
  event_id,
  MIN(event_timestamp) AS canonical_timestamp
FROM raw.events_server
GROUP BY event_id;

SELECT
  event_id,
  MIN(event_timestamp) AS canonical_timestamp
FROM raw.events_server
GROUP BY event_id;

4. Como gerar métricas consistentes mês a mês

Essa é a maior dor das equipes.

O segredo é versão de métrica.

Exemplo de versionamento:

• leads_v1 = leads sem validação

• leads_v2 = leads válidos

• leads_v3 = leads válidos + dedupe + verificação de opt-in

Ao versionar, você nunca perde histórico.

SQL de métrica versionada:

CREATE TABLE analytics.leads_v3 AS
SELECT
  *
FROM model.leads_valid
WHERE opt_in = TRUE;

CREATE TABLE analytics.leads_v3 AS
SELECT
  *
FROM model.leads_valid
WHERE opt_in = TRUE;

CREATE TABLE analytics.leads_v3 AS
SELECT
  *
FROM model.leads_valid
WHERE opt_in = TRUE;

5. Erros reais em pipelines que geram caos analítico

Erro 1 — fazer tudo na camada raw

Resultado: impossível validar o que é verdade.

Erro 2 — deduplicação parcial

Ex: dedupe no client mas não no server → números dobrados.

Erro 3 — recriar tabelas sem versionamento

Isso força o analista a “adivinhar” por que números mudaram.

Erro 4 — exportar GA4 sem configurar parâmetros customizados

95% das empresas fazem isso.

Erro 5 — pipelines sem regras de fallback para UTMs

Origem vira Direct → relatórios perdem confiabilidade.

6. Checklist oficial de pipelines confiáveis

1) Toda tabela precisa ter chave única (PK)

• event_id

• transaction_id

• lead_id

2) Raw nunca é alterado

3) Clean precisa aplicar:

• dedupe

• validação sintática

• validação de negócio

4) Model precisa refletir regras da empresa

5) Analytics nunca deve conter lógica complexa

Somente SELECTs, nunca regras.

7. Conexão com os posts anteriores da série

👉 Post 1 - Como construir dashboards que refletem a “verdade de negócio” (GA4 + BigQuery)
👉 Post 2 - Como padronizar métricas entre equipes e ferramentas (GA4, CRM, Ads e BigQuery)
👉 Post 3 - Como alinhar definições de conversão entre GA4, Ads e CRM (e finalmente parar com divergências)
👉 Post 4 - Como limpar conversões no GA4: deduplicação, parâmetros obrigatórios e validação técnica
👉 Post 5 — Como construir pipelines confiáveis com BigQuery: coleta, limpeza e versionamento de métricas
👉 Post 6 — Como modelar conversões corretamente: lógica, deduplicação, janelas e atribuição multi-origem
👉 Post 7 — Auditoria técnica de métricas: como validar dados, detectar erros e garantir integridade no GA4 + BigQuery
👉 Post 8 - Como criar um Sistema Oficial de Métricas para sua empresa (ou ONG): governança, padronização e ciclo de melhoria contínua)

8. Recursos técnicos

👉 Guia oficial BigQuery
👉 GA4 → BigQuery schema
👉 GTM Server-Side