Google Analytics in 30 secondi

Non ho mai voluto capire sino in fondo quanto il mio vecchio contatore fosse stato utilizzato da quando lo pubblicai: ovviamente il link di ritorno ha i parametri delle campagne, ma è chiaro che se nessuno clicca, io non posso sapere se e dove è installato. Però a giudicare dalle tre email in rapida successione che mi informano dell’avvenuto disastro – il contatore non conta più – e mi chiedono aiuto su come risolverlo, tanto male non deve essere stato 🙂

E così ne ho approfittato e l’ho aggiornato alla versione 1.1, utilizzando questa volta la libreria GAPI. Il funzionamento è lo stesso, ho solo dovuto aggiungere una dimensione “fasulla” perché la libreria non accetta query senza dimensioni, ma alla fine le tre metriche del contatore vengono mostrate.
Se quindi utilizzavate il contatore e da qualche tempo ha smesso di funzionare… è tempo di aggiornare il tutto. Ogni tanto va fatto! 🙂

Trovate tutto nella pagina apposita

Dicevo giustamente nello scorso post “riuscirà il team di Google Analytics a stare buono buonino una settimana?”
evidentemente no! mentre ero in ferie ci sono state due novità, che vado adesso ad illustrare con il dovuto ritardo:

comparazione temporale:
Quando adesso si seleziona “confronta con” nell’intervallo di date è disponibile un menu a tendina con tre opzioni: personalizzato, periodo precedente e anno precedente. Il primo ci permette di selezionare manualmente le date, il secondo attiva il confronto con il periodo precedente, come è stato fino ad ora, e il terzo attiva il confronto con il medesimo periodo dell’anno precedente. Soprattutto l’ultima è molto comoda, specie per rapidi check al volo.

scorciatoie:
Le piccole cose che fanno grande questo prodotto! Quante volte in vita vostra avete maledetto l’assenza di un’opzione per salvare le decine di configurazioni che avete fatto per arrivare ad un certo report? scelgo il report, passo alla scheda e-commerce, metto un filtro alla tabella, applico due segmenti, seleziono la visualizzazione a torta, cambio l’ordine di una colonna. Me lo ricorderò la prossima volta?
Da adesso non c’è più problema: nella barra grigia in alto c’è un nuovo pulsante – Scorciatoia – che permette di salvare la visualizzazione così com’è (escluso il periodo temporale, naturalmente). Lo premo e il mio report finisce in un’area della Home che si chiama Collegamenti: posso dargli un nome mnemonico e riaprirlo così come l’ho salvato quando voglio. Un notevole risparmio di tempo, e una modifica piccola ma che nel lungo periodo può far risparmiare ore di lavoro!

[update 28 agosto: con più calma – in ferie 😀 – ho capito il mio errore. ci sono riuscito. Quando torno scriverò un post di istruzioni…]

Subito prima delle ferie – le MIE ferie – il team di Analytics ci propone uno script per facilitare l’importazione di dati dentro a Google Docs: il sogno di noi tutti sarebbe un analogo per Excel, quantomeno per evitare il doppio salto GA -> Google Docs -> Excel (e lo so che ci sono altri strumenti diretti, io parlavo di uno scrip made in Google 🙂 ), ma ovviamente Google ha tutto l’interesse a spingere Docs usando anche questo genere di argomenti.

Volevo postarvi delle istruzioni carine per farvi già creare qualcosa, ma come al solito voglio essere sincero al 100%: gli ho dedicato 20 minuti ma non sono riuscito a importare un solo dato, usando le funzioni già presenti. Dovrei dedicarmi alla parte “costruisci il tuo script”, ma non mi sembra una cosa da fare la sera prima della partenza per le ferie: se ci riuscissi e venisse una cosa carina so che sarei capace di fare moooolto tardi, e domani devo guidare 🙂

