Google Analytics in 30 secondi

Una delle cose che dico sempre a clienti e durante i corsi, e che sottolineo finché non viene recepita bene, è che Google Analytics sottostima il traffico diretto, perché semplicemente le visite potenziali da tracciare come DIRECT non sovrascrivono il cookie __utmz se in esso è presente un’altra campagna (che non sia direct, ovvio). La cosa l’ho spiegata tempo fa nel post in cui illustravo un’eccezione: tabella di conversione delle sorgenti.

La cosa si può spiegare in parte anche con le ipotesi “maliziose”. Se un utente fa un clic su un annuncio AdWords ma non converte, se poi torna con visita diretta e converte, la conversione viene attribuita al cpc, facendolo sembrare più redditizio di quanto non sia realmente. Ma la cosa come abbiamo detto vale anche per ricerche organiche, referral e campagne, vorrei che restasse chiaro. Dal punto di vista dell’analista d’altronde la cosa nemmeno mi dispiace troppo: il traffico diretto è un po’ un punto morto delle analisi, si possono fare ipotesi (e a volte si riescono anche a verificare), si può vedere la landing page, ma non ci sono molti altri spunti possibili, al contrario di tutte le altre fonti di traffico.

Cosa succede però nei Funnel multicanale, dove la sorgente usata (e addirittura l’ordine delle sorgenti) ha un ruolo fondamentale per la comprensione dei report? se si seguisse la stessa logica si avrebbero GROSSI problemi a comporre quei report, e le valutazioni conseguenti ne sarebbero inficiate. Infatti, come ci informa questo articolo della guida, nelle Canalizzazioni Multicanale – E SOLO IN QUEL SET DI RAPPORTI – il traffico diretto è puntualmente tracciato a prescindere dal cookie __utmz. Nell’esempio precedente al cpc verrebbe attribuita una conversione indiretta (e verrebbe raffigurato come una freccia nel report “canalizzazioni indirette”) e al traffico diretto verrebbe attribuita la conversione (e verrebbe indicato con un rettangolo).

E’ una differenza fondamentale da tenere ben presente quando si guardano i funnel multichannel.

Nel proseguo dell’articolo vengono menzionati altri due fatti interessanti, che riporto per comodità:

• ci possono volere fino a due giorni di tempo per vedere i dati delle canalizzazioni multicanale. Meglio non fare analisi per il giorno precedente.
• Il totale conversioni indicato è sempre dato dalla somma di GOAL + transazioni ECOMMERCE

Nel complesso mi sembrano tre cose molto utili da tenere a mente quando si analizzano i multichannel funnel. Voi li usate? li avete personalizzati?

Una delle pecche che affliggono Google Analytics da quando esiste è la gestione degli accessi. Sappiamo che esistono due livelli di accesso, utente e amministratore, che hanno naturalmente differenti “poteri”: l’utente viene aggiunto a un profilo, può vedere solo quel profilo e non ha accesso agli strumenti di gestione, come la creazione di filtri o l’aggiunta di altri utenti. L’amministratore viene aggiunto al profilo ma può vedere tutti i profili dentro all’account che lo contiene, e può effettuare operazioni di amministrazione. Non può però fare due cose:

1. non può rimuovere l’admin originale, cioè colui che ha creato l’account (per questioni di sicurezza, altrimenti potrebbe “rubare” l’account)
2. non può rimuovere sè stesso

La questione del rimuovere sè stessi è un problema per entrambe le tipologie di utente, e fino a oggi nemmeno io avevo la soluzione. Pochi minuti fa però mi è capitato sotto mano questo link a una form di richiesta creata da Google, che dovrebbe fare proprio al caso nostro. Dico dovrebbe perché ho inviato una richiesta (un cliente di non so quanti anni fa, che nonostante ripetute richieste non mi ha mai rimosso dall’accesso ai suoi dati), ma ancora non è successo nulla. Vi incollo ugualmente il link alla form

https://docs.google.com/spreadsheet/viewform?formkey=dGM3X2tYY1ZhX3lPVkRBYmRsYXBOUXc6MQ

e se anche voi avete profili che non riuscite a togliervi di mezzo, provateci!

E’ quasi finito un anno fantastico per Google Analytics: annunci continui, novità una dietro l’altra e l’arrivo di Google Analytics Premium. Non so se si potrà ripetere un anno così (o forse si, dato che è solo da metà anno in poi che tutto ha subito un’accelerazione…), ma è mio dovere fare un fact check delle previsioni fatte a Gennaio:

