Sep 29 2022

HelpSemaforoQuesto semaforo indica il livello difficoltà del post
semaforo verde - articolo per tutti semaforo giallo - articolo avanzato semaforo rosso - articolo per esperti

Su GA4 posso di nuovo filtrare gli IP. come è possibile?

autore: Marco Cilia categoria: codice di monitoraggio

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=UA-4120792-1

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.

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? 🙂


Mar 18 2022

HelpSemaforoQuesto semaforo indica il livello difficoltà del post
semaforo verde - articolo per tutti semaforo giallo - articolo avanzato semaforo rosso - articolo per esperti

E così, GA Universal muore

autore: Marco Cilia categoria: generale

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.


Dec 31 2021

HelpSemaforoQuesto semaforo indica il livello difficoltà del post
semaforo verde - articolo per tutti semaforo giallo - articolo avanzato semaforo rosso - articolo per esperti

Capire le sessioni in GA4

autore: Marco Cilia categoria: report

[sintesi adattata tradotta del post https://www.bounteous.com/insights/2021/12/02/understanding-sessions-google-analytics-4/ ]

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.


Aug 27 2021

HelpSemaforoQuesto semaforo indica il livello difficoltà del post
semaforo verde - articolo per tutti semaforo giallo - articolo avanzato semaforo rosso - articolo per esperti

La gran confusione di GA4 con le valute

autore: Marco Cilia categoria: codice di monitoraggio

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:

  1. salva la revenue in valuta locale e anche la currency
  2. 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!

Se infatti guardiamo allo schema di export di BQ per GA4, troviamo queste colonne:

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:

  1. salva la revenue in valuta locale ma non salva la currency
  2. 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…


Dec 10 2020

HelpSemaforoQuesto semaforo indica il livello difficoltà del post
semaforo verde - articolo per tutti semaforo giallo - articolo avanzato semaforo rosso - articolo per esperti

GA4 è un po’ un TagManager

autore: Marco Cilia categoria: codice di monitoraggio

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… :/


Nov 24 2020

HelpSemaforoQuesto semaforo indica il livello difficoltà del post
semaforo verde - articolo per tutti semaforo giallo - articolo avanzato semaforo rosso - articolo per esperti

GA4 può segmentare il real-time

autore: Marco Cilia categoria: codice di monitoraggio

Tra le poche cose buone E FUNZIONANTI che ci sono in GA v4, questa non l’avevo ancora notata: a differenza di Universal è possibile segmentare il report real-time con dimensioni diverse da quelle del report stesso; ovvero, con dei veri e propri segmenti, e non con dei semplici filtri. Guardate qua:

Sebbene un po’ fuorviante, per segmentare il real-time dovrete agire sul pulsante “aggiungi confronto”. Resta invariato invece il limite di segmenti utilizzabili contemporaneamente, quindi 4.


Oct 14 2020

HelpSemaforoQuesto semaforo indica il livello difficoltà del post
semaforo verde - articolo per tutti semaforo giallo - articolo avanzato semaforo rosso - articolo per esperti

Google Analytics 4

autore: Marco Cilia categoria: codice di monitoraggio

Ottobre è il mese prediletto per lanciare nuove versioni di Google Analytics. Se non ricordo male infatti anche Universal analytics arrivò in questo mese, si vede che è di ispirazione per gli ingegneri 🙂

Se ho ben capito cosa intendono con questo naming, direi che:

  • Urchin.js è considerata la versione 1
  • il tracking asyncrono nelle sue varie forme è la versione 2
  • Universal Analytics è la 3
  • App+Web, espanso e rinominato, è appunto la versione 4

Iniziamo subito col dire che al momento non è chiaro – ma probabilmente è un “grosso NO” – se sarà possibile migrare i dati pregressi. La guida dice infatti di creare una nuova property per migrare a GAv4, e la cosa è sospetta nella misura in cui non si tratta di una vera e propria migrazione come siamo stati abituati sino ad ora: cambio il codice e via. Il problema, da quel poco che ne ho capito sinora, è che la struttura dei dati sottostanti (il database in cui sono memorizzati, per facilitare il concetto) è molto diversa da quella attuale, al punto da non rendere immediata o addirittura impossibile la coesistenza delle due cose.

Se così fosse ci troveremmo di fronte a un problema, ma anche a qualcosa di grosso: se gli ingegneri davvero arrivano a dire che bisogna “buttare via tutto”, o che comunque si può fare ma è meglio di no, allora significa che le potenzialità del nuovo strumento sono innumerevoli e molto ampie, e che ci credono tantissimo. E’ l’unica spiegazione che riesco a darmi.

Se ne volete un esempio, vi riporto questa parte di questa pagina dell’help sulla migrazione ecommerce a v4 (grassetto mio. tra parentesi, guardate quanto è lunga quella pagina, tanto per dire…):

If you are upgrading from a Universal Analytics property, you should leave your Universal Analytics implementation unchanged. Create duplicate events for your Google Analytics 4 property with updated names that are aligned with the new Google Analytics schema. You will have two independent implementations side by side, each doing slightly different things.

While it’s possible to use your existing Universal Analytics implementation for your Google Analytics 4 property, this is not advised.

Ma cosa avrà di nuovo questa versione 4?
L’interfaccia, sicuramente. Ancorché immatura, per usare un eufemismo, i report di App+web sono notevolmente diversi da quelli classici, lo sapete. Qui la cosa sarà accentuata ancora, man mano che saranno aggiunte nuove funzionalità.
Capacità predittive: stando a quanto si legge in giro, il sistema sarà in grado di fare previsioni, ad esempio di proiettare le revenue future o i churn. Machine learning everywhere, baby! 🙂
Integrazione migliorata con Google Ads e Youtube
Google Signals ovunque, approccio user-centrico (di nuovo, ma non era Universal quello user-centrico? 😉 ) e capacità di riempire i buchi che si formano a causa delle politiche sempre più restrittive dei browser. Questo un po’ mi spaventa, perché sinora nessuno aveva mai osato fare una cosa del genere: speriamo sia un processo un po’ più furbo di quel tipo che una volta mi disse “abbiamo 3 giorni di buco, mettiamo noi dei numeri a mano?” 🙂
Creazione di eventi dall’interfaccia: questa è interessante, se state collezionando eventi e vi accorgete che qualcuno sta sbagliando una nomenclatura, potete istruire l’interfaccia a correggere ed aggregare meglio i dati.
Consent mode, abbiamo iniziato a vederlo in giro (se come me navigate sempre con la console aperta e guardate il mondo “codificato”, come in Matrix 😀 ) ma sulla v4 sarà uno standard: la capacità di interagire direttamente con le preferenze di privacy degli utenti e di lasciare “appesi” i tracking fino a che l’utente non effettua una scelta.

Come al solito, chi vivrà vedrà. Perché di una cosa sono sicuro e ve l’ho già detta: stavolta non si tratta solo di cambiare il codice e attivare dei report nuovi. Stavolta è tutto nuovo, praticamente da rifare da zero. E’ una grossa opportunità per molti di ricominciare col piede giusto, e costringerà altri a fare scelte dolorose, a meno che non mi stia sbagliando di grosso e domani esca il pulsantone “premi e dimentica” 😀 Ma come tutte le grandi opportunità e le grandi sfide, la vinceremo con la solita caparbietà e un po’ di pazienza. E ora andate, e create tracking paralleli! 😛


Oct 11 2020

HelpSemaforoQuesto semaforo indica il livello difficoltà del post
semaforo verde - articolo per tutti semaforo giallo - articolo avanzato semaforo rosso - articolo per esperti

Avete visto la nuova cronologia modifiche?

autore: Marco Cilia categoria: codice di monitoraggio

Se lavorate in azienda e magari siete gli unici a poter fare modifiche all’account Google Analytics che gestite, o in generale ne avete pochi e con poche persone che ci mettono mano, la cronologia modifiche è forse uno dei posti che controllate di meno in assoluto durante il vostro lavoro.

Ma se lavorate in una grande azienda, o peggio ancora in agenzia, sapete bene che la quantità di account moltiplicata per la quantità di persone che vi hanno accesso rendono il fatto di dover risalire a qualche momento nel passato per sapere chi ha fatto cosa una mera questione di tempo: prima o poi lo dovrete fare, e spesso lo dovrete fare con l’intento di dimostrare qualcosa, nel bene o nel male.

Quindi da parecchi anni esiste la cronologia modifiche dell’account GA, che però ha sempre avuto parecchie limitazioni, una su tutte una barra di ricerca davvero inutile che spesso costringeva a rileggersi tutto lo storico in cerca di fatti interessanti. Ebbene, l’altro giorno mi ci sono affacciato per risolvere una questione e l’ho trovata completamente rifatta, in meglio per fortuna.

Oltre alla possibilità di limitare temporalmente gli eventi mostrati, ora possiamo anche limitarli per PROPERTY. Comodissimo se la modifica che cerchiamo sappiamo stare in una property di un account con decine di esse.

Inoltre, con la ricerca avanzata vi sono ora tre filtri molto comodi per limitare ulteriormente la ricerca:

  • Tipo di “prodotto”
  • Tipo di azione
  • utente che ha fatto la modifica
parte della finestra per limitare il tipo di “prodotto”

In pochi clic ho trovato quel che cercavo, e sono stato contento che il team abbia introdotto questa novità. A volte aver dovuto rileggere tutta la cronologia è stato davvero frustrante, su account molto grandi.

[edit 13 ottobre: talmente abituato ad accedervi dalla colonna “account” non mi ero accorto che ora – giustamente – hanno introdotto anche la cronologia ristretta alla sola property. bravi!


Aug 26 2020

HelpSemaforoQuesto semaforo indica il livello difficoltà del post
semaforo verde - articolo per tutti semaforo giallo - articolo avanzato semaforo rosso - articolo per esperti

GTM serverside e Optimize JS API

autore: Marco Cilia categoria: codice di monitoraggio

Durante questa estate 2020 il team di Google ha lanciato due novità importanti nel mondo dei nostri tool “di corredo” per Google Analytics.

La prima è il Tag Manager server-side: si tratta di una installazione del Tag Manager che risiede su un server in cloud, al momento solo su infrastruttura Google Cloud, e che viene triggerato tramite chiamate HTTP. In pratica il GTM non verrà più “caricato” sul sito, dove chiamate javascript fanno scattare i tag sulla base di regole impostate, bensì resterà nel cloud e il sito dovrà inviare richieste HTTP ad esso, che svolgerà il resto del lavoro (controllare la validità della richiesta, controllare che ci siano regole che soddisfano la richiesta, controllare se ci sono tag da inviare su quelle regole) nel cloud di Google. Come dice Simo Ahava nel suo post enciclopedico, è una specie di proxy, con alcuni indiscutibili vantaggi. Tutto può essere validato, e tutto può essere controllato. Simo dice che potenzialmente si potrà creare una infrastruttura di tagging senza caricare un solo codice di terze parti. L’altro lato della medaglia è però – ovviamente – che non si tratta di qualcosa alla portata di tutti, che avrà un costo (essendo basata sul cloud Google) e che probabilmente servirà un po’ di supporto da parte dei vendor per costruire i tag server side. Se infatti tutti noi sappiamo A MEMORIA tutti i parametri delle chiamate GET verso /collect – VERO? 😀 – per alcuni tag non c’è proprio documentazione, e sarebbe difficile replicarli o tenerli aggiornati.

La seconda novità è l’introduzione da parte di Optimize di una API javascript per integrarsi con tool di terze parti. La prima integrazione è con HotJar, famoso sistema di heatmapping e session recording, e consente di “bollare” su HotJar coloro che fanno parte di un test, in modo da poterli filtrare poi in piattaforma e analizzarli separatamente.


May 01 2020

HelpSemaforoQuesto semaforo indica il livello difficoltà del post
semaforo verde - articolo per tutti semaforo giallo - articolo avanzato semaforo rosso - articolo per esperti

Google Optimize ottiene dignità con un suo file di installazione

autore: Marco Cilia categoria: codice di monitoraggio

Google Optimize, lo strumento di Google per effettuare A/B test, multivariati e personalizzazioni, ha da poco introdotto la possibilità di richiamare il proprio codice tramite file dedicato, così che non venga più trattato come un “semplice” plugin di Google Analytics.

Fino ad oggi infatti l’installazione di Optimize era una delle operazioni più esoteriche misteriose dell’intero panorama degli strumenti Google: hai il GTM o no? GA è in pagina o no? devi usare o no lo snippet di codice detto “anti-flicker”? sei sicuro che la configurazione dell’oggetto GA che usa il plugin di Optimize sia coerente con quella del tracker di GA? e se usi GTM, nello snippet dell’anti-flicker il riferimento deve essere al codice GTM o no? (perché qualche genio ha scritto “Replace CONTAINER_ID with your Optimize container ID. If you’re using Google Tag Manager to deploy Optimize, replace CONTAINER_ID with your Tag Manager container ID.” ed entrambi hanno un ID del tipo GTM-xxxxx (ma come si fa? :O )

In ogni caso, la pagina con le istruzioni per l’installazione del codice è stata modificata, e ora le opzioni disponibili sono essenzialmente due:

  1. usare il file optimize.js
  2. usare GTM

Nel primo caso sarà sufficiente richiamare nel tag HEAD delle pagine lo script

<script src="https://www.googleoptimize.com/optimize.js?id=OPT_CONTAINER_ID"></script>

oppure l’equivalente versine asincrona semplicemente aggiungendo “async” dopo “script”. Il vantaggio dello snippet sincrono è che di fatto blocca il caricamento della pagina finché non è pronto, piazzandolo in alto ci si assicura che Optimize sia già pronto per modificare la pagina quando essa viene caricata. In teoria questo dovrebbe anche rendere superfluo l’uso dell’anti-flicker, ma se volete installarlo ugualmente allora esso va messo prima del codice, come sempre. Ovviamente, il resto delle raccomandazioni resta valido: il dataLayer deve essere inizializzato PRIMA dello snippet di Optimize, ed eventuali librerie javascript che dovremo usare nel test devono essere chiamate prima dello snippet di Optimize.

Questo modo di installare Optimize mi sembra sicuramente più pulito e comprensibile, si slega dall’installazione di GA e indubbiamente rende più fruibile il prodotto.