(per quanti si stiano domandando “è meglio questo o quello vecchio postato da SeoMoz?” la risposta è: quello di SeoMoz non richiede nessuna conoscenza particolare, però vuole la password in chiaro e spesso a me dà problemi. Questo richiede di smanacciare almeno un pochino con il pannello delle API, se si vuole scrivere o aggiungere pezzi di codice, però è fatto da Google ma non sono riuscito a farlo funzionare. Vedete voi 🙂 )

Non è detto che riesca a scrivere/leggere durante le ferie, e spero che non succeda nulla di troppo importante nel frattempo: in fondo si tratta di una sola settimana, dite che il team di Google ce la fa a stare buono mentre mi riposo un pochino? 🙂

Una volta esistevano i grafici di comparazione di settore, dentro a Google Analytics: grafici che mettevano in comparazione le performance del sito contro una media di “almeno 100 siti della medesima categoria”, scelti automaticamente da Google. Piuttosto inutile invero, anche se molte persone con cui ho parlato lo guardavano con piacere.

Google dà e Google toglie, come si dice: resisi conto che il risultato era una schifezza, diciamo pure apertamente, fecero sparire il report, annunciando che l’avrebbero trasformato in una newsletter. Detto fatto, il primo numero arrivò quasi subito. Poi ne fecero un secondo numero, e poi se la memoria non mi inganna il nulla. Eppure Google non ha problemi a conoscere i dati di tutti, e siccome Google Analytics è lo strumento di web analytics più diffuso del pianeta, fare un benchmark di questo tipo non è nemmeno troppo difficile.

E quindi? quindi per adesso niente. Però se vi loggate nel vostro profilo e cliccate Amministrazione -> Impostazioni Proprietà, troverete da qualche tempo un menu a tendina che si chiama “Categoria del settore”, il cui help in linea – in inglese – recita

Choose your industry so we can work towards building tailored reports, customized communication, and better education material. Your selection does not affect tracking and data collection.

.

Se non altro questa volta hanno detto che “lavoreremo alla costruzione di report”, speriamo che sia la volta buona e che il report sia effettivamente utile 🙂

Da quando mi occupo di questa disciplina ho sempre ritenuto che essa avesse molto a che fare con il pensiero laterale. In realtà il pensiero laterale secondo me aiuta in qualsiasi tipo di ragionamento, ma nella web analytics è particolarmente utile. Quando si ha a che fare con un progetto di analisi dei dati web non è affatto scontato che ad azione corrisponda reazione. “se aumento il budget delle campagne ppc aumento il traffico sul sito e il tasso di conversione”: ma chi l’ha detto? “se diminuisce il traffico allora il progetto sta andando male”: dipende dagli obiettivi, anzi potrebbe essere addirittura un bene!

La web analytics non è quasi mai un processo SE… ALLORA… e le interpretazioni dei fenomeni possono essere molteplici. Ancora, molteplici possono essere le vie per l’INDIVIDUAZIONE di un fenomeno, o per individuare la sua spiegazione, quando è possibile.

Perché mi è venuto in mente tutto questo? perché qualche tempo fa ho risposto a un tweet di Randy Zwitch che parlava di un orologio con i numeri romani “sbagliati”. Avete mai visto gli orologi con il numero quattro fatto con quattro “I” (IIII) invece di una “I” e una “V” (IV)? si vedono specialmente nelle torri campanarie, o almeno qui in Liguria accade spesso.

La spiegazione è che nel passato non erano molto contenti di sprecare materiali e lavoro e cercavano quindi di ottimizzare tutti i processi. Se contate i singoli elementi che servono per comporre un orologio con i numeri romani “normali” avrete:

• 17 “I”
• 5 “V”
• 4 “X”

Se invece usiamo la notazione IIII per il numero quattro, gli elementi diventano:

• 20 “I”
• 4 “V”
• 4 “X”

Questa seconda combinazione si può ottenere stampando quattro volte un calco XVIIIII, senza residui e avanzi, mentre la precedente fa sempre avanzare qualcosa.

Cosa insegna tutto questo al web analyst?
1) non partire mai con “è impossibile” e lascia sempre spazio al dubbio. E’ facile dire “quegli orologi sono sbagliati”, ma come vi ho dimostrato non è proprio così. Se il cliente dice “ho un orologio con quattro “I” invece di una “IV”, quantomeno una verifica va fatta, prima di troncare la questione.