• link in uscita: la funzione è già pronta, se non la annunciano quest’anno perdo tutte le speranze. PREVISIONE SBAGLIATA, perdo le speranze (a meno che l’autotrack non fosse un esperimento buttato lì per caso)
• social media come fonte separata: riesumo una previsione di inizio 2009, ma penso che questo sia l’anno cruciale. MEZZO PUNTO: nei funnel multicanale i social sono effettivamente separati
• Google TV tracking: appena Google TV risolverà i suoi piccoli problemi, Google Analytics annuncerà una SDK dedicata (anche se in realtà si potrebbe già fare con quella Android) per tracciare la navigazione e l’uso delle TV multimediali, chiudendo il cerchio con la già esistente funzione di monitoraggio degli spot pubblicitari televisivi. MEZZO PUNTO. Alla fine la Google TV è a tutti gli effetti basata su Android, per cui l’SDK c’è e funziona
• novità nella gestione di account e profili: credo che durante questo anno verranno abbassati alcuni limiti attuali del sistema: i 50 profili per account, la gestione un po’ complessa degli account, e verrà finalmente data la possibilità di migrare gli storici da un account a un altro. PREVISIONE ERRATA!

Le sparate di fanta-web analytics ovviamente erano fuori concorso, e infatti Webtrends sta meglio che mai, e Adobe punta moltissimo sulla suite di digital measurement, per cui niente. Chi voleva una piattaforma professionale ha avuto Google Analytics Premium, e tutti proseguono per la loro strada.

E veniamo alle previsioni per il 2012:

• Real Time: sarà esteso anche a eventi e transazioni ecommerce, e non solo alle pagine. Non mi sembra poi così complicato da gestire, se sono riusciti a darci già quel che vediamo…
• Import API: fino a un mese fa non l’avrei mai scritto, ma come spiegavo nel post sul social data hub, non lo vedo più come un tabù. D’altronde solo i grandi sciocchi non cambiano mai idea…
• Integrazione con Website Optimizer: magari sulla falsariga dell’import dei dati di Webmaster Tools, con la possibilità di segmentare le visite degli esperimenti.
• GA predittivo: Analytics sarà in grado di fare proiezioni e previsioni sui dati futuri. Una versione potenziata dell’intelligence, che non si limiti al risultato atteso ma ad elaborare una serie futura.

L’anno scorso non ha partecipato nessuno alle previsioni, per cui non ho nessuno da tirare in ballo. Considerando l’enorme – nuova – potenza di calcolo di Analytics, si può immaginare quasi qualsiasi cosa, per cui non abbiate timore! Lasciate la vostra previsione nei commenti, magari tra un anno potrete dire “ve l’avevo detto!”

Qualche giorno fa Google ha aggiornato – finalmente direi – il suo corso ed esame per conseguire il Google Analytics Qualified Individual, la certificazione dei singoli. La versione online era ormai troppo distaccata dal prodotto reale, e non rifletteva gli innumerevoli aggiornamenti sia dell’interfaccia sia delle funzionalità.

Il post elenca quattro punti (cardine, aggiungerei) che è importante assicurarsi di aver compreso prima di intraprendere l’esame. Questi punti sono:

• capire gli account, le web properties e i profili
• capire i tipi di goal e quando usarne uno piuttosto che un altro
• capire i concetti di metrica e dimensione
• essere consci delle nuove funzioni e dei nuovi report di Google Analytics

Speriamo che con l’occasione abbiano anche sistemato quel paio di domande ambigue che da sempre mi impediscono di raggiungere il 100% nello score del test

Ho notato che l’annuncio sul Social Data Hub è passato in sordina tra le maglie dei blog e delle testate online: chi ha rilanciato, si è limitato a riportare la notizia così com’era, quasi senza commenti.
Io, è noto, sono un Google enthusiast e a volte sovrastimo l’impatto delle novità che Google introduce; mi è capitato ultimamente con Google Wave, mentre sono più cauto e ponderato quando si tratta di Google Analytics, tuttavia in questo caso non mi capacito del perché la cosa sia passata così “liscia”. O forse si, ed è perché in pochi hanno letto la documentazione o hanno capito come funzionerà la cosa. Motivo per cui sono lieto di aver scritto questa frase

…per importare dati dentro agli account di GA. E attenzione, vi ricordo che è la prima volta in 6 anni che si può importare qualcosa in Analytics.

che è stata all’incirca la stessa che poi ha detto Justin Cutroni nel suo post

