Quando gli acquisti registrati in Google Analytics 4 non coincidono con gli ordini del negozio, la domanda utile non è se i due sistemi restituiscano numeri perfettamente identici. Occorre capire se lo scostamento è stabile, spiegabile e monitorato.
Un audit del GA4 ecommerce tracking permette di distinguere i limiti di osservabilità dalle anomalie tecniche, riconciliare gli ordini attraverso il transaction_id e individuare eventuali blackout prima di campagne, saldi o altri periodi commerciali critici.
Di cosa parlerò in questa pagina
Il caso del 32%: un segnale da verificare, non una regola generale
Un audit citato da Search Engine Journal, relativo a otto ecommerce britannici gestiti dall’agenzia dell’autore, mostra quanto possa diventare ampio il divario tra analytics e negozio.
Nel caso più grave, la quota di ordini rilevata da GA4 è passata:
- dall’81% nel quarto trimestre 2024;
- al 41% nel quarto trimestre 2025;
- fino al 32% tra il 25 dicembre 2025 e il 4 gennaio 2026.
Nello stesso periodo natalizio, GA4 indicava ricavi in calo del 68% rispetto all’anno precedente, mentre il negozio registrava un calo del 13%.
Questo è un episodio circoscritto, non un tasso medio attribuibile a GA4. Il caso documenta un rischio concreto, ma non dimostra che GA4 perda normalmente circa due terzi degli ordini. L’audit riguardava inoltre i clienti di una singola agenzia e non costituisce uno studio rappresentativo.
GA4 non è il registro contabile degli ordini
Il backend ecommerce o il gestionale deve restare la fonte di verità per:
- ordini effettivi;
- ricavi;
- rimborsi;
- imposte.
GA4 svolge un ruolo differente: serve soprattutto per analizzare comportamento degli utenti, attribuzione e tendenze. Gli eventi ecommerce, compreso purchase, devono essere implementati e inviati dal sito o dall’applicazione: GA4 non li raccoglie automaticamente.
Un divario rispetto al backend non prova quindi, da solo, che esista un bug di GA4. Inoltre, una corrispondenza perfetta potrebbe non essere raggiungibile a causa dei limiti di osservabilità.
Perché GA4 e backend possono non coincidere
Le cause dello scostamento possono essere divise in due gruppi principali.
Limiti di osservabilità
GA4 potrebbe non osservare alcuni acquisti a causa di:
- consenso negato;
- ad blocker;
- protezioni applicate dal browser.
Questa parte del divario non dipende necessariamente da un errore nell’implementazione.
Anomalie tecniche
Altri scostamenti possono invece dipendere dalla catena di raccolta, per esempio:
- blackout della CMP, del checkout o della pagina di conferma;
- cookie banner bloccati dopo il raggiungimento dei limiti del relativo piano;
- ordini caricati in ritardo;
- eventi duplicati;
- thank-you page ricaricabili;
- mancata pulizia dell’oggetto ecommerce nel
dataLayer; - uso contemporaneo di
gtag.jse Google Tag Manager, con il rischio di doppi conteggi.
L’audit deve separare questi problemi tecnici dalla parte di traffico e acquisti che GA4 non può osservare.
Come confrontare gli acquisti GA4 con gli ordini reali
Il controllo quantitativo centrale consiste nel calcolare periodicamente il capture rate degli ordini:
capture rate = transaction_id distinti degli eventi purchase / ordini web validi del negozio
Il confronto dovrebbe essere effettuato almeno su base settimanale, escludendo dal denominatore i canali che GA4 non può osservare. Il risultato non va letto come un voto assoluto: è più importante verificare che lo scostamento sia coerente nel tempo e compatibile con la configurazione adottata.
Non fermarsi ai totali aggregati
Due totali simili non dimostrano che il tracciamento sia corretto. Ordini mancanti e duplicazioni potrebbero compensarsi, producendo un risultato apparentemente plausibile.
È quindi necessario riconciliare anche un campione di transaction_id tra GA4 e backend, controllando quali ordini:
- sono presenti in entrambi i sistemi;
- mancano in GA4;
- risultano duplicati;
- presentano valori o articoli incoerenti.
Segnali da indagare
- variazioni improvvise del capture rate;
- capture rate vicino a zero o superiore al 100%;
- giorni con sessioni ma senza acquisti;
- ricavi GA4 in controtendenza rispetto al backend;
- picchi di acquisti attribuiti a “Unassigned”.
Checklist end-to-end del tracciamento purchase
Un controllo affidabile non si limita alla presenza del tag. Deve coprire l’intero percorso, dalla creazione dell’ordine alla disponibilità dell’evento nei report elaborati.
1. Eseguire acquisti di prova
Il percorso dovrebbe essere testato nelle principali condizioni previste dal negozio:
- consenso accettato e negato;
- desktop e mobile;
- diversi gateway di pagamento;
- checkout ospite e utente autenticato;
- ordini con coupon;
- valute supportate;
- ritorno dal gateway di pagamento;
- refresh della pagina di conferma.
2. Controllare ogni passaggio tecnico
Durante i test è utile verificare:
- console del browser;
- contenuto del
dataLayer; - GTM Preview e Tag Assistant;
- richieste di rete;
- DebugView;
- report elaborati di GA4.
DebugView aiuta durante la diagnosi, ma il controllo deve proseguire fino ai dati effettivamente disponibili nei report.
3. Validare struttura e parametri di purchase
L’evento deve usare il nome purchase e una struttura conforme. In particolare, occorre verificare:
transaction_idunivoco;- array
items; - almeno
item_idoppureitem_nameper ciascun articolo; currencyquando viene inviatovalue.
Google considera il primo evento ecommerce ricevuto con uno specifico transaction_id e ignora quello successivo con lo stesso ID. Per questo il transaction ID deve essere stabile e univoco: non va rigenerato a ogni caricamento della pagina, ma non deve nemmeno essere condiviso tra ordini diversi.
4. Cercare doppie implementazioni e dati residui
Occorre controllare che lo stesso acquisto non venga inviato sia tramite gtag.js sia tramite Google Tag Manager. È inoltre necessario pulire correttamente l’oggetto ecommerce per evitare che dati relativi a un evento precedente vengano riutilizzati.
Consent Mode, server-side e Measurement Protocol: possibilità e limiti
Consenso e raccolta server-side influenzano l’architettura del tracciamento, ma non sono scorciatoie capaci di garantire automaticamente la registrazione di ogni acquisto.
Consent Mode
Con Consent Mode Basic, i tag rimangono bloccati fino al consenso. In modalità Advanced possono partire ping senza cookie, utilizzabili per una modellazione più articolata.
La modellazione non equivale però alla registrazione certa di ogni ordine e dipende da soglie minime di dati. Consent Mode non deve quindi essere interpretato come uno strumento capace di annullare ogni differenza rispetto al backend.
Invio dell’acquisto dal backend
Generare o integrare l’evento a partire dal backend può ridurre la dipendenza da:
- pagina di conferma;
- errori JavaScript;
- refresh della thank-you page.
Non risolve tuttavia automaticamente problemi di deduplicazione, attribuzione, blackout originati nel browser o requisiti legati al consenso. Non va inoltre confuso con il semplice utilizzo di Google Tag Manager server-side.
Measurement Protocol
Per uno stream web, Measurement Protocol richiede:
measurement_id;- API secret;
client_id.
Il parametro session_id aiuta a collegare l’evento alla sessione e a conservarne meglio l’attribuzione. Google descrive Measurement Protocol come un’integrazione della raccolta effettuata tramite gtag.js o GTM: un’impostazione esclusivamente server-to-server può produrre report parziali.
Una risposta HTTP positiva non è sufficiente a dimostrare la correttezza semantica del payload. È sempre necessario validare parametri, identificativi, deduplicazione e risultato nei report.
Monitorare lo scostamento prima dei picchi di vendita
L’audit non dovrebbe essere un intervento isolato effettuato soltanto dopo il calo dei ricavi in GA4. Un processo preventivo può comprendere:
- calcolo settimanale del capture rate;
- riconciliazione periodica di un campione di
transaction_id; - alert su variazioni improvvise e giorni senza acquisti;
- test end-to-end prima di campagne, saldi e picchi stagionali;
- verifica dopo modifiche a checkout, CMP, gateway,
dataLayero container GTM.
L’obiettivo non è trasformare GA4 in un sistema contabile, ma mantenere dati sufficientemente affidabili per analisi, attribuzione e confronto delle tendenze.
Serve un audit tecnico del tracciamento ecommerce?
Posso supportare agenzie, web agency, digital agency e professionisti nella riconciliazione backend–GA4 e nella diagnosi della catena composta da backend, checkout, dataLayer, Google Tag Manager, CMP e GA4.
AI Modified
Fonti
- GA4 Missed 66% Of One Retailer’s Holiday Orders: Check Yours Before Peak Season (www.searchenginejournal.com)
- Measure ecommerce | Google Analytics | Google for Developers (developers.google.com)
- Validate your ecommerce setup (gtag.js) | Google Analytics | Google for Developers (developers.google.com)
Domande frequenti sul GA4 ecommerce tracking
Il divario può dipendere da consenso negato, ad blocker e protezioni del browser, oppure da problemi tecnici nella CMP, nel checkout, nella pagina di conferma, nel dataLayer o nell’implementazione dei tag. La differenza non dimostra automaticamente un errore di GA4.
Si dividono i transaction_id distinti degli eventi purchase per gli ordini web validi del negozio. Dal confronto vanno esclusi i canali che GA4 non può osservare.
Devono essere verificati almeno un transaction_id univoco, l’array items e, per ogni articolo, item_id oppure item_name. Se viene trasmesso value, è richiesta anche currency.
Occorre confrontare un campione di ID tra GA4 e backend, invece di limitarsi ai totali. In questo modo è possibile individuare ordini assenti, duplicazioni o acquisti compensati nei dati aggregati.
Sì. In modalità Basic i tag restano bloccati fino al consenso; in modalità Advanced possono partire ping senza cookie. Anche blackout o limiti operativi della CMP possono interrompere la raccolta. La modellazione non garantisce comunque la registrazione di ogni ordine.
No. Possono ridurre alcune fragilità, come la dipendenza dalla pagina di conferma, ma non risolvono automaticamente deduplicazione, attribuzione, blackout nel browser o aspetti legati al consenso. Measurement Protocol integra la raccolta web e un’impostazione solo server-to-server può produrre report parziali.
La fonte di verità resta il backend ecommerce o il gestionale. GA4 è destinato soprattutto all’analisi del comportamento, dell’attribuzione e delle tendenze.
