BigQuery + Google Ads data pipeline 2026: costruire il proprio data warehouse di reporting

Ogni operazione Google Ads seria alla fine supera la UI della piattaforma e gli spreadsheet esportati. Le domande di reporting che contano di più — qual è il mio vero costo per deal closed-won, quali campagne guidano sessioni che convertono 60 giorni dopo, come si riconciliano Google, GA4 e il CRM — non possono essere risposte dentro Google Ads perché i dati vivono in tre sistemi diversi. Un data warehouse di reporting su BigQuery è come i team di analytics risolvono questo nel 2026, e Google ha reso l'ingresso drammaticamente più facile con il Data Transfer Service gestito.

Questo è un tutorial pratico per analisti e ingegneri. Costruiremo la pipeline end to end: provisioniamo il progetto Cloud, configuriamo il Data Transfer Service, abilitiamo l'export GA4, progettiamo uno schema a layer, uniamo il revenue CRM su GCLID, scheduliamo il refresh giornaliero, mettiamo Looker Studio sopra e teniamo i costi BigQuery sotto controllo. Assumiamo fluenza in SQL e familiarità di base con Google Cloud. Se venite da una fondazione tracking-first, la nostra guida alla configurazione GA4 e all'import di conversioni è il prerequisito giusto.

Perché costruire una pipeline BigQuery per Google Ads

La UI di Google Ads è eccellente per gestire campagne e debole per l'analisi cross-system. Tre limiti strutturali spingono i team verso un warehouse.

Primo, il gap di revenue. Google Ads sa quanto ha speso e quante conversioni ha contato, ma non conosce la vostra pipeline closed-won, la lunghezza del vostro ciclo di vendita o il vostro tasso di rimborsi. Un lead che Google conta come evento di conversione da 0 € potrebbe diventare un deal enterprise da 40.000 € nove mesi dopo. Senza unire il revenue CRM al click, ottimizzate verso il volume di conversioni anziché il profitto — il fallimento di reporting più comune e più costoso nel PPC B2B.

Secondo, il blend cross-channel. L'acquisizione moderna gira su Google, Meta, LinkedIn e altro. Ogni piattaforma riporta nel proprio walled garden con la propria attribuzione. Un warehouse è l'unico posto dove costruire una singola vista blended dove spend e risultati di ogni canale stanno nella stessa tabella con definizioni coerenti. La nostra guida all'attribuzione cross-channel copre la metodologia; BigQuery è dove la implementate.

Terzo, il soffitto dell'analisi. Test di incrementalità, modellazione del customer lifetime value, cohort retention e marketing mix modeling richiedono tutti dati a livello di evento e storici che la UI semplicemente non espone. Un warehouse con due o tre anni di storia pulita è il substrato su cui poggia ogni tecnica di misurazione avanzata. Il framework MMM open-source di Google, coperto nella nostra guida Meridian, legge direttamente da BigQuery.

L'economia è favorevole. Il Data Transfer Service è gratuito. I primi 10 GB di storage di BigQuery e il primo 1 TB di query processing al mese sono gratuiti, e oltre lo storage costa circa 0,02 € per GB al mese e le query circa 5-6 € per TB scansionato. Un warehouse ben costruito di singolo account raramente eccede i 150 € al mese e spesso gira sotto i 50. Contro il costo di spend pubblicitario mal allocato, è un errore di arrotondamento. L'investimento è tempo di engineering, non bollette cloud.

Il ritorno è duraturo. Una volta che la pipeline esiste, ogni nuova domanda diventa una query SQL anziché un esercizio manuale di export-and-pivot. I report si refreshano da soli. I nuovi canali si innestano nello stesso schema. E la fondazione dati cumula: più a lungo gira il warehouse, più preziosa diventa la sua storia per la modellazione.

Panoramica dell'architettura e le tre sorgenti dati

L'architettura di riferimento è un warehouse a layer alimentato da tre sorgenti, trasformato da SQL schedulato e mostrato in Looker Studio.

Le tre sorgenti dati:

La convenzione dei dataset a layer mantiene il warehouse manutenibile ed efficiente in termini di costo:

