{"id":11482,"date":"2024-04-30T12:19:20","date_gmt":"2024-04-30T10:19:20","guid":{"rendered":"https:\/\/www.noooagency.com\/?post_type=noooborders&p=11482"},"modified":"2026-03-12T18:47:17","modified_gmt":"2026-03-12T17:47:17","slug":"gli-errori-piu-comuni-da-evitare-in-ga4","status":"publish","type":"noooborders","link":"https:\/\/www.noooagency.com\/noooborders\/gli-errori-piu-comuni-da-evitare-in-ga4\/","title":{"rendered":"Gli errori pi\u00f9 comuni da evitare in GA4"},"content":{"rendered":"\n

Dopo un anno di \u201cutilizzo forzato\u201d possiamo dire che, nonostante il cambio radicale dell\u2019architettura del dato nel dietro le quinte <\/em>e un\u2019interfaccia completamente diversa, in realt\u00e0 il passaggio da UA a GA4<\/strong> \u00e8 stato meno impegnativo di quanto annunciato, gran parte dei bug (o delle lacune) iniziali sono oggi un ricordo affidato a qualche post Linkedin (invecchiato male), e in definitiva l\u2019utilit\u00e0 delle nuove feature valeva l\u2019impegno per la migrazione.<\/p>\n\n\n\n

Ma la nuova piattaforma, per sua natura, ha introdotto alcuni elementi che richiedono accortezze o interventi nuovi, che non erano necessari nel vecchio UA. Ecco alcuni errori comuni nel setup di GA4 <\/strong>che, con piccole accortezze, possono essere evitati, per garantire dati puliti e attendibili.<\/p>\n\n\n\n

Non definire dimensioni o metriche custom<\/h4>\n\n\n\n

La misurazione in GA4 si basa sugli eventi: ogni informazione inviata al backend \u00e8 legata a un evento.
Nel vecchio UA, un evento era definito da una categoria, un\u2019etichetta e un\u2019azione: da un lato, una struttura semplice e coerente, dall\u2019altro poca flessibilit\u00e0 (che portava spesso a usare i campi azione o etichetta in maniera creativa per farci stare pi\u00f9 informazioni).

Gli eventi in GA4 prevedono solo un nome ed eventualmente una serie di parametri aggiuntivi che possiamo chiamare e popolare come vogliamo: ad esempio, se l\u2019utente sceglie un punto vendita in una lista posso far scattare l\u2019evento \u201cget_store_info<\/em>\u201d e passare il parametro \u201cstore_name<\/em>\u201d con il nome o l\u2019etichetta del negozio selezionato.

Ogni parametro extra va dichiarato in GA4: nel pannello di amministrazione, alla voce \u201cdefinizioni personalizzate<\/em>\u201d \u00e8 possibile definire dimensioni o metriche personalizzate<\/strong>, passando il nome esatto che abbiamo utilizzato nel codice di tracciamento. Le dimensioni e metriche custom che non sono definite in GA4 non saranno accessibili in nessun report.<\/p>\n\n\n\n

Pro tip: tutti gli elementi passati in un evento sono registrati in BigQuery<\/strong>, se il collegamento con il database \u00e8 stato attivato. In questo caso, anche gli elementi custom non definiti nell\u2019interfaccia GA4 saranno comunque accessibili facendo le giuste query sui dati di analytics.<\/p>\n\n\n\n

Usare dimensioni con cardinalit\u00e0 troppo elevata<\/h4>\n\n\n\n

GA4 non accetta di buon occhio le dimensioni con troppi valori (500 valori distinti in un singolo giorno). In questo caso, i report in GA4 troncano le dimensioni rappresentate nelle tabelle a pochi valori, raggruppando quindi gran parte dei valori in un generico \u201cother<\/em>\u201d.

Questo limite \u00e8 da tenere a mente soprattutto quando si definiscono dimensioni custom: serve davvero quel valore cos\u00ec preciso? Posso raggruppare i valori grezzi in segmenti ragionevoli, per ridurre il numero di valori effettivamente passati nella dimensione? Come verr\u00e0 usata quella dimensione nei report? Il rischio di avere un buon numero di record in \u201cother<\/em>\u201d \u00e8 un problema per le analisi che devo fare?

Il consiglio \u00e8 di evitare di avere dimensioni con cardinalit\u00e0 troppo elevata<\/strong>, ma ci\u00f2 dipende sempre dai casi specifici e dall\u2019utilizzo che si vuole fare dei dati. Va detto che il limite incide sui report standard di GA4, ma non vale, ad esempio, per i dati letti in BigQuery (se GA4 e BigQuery sono stati collegati).<\/p>\n\n\n\n

Non escludere i referral<\/strong><\/h4>\n\n\n\n

Niente di nuovo, in realt\u00e0: i referral indesiderati<\/strong> c\u2019erano anche in UA.
Questa situazione si nota per lo pi\u00f9 sugli e-commerce: sono pronto per l\u2019acquisto, aggiungo il metodo di pagamento, il sito mi rimanda alla pagina di autenticazione del servizio di pagamento scelto (carta di credito, PayPal, portale della banca), autorizzo il pagamento e vengo reindirizzato all\u2019e-commerce, dove l\u2019acquisto viene finalizzato e confermato. Ecco che al nuovo atterraggio nel sito parte una nuova sessione, con sorgente referral dal sito di autorizzazione del pagamento!

Cos\u00ec, nei report delle conversioni, il canale PayPal referral <\/strong>si prende gran parte dei meriti delle transazioni, nascondendo quelli che sono i canali che hanno davvero portato l\u2019utente sul nostro sito.
Il problema si risolve facilmente: nel pannello di amministrazione dello stream di GA4 c\u2019\u00e8 una voce \u201creferral indesiderat<\/em>i\u201d dove baster\u00e0 inserire \u201cPayPal<\/em>\u201d nella lista per evitare che gli atterraggi da questo canale facciano partire una nuova sessione.

PayPal sembra in realt\u00e0 l\u2019unica sorgente che crei questa situazione in GA4, mentre in UA il fenomeno era molto pi\u00f9 diffuso e includeva tutti i siti dei circuiti di carte di credito nonch\u00e9 di alcune banche. Per essere sicuri di aver escluso tutti i referral indesiderati \u00e8 comunque bene verificare, di tanto in tanto, i canali (\u201csorgente\/mezzo della sessione<\/em>\u201d) che hanno portato conversioni: se tra questi ci fossero siti di sistemi di pagamento, \u00e8 bene aggiungerli alla lista degli indesiderati.<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

Non pensare al sincronismo dei tag in TagManager e perdere informazioni importanti in GA4<\/h4>\n\n\n\n

Il TagManager <\/strong>crea una lista di comandi in javascript che vengono eseguiti quando l\u2019utente apre una pagina web. L\u2019ordine di questi comandi dipende dall\u2019ordine dei frigger<\/strong>, ma ci possono essere casi in cui un evento nel sito avviene prima di quanto ci aspettiamo e magari viene tracciato da un tag GA4 prima ancora che GA4 sia stato definito e inizializzato!<\/p>\n\n\n\n

\u00c8 allora buona prassi inizializzare il tag di GA4 il prima possibile su ogni pagina (indicativamente, all\u2019evento \u201cinitialization<\/em>\u201d) eventualmente facendo scattare l\u2019evento page_view <\/em>pi\u00f9 tardi.
In questo modo si garantisce che GA4 registri le informazioni base del traffico (se per qualche motivo scattasse un evento di \u201cengagement<\/em>\u201d, come uno scrolling, prima del tag base di GA4, la sessione partirebbe con un traffico \u201cunassigned<\/em>\u201d o \u201cnot set<\/em>\u201d).<\/p>\n\n\n\n

Non tracciare tutti gli step del processo d\u2019acquisto<\/strong><\/h4>\n\n\n\n

GA4, come anche UA, ha una serie di eventi e parametri standard pensati per gli e-commerce. Esiste un evento per ogni step del percorso d\u2019acquisto, a partire dalla visualizzazione di un prodotto, passando per l\u2019aggiunta al carrello, l\u2019inizio dell\u2019acquisto e fino alla conferma dell\u2019avvenuto acquisto.
\u00c8 bene tracciare ognuno degli step per capire dove il percorso utente pu\u00f2 presentare criticit\u00e0.

Un prodotto ha molte visualizzazioni ma tasso di aggiunta al carrello molto inferiore rispetto ad altri prodotti? Il problema potrebbe essere la pagina prodotto, che non fornisce abbastanza informazioni o non \u00e8 abbastanza convincente, oppure una UI con problematiche o ancora un problema di pricing del prodotto.

Uno step del percorso presenta un tasso di abbandono stranamente alto? Anche qui, problema di UI? O problemi tecnici nella creazione dell\u2019account o nel metodo di pagamento?

Se il sito offre diversi metodi di pagamento, anche registrare il metodo scelto \u00e8 interessante: alti tasso di abbandono<\/strong> legati a uno specifico metodo possono mostrare problemi con quel metodo specifico (errori di implementazione, sistemi di autorizzazione con filtri troppo restrittivi a monte, ecc).
Ogni step del percorso \u00e8 importante e andrebbe tracciato e verificato con cura.<\/p>\n\n\n\n

Non impostare correttamente gli obiettivi<\/h4>\n\n\n\n

Come accennato in precedenza, ogni \u201chit<\/em>\u201d in GA4 \u00e8 un evento. Ma non tutti gli eventi hanno la stessa importanza per il business: ad esempio, un \u201cacquisto completato<\/em>\u201d \u00e8 pi\u00f9 interessante, per valutare i risultati, di un \u201caggiunta del metodo di pagamento<\/em>\u201d. Alcuni eventi sono quindi indicatori dello stato di salute del business, altri, comunque importanti, sono comunque necessari per analisi e ottimizzazione ma non indicano un obiettivo finale.

Ogni evento in GA4 porta con s\u00e9 un parametro, pi\u00f9 o meno \u201cimplicito\u201d: isConversionEvent<\/em>. Di default, ogni evento, sia quelli standard come page_view<\/em> (con l\u2019unica eccezione dell\u2019evento \u201cpurchase<\/em>\u201d) che quelli custom, hanno questo parametro impostato su \u201cfalse<\/em>\u201d. Nel pannello di amministrazione di GA4 possiamo promuovere qualunque evento registrato dal nostro tracking a conversione semplicemente cliccando su uno switch: questa azione cambia il parametro \u201cisConversionEvent<\/em>\u201d di quell\u2019evento a true.
Come scegliere quali eventi vanno indicati come conversioni (oggi chiamate \u201ceventi di valore<\/em>\u201d)? Due sono le principali situazioni da considerare:<\/p>\n\n\n\n

1) Solo le conversioni (e non gli eventi) possono essere importati in Google Ads: \u00e8 bene quindi promuovere a conversione ogni evento sul quale si vogliono ottimizzare le campagne<\/strong> di Google Ads.
Ad esempio, in business dove gli acquisti per settimana sono molto pochi o dove il processo di decisione \u00e8 molto lungo, oltre al \u201cpurchase<\/em>\u201d, conversione per default, anche l\u2019add_to_cart<\/em> potrebbe essere considerato come conversione, aiutando cos\u00ec la piattaforma ad apprendere come ottimizzare lavorando su pi\u00f9 dati rispetto ai meno frequenti \u201cpurchase<\/em>“);<\/p>\n\n\n\n