2) ci vuole molta fantasia in questo lavoro, per immaginarsi tutto quel che può essere successo a monte di un determinato fenomeno. L’informazione è importante, la storia del cliente anche, ma spesso bisogna astrarsi un pochino da tutto e provare a lavorare con l’immaginazione (o almeno, per me funziona 🙂 )

3) l’avvocato del diavolo è una tecnica molto proficua. Se c’è un fenomeno da valutare, dismetti i panni di chi deve spiegarlo, e prova a indossare i panni del fenomeno “sballato”: perché lo faccio? da dove vengo? quanto danno sto provocando, e perché? in questo specifico esempio è inutile provare a ragionare se sia giusto o sbagliato il quattro scritto così, bisognava indossare i panni di chi l’orologio lo deve produrre.

Ah beh certo, e poi c’è il “fattore C“: ti starai infatti domandando perché conoscevo la storia dei numeri romani… l’ho letta da piccolo sulla posta dei lettori di un numero di Martin Mystére 🙂

C’è un buon articolo dell’help che spiega la differenza tra tasso di uscita e tasso di rimbalzo, e siccome in poco tempo mi sono capitate due domande in proposito, ve lo riassumo e traduco qui dato che in italiano non è ancora disponibile (avevo già comunque parlato della questione anni fa)

Molte persone pensano che siccome il tasso di uscita è basato sull’ultima pagina vista, esso dovrebbe essere almeno uguale al bounce rate, che tratta le visite in cui vi è una sola pagina (la prima e l’ultima). In realtà la cosa è leggermente diversa, poiché il tasso di uscita è la percentuale di pagine viste in cui la pagina oggetto è stata l’ultima della sessione, mentre il bounce rate è la percentuale di visite in cui la pagina in oggetto è stata l’unica della sessione.
Inoltre come dovremmo sapere benissimo, il tasso di rimbalzo è calcolato soltanto sulle visite che iniziano sulla pagina oggetto.

Chiariamo prima di tutto quest’ultimo punto, con un esempio: sito di 3 pagine, 1 sola visita al giorno
Lun: Page A > Page B > Page C
Mar: Page B > Page A > Page C
Mer: Page A > exit

Il report dei contenuti per la pagina A mostrerà 3 pagine viste e un tasso di rimbalzo del 50% (quante volte è landing page? 2. quante volte la visita non prosegue? 1. quindi 50%).

Modifichiamo l’esempio così

Lun: Page B > Page A > Page C
Mar: Page B > Exit
Mer: Page A > Page C > Page B
Gio: Page C > Exit
Ven: Page B > Page C > Page A

Il tasso di uscita è
Page A: 33% (la pagina A fa 3 pageview, di cui una è l’ultima della sessione 1/3=33%)
Page B: 50% (la pagina B fa 4 pageview, di 2 sono le ultime della sessione 2/4=50%)
Page C: 50% (la pagina C fa 4 pageview, di 2 sono le ultime della sessione 2/4=50%)

Il bounce rate invece è:
Page A: 0% (è landing page 1 volta – Mercoledì – ma la visita continua)
Page B: 33% (è landing page 3 volte, e 1 volta la visita finisce lì. 1/3=33%.)
Page C: 100% (è landing page 1 volta – Giovedì – ma la visita finisce lì)

Tra le due metriche quindi non c’è nessuna relazione, dato che sono calcolate in modo separato basandosi su presupposti diversi. Exit rate guarda alle pageview, tasso di rimbalzo alle visite.

Questa è una segnalazione molto rapida per informarvi che da adesso sono pubbliche le nuove API dedicate alle canalizzazioni multicanale: ovvero un modo per estrarre i dati presenti nei multi-channel funnel e rielaborarli come meglio ci aggrada; non che mancassero le possibilità, attraverso la creazione di raggruppamenti di canali personalizzati, ma si sa, gli sviluppatori sono sempre avidi di API e le possibilità in questo modo diventano infinite.