• raw_google_ads — export DTS non toccati. Mai interrogati direttamente dai report. Trattate come zona di atterraggio immutabile.
• export GA4 grezzo — le tabelle events_ che GA4 fa atterrare nel proprio dataset, partizionate per event date.
• staging — viste e tabelle pulite e standardizzate. Micros castati in valuta, colonne rinominate, duplicati della finestra di refresh rimossi, date spine e mapping account uniti.
• reporting — tabelle curate e denormalizzate costruite appositamente per le dashboard. Questo è l'unico layer che Looker Studio tocca.

Questa separazione conta per tre ragioni: isola i dati grezzi così che un bug di trasformazione non corrompa mai la sorgente, concentra i join costosi in build schedulate anziché in refresh-per-dashboard e vi dà un confine di permessi pulito — gli analisti ottengono accesso in lettura solo a reporting.

L'orchestrazione è deliberatamente semplice. Il Data Transfer Service e l'export GA4 girano sullo schedule di Google, facendo atterrare dati freschi ogni mattina. Alcune ore dopo, le scheduled query BigQuery ricostruiscono le tabelle di staging e reporting. Looker Studio legge il risultato. Nessun orchestratore esterno, nessun server, nessun container. Potete laurearvi a dbt e Cloud Composer più tardi, ma non vi servono per partire, e aggiungerli prematuramente è over-engineering.

Una nota sulle region: scegliete una location BigQuery (multi-region EU per la residenza dei dati europei) e usatela per ogni dataset. Le query cross-region non sono permesse, quindi un mismatch di location tra il vostro dataset DTS e il vostro dataset CRM romperà i join. Decidete una volta, in anticipo.

Configurare il Google Ads Data Transfer Service

Il Data Transfer Service (DTS) è la fondazione, e sono genuinamente pochi click di configurazione più un'attesa per il backfill.

Prerequisiti:

• Un progetto Google Cloud con billing abilitato
• La BigQuery API e la BigQuery Data Transfer API abilitate
• Un account Google con accesso in lettura al target Google Ads (o MCC)
• Il customer ID dell'account Google Ads (10 cifre, senza trattini)

Passi di configurazione:

1. Nella console BigQuery, aprite Data transfers e cliccate Create transfer.
2. Scegliete Google Ads come sorgente.
3. Nominate il transfer, impostate lo schedule su giornaliero e scegliete un orario di run nelle prime ore del mattino.
4. Impostate il dataset di destinazione su raw_google_ads.
5. Inserite il Customer ID — usate l'ID MCC per estrarre tutti gli account figli in un transfer.
6. Configurate la finestra di refresh (il numero di giorni trailing che il DTS ri-estrae a ogni run) per catturare il backfill delle conversioni e l'attribuzione tardiva.
7. Autenticatevi con un account che ha l'accesso Google Ads necessario e salvate.

Il DTS creerà un set di tabelle in raw_google_ads — campagna, gruppo di annunci, criteri del gruppo di annunci (keyword), conversioni e altro — ciascuna con suffisso di data o partizionata, a seconda della tabella. Il naming segue lo schema documentato di Google; tenete quella documentazione aperta come riferimento perché i nomi delle colonne sono verbosi e le tabelle stat separano le metriche dagli attributi.

