Dec 10 2020
GA4 è un po’ un TagManager
Sottotitolo: chi non documenta è perduto
Oggi stavo studiando la funzione di modifica degli eventi di GA4, cioè quella modalità che ti permette di MODIFICARE gli eventi (cioè qualsiasi hit di GA4) direttamente da interfaccia; il caso d’uso più banale è l’errore di ortografia su un nome evento o un parametro: oggi devi per forza di cose fare una modifica sul codice o sul Google Tag Manager, e se non puoi farlo direttamente devi aspettare che qualcuno lo faccia per te. Finché la modifica non viene fatta, entrano dati sbagliati. Domani invece potrai editare l’evento dalla UI di GA4 e tagliare la testa al toro.
Clicca qui, clicca là, sono arrivato su questa pagina dell’help
https://support.google.com/analytics/answer/10085872
e la cosa che mi ha incuriosito di più è stata questa frase:
Le modifiche vengono eseguite sul lato client prima che i dati siano inviati ad Analytics per l’elaborazione.
Questo significa che gli eventi modificati NON VENGONO modificati in fase di analisi, ma vengono proprio SPARATI dal browser mentre l’utente naviga.
Significa anche, di conseguenza, che il MIO codice di Analytics è diverso dal TUO codice di Analytics, perché le modifiche agli eventi che io ho messo nell’interfaccia devono necessariamente essere diverse e distinte dalle tue.
Se ci pensiamo, questa cosa è vera già per altri due strumenti di Google: Google Optimize e Google Tag Manager, cioè strumenti che sono fortemente basati su logiche di funzionamento personalizzate. Fino ad oggi invece GA Universal era basato su una libreria unica (il file analytics.js) uguale per tutto il mondo, e le personalizzazioni avvenivano sull’oggetto javascript di tracciamento, o sulla coda di comandi che vi transitava attraverso. Ebbene, con GA4 invece anche la libreria di Analytics viene personalizzata per property, e infatti troviamo una chiamata al file
https://www.googletagmanager.com/gtag/js?id=G-ABC123456
e non una chiamata generica.
E quindi, perché “chi non documenta è perduto?” perché in questo modo il numero di “posti” in cui può “accadere” qualcosa che ha effetti su quel che poi leggerai su GA (o su BigQuery, o su DataStudio) aumenta. Non solo, le logiche dietro alla creazione di questi eventi modificati non sono intelleggibili ma nascoste dietro al codice; sarebbe come sperare di interpretare cosa fa un esperimento di Optimize guardando il sorgente. Fattibile, ma non alla portata di tutti.
Quindi un evento che vediamo su GA4 potrebbe:
- essere lì, giusto, perché c’è un tag e un trigger su GTM
- essere lì, giusto, perché viene sparato dal sorgente della pagina
- essere lì, sbagliato, perché c’è un tag scritto male e un trigger su GTM
- essere lì, sbagliato, perché viene sparato male dal sorgente della pagina
- essere lì, giusto, perché c’è un tag scritto male e un trigger su GTM ma poi c’è una modifica evento che lo corregge
- essere lì, giusto, perché viene sparato male dal sorgente della pagina ma poi c’è una modifica evento che lo corregge
- essere lì, sbagliato, perché verrebbe sparato giusto dal GTM ma qualcuno ha sbagliato la modifica evento nella UI di GA4
- essere lì, sbagliato, perché verrebbe sparato giusto dal sorgente della pagina ma qualcuno ha sbagliato la modifica evento nella UI di GA4
Capite da soli che la chiave per non impazzire dietro a questo labirinto di possibilità è solo quella di avere dei documenti esaustivi, completi ed aggiornati sul piano di tracking. Quale attore fa cosa, quale opzione modifica cosa, chi e dove deve toccare per ottenere un certo effetto.
Senza questa disciplina nel fare i piani di tracking, saranno solo eterni dolori… :/