Google Analytics in 30 secondi

Quando vi ho parlato del Google Tag Manager ho volontariamente omesso un particolare sul suo funzionamento: l’ho fatto per non appesantire troppo il post, che conteneva già abbastanza concetti nuovi e che non volevo risultasse troppo ostico da digerire 🙂

Il concetto che ho omesso è quello del datalayer, cioè di un livello di astrazione dei dati passabili al GTM: pensiamo al datalayer come a un baule che contiene tutti – o quasi tutti – i dati possibili e immaginabili che ci potrebbero servire: li contiene sempre, anche quando in realtà non ci servono, ed è presente in ogni pagina; naturalmente i dati sono generati dinamicamente, non è importante come anche perché dipende da molti fattori, l’importante è sapere che esso ci potrebbe essere.

Un semplice datalayer di esempio per il Google Tag Manager potrebbe essere fatto così:

<script>
  dataLayer = [{
    'pageCategory': 'signup',
    'visitorType': 'high-value'
  }];
</script>

questo baule contiene la categoria della pagina e il tipo del visitatore, e abbiamo detto che è sempre presente in tutte le pagine, anche se con valori differenti. Lo stesso datalayer per un’altra pagina potrebbe avere pageCategory: news, lo stesso datalayer per un altro utente potrebbe avere visitorType: non-customer.

Il Tag Manager attraverso una macro può facilmente estrarre uno di questi valori, è una funzione già presente nell’interfaccia:

e una volta estratta la può utilizzare all’interno dei tag presenti nel container.

Non solo, attraverso una apposita funzione, dataLayer.push({‘Data Layer Variable Name’: ‘value’}) si possono aggiungere al volo variabili che non erano previste in partenza, o sovrascriverne altre che invece c’erano.

A questo punto dovrebbe essere chiaro perché un dataLayer può fare la differenza in un progetto di analisi web: vi è mai capitato di dover implementare qualcosa su Google Analytics che richiedesse una modifica del codice? se si, forse avete dovuto passare per la fase “devo spiegare a chi gestisce il sito cosa fare, dove farlo, come farlo”, che poi è il motivo per cui esiste il GTM. Ecco, tanto quanto l’implementazione dei codici è facilitata dall’inserimento di un solo container del Tag Manager, una buona pianificazione del dataLayer e delle chiamate permette allo sviluppatore di lavorare una volta sola, e a noi di avere sempre a disposizione tutte le informazioni utili al nostro piano di tracciamento del progetto.

Tanto per farvi un’idea, vi mostro un esempio un po’ più complesso (ma secondo me ancora incompleto di come vedrei io un dataLayer) fatto da Justin Cutroni qualche mese fa:

var dataLayer = {
"pageTitle" : "Receipt Page",
"pageURL" : "/pages/checkout/receipt",
"pageCat" : "Checkout Pages",
"PageCat2" : "",
"tranID" : "17658726382",
"tranTotal" : "34.95",
"tranTax" : "0.00",
"tranShipping" : "0.00",
"tranShippingMethod" : "USPS",
"tranCurrency" : "USD",
"tranProds" : "249|398",
"tranSKUs" : "249-32|398-12",
"tranProdNames" : "Kids Onsie|Kids Lava Lamp",
"tranCategories" : "Kids|Kids",
"tranPayMethod" : "VISA",
"visitorType" : "RETURN",
"visitorState" : "Logged In",
"visitorFirstPurchDate" : "20111205",
"visitorFirstProds" : "822"
}

La sintassi non è quella del Google Tag Manager, il post è di Maggio, ma siccome Justin lavorava già per Google, col senno di poi quel post che allora mi sembrava solo una buona idea lungimirante si rivela per quel che è: una comunicazione di intenti per un prodotto in fase di sviluppo 🙂

[edit: L’editor s’è mangiato un pezzo del post. Un dataLayer in realtà è un altro concetto che è trasversale al Tag Management; fatto così al momento funziona solo sul GTM, ma io penso che Google abbia la forza e il dovere di provare a creare uno standard per il datalayer, in modo che possa essere più facile in futuro cambiare soluzione di Tag Management senza dover rifare questa parte di implementazione.]

Sono stato due giorni allo IAB, e ho incontrato molte persone.
C’è stato un attimo, come una folgorazione, in cui per la prima volta in tanti anni ho davvero percepito a pieno cosa ho costruito in questi 4 anni e mezzo con il blog e l’attività che ne è derivata. Era una cosa che, potete anche ridere, non avevo mai realizzato, non con questa portata.

