In Google Ads la finestra di conversione post-clic può essere impostata fino a 90 giorni e la conversione viene registrata nel giorno del clic, non nel giorno in cui è avvenuta. In GA4 lo stesso acquisto è datato al momento in cui è successo, con una finestra di lookback predefinita di 30 giorni. Due sistemi che datano e attribuiscono lo stesso ordine in modo diverso non possono restituire lo stesso numero: una quota di scostamento è prevista dal progetto delle due piattaforme.
Quindi la risposta secca è questa: le conversioni Google Ads non corrispondono a GA4 perché cambiano quattro cose — la data di registrazione, il modello di attribuzione, la regola di conteggio e il perimetro di raccolta. Il problema è che sotto questa differenza fisiologica si nasconde spesso un errore di implementazione vero. Il lavoro non è far coincidere i numeri, è separare la parte spiegabile da quella che non lo è, e sistemare solo la seconda.
Prima di cercare il bug, verifica di non confrontare due metriche diverse
La maggior parte delle segnalazioni di "dati sballati" muore qui. Prima di toccare un tag, allinea quattro cose.
La metrica. In Google Ads la colonna Conversioni non è Tutte le conversioni: la prima contiene solo le azioni con "Includi in Conversioni" attivo, la seconda tutto il resto. Molti falsi allarmi nascono dal fatto che l’azione esiste, raccoglie dati, ma è esclusa dalla colonna principale. In GA4, allo stesso modo, il totale degli eventi chiave include anche il traffico non a pagamento.
Il fuso orario. L’account Google Ads e la proprietà GA4 hanno impostazioni separate. Se uno è su UTC e l’altro su Europe/Rome, ogni giornata ha due ore di eventi spostate sul giorno sbagliato. Su volumi bassi è rumore visibile, su campagne serali è una differenza sistematica.
Il perimetro. In GA4 non guardare il totale degli eventi chiave: usa il report Google Ads oppure un’esplorazione filtrata su sorgente/mezzo google / cpc, meglio ancora sull’ID campagna Google Ads. Stai confrontando campagne a pagamento, non tutto il sito.
La finestra. Minimo 30 giorni, chiusi, e terminati da almeno due settimane. Confrontare il mese in corso non ha senso: i dati di Ads sono ancora in riempimento all’indietro.
Fatto questo, calcola lo scostamento in percentuale, non in valore assoluto: (Ads − GA4) / Ads. Le soglie che uso come riferimento operativo — non sono un dato ufficiale di Google, sono una regola pratica — sono queste: sotto il 10% lascia perdere, è fisiologia; tra il 10% e il 25% la differenza deve essere spiegabile voce per voce (data del clic, view-through, conversioni modellate); sopra il 25-30% c’è quasi sempre un problema di implementazione o un doppio conteggio. E ricorda il segno: se è GA4 a mostrare più eventi chiave di quante conversioni veda Ads, le cause probabili sono altre (perdita del gclid, conversione non importata, conteggio "una" in Ads contro eventi ripetuti in GA4).
Le differenze che non sono errori
Data del clic contro data dell’evento. Un utente clicca il 2, acquista il 20. Google Ads scrive quella conversione sul 2, GA4 sul 20. Su cicli decisionali lunghi il mese corrente è strutturalmente "sbagliato" e si riallinea nelle settimane successive. Verifica rapida: ricalcola lo stesso periodo a 30 e 60 giorni di distanza. Se il numero di Ads cresce, hai trovato una parte della differenza e non devi fare nulla.
Modelli e perimetro di attribuzione. Google Ads conta anche conversioni view-through, engaged-view su YouTube e percorsi cross-device riconosciuti tramite account Google. GA4 usa un’attribuzione cross-channel: la stessa conversione può finire su Organic, Direct, Email o Referral se nel percorso c’è un altro punto di contatto. Non sono due misurazioni della stessa cosa: Ads misura il contributo del proprio canale, GA4 lo mette in competizione con gli altri. Usa il confronto tra modelli in Ads e il report di confronto attribuzione in GA4 per quantificare l’ampiezza del fenomeno prima di dare la colpa al tracciamento.
Conversioni modellate e conversioni avanzate. Quando l’utente nega il consenso, con il Consent Mode avanzato Google stima le conversioni mancanti e le somma in Ads. Le conversioni avanzate recuperano match aggiuntivi via dati utente hashati. Entrambe alzano il numero in Ads senza toccare GA4 nello stesso modo. È il comportamento previsto, non un bug. Se la tua configurazione del consenso è approssimativa, però, la modellazione lavora su una base sbagliata: vale la pena verificare come hai impostato il Consent Mode v2 lato server prima di fidarti del delta.
Regola di conteggio. L’azione di conversione in Ads può essere impostata su "ogni" o "una" conversione per clic. GA4 conta ogni occorrenza dell’evento. Per un e-commerce con conteggio "ogni", un refresh della thank you page o un ritorno dal gateway di pagamento genera un acquisto doppio da entrambe le parti; per la lead generation, un form inviato due volte nella stessa sessione fa lo stesso. Test da due minuti: rapporto conversioni/sessioni e conversioni/utenti. Se un e-commerce ha più di un acquisto ogni utente acquirente, stai gonfiando.
Finestre non allineate. Finestra post-clic di Ads (30 giorni di default, fino a 90), finestra view-through, finestra engaged-view, lookback di GA4. Allinearle non rende i numeri identici, ma elimina una variabile dal confronto.
Il protocollo: cosa controllare, in che ordine
Se dopo gli allineamenti lo scostamento resta sopra soglia, procedi in sequenza. Saltare passaggi significa cambiare tag a caso.
Passo 1 — doppio conteggio e conversioni fantasma. Apri l’elenco delle azioni di conversione e guarda la colonna Origine. Lo scenario classico è la stessa conversione presente due volte: una dal tag Google Ads nativo, una importata come evento chiave da GA4. Se entrambe hanno "Includi in Conversioni" attivo, stai contando doppio e lo smart bidding sta imparando su numeri gonfiati. Scegline una. Il mio parere: per e-commerce con valore e transaction_id ben strutturati, il tag nativo lato server dà più controllo sulla deduplica e sul valore; l’importazione da GA4 è comoda ma eredita l’attribuzione e le trasformazioni di GA4, inclusi gli eventi chiave importati che perdono il valore e falsano il ROAS.
Passo 2 — gclid. Auto-tagging disattivato, redirect della landing che strippa i parametri, PSP che riporta l’utente su un URL pulito: senza gclid la conversione non torna mai in Ads. Verifica aprendo un annuncio reale e controllando che il parametro sopravviva al primo caricamento e agli eventuali redirect.
Passo 3 — implementazione. Anteprima GTM, Tag Assistant, DebugView di GA4, diagnostica dell’azione di conversione in Ads e, se puoi, una transazione reale di importo simbolico. Qui emergono gli errori che nessun modello di attribuzione giustifica: trigger su click invece che su submit, thank you page raggiungibile direttamente, valore passato come stringa o in valuta diversa, transaction_id assente e quindi deduplica impossibile. Se il problema è a monte, nella struttura dei dati, non lo risolvi nel tag: il Data Layer va sistemato prima.
Passo 4 — perdita strutturale. Ad-blocker e tracker prevention colpiscono in modo diverso i due endpoint; su Safari i cookie scritti via JavaScript hanno vita breve e le conversioni ritardate si perdono; i redirect verso Stripe, PayPal o i gateway bancari rompono la sessione e spostano l’acquisto su referral in GA4. Quantifica con il terzo termine di paragone che quasi nessuno usa: gli ordini a gestionale. Backend 1.000 ordini, GA4 870, Ads 910 su quella finestra: adesso sai dove stai perdendo e quanto.
Passo 5 — baseline. Documenta lo scostamento residuo e monitoralo. Un 12% stabile è informazione; un 12% che diventa 40% in una settimana è un alert.
| Sintomo | Causa più probabile | Verifica |
|---|---|---|
| Ads molto più alto solo nel mese corrente | Data clic vs data evento | Ricalcola a 30 e 60 giorni |
| Ads più alto in modo stabile su Display/YouTube | View-through ed engaged-view | Confronto modelli in Ads |
| GA4 più alto di Ads | gclid perso o conteggio "una" | Test landing con parametri |
| Entrambi più alti del gestionale | Eventi duplicati | Conversioni/utenti, transaction_id |
| Ads raddoppia da un giorno all’altro | Importazione + tag nativo | Colonna Origine |
Cosa risolve il server-side, cosa no, e quale numero usare per il budget
Il tracciamento server-side migliora la resilienza agli ad-blocker e ai blocchi di rete, allunga la durata dei cookie di prima parte scritti via HTTP, rende più affidabile l’invio delle conversioni avanzate e permette di registrare l’evento anche quando il browser chiude la pagina prima della richiesta. Su e-commerce con redirect di pagamento è spesso la differenza tra recuperare l’acquisto e perderlo: è il motivo per cui la combinazione tra GTM server-side e Google Ads incide sul volume di conversioni importate.
Non risolve nulla di tutto il resto. Non cambia il modello di attribuzione, non allinea la data del clic alla data dell’evento, non uniforma le finestre, non corregge una regola di conteggio sbagliata, non recupera gli utenti che hanno negato il consenso. Chi te lo presenta come la soluzione al disallineamento Ads/GA4 ti sta vendendo un’altra cosa. Nel breve periodo può perfino allargare la differenza, perché durante la migrazione un lato raccoglie più eventi dell’altro.
L’ordine corretto è: prima metrica allineata e deduplica pulita lato client, poi valutazione del passaggio al server. Se gestisci poche decine di conversioni al mese, con un flusso senza redirect esterni e un Data Layer semplice, puoi procedere da solo partendo dalla differenza operativa tra client-side e server-side. Se hai gateway di pagamento esterni, carrelli multi-step, più domini o un Data Layer scritto da tre agenzie diverse, fatti accompagnare: in quei casi un errore di configurazione si traduce direttamente in budget mal allocato, e vale la pena leggere quando il server-side conviene davvero prima di muoverti.
Ultima cosa, la più pratica. Smetti di inseguire l’allineamento perfetto: non arriverà, e il tempo speso a cercarlo è tempo tolto all’ottimizzazione. Usa Google Ads per decidere le campagne, perché è il dato su cui lo smart bidding impara. Usa GA4 per confrontare i canali tra loro e leggere il comportamento post-clic. Usa gestionale o CRM come fonte di verità per fatturato e ROAS reale. Poi calcola il coefficiente che lega le tre fonti e aggiornalo ogni trimestre. Chi vuole riconciliare i dataset senza stime ha una strada pulita: portare gli eventi grezzi dal container server a BigQuery e incrociarli con gli ordini del backend sulla chiave transazione. È l’unico modo per avere un numero che non devi difendere in riunione.