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: real-time

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: generale

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: esperimenti

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: esperimenti

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.


Jan 28 2020

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

Il costo di un errore

autore: Marco Cilia categoria: web analytics

L’altro giorno riflettevo sul costo che ha nell’economia di un progetto DATA affrontare e gestire un errore, un problema che inficia i dati.

A Febbraio 2018 un cliente ha avuto un problema di spam nei dati di GA, una cosa seria e non trascurabile che si è trascinata per alcuni giorni. I dati di quei giorni sono completamente sballati, inutilizzabili. A fatica si è trovato un segmento per ripulirli, si è applicato e non ci si è più pensato per un po’. Ma esattamente per quanto?

Per poco, purtroppo.
Ad Aprile 2018 il report del Q1 2018 era inservibile. Rifallo applicando il segmento, evita che campioni, spendici tempo.

A Gennaio 2019 il report annuale del 2018 era sballato. Applica il segmento e tieni conto dell’anomalia di Febbraio

Ad Aprile 2019 il report del Q1 2019 era perfetto, ma la comparazione con l’anno prima dava solo valori negativi. Applica il segmento e rifai le variazioni percentuali

A Gennaio 2020 il confronto temporale del 2019 con l’intero 2018 è vittima di un problema. Insomma avete capito.

Per un problema di alcuni giorni di FEBBRAIO 2018, ancora oggi – per l’ultima volta – a distanza di quasi due anni dobbiamo ricordarci che è accaduto, come si chiama il segmento, di avvisare chi mette mano ai dati, eccetera…

E’ per questo che dico sempre “prevenire è meglio che curare”, e che sono un fissato dei controlli automatizzati 🙂


Dec 03 2019

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

_setAllowAnchor è morto

autore: Marco Cilia categoria: codice di monitoraggio

Se mai è stato vivo, ovviamente. Vi parlai di _setAllowAnchor dieci anni fa ( !!! ) , era una funzione che serviva a dire a Google Analytics di guardare anche dopo il cancelletto, negli URL, in cerca dei parametri UTM utili a tracciare una campagna.

In effetti, nelle ultime versioni degli script di tracciamento non se n’è mai fatta menzione, sembrava sparita. E infatti la raccomandazione per tutti era “i parametri UTM devono stare prima del cancelletto. Correggete quell’URL della campagna!”. Se non che ultimamente capita che troviamo nei report delle pagine degli indirizzi con #utm_source=eccetera… ma andando a controllare sorgente e mezzo non troviamo referral o direct, come ci aspettiamo, bensì i valori corretti, uguali a quanto scritto nei parametri.

La risposta più ovvia, la prima, è che allora i parametri sono stati duplicati: c’erano gli utm giusti, poi il cancelletto e poi gli utm ripetuti. Quelli giusti vengono “strippati via” dal motore di Analisi di GA come sempre, gli altri invece ce li ritroviamo nei report.

Però perché non indagare anche l’altra ipotesi? pronti via, compongo un URL senza parametri dopo il punto di domanda, ma solo con utm dopo il cancelletto, lo visito e voilà: il report real time prima, e i report di acquisizione dopo, mi mostrano i miei UTM di test belli a posto come se niente fosse.

Quindi la buona notizia è che Google Analytics ha iniziato – non saprei proprio dire da quando però – a gestire correttamente i parametri di campagna anche quando sono posizionati dopo il cancelletto, cosa che invece prima era il male assoluto! 🙂

Semplificare, sempre semplificare la vita all’analista!


Nov 12 2019

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

10 minuti di terrore estremo

autore: Marco Cilia categoria: generale

Ieri, per forse la seconda volta da che ne ho memoria (e saranno quindi 14 anni tra due giorni), Google Analytics non ha funzionato per 10 minuti. Non i soliti errori di caricamento dati, restituiva proprio errore 500 il server. Era bombato.

Confesso che lì per lì non mi sono allarmato troppo, salvo poi passare su GTM e vedere che era giù tutto anche lì. Il mio collega Mirco nel mentre accede a BigQuery e troviamo un errore anche lì. E allora panico! la cosa deve essere grave.

Mi è tornato in mente un vecchio video divertente sulle conseguenze dell’internet down in un ufficio – che ora non ritrovo – ma confesso che mi sono sentito così. Certo, avevo altre cose da fare nel frattempo, ma sentivo che mi mancasse qualcosa, la certezza granitica dell’interfaccia di GA.

Ogni tanto è bene ricordarsi che tutti sbagliano, anche Google 🙂


Oct 30 2019

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

Eliminare dati personali da GA

autore: Marco Cilia categoria: codice di monitoraggio

Da qualche settimana è presente nel pannello di amministrazione una nuova voce nella colonna delle property: si chiama Richieste di eliminazione dati.