Ho visto amici, clienti ed ex-clienti. Ho visto persone che lavorano per grandissime realtà parlarmi dei loro fornitori, e realizzare che ho contribuito a formarli con i miei corsi. Ho sentito parlare di persone che conoscevo benissimo perché le ho aiutate nei commenti o via email. Conosco molte realtà medie e piccole, perché ci lavorano persone che stimo e anche amici. Sono stato salutato da persone che non avevo mai visto, ma che invece mi conoscevano benissimo per via di quel che scrivo. E ho visto persone guardare il cartellino con il nome e non capire chi fossi, ma illuminarsi alla pronuncia di “goanalytics.info” 🙂

Insomma, la mia rete di relazioni è molto più grande di quanto immaginassi, e la cosa mi ha stupito e reso felice: per questo, una volta tanto, sono io che ringrazio voi! 🙂

(e il blog non è morto, state tranquilli. Ho in mentre almeno tre post da scrivere)

Fino ad oggi esisteva un unico flusso in uscita da Google verso altri prodotti Google: l’uso dei dati “reali” al posto di quelli stimati all’interno di DoubleCick For Publishers. Se il proprietario dell’account aveva deciso di condividere i dati con altri prodotti Google – tramite l’apposita opzione nell’amministrazione dell’account – i dati in DFP erano più precisi di quelli stimati da Google.

Oggi il blog ufficiale ci informa che presto esisterà un altro prodotto Google che beneficerà dei dati provenienti da Google Analytics, e questo prodotto è AdWords. Praticamente il link che adesso è univoco ADW->GA diventerà biunivoco ADW<->GA. Il motivo è poter beneficiare di dati che tipicamente sono dentro al prodotto di analytics, come bounce rate delle campagne, tempo medio, pagine per visita, eccetera, direttamente da dentro all’interfaccia verde di AdWords.

Questo sempre nell’ottica di riuscire a tirare fuori insights più interessanti con meno passaggi. In questo caso non direttamente da dentro ad Analytics, ma questo è un vantaggio che tutti quelli che gestiscono campagne apprezzeranno…

Sono anni che parliamo della Business Platform, e Google ultimamente ci ha dimostrato chiaramente che anche se non la chiama così, sta puntando a quello. E che Business Platform sarebbe, se non avesse come complemento un tag manager?
Ecco, durante l’Emetrics di Boston Google ha appena annunciato il rilascio del suo tag manager, chiamato con molta fantasia “Google Tag Manager“, un prodotto dedicato a tutti coloro che hanno necessità di implementare sui propri progetti tag di marketing e misurazione. Insieme allo strumento viene anche lanciata una rete di partner qualificati, e sono piuttosto orgoglioso di poter affermare che Intarget fa parte di quella rete. Sul blog aziendale trovate anche alcune considerazioni in ottica business su quanto questa novità del tag manager sia importante in un moderno progetto digital.

Un tag manager, per chi non lo sapesse, è uno strumento che consente di astrarre di un livello la messa in produzione e la modifica dei tag sul proprio sito. Invece di operare direttamente sulle pagine o sui template che le generano, si applica un unico tag a inizio progetto e il resto delle modifiche viene completamente gestito attraverso un’interfaccia web. Non è una idea nuova, di tag manager in giro ce ne sono parecchi da anni, ma l’approccio Google a qualsiasi cosa riserva sempre qualche sorpresa…

Il primo concetto con cui familiarizzare è l’account, che ricalca esattamente quello che noi conosciamo per Google Analytics: un account può contenere diversi progetti, per cui è assolutamente necessario che sia l’account del proprietario del sito a generare il tag contenitore necessario; esattamente come in Google Analytics poi sarà possibile aggiungere utenti, con due livelli di accesso all’account, e quattro livelli al singolo contenitore.

Il secondo concetto è quello di contenitore, cioè del tag fisico che andrà poi inserito sulle pagine del progetto: un contenitore si presenta come un blocco di codice – iframe e javascript sostanzialmente – con un identificativo univoco. Una volta inserito quello nel sito, si potranno effettuare le necessarie modifiche agendo sull’interfaccia web del tag manager.

All’interno di un contenitore si possono poi definire i tag: i tag sono quei pezzetti di codice che fino ad ora siamo stati abituati ad incollare nei template delle pagine dei siti, sotto forma di javascript, html o di pixel tracking. Il Google Tag Manager ha già alcuni template predefiniti – ed altri immagino verranno aggiunti prossimamente, che facilitano molto l’inserimento. Per aggiungere un tag di base di Google Analytics, senza alcuna personalizzazione, basterà selezionare il modello appropriato e incollare il numero UA-xxxxxx-y. Altri modelli predefiniti sono il codice delle conversioni di AdWords, il remarketing o il DoubleClick Floodlight. In ogni caso è sempre possibile definire un tag incollando il codice necessario nell’interfaccia invece che sul sorgente delle pagine.

