Nonostante ormai non sia più così assiduo nella scrittura come un tempo, mi arrivano continuamente attestati di stima per quel che ho fatto – e faccio, ma meno di prima – qui sopra. Ieri sono andato a conoscere il nuovo referente interno di un cliente molto importante, e lui mi dice “ti conosco di fama, ti ho anche citato in una mia presentazione anni fa. Quando ho iniziato questo lavoro il mio capo di allora mi disse ‘tu leggi ogni mattina quel che scrive goanalytics.info, e vedrai che vai liscio’ “.
E niente, per poco mi metto a piangere. Non lo so se me lo merito, ma ce l’ho messa tutta e a volte mi sembra che si, forse un pochino… 🙂
Quindi Grazie! forse non ve l’ho mai detto. E se si, forse non abbastanza!
Una delle cose divertenti di Google Analytics 4 (mhhhh, una delle TANTE cose divertenti…) è che ormai abbiamo capito che non possiamo mai dire “Su Universal è sempre stato così, quindi per coerenza lo sarà anche qui”, no?
Ecco, parliamo un attimo di come funzionavano revenue e resi su Universal Analytics: tracciavi una transazione, che aveva una revenue associata. ID transazione -> Revenue. Tracciavi un reso, che aveva una revenue associata (diciamo per comodità la stessa revenue, reso totale). ID transazione -> Refund Amount. Notate la metrica diversa?
Poi se volevi le revenue nette potevi creare una custom metric e fare {{Revenue}} – {{Refund Amount}}, o affiancare le due colonne in un report tabellare e vedere quanto reso sul totale incassato.
E su GA4? OVVIAMENTE su GA4 è diverso: Su GA4 tracci una transazione con l’evento purchase e hai una revenue, quindi ID Transazione -> PurchaseRevenue. Poi tracci un reso con un evento refund, però hai ugualmente una revenue, cioè ID Transazione -> PurchaseRevenue. Vediamo un caso reale:
I più attenti di voi noteranno che riporta “2” nelle transactions. L’ho lasciato apposta, ci arriviamo tra poco, per ora fate finta di non averlo visto. Quindi la transazione 5007088 ha revenue 149 euro, giusto?
No, sbagliato! Adesso aggiungo la dimensione data
Tra l’altro si nota che se prendessi solo il 20 settembre e questa fosse la mia unica transazione, per quel giorno avrei revenue negativa! “Marco, ma non si è sempre detto che non si mandano transazioni con valori negativi per rettificare le revenue?” certo, è uno dei mantra massimi di Universal insieme a “MAI usare gli utm su link interni” (che infatti non si sente tanto bene nemmeno lui 😀 ). In effetti però quel valore negativo non è una TRANSAZIONE con revenue negativa, ma il risultato dell’evento refund cui abbiamo passato un valore positivo. Guardiamo infatti la revenue di un certo periodo con un explore, usando la stessa metrica che vedete nel report Monetization
Questo ecommerce ha guadagnato 71k? NO! Se infatti divido per eventi la figura è ben diversa
Ne ha incassati 93,5 ma nel frattempo ha avuto quasi 22k di resi. che è ben diverso, se stiamo valutando ad esempio l’efficacia di una campagna e non la qualità del prodotto.
Quindi occhio, perché nei report standard, anzi ogni volta che usate la metrica Purchase revenue / Total Revenue, fareste meglio a controllare che succede filtrando solo per evento “purchase” o filtrando via “refund”. Potreste avere delle gioie 🙂
Da qualche tempo su GA4 è possibile avere (“ri-avere” per i nostalgici del “si stava meglio con GA3 😀 ) il report con la progressione e i drop del funnel di checkout, e anzi non solo del checkout: possiamo in realtà creare qualsiasi funnel con qualsiasi pagina, evento, o combinazione di pagine ed eventi, e incastonarlo nel menu principale, ad esempio dentro a Monetizzazione, sempre per compiacere i nostalgici. Come?
Facile, con un explorer che trasformeremo in un report standard.
Apriamo la sezione Explore e creiamo un nuovo report, ovviamente di tipologia Funnel (Esplorazione della canalizzazione se usate l’interfaccia italiana – ma non dovreste proprio 😉 )
Configuriamo il nostro report innanzitutto decidendo quanti e quali sono gli step. Qui come detto potete usare qualsiasi cosa abbiate nel vostro Analytics: eventi, eventi con parametri particolari, pagine, eventi custom o eventi predefiniti, tutto
Tralasciamo pure le metriche, tanto in un report di tipo funnel ci saranno sempre e solo gli “Utenti Attivi”
Selezioniamo le dimensioni applicabili. Attenzione perché le dimensioni che scegliamo qui (e l’ordine in cui le mettiamo) si rifletterà tale e quale nel report standard. Quindi la prima dimensione che scegliamo sarà la dimensione predefinita del report, la seconda sarà la prima del menu a tendina, la terza la seconda del menu a tendina e così via
Modifichiamo il report fino a quando non lo troviamo soddisfacente. Attenzione anche qui! se dopo avremo bisogno di modificare il report standard, dovremo per forza distruggerlo e ripartire dall’explore, quindi cerchiamo di essere ben sicuri in questo passaggio
Salviamo con nome il report nella libreria attraverso un pulsante che esiste solo nei report di tipo Funnel, il pulsante “salva come report nella Libreria” in alto a destra
Apriamo la Libreria, editiamo una Collection (per Esempio Ciclo di vita) o creiamo una Collection nuova, e andiamo a incastrare dove vogliamo il nostro report appena salvato
Voilà, il report del Funnel è adesso un report standard, visibile da tutti al pari degli altri
Come detto, pongo l’accento su due temi importanti: uno è che il funnel è “libero”, non necessariamente legato al comportamento ecommerce o di checkout come era su GA3: posso fare un funnel di tutti quelli che atterrano da cpc, e che dopo vedono un certo listing, e aggiungono al carrello un prodotto di una certa categoria, eccetera… ovviamente più sono specifico e meno utenti avrò nella mia canalizzazione, ma avete capito. L’altro tema è che una volta incardinato nel menu, il report (questo report, almeno) non è editabile. Va distrutto e ricreato partendo dall’explore in caso ci sia bisogno di modifiche. Un piccolo prezzo da pagare in cambio di una feature molto potente, tutto sommato.
Mi aspettavate, me lo avete chiesto (grazie, vi ricordate ancora di me 🙂 ) e quindi eccomi qua. Oggi, stanotte, domani – o forse chi lo sa, invece magri ancora per qualche giorno funzionerà, ma insomma, ci siamo – oggi ufficialmente muore Google Universal Analytics, già Google Analytics asincrono, già Google Analytics, e ancora prima Urchin. Diciamo che oggi smetterà di funzionare la mia property più vecchia, quella che ho aperto nel dicembre 2005
Poi dopo 3 anni, nel 2008, ho avviato questo blog e abbiamo iniziato a conoscerci. (Si, dai, “e ora tutto questo andrà perduto, come lacrime nella pioggia“, come sei banale! vi sento, cosa credete? 😀 ).
Non c’è molto che possa aggiungere all’ottimo post di Simo che sono sicuro avete già letto tutti. Anche io come lui devo la mia carriera in larga parte a Google Analytics, e anche io come lui sono stupito dal livello di “non ascolto” di Google. Magari, al suo livello di influenza, non avrei aspettato così tanto per scriverlo, se voleva scuotere qualche animo per davvero a Mountain View. Ma a parte questo, potremo dire sicuramente un paio di cose su Universal Analytics:
se oggi la digital analytics è un mercato maturo, pieno di professionisti, e un’attività imprescindibile per un brand moderno che faccia marketing lo dobbiamo a lui. Non possiamo sapere SE sarebbe arrivato un tool simile, ne se avrebbe avuto la sua portata (culturale) e la sua scala (tecnica), ma quasi certamente non sarebbe stato la perfetta macchina da marketing che GA è stato per l’ecosistema Google
Di contro, se oggi la digital analytics è anche spesso “solo” il setup di Google Analytics lo dobbiamo a lui, alla sua facilità, alla sua versatilità e malleabilità; potevi adattare Universal a quasi qualsiasi cosa, tutto sommato velocemente, avevi sempre risposte veloci e precise, e questo alla lunga ha smesso di far pensare per davvero molte persone, ha impedito loro di porsi le giuste domande, o ha fatto credere a molte persone che fare un report (essere in grado di fare un report) fosse sufficiente a rispondere a ogni domanda
Di fatto, sono in realtà due aspetti “culturali” e molto poco tecnici, e sono frutto delle due facce di una stessa medaglia.
Cosa ci riserva il futuro non lo sappiamo. Di sicuro GA4 ha tanta strada da fare prima di arrivare anche solo ad ambire di poter avere la stessa portata culturale. Tecnicamente ce la può anche fare in poco tempo – con un po’ di impegno da parte di Google, chiaro – ma culturalmente ci vorrà del tempo. E come dice Simo, la rivoluzione culturale l’abbiamo fatta tutti insieme, Google, i partner, le agenzie e la community. E’ impensabile farne un’altra senza uno di questi componenti, ma invece ce n’è un gran bisogno altrimenti GA4 sarà “solo” l’evoluzione tecnologica apparentemente complicata di un grande tool sottoutilizzato dai più. E invece l’industry ha bisogno di molto di più, molto molto di più.
(e magari, chissà, ora che ho tolto la polvere dal pannello di WordPress sia mai che… 🙂 )
autore: Marco Ciliacategoria: report the_tags('tag: '); ?>
L’altro giorno mi sono trovato un po’ spiazzato da una frase che suonava alla lontana come “su GA4 non c’è il report Google Ads”. Che però è una cosa piuttosto imprecisa: è vero che GA4 non c’è una sezione dedicata nel menu di navigazione. È vero che su GA4 non ci sono tutti i report dedicati a Google Ads cui eravamo abituati prima. Ma è altrettanto vero che il report Google Ads è vivo e vegeto, esiste ed è fruibile. Solo, è un po’ nascosto. Dove lo trovate, quindi?
Se avete collegato Google Ads e Google Analytics 4, navigate fino alla schermata Ciclo di vita -> Acquisizione -> Panoramica dell’acquisizione, dove tra i widget troverete anche “Sessioni per Campagna Google Ads della sessione”. Da quel widget potrete vedere le prime 7 campagne per sessioni, ma usando il link “visualizza le campagne Google Ads” arriverete al report dedicato, questo:
A parte che mancano le impressions, somiglia molto al report “tutte le campagne” della sezione Google Ads di GA3. Inoltre cambiando la dimensione principale del report si può riprodurre i report campagne, ad set, keyword, query di ricerca, rete pubblicitaria; molti report in un solo report. Per le impressions al momento non si può fare niente, nel senso che anche provando ad editare il report la metrica non è disponibile. Quel che invece potete fare è incardinarlo nella struttura del menu, in modo da renderlo a portata di clic per tutti gli utenti della property, come ho fatto io:
Fate così:
Quando siete nel report Google Ads cliccate l’icona a forma di penna in alto a destra, per entrare in modalità MODIFICA
Non toccate niente (o personalizzate quel che volete, se lo ritenete necessario) e premete il tasto blu “Salva…” in alto a destra selezionando “salva come nuovo rapporto”
Date un nome al rapporto, ad esempio con grande fantasia “Campagne Google Ads” 🙂
Tornate al report, in modo da vedere il menu principale, e scegliete “Libreria” in basso a sinistra, vicino all’icona dell’amministrazione
Premete “Modifica raccolta” in corrispondenza della raccolta “Ciclo di vita”, e così facendo vedrete il menu esploso e modificabile.
A questo punto cercate il report “Campagne Google Ads” (o come lo avete chiamato) e trascinatelo sotto ad Acquisizione Traffico
in basso a sinistra fate “Salva…” e poi “Salva le modifiche alla raccolta corrente”
Et voilà, ora il menu ha il suo report Google Ads, per tutti gli utenti che hanno accesso alla property
autore: Marco Ciliacategoria: filtri the_tags('tag: '); ?>
AH! fermi tutti! Non si era detto che GA4 anonimizza gli IP per default? che non manda niente negli Stati Uniti? MA ALLORA CI PRENDE IN GIRO??
Beh, no, niente affatto. Vediamo un po’ come gira la macchina.
Innanzitutto da dove è che filtro gli IP? dal pannello di AMMINISTRAZIONE, poi DATA STREAMS, poi seleziono lo stream appropriato, poi CONFIGURE TAG SETTING (poi “show all” altrimenti non si vede la voce) e quindi finalmente DEFINE INTERNAL TRAFFIC. Vi ritroverete davanti a una schermata così
Potete inserire varie condizioni come al solito e salvare la regola. Di fatto, quel che accade è che il traffico da quel/quegli indirizzi IP verrà marcato con un parametro “traffic_type” = internal e lo potrete filtrare tramite l’apposito menu.
OK, ma come fa, dato che gli IP ASSOLUTAMENTE non ci arrivano alla macchina di analisi? beh, la cosa è abbastanza interessante: come i più attenti di voi avranno notato, le chiamate al file javascript di analytics (il gtag.js) non sono tutte uguali come accadeva con le vecchie versioni, ma sono parametrizzate. Ad esempio per questo blog viene chiamato https://www.googletagmanager.com/gtag/js?id=G-CPT24FYWZ1
All’interno del file ci sono varie regole e settaggi aggiuntivi, che sono diversi da file a file e dipendono dalle impostazioni che avete nei pannelli. Quando voi salvate un’impostazione tipo questa degli indirizzi IP, di fatto modificate il file che viene scaricato dagli utenti.
All’interno del file quindi c’è una regola che semplicemente dice “se l’indirizzo IP corrisponde a uno di quelli listati, aggiungi il parametro traffic_type=internal”. L’indirizzo IP non viene inviato (o insomma, viene inviato almeno al primo server collettore che per l’Europa è region1.analytics.google.com) ma il traffico può essere filtrato come ai vecchi tempi perché c’è un parametro nella hit – già in partenza, senza quindi dover aspettare che l’IP arrivi ai server – che “marchia” adeguatamente la stessa.
La stessa cosa avviene quando impostate la creazione di un evento dall’interfaccia. La regola viene scritta nel file gtag della vostra property e l’evento viene creato NEL BROWSER e inviato, non viene creato in fase di analisi. Brillante, no? 🙂
autore: Marco Ciliacategoria: generale the_tags('tag: '); ?>
Questo blog esiste dal 2008, alcuni di voi lo seguono da allora. Nel corso del tempo abbiamo visto di tutto – come si suol dire – e ne abbiamo sentite di tutti i colori. Un tempo mi dilettavo in previsioni sul futuro dello strumento e vi ho sempre raccontato con dovizia di particolari ogni nuova feature. Se sono stato accomodante con Google? probabilmente si, ma perché sono sempre stato convinto della bontà del prodotto. Ma se cercate bene, troverete anche spunti molto critici, non sono mai stato uno cui piace la piaggeria… 🙂
Ora, su alcune cose in questi anni mi sono sentito di poter dire a voi e ai clienti che “ci metto la mano sul fuoco”, perché in oltre 17 anni di uso dello strumento, Google ci aveva abituato bene; diciamo che era un meccanismo ben oliato e “prevedibile”. Ultimamente invece mi sono trovato già due volte a dire “questa cosa ho sempre detto che non sarebbe mai stata possibile, e invece…”: una su tutte è l’uso dell’identità Google per deduplicare gli utenti cross-device, prerogativa di GA4.
L’altra è la CLAMOROSA SMENTITA del mio mantra “ma no, Google non ha mai forzato nessuno a passare di versione, infatti se vuoi usare il codice di urchin.js è ancora lì. Semplicemente sviluppano feature solo per le nuove versioni così sei incentivato a passare, coi tuoi tempi naturalmente”.
Lo saprete ormai tutti perché non si parla d’altro, invece dal 1 Luglio 2023 Universal SMETTERA’ di raccogliere dati, e funzionerà solo Google Analytics 4. E già questa di per sé è una rottura clamorosa rispetto al passato, uno switch epocale che non sarà esente da traumi. Ma per non farsi mancare niente, avremo accesso ai report Universal per “almeno ancora 6 mesi”, dopodiché anche quelli spariranno. Come se “scaricarsi i report” fosse la soluzione… (si, mi scarico i report mensili dal 2005 al 2023, che sai mai che un CEO voglia l’andamento annuale del sito da quando esiste? ma di quali metriche poi? le sessioni? per channel? per device? per entrambi? e le mie custom dimension utili a segmentare i dati? riscarico anche – di nuovo – tutto in base ad ogni CD?)
Ora, capisco molto bene i vantaggi di GA4, che è un tool completamente riscritto da zero, il cambio di logiche, e che nel lungo periodo saremo tutti più contenti e lavoreremo meglio. Davvero, tralasciando i peccati di gioventù del tool e il suo essere uscito sul mercato in condizioni non ancora ottimali, sapevo per certo che saremmo andati tutti lì, perché e con quali vantaggi. Non capisco però perché Google abbia BISOGNO di forzare la mano così a tutti. 15 mesi sembrano tanti, ma se avete lavorato con realtà di una certa caratura invece saprete che siamo già in ritardo. E’ un non-sense e secondo me è anche un boomerang niente male per Google. Quando metti fretta alle persone, a volte fanno scelte non ben ponderate, per comodità…
In ogni caso, credo che nei prossimi mesi avremo BEN BEN da fare, non sarà affatto una passeggiata.
Anche una cosa semplice come il concetto di sessione ha bisogno di un po’ di attenzione quando c’è in gioco Google Analytics 4; d’altronde GA4 è un tool completamente basato su eventi (quindi anche le sessioni sono eventi) e questo impatta anche su cose che diamo per scontate come ad esempio il bounce rate.
Tanto per cominciare esiste un evento denominato “session_start” che viene inviato automaticamente da GA4 per conteggiare quante sessioni iniziano in un determinato periodo di tempo. Questo significa anche che le sessioni non si resettano in GA4 quando erano solite farlo in GA3, ad esempio quando durante la stessa visita si cambiano i parametri della campagna o se durante la visita scocca la mezzanotte.
Esempio: qualcuno clicca una email promozionale di una giacca, atterra sul sito ma non la compra. Poco dopo però cambia idea, riapre la posta ma trova un’altra mail promozionale, di una maglietta, clicca quella, va sul sito e compra entrambe le cose. Su GA3 queste sono due sessioni distinte (una senza acquisti, una con due acquisti) per via del cambio dei parametri di campagna, mentre su GA4 questo non è più vero: i parametri “ga_session_id” e “ga_session_number” sarebbero gli stessi.
Inoltre, su GA3 se settiamo una custom dimension con scope “sessione”, questa sarà applicata a tutte le pageview e gli eventi della sessione, anche se il valore lo abbiamo inviato solo con una delle due; su GA4 al momento questo non è vero, e per ottenere lo stesso effetto dobbiamo inviare il parametro che vogliamo agisca come una custom dimension di sessione con ogni evento.
Il bounce rate: sappiamo tutti che su GA3 una sessione bounce è una sessione in cui accade un solo evento interattivo (tipicamente una pageview). Su GA4 il concetto di bounce non esiste, mente esiste il suo opposto, ovvero le “engaged_sessions“: le engaged_sessions sono le sessioni in cui un utente ha visto più di una pagina o è rimasto per più di 10 secondi (ma è possibile cambiare il timer fino a 60 secondi, nelle impostazioni dello stream).
Su GA3 una sessione termina, per definizione, se l’utente non invia nessun evento interattivo per più di 30 minuti. Se ne invia uno dopo 30 minuti e 7 secondi, parte una nuova sessione. Questo calcolo viene fatto in fase di analisi dei dati, prima di compilare i report, facendo le sottrazioni tra i timestamp degli eventi e delle pagine inviati. Invece su GA4 è il browser che “conteggia” se la sessione è ancora attiva, inviando di tanto in tanto un evento “user_engagement“. Se lasciamo il browser o la app in background, questo evento non parte, quindi l’utente è “engaged” solo se sta davvero navigando attivamente il sito. In questo modo il tempo sul sito è più accurato di prima.
E’ bene familiarizzare il prima possibile con questi concetti, data la natura a volte profondamente diversa rispetto alla versione precedente del tool.
autore: Marco Ciliacategoria: generale the_tags('tag: '); ?>
Amici! E’ veramente tanto tempo che non ci sentiamo, e si lo so, è colpa mia 🙂
Oggi parliamo di una delle tante cose che ancora non hanno senso nel nuovo (fantasmagorico, secondo Google) Google Analytics 4: le valute!
Ora mi direte, che ci sarà mai da dire sulle valute? seguitemi, perché come sempre ripartiremo dall’inizio.
Gli albori
Agli albori la valuta su GA semplicemente non esisteva, era una mera etichetta che veniva aggiunta al valore monetario passato come numero, per le revenue di transazioni e prodotti. Passavi 100.000 YEN e 40 euro e avevi settato la valuta in EURO? avevi guadagnato – secondo GA – 100.040 Euro. In pratica, dovevi farti tu la conversione PRIMA di inviare il dato
Universal Analytics
L’avvento di un modello di dati più furbo e dell’Enhanced Ecommerce innalza il tool ad un livello migliore, dove finalmente anche un ecommerce internazionale può gestire la questione decentemente. Quindi, ogni valore monetario inviato viene accompagnato da una stringa di testo con la currency. Se la si omette, GA da per scontato che sia quella specificata nelle impostazioni della property.
Questo si riflette tra l’altro nella possibilità di fare report avendo fianco a fianco il valore della revenue nella valuta di default della property (diciamo EURO d’ora in poi per facilità) così come il valore in valuta locale e la currency inviata, usando le apposite dimensioni fornite dall’interfaccia (ad esempio “Local product revenue” o “Local revenue”).
Ancora, su BigQuery la currency viene esposta sia per gli items sia per le transacions, come si vede qui
GA Universal quindi fa due cose quando gli mandate una transazione in valuta locale:
salva la revenue in valuta locale e anche la currency
converte il valore nella valuta impostata nella property, usando il valore di exchange rate “ufficiale Google” del giorno precedente.
Quando guardate un report, fa la somma delle revenue e ve le mostra, as simple as that.
GA4
La faccenda si complica, e non poco, quando veniamo al nostro nuovo amico. Partiamo innanzitutto dalla documentazione, che trovate a questo indirizzo. Colpiscono subito i disclaimer gialli, che vi riporto qui.
Data is based on the exchange rate one day before the transaction, and is provided by financial exchanges. It may be delayed as specified by financial exchanges or our data providers. Google does not verify any data and disclaims any obligation to do so.
(e fin qui niente di strano)
Changes to the global currency type will affect future as well as historical data, and previous data will be converted to the newly configured currency.
(cambia il dato storico? ma come è possibile?)
Even if the currency setting for your property or view is set to match your local currency, Analytics performs a conversion at the moment of processing a hit for non-USD currencies and a fresh conversion on that figure each time a report is generated. This can lead to very small differences in your reports for your local currency due to fluctuations in the daily exchange rate.
WTF?!??!
In pratica ci sta dicendo che se modifichiamo la currency nelle impostazioni delle property, cambieranno anche i dati storici. Ma questo è possibile solo se lui avesse salvato i valori originali in qualche modo e li modificasse solo al momento del reporting. Il che, in effetti, è quel che fa: Google Analytics 4 salva SEMPRE i valori IN DOLLARI!
Tuttavia, sia nell’interfaccia sia nell’export BQ MANCA LA CURRENCY LOCALE, non viene proprio salvata.
GA4 quindi fa alcune cose in più quando gli mandate una transazione in valuta locale:
salva la revenue in valuta locale ma non salva la currency
converte il valore in USD, per tutti.
Quando guardate un report, prima riconverte gli USD nella valuta della property, poi fa la somma e ve la mostra. E questo già da solo basta affinché i report con Universal non tornino. Ma c’è dell’altro:
Se io prendessi le revenue dal primo gennaio a oggi in USD da BQ e le convertissi al tasso di cambio di ieri, otterrei un valore diverso dall’usare tutti i tassi di cambio giornalieri dal primo gennaio a ieri. Altro motivo di possibile discrepanza. E ovviamente non esiste una tabella con gli exchange rate storici “ufficiali Google”.
Inoltre, non avendo la currency locale salvata come etichetta, non posso fare un report degli incassi per ogni singola currency, a meno di non destinare un parametro evento all’uopo, il che mi sembra francamente ridicolo.
Di contro, magra consolazione, se oggi cambio la valuta della property da EUR a pesos messicani, GA4 non batterebbe ciglio e potrei rivedere anche le performance passate in pesos senza operazioni aggiuntive.
Ufficio complicazioni cose semplici, diremmo qui in Italia…
autore: Marco Ciliacategoria: tagmanager the_tags('tag: '); ?>
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.
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… :/