Fino ad oggi l’unico modo conosciuto per eliminare dati da Google Analytics era quello di cancellare un clientID o uno userID, tramite interfaccia o API. Ve ne avevo parlato tempo fa
Ovviamente se per errore avete registrato – ad esempio – indirizzi email nell’URL delle pagine quel metodo non era molto efficace. Provate un po’ voi a ricavare tutti i clientID interessati (ammesso che li abbiate salvati in una custom dimension – del giusto scope – perché di default il clientID non è una dimensione disponibile). E’ impossibile lo so…

Quindi alla domanda dei clienti “che succede se ci accorgiamo di un problema del genere?” la risposta è sempre stata “prevenite, prevenite, prevenite. Se ve ne accorgete, correggete e sperate che il problema non sia troppo esteso e nessuno se ne accorga. Se il problema è grave, sappiate che Google per tutelarsi ha il diritto di cancellarvi l’account“.

Ma tramite la nuova funzione (Amministrazione -> Property -> Richieste di eliminazione dati (Data Deletion Requests se avete l’interfaccia inglese)) invece noi possiamo creare delle “richieste d’incidente” nelle quali indicheremo il periodo temporale interessato e l’elemento che andrà cancellato, tra quelli che sono papabili di aver registrato informazioni personali. Favorisco uno screenshot:

a queste voci vanno aggiunte anche “URL” e “Tutti”

Attenzione che le richieste sono sempre espresse in Tempo Coordinato Universale, per noi in Italia quindi -1 o -2 a seconda dell’ora legale.
Non si tratta però di una cancellazione selettiva, cioè se avete registrato email nell’URL non verranno cancellate solo le URL problematiche, bensì TUTTE le URL che fanno parte del periodo indicato. E’ un po’ drastico, ma sempre meglio della cancellazione di tutto l’account, no? 🙂


Oct 01 2019

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

Perché non vi ho ancora parlato di app+web

autore: Marco Cilia categoria: codice di monitoraggio

App+web è l’ultima, ennesima, incarnazione di Google Analytics, la “next big revolution” dopo l’avvento di Universal Analytics nel 2012.

Una property di tipo app+web consentirà, con un solo codice di monitoraggio, di tracciare siti web e applicazioni per cellulari (e anche tutte le vie di mezzo, come quelle orrende app che poi sono solo delle cornici su pagine mobili) in un unico posto, e di beneficiare quindi di un reporting unificato e di un tracciamento dell’utente univoco basato su USERID vostro oppure – udite udite – del device graph di Google.

Se ci uniamo anche che il tutto sarà basato su Firebase e che quindi sarà facilissimo, ancorché da vedere se gratuito come ora, esportare tutto su Google BigQuery otteniamo una miscela esplosiva e materiale per tonnellate di post, no? E allora perché non ho scritto niente?

Tralasciando i problemi di tempo, in realtà qualche sprazzo ce l’avrei anche avuto, ma il fatto è che sto invecchiando e ho ormai una certa esperienza di come vanno le cose in Google e dintorni. Questa cosa sarà un’incredibile rivoluzione? poco ma sicuro! potete giurarci! Si ma quando? ecco, sicuramente non domani. E probabilmente nemmeno l’anno prossimo. Perché? perché la cosa è stata buttata fuori quasi in sordina, a inizio agosto quasi come a dire “vediamo un po’ chi se ne accorge”… perché app+web è al momento molto limitato, e tanto per dirne una non ci sono tutte le funzioni di Enhanced Ecommerce.
Oppure ve ne dico un’altra: non ci sono le sessioni 😀 C’è un evento di tipo session_start, ma il reporting è completamente basato sugli utenti. Non potete nemmeno creare l’equivalente del report sorgente/mezzo! Potete creare un custom report che ci assomiglia vagamente, ma scordatevi il report come lo conoscete adesso.

Poi, indubbiamente, ci saranno anche dei grossi vantaggi: oltre a BigQuery di cui ho già detto, le nuove property avranno l’Analysis, una feature che permette di creare custom report molto più completi di adesso, con drag&drop e molti stili e personalizzazioni e che adesso è presente solo nei Google Analytics 360, però ecco, sembra un po’ tutto buttato lì. “ecco un assaggio di cosa faremo, diteci cosa ne pensate” sembra riecheggiare dal retro dell’interfaccia di GA: ci manca solo che sbuchi un sondaggione fatto con Google Surveys 😀

Quindi vi dico in estrema onestà: questa cosa cambierà per sempre il nostro modo di guardare Analytics, ma lo farà tra un po’ di tempo e capiremo insieme con quanto trauma. Quindi aprite una property app+web subito, installate il codice e cominciate a giocarci come sempre facciamo quando dobbiamo studiare una novità, ma questa roba non la vedremo in produzione per mooooolto tempo, ho idea…

Commenti?

[update 11 ottobre]:
meno male che qualcuno più famoso e serio di me dice le stesse identiche cose, almeno mi consolo di non essere poi così malandato 😀