GA4 in un negozio online quasi sempre “funziona”: i grafici si disegnano, le sessioni arrivano. L’audit parte da un’altra domanda: gli eventi e-commerce dicono la verità? Ogni funnel, ogni analisi e ogni campagna ottimizzata sulle conversioni GA4 vale esattamente quanto l’implementazione sottostante. Questa guida è una checklist di audit: eventi completi, errori tipici, copertura rispetto agli ordini reali e routine di validazione.
Checklist
Eventi e-commerce GA4: il set che deve funzionare
Il percorso d’acquisto in GA4 è composto da eventi standard con nomi definiti nella documentazione Google. L’audit inizia verificando che vengano inviati tutti e quali parametri contengono:
| Evento | Quando deve essere inviato | Cosa deve contenere |
|---|---|---|
| view_item_list | visualizzazione di listing / categoria | items con item_id |
| view_item | apertura della scheda prodotto | items, value, currency |
| add_to_cart | aggiunta al carrello | items con quantità e prezzo |
| begin_checkout | avvio del checkout | items, value |
| add_payment_info | scelta del metodo di pagamento | items, payment_type |
| purchase | una volta per ogni ordine pagato | transaction_id, value, currency, items |
Due regole sopra tutte: nomi standard (invenzioni come add_to_basket non alimentano né i report e-commerce né i modelli di conversione) e item_id coerenti, allineati agli identificativi del sistema del negozio e del feed prodotti. Senza la seconda non è possibile collegare i comportamenti ai singoli prodotti, base di tutta l’analisi del funnel descritta nella guida su come collegare le statistiche GA4 alle vendite.
Errori tipici
Cinque errori tipici delle implementazioni GA4 nei negozi
Gli stessi errori si ripetono in un negozio dopo l’altro, indipendentemente dalla piattaforma. Appunti dagli audit:
purchase solo sulla pagina di ringraziamento
Dopo un pagamento con reindirizzamento, una parte dei clienti non ci torna mai. L’ordine c’è, l’evento no; la copertura cala in silenzio e in modo irregolare.
transaction_id mancante o ripetuto
Senza identificativo non c’è deduplicazione: la pagina di ringraziamento ricaricata conta l’ordine una seconda volta. Il numero di eventi deve essere uguale al numero di transazioni univoche.
value a volte lordo, a volte netto
Un valore di purchase che tra un template e l’altro include o esclude tasse e spedizione gonfia o riduce i ricavi in GA4. Stabilisci un’unica definizione e verificala su un ordine di prova.
item_id non allineato al negozio
GA4 invia lo SKU della variante, il negozio riporta l’ID prodotto, il feed un altro ancora. Tre sistemi, tre dizionari e nessuna analisi comune per prodotto.
Nomi personalizzati invece di quelli standard
Gli eventi funzionano ma hanno nomi inventati, quindi i report e-commerce restano vuoti e i modelli di conversione non hanno dati su cui lavorare.
Metodo principale
Copertura: confronta purchase con gli ordini del negozio
Il test più affidabile dell’implementazione non richiede di guardare il codice: confronta il numero e il valore degli eventi purchase con gli ordini pagati del sistema del negozio, periodo per periodo. Questo solo numero (la copertura) dice se ci si può fidare dei dati (dati illustrativi, negozio di integratori):
Copertura: purchase in GA4 / ordini pagatinegozio di integratori · dati illustrativi
Nella settimana 3 il problema è l’implementazione, non i clienti: dopo il cambio del gateway di pagamento una parte dei clienti ha smesso di tornare sulla pagina di ringraziamento. Senza un monitoraggio della copertura, quella settimana sarebbe sembrata un semplice «calo di traffico» e avrebbe portato a decisioni di budget sbagliate.
Una certa differenza è normale: blocco degli script, consensi mancanti e percorsi di pagamento atipici sottraggono sempre qualche punto percentuale. Il segnale d’allarme non è il numero in sé, ma il cambio di livello: una copertura stabile da mesi che crolla all’improvviso indica un guasto nella misurazione. La stessa logica vale per i valori: somma di value degli eventi purchase rispetto al fatturato degli ordini pagati.
Il sistema del negozio dice quanto hai venduto davvero. GA4 dice quanto ne vede. L’audit serve a evitare che il secondo numero si stacchi dal primo.
La routine
Validazione passo per passo: ordine di prova e DebugView
L’audit qualitativo si fa a mano, sul negozio online in produzione:
Attiva DebugView e percorri il funnel
Dalla pagina di categoria alla scheda prodotto e al carrello, fino a un ordine di prova pagato. Ogni passaggio deve mostrare il proprio evento in DebugView in tempo reale.
Controlla i parametri di ogni evento
Array items con item_id, prezzo e quantità corretti; in purchase anche transaction_id, value e currency. Confronta value con l’importo dell’ordine e con la definizione concordata (lordo o netto, con o senza spedizione).
Testa i casi limite
Pagamento con reindirizzamento, ricaricamento della pagina di ringraziamento, ritorno dalla cronologia del browser. È qui che nascono eventi mancanti e duplicati, non nel percorso ideale.
Imposta un monitoraggio costante della copertura
Un riepilogo settimanale di purchase rispetto agli ordini pagati (numero e valore). Un audit una tantum perde validità al primo cambio di template, plugin o gateway di pagamento.
Rischio concreto
Un’implementazione difettosa non danneggia solo i report. Le campagne Google Ads imparano dagli eventi GA4: un buco nei purchase significa meno segnali di conversione, ottimizzazione peggiore e ordini che costano davvero di più. Il meccanismo delle discrepanze tra piattaforme pubblicitarie e negozio è spiegato nella guida su conversioni e attribuzione.
DataOrganizer
Come DataOrganizer controlla la qualità dei dati GA4
DataOrganizer importa gli eventi GA4 e, in parallelo, gli ordini dal sistema del negozio, quindi la copertura si calcola direttamente dai dati, senza esportazioni manuali: numero e valore dei purchase rispetto agli ordini pagati, giorno per giorno. In più, il rilevamento automatico delle anomalie segnala i cambiamenti improvvisi prima che qualcuno apra un report:
Copertura purchase nelle ultime settimane:
| Settimana | purchase GA4 | Ordini pagati | Copertura numero | Copertura valore |
|---|---|---|---|---|
| 18/08–24/08 | 418 | 446 | 94% | 95% |
| 25/08–31/08 | 289 | 401 | 72% | 70% |
| 01/09–07/09 | 437 | 459 | 95% | 96% |
Nella settimana 25/08–31/08 la copertura è scesa al 72% ed è tornata nella norma dopo l’01/09, mentre il numero di ordini pagati nel negozio è cambiato solo di poco (401 contro 446 e 459 nelle settimane vicine): la perdita riguarda quindi la misurazione. Il calo coincide con il cambio del gateway di pagamento; la causa più probabile è il pagamento con reindirizzamento senza ritorno alla pagina di ringraziamento (da confermare con un ordine di prova). I report GA4 di quella settimana sottostimano le vendite; per i confronti usa i dati del negozio.
Da ricordare
L’audit GA4 funziona solo se diventa un’abitudine. Sul piano qualitativo: ordine di prova con DebugView dopo ogni modifica al negozio. Sul piano quantitativo: copertura dei purchase rispetto agli ordini pagati ogni settimana. DataOrganizer gestisce automaticamente la seconda parte, perché tiene le due fonti affiancate.
FAQ
Domande frequenti sull’audit GA4 nell’e-commerce
Quali eventi e-commerce deve avere un negozio online in GA4?
Il percorso standard: view_item_list, view_item, add_to_cart, begin_checkout, add_payment_info e purchase, ciascuno con l’array items, e purchase con transaction_id, value e currency. I nomi devono essere quelli standard della documentazione Google: i report e-commerce non riconoscono nomi inventati.
Perché GA4 mostra meno ordini del negozio?
Di solito perché purchase viene inviato solo sulla pagina di ringraziamento (dopo un pagamento con reindirizzamento alcuni clienti non ci tornano), per il blocco degli script e per i consensi mancanti. Una differenza di qualche punto percentuale, fino a un 10–15%, è normale; un calo improvviso della copertura indica un guasto nella misurazione, non un cambiamento nel comportamento dei clienti.
Cosa causa i purchase duplicati?
Il ricaricamento o la riapertura della pagina di ringraziamento quando manca transaction_id. Un’implementazione corretta invia purchase una sola volta per ordine, con un identificativo univoco; l’audit confronta il numero di eventi con il numero di identificativi univoci.
Come verificare la correttezza dell’implementazione?
Sul piano qualitativo: ordine di prova con DebugView e controllo dei parametri di ogni evento, inclusi i casi limite (reindirizzamenti di pagamento, ricaricamenti). Sul piano quantitativo: copertura del numero e del valore dei purchase rispetto agli ordini pagati del negozio, monitorata costantemente e non una tantum.
Come aiuta DataOrganizer?
Tiene affiancati gli eventi GA4 e gli ordini del negozio, quindi la copertura si calcola automaticamente sui totali giornalieri (numero e valore dei purchase rispetto agli ordini pagati), mentre il rilevamento delle anomalie segnala i cambiamenti improvvisi nei dati. Alla domanda «GA4 registra tutti gli ordini?» si ottiene in un minuto una risposta con i numeri, insieme all’indicazione del periodo in cui i dati non sono affidabili.
Promemoria dell’intera guida
Audit GA4 in tre livelli
1. Set completo di eventi con nomi standard. Il percorso da view_item a purchase, con items, transaction_id, value e currency. Tutto il resto si costruisce su questa base.
2. La copertura come indicatore costante di affidabilità. Numero e valore degli eventi purchase rispetto agli ordini pagati registrati nel negozio, settimana dopo settimana. Un cambio di livello è un allarme sull’implementazione, prima che diventi una decisione di budget sbagliata.
3. Validazione dopo ogni modifica. Un ordine di prova con DebugView dopo ogni cambio di template, plugin o gateway di pagamento. DataOrganizer completa il quadro: copertura e anomalie si calcolano da sole, perché i dati di GA4 e del negozio si trovano uno accanto all’altro.
DataOrganizer · GA4 sotto controllo costante
Collega GA4 e la piattaforma del negozio: i totali giornalieri di purchase vengono confrontati con gli ordini pagati e le anomalie nei dati vengono segnalate automaticamente. Account demo subito disponibile, paghi solo le fonti collegate.