I tag vengono eseguiti basandosi su delle regole: esse servono a dire al Tag Manager quando eseguire un tag piuttosto che un altro, e sono del tipo “tutte le pagine”, “tutte le pagine tranne…”, “l’url della pagina contiene xyz”, “viene scatenato un certo evento”, “il referrer è…”, ed altre ancora… Esiste in realtà una regola più generale che si può usare per generare qualsiasi regola, ed è: “macro soddisfa condizione”. A questo punto la domanda che sorge spontanea è cosa sia una macro 🙂

Una macro, nel tag manager, è un identificatore di un qualcosa, che servirà poi per definire una regola. Questo qualcosa può essere una variabile javascript, una stringa, un oggetto del DOM, un evento, un referrer, un url e una serie di altre cose.
Combinando insieme macro e regole si sarà in grado di identificare puntualmente le condizioni sulla base delle quali scatenare un tag piuttosto che un altro, anche in modo molto complesso: arrivo sulla pagina x dal referrer y, e se una certa variabile javascript ha un determinato valore, estraggo dal DOM una stringa e la passo al tag manager che la scrive nel tag di remarketing di AdWords.

Tutto questo lavoro non è semplice, ovviamente, e poiché il grado di complicazione è elevato, il Google Tag Manager ha al suo interno una funzione bellissima: il versioning dei tag. Questo è utilissimo perché in caso di problemi con un solo click si può tornare indietro di una o più versioni, ripristinando tutti i tag all’ultima situazione sicuramente funzionante, ma non solo… il versioning funziona anche per le versioni non ancora messe in produzione: se si fanno delle modifiche si può creare una nuova versione del contenitore e pubblicarla in una “sandbox”, cioè funzionante soltanto sui browser abilitati da chi ha creato la versione. Questo permette di conoscere in modo visuale, attraverso una consolle nel browser, se la nuova configurazione funziona man mano che si visita il sito live. Se tutto è corretto, si potrà procedere alla pubblicazione vera e propria.

I vantaggi del Google Tag Manager sono piuttosto evidenti, una volta compreso cosa è e come funziona, ma ve li elenco ugualmente:
– velocità di implementazione, modifica e rimozione
– gestione centralizzata
– minori o assenti richieste al reparto IT
– possibilità di avere preview sul funzionamento di tag non ancora in produzione
– rollback immediati

Questo è un altro grande passo nella direzione della piattaforma di marketing a 360° che desideriamo da tanto: qui non si tratta di nuove funzionalità di un prodotto o di un altro, di evoluzioni o di unificazioni di prodotti già esistenti. Qui si sta parlando di un nuovo prodotto che racchiude tutti gli altri, che facilita molto le operazioni alle agenzie, scarica i clienti da alcune attività e quasi azzera il lavoro di reparti IT e web developer. Come si può dire di no a tutto questo? 🙂
Voi cosa ne pensate?

[qui c’è un post di Daniel Waiseberg con alcuni screenshot]

Mi sono perso una discussione su Twitter in cui cinic afferma che Analytics è inferiore ad altri strumenti di monitoraggio delle prestazioni del sito. Rimedio con un post sul blog, tanto in 140 caratteri non ci starebbe 🙂

Quando parliamo di strumenti per il monitoraggio delle prestazioni del sito, ci riferiamo di solito a siti o software che interrogano le vostre pagine e vi fanno un resoconto di quanto ci mette ogni singolo elemento ad essere caricato: alcuni esempi di queste applicazioni sono Yslow, GTmetrix, Google Pagespeed online, Pingdom. Qualsiasi browser moderno ha integrato uno strumento simile, più o meno evoluto.

Google Analytics, come dovreste sapere, ha da qualche tempo introdotto dei report relativi alla velocità del sito, ne ho parlato qualche tempo addietro.

Ora, la prima domanda da porsi è sicuramente questa: “cosa voglio ottenere?” e la seconda è altrettanto indubbiamente “come faccio a ottenerlo?“. Per quanto riguarda il cosa, la risposta è invariabilmente “voglio ottenere un miglioramento dei tempi di caricamento delle pagine”. Per capire cosa cambiare, tutti gli strumenti che ho elencato prima vanno bene. Il livello di dettaglio cambia, ma le indicazioni sono sempre valide: minificare tutto, comprimere le immagini, aggiungere una CDN, javascript asincroni, eccetera…

