Dopo un anno di “utilizzo forzato” possiamo dire che, nonostante il cambio radicale dell’architettura del dato nel dietro le quinte e un’interfaccia completamente diversa, in realtà il passaggio da UA a GA4 è 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’utilità delle nuove feature valeva l’impegno per la migrazione.
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 che, con piccole accortezze, possono essere evitati, per garantire dati puliti e attendibili.
Non definire dimensioni o metriche custom
La misurazione in GA4 si basa sugli eventi: ogni informazione inviata al backend è legata a un evento.
Nel vecchio UA, un evento era definito da una categoria, un’etichetta e un’azione: da un lato, una struttura semplice e coerente, dall’altro poca flessibilità (che portava spesso a usare i campi azione o etichetta in maniera creativa per farci stare più 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’utente sceglie un punto vendita in una lista posso far scattare l’evento “get_store_info” e passare il parametro “store_name” con il nome o l’etichetta del negozio selezionato.
Ogni parametro extra va dichiarato in GA4: nel pannello di amministrazione, alla voce “definizioni personalizzate” è possibile definire dimensioni o metriche personalizzate, 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.
Pro tip: tutti gli elementi passati in un evento sono registrati in BigQuery, se il collegamento con il database è stato attivato. In questo caso, anche gli elementi custom non definiti nell’interfaccia GA4 saranno comunque accessibili facendo le giuste query sui dati di analytics.
Usare dimensioni con cardinalità troppo elevata
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 “other”.
Questo limite è da tenere a mente soprattutto quando si definiscono dimensioni custom: serve davvero quel valore così preciso? Posso raggruppare i valori grezzi in segmenti ragionevoli, per ridurre il numero di valori effettivamente passati nella dimensione? Come verrà usata quella dimensione nei report? Il rischio di avere un buon numero di record in “other” è un problema per le analisi che devo fare?
Il consiglio è di evitare di avere dimensioni con cardinalità troppo elevata, ma ciò dipende sempre dai casi specifici e dall’utilizzo 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).
Non escludere i referral
Niente di nuovo, in realtà: i referral indesiderati c’erano anche in UA.
Questa situazione si nota per lo più sugli e-commerce: sono pronto per l’acquisto, 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’e-commerce, dove l’acquisto 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ì, nei report delle conversioni, il canale PayPal referral si prende gran parte dei meriti delle transazioni, nascondendo quelli che sono i canali che hanno davvero portato l’utente sul nostro sito.
Il problema si risolve facilmente: nel pannello di amministrazione dello stream di GA4 c’è una voce “referral indesiderati” dove basterà inserire “PayPal” nella lista per evitare che gli atterraggi da questo canale facciano partire una nuova sessione.
PayPal sembra in realtà l’unica sorgente che crei questa situazione in GA4, mentre in UA il fenomeno era molto più diffuso e includeva tutti i siti dei circuiti di carte di credito nonché di alcune banche. Per essere sicuri di aver escluso tutti i referral indesiderati è comunque bene verificare, di tanto in tanto, i canali (“sorgente/mezzo della sessione”) che hanno portato conversioni: se tra questi ci fossero siti di sistemi di pagamento, è bene aggiungerli alla lista degli indesiderati.
Non pensare al sincronismo dei tag in TagManager e perdere informazioni importanti in GA4
Il TagManager crea una lista di comandi in javascript che vengono eseguiti quando l’utente apre una pagina web. L’ordine di questi comandi dipende dall’ordine dei frigger, 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!
È allora buona prassi inizializzare il tag di GA4 il prima possibile su ogni pagina (indicativamente, all’evento “initialization”) eventualmente facendo scattare l’evento page_view più tardi.
In questo modo si garantisce che GA4 registri le informazioni base del traffico (se per qualche motivo scattasse un evento di “engagement”, come uno scrolling, prima del tag base di GA4, la sessione partirebbe con un traffico “unassigned” o “not set”).
Non tracciare tutti gli step del processo d’acquisto
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’acquisto, a partire dalla visualizzazione di un prodotto, passando per l’aggiunta al carrello, l’inizio dell’acquisto e fino alla conferma dell’avvenuto acquisto.
È bene tracciare ognuno degli step per capire dove il percorso utente può presentare criticità.
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 è 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’account o nel metodo di pagamento?
Se il sito offre diversi metodi di pagamento, anche registrare il metodo scelto è interessante: alti tasso di abbandono 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 è importante e andrebbe tracciato e verificato con cura.
Non impostare correttamente gli obiettivi
Come accennato in precedenza, ogni “hit” in GA4 è un evento. Ma non tutti gli eventi hanno la stessa importanza per il business: ad esempio, un “acquisto completato” è più interessante, per valutare i risultati, di un “aggiunta del metodo di pagamento”. 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é un parametro, più o meno “implicito”: isConversionEvent. Di default, ogni evento, sia quelli standard come page_view (con l’unica eccezione dell’evento “purchase”) che quelli custom, hanno questo parametro impostato su “false”. 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 “isConversionEvent” di quell’evento a true.
Come scegliere quali eventi vanno indicati come conversioni (oggi chiamate “eventi di valore”)? Due sono le principali situazioni da considerare:
1) Solo le conversioni (e non gli eventi) possono essere importati in Google Ads: è bene quindi promuovere a conversione ogni evento sul quale si vogliono ottimizzare le campagne di Google Ads.
Ad esempio, in business dove gli acquisti per settimana sono molto pochi o dove il processo di decisione è molto lungo, oltre al “purchase”, conversione per default, anche l’add_to_cart potrebbe essere considerato come conversione, aiutando così la piattaforma ad apprendere come ottimizzare lavorando su più dati rispetto ai meno frequenti “purchase“);
2) Per la reportistica, è bene avere ben chiaro quali sono gli eventi indicatori dello stato di salute del business: la creazione di report su questi eventi sarà molto semplificata se, appunto, questi eventi di valore sono facilmente filtrabili attraverso l’etichetta “conversione” (dietro le quinte, questo si traduce in isConversionEvent=true)
Non mantenere documentazione
Ci siamo passati tutti: poco tempo, un intervento d’urgenza o non programmato, fatto di fretta, una collaborazione a più mani sui tracciamenti… e alla fine nessuno scrive in un documento quello che ha fatto nel sito, nel tagManager o in GA4.
Sì, ci vuole tempo. E sì, serve ancora più tempo per farlo bene.
Scrivere documentazione è importante per tenere traccia di cosa è stato fatto e del perché è stato fatto in quel modo.
Si può scegliere un Google Sheet, un Excel in Sharepoint, un block notes nel cassetto dell’IT manager, ma è bene tenere traccia di cosa è stato implementato e di quei dettagli tecnici che possono essere utili in futuro per la manutenzione o la modifica dei tracciamenti.
Il measurement plan elenca gli eventi che misureremo sul sito e come utilizzeremo questi eventi (grafici, tabelle eccetera) e può anche includere il tracking plan, cioè come tracceremo tecnicamente questi eventi.
Eventualmente, il tagManager consente anche di aggiungere note ai vari tag o trigger: questi non sostituiscono ovviamente un tracking plan, ma possono già essere un modo veloce di mantenere un minimo di ordine in ciò che viene fatto.
Come già anticipato nell’articolo La Data Visualization come guida nelle strategie aziendali, l’importanza strategica che riveste uno strumento come Google Analytics è sempre più 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.