2) Per la reportistica, \u00e8 bene avere ben chiaro quali sono gli eventi indicatori<\/strong> dello stato di salute del business: la creazione di report <\/strong>su questi eventi sar\u00e0 molto semplificata se, appunto, questi eventi di valore sono facilmente filtrabili attraverso l\u2019etichetta \u201cconversione<\/em>\u201d (dietro le quinte, questo si traduce in isConversionEvent=true<\/em>)<\/p>\n\n\n\n

Non mantenere documentazione<\/h4>\n\n\n\n

Ci siamo passati tutti: poco tempo, un intervento d\u2019urgenza o non programmato, fatto di fretta, una collaborazione a pi\u00f9 mani sui tracciamenti\u2026 e alla fine nessuno scrive in un documento quello che ha fatto nel sito, nel tagManager o in GA4.<\/p>\n\n\n\n

S\u00ec, ci vuole tempo. E s\u00ec, serve ancora pi\u00f9 tempo per farlo bene.
Scrivere documentazione \u00e8 importante per tenere traccia di cosa \u00e8 stato fatto e del perch\u00e9 \u00e8 stato fatto in quel modo.
Si pu\u00f2 scegliere un Google Sheet, un Excel in Sharepoint, un block notes<\/strong> nel cassetto dell\u2019IT manager, ma \u00e8 bene tenere traccia di cosa \u00e8 stato implementato e di quei dettagli tecnici che possono essere utili in futuro per la manutenzione o la modifica dei tracciamenti.
Il measurement plan<\/strong> elenca gli eventi che misureremo sul sito e come utilizzeremo questi eventi (grafici, tabelle eccetera) e pu\u00f2 anche includere il tracking plan<\/strong>, cio\u00e8 come tracceremo tecnicamente questi eventi.<\/p>\n\n\n\n