Questo risponde in parte anche alla seconda domanda, come ottenere il risultato: questi strumenti ti consentono di verificare ogni singolo elemento di una tua pagina, una pagina alla volta, e di correggere i problemi.
Il problema è uno solo, tuttavia: questi strumenti funzionano su un server – tipicamente con una linea veloce – o sul TUO brower, con la TUA connessione.

Google Analytics invece registra i tempi di caricamento di tutte le pagine oggetto del campione, sui browser dei tuoi utenti, con le linee dei tuoi utenti. Questo gli permette di darti dei report che sono esattamente il risultato di quel che succede nei browser delle persone che dovrebbero starti più a cuore: i tuoi clienti. E non il server di GTmetrix 🙂

Posso anche ottimizzare completamente la mia homepage, sul mio browser e con la mia ADSL. Posso anche essere scrupoloso e recuperare il mio 56k dall’armadio e rifare il processo. Ma se il 43% dei miei utenti si collega dall’Egitto, o se il 61% degli utenti che arrivano da un certo referrer ha un determinato routing lento questa settimana, le mie ottimizzazioni per assurdo potrebbero anche essere inutili. Le considerazioni che mi porta a fare Google Analytics quando guardo i report sulla velocità del sito non hanno quasi mai a che fare con gli elementi delle mie pagine, o con il mio server. Hanno quasi sempre a che fare con i SEGMENTI di traffico che analizzo, per i quali lo strumento mi indica tempi di caricamento differenti. Segmentare in base a una o più dimensioni è un’altra cosa che gli strumenti classici non fanno, sempre perché analizzano una pagina alla volta da una sola location alla volta.

In sostanza, Google Analytics non è GTmetrix perché gli è complementare. GA mi dice se e dove c’è un problema, GTmetrix – o chi per esso – mi consente di risolvere parte di esso. Google Analytics usa i dati reali dei tuoi utenti per dirti se e dove hanno un problema, GTmetrix si astrae e si concentra sull’unico problema che può risolvere.

Sebbene sia un caso un po’ di nicchia, potrebbe esservi capitato di avere due domini o sottodomini tracciati con lo stesso codice, quindi di avere almeno due profili filtrati sulla base del nome host, in cui uno di essi usa il tracking dell’ecommerce; vi sarete sicuramente accorti che le transazioni finiscono in entrambi i report, che non sono filtrabili. Più in generale, i dati dell’ecommerce non venivano mai legati ai dati di livello pagina (altra cosa che non si poteva fare era un filtro del tipo “escludi le transazioni provenienti dalla pagina x”).

Nel prossimo futuro invece questa situazione verrà risolta, ed inoltre verrà esteso il supporto all’utilizzo delle variabili personalizzate nei dati di ecommerce.

Se leggeste tutti i messaggi, mail, forum e gruppi che leggo io su Analytics (o quantomeno se leggeste gli stessi che leggo io) sapreste benissimo che il mondo delle API che ad alcuni sembra una cosa oscura e “di nicchia” è vivo e vegeto e migliaia di persone creano applicazioni utili attraverso di esse. Non solo, esse vorrebbero di più, e continuamente si lamentano che nelle API non c’è questa metrica, vorrebbero questa dimensione, non si può incrociare quei dati.

Con l’aggiornamento di ieri molti di loro saranno stati soddisfatti, giacché il blog ci informa che sono ora disponibili oltre 40 nuove metriche e dimensioni: la lista completa è in questa pagina.

All’interno dell’ultimo update troveremo quindi metriche relative al social (bottoni sociali e interazioni offsite), ai dispositivi mobili, al dettaglio dei contenuti e ai tempi utente.

Insomma, un sacco di roba, potete provare da voi le novità attraverso il data query explorer 🙂

I sostenitori della tesi “Google non si dà mai la zappa sui piedi da solo” avranno un po’ da pensare, dato che anche il browser di Mountain View si avvia buon ultimo verso l’introduzione al supporto al “do not track“: per chi non lo sapesse do not track – DNT da ora in poi – è uno standard in fase di definzione al W3C, adottato da tutti i principali browser del mondo, e addirittura attivato di default su Internet Explorer 10. Attualmente il DNT è implementato nella versione DEV di Chrome; questo significa che se tutto va bene poi passerà alla versione beta, e successivamente arriverà su milioni di versioni stabili in giro per il mondo.