Per prima cosa una precisazione: le nuove aPI funzionano solo se state usando la versione 3 delle core reporting API; è un modo come un altro (il migliore che Google conosce) per convincere le persone ad aggiornare le proprie abitudini 🙂
In secondo luogo, se vorrete usarle, dovreste dare un’occhiata alle metriche e alle dimensioni che si possono estrarre attraverso questa nuova feature.

Sono molto curioso di scoprire cosa gli sviluppatori tireranno fuori con queste nuove, potentissime e promettenti, API. Poi uno dice che il mondo non è dei programmatori… 😀

Ormai penso di poter dire senza timore di smentita che siamo nel pieno di quella che fino a qualche anno fa pensavamo si sarebbe chiamata “Business Platform“, cioè un prodotto completo in grado di aiutare chi fa business sul web ad avere il quadro completo della situazione.

Avevamo detto che il centro di tutto avrebbe dovuto essere Google Analytics, e praticamente la cosa si sta avverando, visto che oggi è stato annunciata l’integrazione del Remarketing di AdWords nello strumento.

Nello specifico, si tratta di un sistema per crare liste di remarketing (non nominative, naturalmente) sulla base di specifici segmenti di visitatori, operazione che ad oggi si può fare tramite l’inserimento di un ulteriore codice AdWords sulle pagine che devono attivare la creazione del cookie di remarketing, e che invece tra un po’ sarà fatta automaticamente da Google Analytics, semplicemente con questa riga di codice nello script di base presente su tutte le pagine del sito

ga.src = ('https:' == document.location.protocol ? 'https://' : 'http://') + 'stats.g.doubleclick.net/dc.js';

(nota bene: la fonte di questa informazione è l’help ufficiale. Lì viene detto di aggiungere la linea ma nell’esempio la sostituiscono a quella che chiama ga.js. Daniel Waisberg su searchengineland conferma che bisogna sostituire).

Ci sono alcuni requisiti da soddisfare per poter usare il tag di remarketing:

• Accettare i Termini del Servizio di Google Analytics (e questa è facile, se lo state usando… tuttavia vi conviene rileggerli, perché potrebbero essere mutati dall’ultima volta che li avete guardati)
• Accettare i Termini della Display Advertiser Policy
• Modificare la privacy policy del sito per informare gli utenti dell’uso del remarketing negli annunci pubblicitari mostrati
• Modificare il codice di tracciamento di Analytics
• Avere almeno un account AdWords collegato a quello di Analytics, ed essere amministratori dell’account GA

La mossa mi sembra molto interessante, e lo sforzo titanico di Google nel semplificare la vita agli utenti darà sicuramente i suoi frutti: pensateci un attimo, fino a due mesi fa i test sui contenuti e il remarketing erano operazioni completamente slegate da Analytics, mentre adesso basta la modifica di una linea di codice per entrambe le cose. Meno cose ci sono da modificare, meno è facile sbagliare, e più veloce è il processo. E il tutto è sempre più integrato dentro a un fantastico strumento.

Non vedo l’ora di vedere quale sarà il prossimo prodotto a richiedere una lieve modifica al codice per regalarci altri dati… 🙂

[a proposito: “quando sarà attivata questa feature?” nelle prossime settimane, gradualmente, ed entro la fine dell’estate dovrebbe raggiungere il 100% degli utenti]

Bounce rate “accomodato” è la mia traduzione per “adjusted bounce rate”, come lo chiamano su questo post del blog ufficiale di Google Analytics. Si tratta di un escamotage per evitare di considerare come rimbalzi visitatori che trascorrono più di tot tempo sulla pagina di atterraggio.

In pratica si aggiunge una funzione javascript che trascorso un intervallo di tempo predefinito spara un evento, che essendo una hit di engagement annulla il bounce rate. Il codice di base delle pagine diventerebbe quindi