First, the REALLY big news that I feel has been overlooked is that Google will let other data providers integrate their data into Google Analytics. This is the first time that Google has added a non-Google data source to Google Analytics

Il motivo per cui sarà Justin ad andare a lavorare a Mountain View e non io è però che la sua analisi è ancora più attenta e prende in considerazione un particolare che a me è sfuggito: nelle specifiche tecniche dell’import sono richiesti alcuni dati, tra cui informazioni assolutamente catalogabili come personali e quindi proibite dai termini del servizio di Google Analytics. Una delle opzioni è che Google dovrà cambiare i termini del servizio, l’altra – che sostengo io – e che quei dati siano richiesti per deduplicare gli stream ma che poi non saranno mai mostrati nell’interfaccia. Una sorta di codice identificativo, non credo proprio che un domani Google Analytics potrà dirmi “il tuo contenuto 123 ha ricevuto 32 like da Tizio e Caio ed è stato commentato da Sempronio su Google+ con queste parole…”.

Ma comunque staremo a vedere quando i report saranno disponibili!

Ogni volta che ho a che fare con il passaggio dei visitatori tracciati da un dominio all’altro è un dramma: è un dramma spiegare ai clienti perché bisogna farlo (ma di solito la frase risolutiva è “ma allora perché il vostro sito non legge le informazioni nei cookie di gmail e facebook? ), è quasi sempre un dramma implementarlo se non posso farlo direttamente, perché i tempi di reazione sono allungati. Comunque sia, come tutti voi dovreste ormai sapere, ogni dominio imposta un differente set di cookie, ed è il motivo per cui esiste la funzione _setAllowLinker e le relative _link e _linkByPost, con cui bisogna taggare TUTTI i link che inviano i visitatori all’altro – o agli altri – siti.

Lunametrics ha aggiornato un suo vecchio script per automatizzare la cosa alla sintassi asincrona:

Le istruzioni dicono di assicurarsi che siano presenti la _setDomainName impostata sul dominio di secondo livello nel quale è lo script di Analytics e la _setAllowLinker, condizioni di partenza necessarie, poi di scaricare e modificare lo script inserendo nella riga 5 i domini possibile sui quali si potranno inviare i visitatori, ed eventualmente nella riga 6 le estensioni dei file di cui si vuole tracciare i download.
Poi bisogna caricare il file nei domini e aggiungere una riga in cui si richiama il file; poiché il sistema è basato su jQuery è necessario un riferimento alla libreria, se già non l’avete (vanno bene anche le versioni basilari offerte su CDN, tipo google, microsoft, eccetera).

A quel punto ogni link che punta ad uno dei domini interessati conterrà la funzione _link e _linkByPost, e il processo sarà completamente automatizzato. Un po’ come accadeva con setXDomain su GAaddons, che però è stata dismessa dall’autore

Di questa cosa mi ero accorto lunedì sera, ho aspettato martedì per verificare che non fosse un test o un errore, ieri non sono stato a casa tutto il giorno e stamattina mi trovo già il post fatto sul blog ufficiale. Colpa mia che ho aspettato e non ho potuto dare in anteprima la notizia: nel report velocità del sito sono state implementate nuove metriche tecniche.

Più precisamente nella tab ESPLORAZIONE, a fianco di USO DEL SITO, è stata aggiunta la scheda TECNICO che sostanzialmente divide il tempo medio di caricamento della pagina nelle sue componenti singole:

• Tempo di reindirizzamento: è il tempo speso per un redirect, 0 se non ce ne sono
• Tempo medio di ricerca dominio: è il tempo speso per l’interrogazione del DNS
• Tempo medio di connessione al server: è il tempo necessario per il collegamento tra client e server
• Tempo medio di risposta: è il tempo che il server ci impiega per rispondere alla richiesta effettuata dal client
• Tempo di download medio della pagina: è il tempo effettivamente impiegato per scaricare la pagina

Il tempo che manca è il tempo che il browser impiega per renderizzare la pagina, chiamare i componenti, eseguire javascript, interpretare regole css, eccetera…

Il report secondo me così com’è è un po’ fuorviante, perché omette di specificare il campione usato, che invece è esplicitato nella scheda USO DEL SITO. L’utente potrebbe essere portato a pensare che i tempi specificati siano validi per tutte le pagine viste, perché l’unica metrica nel report è proprio VISUALIZZAZIONI DI PAGINA, mentre è vero il contrario, e cioè che l’analisi viene fatta solo sulle pagine oggetto del campione.