Eventualmente, il tagManager consente anche di aggiungere note ai vari tag o trigger<\/strong>: questi non sostituiscono ovviamente un tracking plan, ma possono gi\u00e0 essere un modo veloce di mantenere un minimo di ordine in ci\u00f2 che viene fatto.<\/p>\n\n\n\n

<\/p>\n\n\n\n

Come gi\u00e0 anticipato nell’articolo La Data Visualization come guida nelle strategie aziendali<\/a><\/strong>, l’importanza strategica che riveste uno strumento come Google Analytics \u00e8 sempre pi\u00f9 centrale. Viste le numerose discussioni dell’ultimo anno su questa specifica tematica e l’epocale passaggio a GA4, ci auguriamo che questo nostro contributo passa aver chiarito alcuni dubbi e aiutato nella comprensione del suo migliore utilizzo.<\/em>

<\/p>\n","protected":false},"excerpt":{"rendered":"

Dopo un anno di \u201cutilizzo forzato\u201d possiamo dire che, nonostante il cambio radicale dell\u2019architettura del dato nel dietro le quinte e un\u2019interfaccia completamente diversa, in realt\u00e0 il passaggio da UA a GA4 \u00e8 stato meno impegnativo di quanto annunciato, gran parte dei bug (o delle lacune) iniziali sono oggi un ricordo affidato a qualche post […]<\/p>\n","protected":false},"featured_media":7516,"template":"","tags":[],"cat_borders":[],"class_list":["post-11482","noooborders","type-noooborders","status-publish","has-post-thumbnail","hentry"],"acf":[],"_links":{"self":[{"href":"https:\/\/www.noooagency.com\/en\/wp-json\/wp\/v2\/noooborders\/11482","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.noooagency.com\/en\/wp-json\/wp\/v2\/noooborders"}],"about":[{"href":"https:\/\/www.noooagency.com\/en\/wp-json\/wp\/v2\/types\/noooborders"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.noooagency.com\/en\/wp-json\/wp\/v2\/media\/7516"}],"wp:attachment":[{"href":"https:\/\/www.noooagency.com\/en\/wp-json\/wp\/v2\/media?parent=11482"}],"wp:term":[{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.noooagency.com\/en\/wp-json\/wp\/v2\/tags?post=11482"},{"taxonomy":"cat_borders","embeddable":true,"href":"https:\/\/www.noooagency.com\/en\/wp-json\/wp\/v2\/cat_borders?post=11482"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}