Eseguite un backfill immediatamente. Un transfer fresco estrae solo in avanti da oggi. Per ottenere storia, triggerate un backfill manuale per gli ultimi 12 mesi (o quanto vi serve indietro e quanto l'account supporta). I backfill girano come una serie di job giornalieri e possono richiedere un po' per range lunghi, ma devono girare solo una volta.

Validate il primo caricamento. Dopo che il run iniziale si completa, fate un sanity-check: sommate il costo (in micros, poi dividete per 1.000.000) per una settimana recente e confrontatelo con la UI Google Ads per la stessa finestra. Piccole discrepanze sono normali per via della finestra di refresh dell'attribuzione e dei confini di fuso orario, ma i totali dovrebbero essere vicini. Se sono selvaggiamente lontani, controllate di aver selezionato il customer ID e il fuso orario giusti.

Considerazioni MCC. Un transfer MCC tagga ogni riga con il suo customer ID. Questo è potente per le agenzie ma moltiplica il volume di dati. Con molti account, partizionare per data e clusterizzare per customer ID nel layer di staging smette di essere un nice-to-have e diventa la differenza tra una bolletta mensile di 40 € e una di 400 €. Pianificatelo dalla prima tabella di staging.

Progettare lo schema BigQuery e il layer di staging

Le tabelle DTS grezze sono accurate ma scomode: costi in micros, nomi di colonne criptici, tabelle stat e attributi separate, e sovrapposizione della finestra di refresh. Il layer di staging risolve tutto questo una volta così che le query a valle restino pulite.

Trasformazioni core di staging:

-- 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;

Le specifiche dei nomi delle tabelle variano con la versione dello schema DTS, ma il pattern regge: castate i micros, rinominate in colonne leggibili, unite le stat agli attributi, partizionate per data, clusterizzate sulle colonne su cui filtrate di più.

Deduplicare la finestra di refresh. Poiché il DTS ri-estrae giorni trailing, la stessa data può apparire in più caricamenti di snapshot. Selezionate lo snapshot più recente per data logica usando una funzione finestra o leggendo la partizione che il DTS marca come current. Saltare questo passaggio fa doppio conteggio dello spend nei vostri giorni più recenti — un bug sottile che erode la fiducia nel warehouse.

Tabelle di supporto che vi serviranno:

Partizionamento e clustering non sono opzionali. Partizionate ogni tabella materializzata di staging e reporting per date. Clusterizzate per customer_id e campaign_id (o qualunque cosa filtrino i vostri report). Questa è la leva che controlla il costo: una query per il mese scorso contro una tabella partizionata per data scansiona solo i byte del mese scorso, non tre anni di storia. La differenza è spesso 30x su un warehouse maturo.

Viste contro tabelle. Per trasformazioni leggere, le viste vanno bene e non incorrono in costo di storage — ma ri-scansionano i dati sorgente a ogni lettura. Per qualunque cosa interrogata ripetutamente dalle dashboard, materializzate una tabella partizionata via scheduled query. La regola del pollice: trasformazione economica letta una volta = vista; trasformazione costosa letta molte volte = tabella materializzata.

Tenete il layer di staging noioso e deterministico. Dovrebbe fare esattamente un lavoro — trasformare gli export grezzi DTS e GA4 in blocchi puliti, ben tipizzati e partizionati — così che il layer di reporting possa concentrarsi sui join interessanti.

Unire dati GA4, Google Ads e CRM

Qui è dove il warehouse si guadagna lo stipendio. Tre sorgenti, unite correttamente, rispondono a domande che nessuna singola piattaforma può.

Il GCLID è la spina dell'attribuzione del revenue. Quando qualcuno clicca un annuncio Google con l'auto-tagging attivo, Google appende un GCLID all'URL di landing. Catturatelo in un campo form nascosto, persistetelo nel vostro CRM contro il lead, e diventa la chiave di join tra i click Google Ads e il revenue 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;

Il LEFT JOIN è deliberato: lo spend non matchato deve restare visibile. Se fate inner-join, ogni click senza un deal matchato sparisce silenziosamente, e la vostra matematica cost-per-revenue si lusinga da sola. Tenete tutto lo spend nel risultato e trattate il tasso di match come una propria metrica di salute.

Unire GA4 per la profondità comportamentale. L'export GA4 fa atterrare righe a livello di evento con event_params nested. Fate unnest per recuperare la campagna, la qualità della sessione e la landing page, poi aggregate alla granularità che vi serve.

-- staging.ga4_sessions (campagna e landing page recuperate da 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;

Vincolate sempre il _TABLE_SUFFIX GA4 a un range di date — le tabelle di eventi sono grandi e una scansione wildcard non limitata è la classica trappola di costo GA4.

Caricare il CRM. Portate i deal in BigQuery con qualunque cosa si adatti al vostro stack: un connettore gestito come Fivetran, una Cloud Function schedulata che chiama l'API del vostro CRM, o un caricamento CSV notturno. Le colonne minime sono deal ID, GCLID, importo closed-won, data di chiusura e stage. Refreshate quotidianamente così che il revenue resti corrente.

Quando la copertura GCLID è scarsa, i tassi di match soffrono e il revenue appare sottostimato. Le correzioni upstream sono enhanced conversions e l'import di conversioni offline, entrambe migliorano quanto affidabilmente i click si legano ai risultati — vedi la nostra guida al setup di enhanced conversions. Come fallback nel warehouse, un join basato su UTM recupera alcune righe non matchate, ma trattatelo come supplemento a confidenza più bassa, non un sostituto del GCLID.

L'output di questa sezione è una singola tabella unificata che porta spend, conversioni Google, engagement GA4 e revenue CRM fianco a fianco — la tabella su cui è costruito ogni report PPC significativo.

Scheduled query e il refresh giornaliero

Con la logica di staging e reporting scritta, automatizzate la build giornaliera così che il warehouse si mantenga da solo.

Le scheduled query native sono lo strumento di partenza giusto. BigQuery vi permette di schedulare qualsiasi statement SQL su una cadenza tipo-cron senza costo extra oltre il query processing che consuma. Schedulate prima la build di staging, poi la build di reporting, entrambe temporizzate alcune ore dopo che il DTS e l'export GA4 tipicamente completano al mattino. Quell'ordinamento garantisce che ogni layer legga dati upstream freschi.

Usate le semantiche di scrittura giuste:

Per la maggior parte del reporting PPC, ricostruire le N partizioni trailing con WRITE_TRUNCATE con scope su quelle partizioni è l'approccio corretto più semplice — assorbe naturalmente il backfill della finestra di refresh del DTS senza duplicare dati più vecchi.

Aggiungete un freshness check. Una piccola scheduled query che confronta la data massima in ogni tabella sorgente con oggi e scrive un alert (o fallisce rumorosamente) cattura il fallimento silenzioso dove il DTS o l'export GA4 saltano un giorno e le vostre dashboard mostrano silenziosamente numeri obsoleti. Questa singola guardia previene la classe più imbarazzante di incidente di 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 quella query restituisce righe, qualcosa a monte è obsoleto e richiede attenzione.

Quando laurearsi a dbt. Le scheduled query gestiscono comodamente un warehouse di singolo account a lungo. Passate a dbt quando la logica di trasformazione eccede circa 10-15 modelli interdipendenti, quando volete test automatici e documentazione a livello di colonna, o quando diversi analisti modificano lo stesso SQL e hanno bisogno di version control e lineage. dbt orchestrato da Cloud Composer (Airflow gestito) è il prossimo passo comune — ma adottatelo perché la complessità lo richiede, non perché è di moda.

Disciplina di backfill. Quando cambiate una trasformazione, ri-eseguitela attraverso la storia così che le partizioni vecchie riflettano la nuova logica. Parametrizzate le scheduled query per data così che lo stesso SQL serva sia per il run incrementale giornaliero sia per un backfill completo manuale.

Reporting Looker Studio e gestione dei costi

Il warehouse è utile solo se le persone possono leggerlo, e Looker Studio è il front end naturale per BigQuery.

Collegatevi solo a tabelle curate. Puntate ogni data source Looker Studio al dataset reporting, mai agli export grezzi o alle tabelle wide di staging. Questa è la decisione di costo più importante nell'intera pipeline. Looker Studio refresha le query sull'interazione e su uno schedule di cache; se una dashboard popolare interroga una tabella full-history non partizionata, i byte scansionati — e la bolletta — cumulano velocemente.

Un set di dashboard di partenza pratico:

• Panoramica esecutiva — spend blended, conversioni e revenue CRM tra canali, con trend nel tempo.
• Panoramica account — performance per account per setup MCC, usando i nomi leggibili dell'account-map.
• Drill-down campagne — spend, CPA, cost-per-revenue e engagement GA4 per campagna e gruppo di annunci.

Controlli di costo che contano davvero:

Monitorate le query più costose. La vista INFORMATION_SCHEMA.JOBS espone ogni query, chi l'ha eseguita e quanti byte ha processato. Un'occhiata settimanale ai top consumer fa emergere quel report o quella scheduled query che silenziosamente domina la vostra bolletta, così potete ottimizzarla — di solito aggiungendo un filtro di partizione o materializzando un 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;

Impostate un budget di fatturazione e un alert sul progetto Cloud indipendentemente da quanto siete attenti. È il backstop che trasforma una query fuori controllo da una sorpresa di fine mese in una notifica dello stesso giorno.

Con tabelle curate, filtri di partizione, BI Engine per le dashboard più calde e monitoraggio settimanale dei costi, un warehouse di singolo account resta comodamente nel range 30-150 € al mese mentre serve report veloci e affidabili.

Pattern SQL per incrementalità e fondazioni LTV

Il warehouse non è solo reporting più carino — è il substrato per il lavoro di misurazione che guida vere decisioni di budget. Ecco i pattern fondazionali.

Incrementalità geo-holdout. Il test di incrementalità chiede quali conversioni sarebbero accadute senza gli annunci. Il warehouse rende l'analisi banale una volta che gira un esperimento geo: taggate le regioni come test o controllo, poi confrontate i tassi di conversione tra i due gruppi per la finestra di test.

-- incrementality lift by region group
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;

Il lift tra test e controllo, normalizzato per dimensione del gruppo, stima il contributo incrementale. La metodologia e il design del test vivono nella nostra guida ai test di incrementalità; BigQuery è dove lo calcolate su scala e lo ri-eseguite ogni trimestre senza sforzo manuale.

Cohort retention e LTV. La modellazione del lifetime value parte dal cohorting dei clienti per mese di acquisizione e dal tracciare il revenue in avanti.

-- monthly acquisition cohorts with cumulative revenue
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;

Questa matrice di cohort è la materia prima per curve LTV, analisi del periodo di payback e ratio CAC-su-LTV per canale di acquisizione — le metriche che dovrebbero governare l'allocazione del budget. Unita alla campagna che ha prodotto il GCLID di ogni cliente, potete computare l'LTV per campagna, non solo il CPA per campagna, che è un target di ottimizzazione molto migliore. La nostra analisi del CAC payback per verticale mostra i benchmark che queste query alimentano.

Reporting cross-channel blended. Una volta che Meta, LinkedIn e altri canali atterrano nello stesso warehouse con definizioni coerenti, un singolo UNION ALL delle tabelle giornaliere di ogni canale seguito da GROUP BY channel con SAFE_DIVIDE(SUM(revenue), SUM(cost)) per ROAS blended produce la vista cross-channel che nessuna UI di piattaforma può. La parte difficile sono le definizioni coerenti, non l'SQL.

Input per marketing mix modeling. I team avanzati alimentano il warehouse direttamente in un MMM. Il framework open-source Meridian di Google legge spend e risultati aggregati settimanalmente — esattamente la forma che le vostre tabelle di reporting già producono. Una singola scheduled query pivota i dati giornalieri nella matrice canale-settimanale che Meridian si aspetta, chiudendo il loop dai dati di click grezzi alla modellazione statistica del budget.

Questi pattern sono fondazioni, non modelli finiti, ma sono la parte difficile da fare bene strutturalmente. Con dati puliti, uniti e partizionati in BigQuery, sovrapporre incrementalità, LTV e MMM diventa un esercizio di analytics anziché un incubo di data plumbing.

Per il contesto più ampio sui cambiamenti di privacy e tracking che rendono un warehouse first-party sempre più essenziale, vedi la nostra guida alla strategia first-party data e l'analisi del futuro cookieless.

Un warehouse di reporting vi dice dove sono andati i soldi; un layer di ottimizzazione decide dove vanno dopo. Se desiderate ottimizzazione AI-driven per Google Ads che possa agire sui segnali cost-per-revenue che la vostra pipeline BigQuery fa emergere, SteerAds esegue un audit gratuito di 14 giorni sugli account Google e Microsoft Ads.

Fonti

• cloud.google.com/bigquery/docs/google-ads-transfer — documentazione Google Ads Data Transfer Service
• cloud.google.com/bigquery/docs — documentazione BigQuery
• support.google.com/analytics — documentazione export BigQuery GA4
• cloud.google.com/looker/docs/studio — documentazione Looker Studio
• cloud.google.com/blog/products/data-analytics — blog Google Cloud data analytics

FAQ