Se un utente imposta il suo browser per non essere tracciato, esso invia sempre un header HTTP indicando la preferenza ai siti web visitati; essi, per contro, dovrebbero evitare di eseguire gli script di tracciamento, ivi compresi quelli dei network pubblicitari. La partita effettivamente si gioca tutta qui: il browser può chiedere di non essere tracciato, ma alla fine è il sito che deve rispettare questa scelta.

Come pensate che finirà? avete paura di veder crollare i vostri dati di monitoraggio?

Qualche giorno fa è capitata nei commenti una domanda, ve la riporto qui insieme alla risposta:

Stefano: Ciao, nella pagina di support agli esperimenti sui contenuti (http://support.google.com/analytics/bin/answer.py?hl=it&answer=1745147) viene spiegato che è possibile “definire la percentuale di visitatori inclusi nell’esperimento” e infatti in uno degli step di configurazione si può impostare la % di traffico a cui far visualizzare le pagine relative all’esperimento.
Quello che non ho capito è come viene diviso il traffico tra le pagine di test (ipotizziamo 2 variabili di pagina, il traffico é diviso al 50% o random?)

Marco:inizialmente in modo proporzionale tra tutte le variazioni, dopo interviene un algoritmo che ottimizza il processo, in modo da inviare meno visite alle pagine che – ragionevolmente – non hanno possibilità di vittoria.

Se la memoria non mi inganna, Google Website Optimizer utilizzava una ripartizione secca, cioé ripartiva egualmente il traffico in base al numero di variazioni dell’esperimento. I nuovi esperimenti sui contenuti di Google Analytics invece usano un algoritmo diverso, che si chiama “esperimento delle slot machine a più braccia” (ma suona MOLTO meglio in inglese: Multi-armed bandit experiments)

Cosa succede quindi quando avviamo un esperimento con – ipotizziamo – 4 variazioni? Quando l’esperimento inizia il traffico viene ripartito ugualmente su ogni variazione, come nell’approccio classico (e non potrebbe essere diversamente, d’altronde); una volta due volte al giorno l’algoritmo esamina i rendimenti di ogni variazione e procede a ripartire “meglio” il traffico successivamente. Una variazione che sembra performare bene ottiene più traffico, una con un rendimento inferiore ne avrà meno. L’algoritmo usato da Google é descritto nell’ultimo paragrafo dell’articolo (Teoria sequenziale delle decisioni di Bayes – si trova qualcosa di più cercando in inglese), mentre l’articolo dell’help ci informa che le rettifiche vengono apportate sulla base di reali differenze di rendimento.

Il vantaggio di questo approccio è che può dare risposte in meno tempo rispetto ad una ripartizione “classica”, perché il processo viene ottimizzato man mano che l’esperimento procede. Inoltre, se l’esperimento riguarda un obiettivo monetario, il traffico viene indirizzato sempre più verso il punto di conversione, e quindi di entrate, mentre nell’approccio classico una certa variazione che performava drasticamente male continuava a ricevere la stessa dose di visite di quella vincente ma non ancora dichiarata vincitrice.

Secondo la teoria sposata da Google, quando ha deciso di utilizzare questo algoritmo, un test deve ad ogni costo cercare di evitare due cose: non arrivare a nessun risultato o peggio arrivare a un risultato identico all’ipotesi di partenza, quantomeno in termini di rendimento.

[photo credit: Ally Cake Design] on Flickr

Il nuovo bannerone che campeggia qui a destra è dello shop di AdWorld Experience. Non sai cos’è? ora te lo spiego: qualche mese fa a Bologna si è tenuta una conferenza su AdWords/advertising. Erano presenti tantissimi nomi illustri del settore, potete vedere da soli l’elenco e farvi un’idea del livello altissimo dell’evento. Ritengo che da sempre AdWords e Analytics siano due facce della stessa medaglia, e nel tempo questo legame si è sempre più rafforzato: si, sto parlando del remarketing integrato a Google Analytics… 🙂

Questo da un lato mi ha spinto a prendere una decisione che rimando da ormai troppo tempo: appena avrò un pochino di tempo, voglio prendere la certificazione AdWords; se prima poteva essere un “plus”, adesso sento che la cosa non è più procrastinabile. Dall’altro lato, visto che i video dell’evento sono adesso disponibili nello shop del sito, mi sembra giusto segnalarvelo, e dare una mano ai ragazzi a diffondere l’iniziativa. E, visto che il link di affiliazione è tracciato – perché negarlo od ometterlo? – vedere se con gli eventuali guadagni riesco a comprarmene un paio anche io 😀