var _gaq = _gaq || [];
  _gaq.push(['_setAccount', 'UA-XXXXXXX-1']);
  _gaq.push(['_trackPageview']);
  setTimeout("_gaq.push(['_trackEvent', '15_seconds', 'read'])",15000);

  (function() {
    var ga = document.createElement('script'); ga.type = 'text/javascript'; ga.async = true;
    ga.src = ('https:' == document.location.protocol ? 'https://ssl' : 'http://www') + '.google-analytics.com/ga.js';
    var s = document.getElementsByTagName('script')[0]; s.parentNode.insertBefore(ga, s);
  })();

A seconda di quanti millisecondi utilizzerete nella vostra implementazione, il vostro bounce rate si abbasserà in modo maggiore o minore.

Ma ragioniamo un attimo su quel che succede:
Normalmente un visitatore atterra su una vostra pagina, e se non compie nessuna azione (cioè se non invia nessun’altra engagement hit), viene considerato un bounce; questo naturalmente può accadere sia se il visitatore trascorre sulla pagina 3 secondi, sia se invece ci resta 5 ore. L’esempio della pagina super ottimizzata del ristorante, che trovo al primo colpo su Google e che contiene anche il numero di telefono, quindi soddisfa in pieno il mio desiderio (e magari si mangia pure bene, e anzi come dice sempre Francesco de Francesco – magari poi ci torno per il matrimonio e gli porto un incasso di seimila euro, e lui vede un bounce! 🙂 ), è perfetta. E’ una pagina che è naturale abbia un alto tasso di rimbalzo, almeno per il segmento di visite organico.

Bene, abbiamo detto quindi che non sappiamo quanto tempo sia stato effettivamente sulla pagina, e benché meno sappiamo se la pagina l’ha letta davvero oppure no!

Implementiamo allora il bounce rate accomodato, e consideriamo bounce solo chi va via prima di 15 secondi. Questo cosa mi dice più di prima? quanti stanno più di 15 secondi, ovvio. Ma è in grado di cambiare la vera informazione che mi servirebbe, cioè se la pagina è stata letta o no? assolutamente no! se uno non la legge, può non leggerla in 8 secondi, ne in 32, ne in 4 ore (perché ha lasciato il browser aperto ed è andato in riunione).

Non sto dicendo che il metodo sia da evitare a tutti i costi, sia chiaro: dico solo che va utilizzato per la reale informazione che mi da, cioè una modifica del tempo sulla pagina; ma trascorrere più tempo sulla pagina non significa che è stata compiuta un’azione!
Se proprio volessimo fare degli aggiustamenti, allora punterei di più sul sistema di Justin Cutroni per tracciare lo scroll della pagina (parte 1 – parte 2), magari in una sua forma alleggerita per sparare l’evento antibounce allo scroll della pagina, che mi sembra una azione molto più del trascorrerci più di 15 secondi.

Le novità introdotte due giorni fa ai content experiment, che nel frattempo sono stati abilitati sul 100% degli account, credo detengano il record assoluto di minore tempo intercorso tra l’annuncio di una funzione e la sua “versione 2” con miglioramenti.

Nel dettaglio, è stato introdotto il supporto a URL relativi, invece che assoluti; ad esempio si può condurre un esperimento su due variazioni di url che si trovano su sottodomini differenti, oppure su un unico url che varia per la presenza di una variabile (oppure anche su protocolli secure / non-secure: c’è un esempio in fondo a questa pagina dell’help).

Inoltre da adesso in poi si possono copiare gli esperimenti, in modo da riutilizzare il codice usato per la pagina originale dell’esperimento originale; ad esempio se un esperimento si conclude ma vogliamo affinarlo, copiamo l’esperimento e lasciamo la stessa landing, che si preoccuperà di redirezionare sulle nuove variazioni.

Infine i report sono ora molto più “Google Analytics like”, cioè sono state introdotte le metriche classiche presenti nelle schede di GA: utilizzo del sito, gruppo obiettivi ed E-commerce, e inoltre si possono mostrare le righe nel grafico come nel resto del prodotto.

Variazioni interessanti, se solo non fossero così dannatamente veloci a introdurle magari si riuscirebbe a testare tutto con più calma… 🙂