Le stesse metriche sono poi presenti nella tab RENDIMENTO, che raggruppa i tempi di caricamento in gruppi: sarà quindi possibile vedere l’intervallo di tempo per cui il server è più lento a rispondere, o il DNS a trasformare l’indirizzo in numero, eccetera.

Si tratta di metriche molto tecniche, che saranno di aiuto a chi fa ottimizzazioni estreme sui tempi di caricamento, ma in linea più generale possono aiutare qualunque business: sapere che c’è un collo di bottiglia è il primo passo per risolvere un problema, e non sono certo io a scoprire che server più veloci hanno impatti positivi sui tassi di conversione!

Mi sono accorto che la dashboard predefinita dei profili che non l’hanno personalizzata è cambiata, probabilmente in un tentativo da parte di Google di renderla più utile e quindi più utilizzata: stiamo parlando della feature secondo me più sottovalutata della storia di Google Analytics! Comunque, la vecchia dashboard si presentava così:

• colonna di sinistra: Widget Visite e bounce rate
• colonna centrale: tabella top10 contenuti e timeline con visite e visitatori
• colonna di destra: grafico a torta delle visite per paese di provenienza

Quella nuova invece mi sembra più funzionale:

• colonna di sinistra: Timeline con le visite per giorno e grafico a torta delle sorgenti
• colonna centrale: timeline del tempo medio sul sito e tabella del tempo medio diviso per paese di provenienza
• colonna di destra: timeline del tasso di conversione totale e tabella dei tassi di conversione per sorgente

Naturalmente è sempre possibile personalizzarla e creare fino a 20 differenti dashboard per ogni profilo…

Facendo seguito al suo progetto di ridisegnare l’intera infrastruttura di API di tutti i suoi servizi, Google ha annunciato che la Data Export API sarà sostituita dalla Core Reporting API. Non si tratta solo di un cambiamento di nome, perché le novità principali sono:

• nuovo output basato su JSON, più veloce nella risposta. Il post ufficiale dice che la dimensione della risposta è più piccola di 10 volte rispetto al vecchio XML, e secondo i primi test la velocità di risposta raddoppia
• Una serie tutta nuova di librerie, tra cui Object C, Ruby, Go…
• supporto alla Google Discovery API e OAuth 2.0
• richiede che l’applicazione sia registrata e ottenga uno specifico ID

Tutto questo avviene se si migra alla versione 3.0 delle API, che poi è l’unica che sarà aggiornata. La versione 2.4 è mantenuta per compatibilità, mentre la 2.3 è deprecata e smetterà di funzionare tra 6 mesi. A questo punto sia la Management API che la Core Reporting sono allineate, e da ora in poi la strada per i programmatori sarà in discesa…

Come promesso oggi a Le Web Paris Phil Mui è salito sul palco per un annuncio nel campo dei social: il Google Analytics Social Data Hub. A quanto sono riuscito a capire si tratta di una piattaforma in grado di interfacciarsi con i social network per importare dati dentro agli account di GA. E attenzione, vi ricordo che è la prima volta in 6 anni che si può importare qualcosa in Analytics.
La mossa è intelligente, perché abbiamo visto in passato quanto siano stati infruttuosi i tentativi di monitorare “normalmente” le fanpage di Facebook con Google Analytics: il codice di tracciamento standard non è più sufficiente, e allora Google chiama a raccolta direttamente gli sviluppatori dei vari social network per aderire ad un sistema unico di trasferimento dei dati riguardanti le attività sui social network.

La dizione esatta è “qualsiasi social network potrà integrare gli stream di attività – come +1, voti e commenti – dentro ai report Social Analytics, che saranno disponibili l’anno prossimo”. roba grossa, eh?
Intanto possiamo dare una sbirciata ai social network che aderiscono già all’iniziativa:
Google Plus, Google Groups, Gigya, Reddit, Diigo, Digg, Blogger, Read It Later, Delicious, VKontakte, ma sono certo che altri si aggiungeranno presto, in secondo luogo si tratta di operazioni che noi non possiamo condizionare in alcuna maniera: l’adozione del protocollo – basato su PubSubHubbub – è a discrezione e cura di chi gestisce il social network.

Anche questa volta per vedere i futuri report social c’è bisogno della preiscrizione, per cui se anche voi volete essere inclusi in questa succulenta novità, potete compilare l’apposito form di richiesta che ho visto passare su Twitter durante la presentazione a Parigi.