Google Analytics in 30 secondi

_trackTrans() è l’ultima funzione della serie e-commerce ed è l’equivalente di trackPageview(). Dopo che altre funzioni hanno raccolto i dati necessari, entrambe si occupano di spedire il contenuto ai server di Google, completando la transizione delle informazioni dai browser ai server collettori.
_trackTrans() va usata tipicamente in congiunzione con _addTrans() e _addItem(), ma sempre e comunque dopo la chiamata a trackPageview(), altrimenti non funzionerà. Per cui, riprendendo gli esempi dei post precedenti, una transazione tipica e completa avrà il seguente codice:

pageTracker._trackPageView();
pageTracker._addTrans(
     "12345", // id_ordine
     "libreria ponte vecchio", // affiliazione
     "35.99", // totale
     "3.00", // tasse
     "5.99", // spedizione
     "Palermo", // città
     "Sicilia", // area
     "Italia" // nazione
     );
pageTracker._addItem(
   "12345", // id_ordine
   "TA2676", //sku
   "GAin30sec", // nome
   "Libri", // categoria
   "35.99", // prezzo
   "1"  //quantità
 );
pageTracker._trackTrans();

Sempre nell’ambito delle funzioni specificamente pensate per l’e-commerce, _addTrans(id_ordine, affiliazione, totale, tasse, spedizione, città, area, nazione) crea un oggetto-transazione del valore specificato. Come nel caso di _addItem() se un visitatore chiama due volte la funzione con uno stesso id_ordine (non sku, che in questo caso non è previsto) la seconda chiamata sovrascrive la prima. I parametri che _addTrans prevede, tutti stringhe, sono i seguenti:

• id_ordine: l’identificativo dell’ordine (lo stesso di _addItem – obbligatorio)
• affiliazione: nome del negozio o del partner che produce la transazione (facoltativo)
• totale: il costo totale sostenuto dal cliente (obbligatorio)
• tasse: l’ammontare dei costi per tasse sostenuti dal cliente (facoltativo)
• spedizione: l’ammontare dei costi di spedizione sostenuti dal cliente (facoltativo)
• città: la città associata alla transazione facoltativo)
• area: l’area associata alla transazione (può essere lo stato USA, o la regione italiana ad esempio – facoltativo)
• nazione: la nazione associata alla transazione (facoltativo)

Questa funzione ha anche un elemento di ritorno, utile in caso di debug. Questo oggetto è _gat.GA_Ecomm_.Transactions_ ed è l’identificativo dell’oggetto-transazione che è stato modificato dalla chiamata alla funzione.
Un utilizzo tipico di _addTrans() è quello che segue:

pageTracker._addTrans(
     "12345", // id_ordine
     "libreria ponte vecchio", // affiliazione
     "35.99", // totale
     "3.00", // tasse
     "5.99", // spedizione
     "Palermo", // città
     "Sicilia", // area
     "Italia" // nazione
     );

Anche questa volta, nel caso di parametri facoltativi, è necessario inserire le virgolette e lasciare vuoto il contenuto.

La funzione di oggi serve nel caso in cui abbiamo attivato i rapporti e-commerce dalle opzioni generali del profilo, e appunto popola i relativi report. _addItem(id_ordine, sku, nome, categoria, prezzo, quantità) aggiunge un elemento acquistato da un visitatore all’oggetto di tracciamento specificato; _addItem traccia gli oggetti per sku (Stock Keeping Unit, identificativo univoco del prodotto), per cui se nella stessa sessione viene chiamata due volte per lo stesso sku, viene registrato soltanto l’ultimo oggetto. La funzione prende sei parametri, tutte stringhe, in ingresso, che più precisamente sono:

• id_ordine: l’identificativo dell’ordine (fortemente consigliato)
• sku: l’identificativo univoco dell’oggetto (obbligatorio)
• nome: il nome dell’oggetto (facoltativo)
• categoria: la categoria merceologica dell’oggetto, se presente (facoltativo)
• prezzo: il prezzo dell’oggetto (obbligatorio)
• quantità: il numero di oggetti acquistati (obbligatorio)

Un esempio di uso della funzione è questo:

pageTracker._addItem(
   "12345", // id_ordine
   "TA2676", //sku
   "GAin30sec", // nome
   "Libri", // categoria
   "35.99", // prezzo
   "1"  //quantità
 );

Per i parametri non obbligatori, è facoltativo solo l’inserimento del valore all’interno delle virgolette, non la presenza del parametro nella chiamata alla funzione. Per intenderci, l’esempio soprastante si può modificare così:

pageTracker._addItem(
   "12345", // id_ordine
   "TA2676", //sku
   "",
   "",
   "35.99", // prezzo
   "1"  //quantità
 );

Il parametro id_ordine è fortemente consigliato poiché le documentazioni ufficiali sono contrastanti: la mia interpretazione è che si possa omettere solo nel caso di chiamata a _addItem() senza la relativa _addTrans(), per cui in casi tutto sommato abbastanza anomali. Nelle implementazioni che ho visto il parametro era sempre presente, per cui io consiglio di inserirlo.

Google ha introdotto un pulsante per accedere direttamente ad Analytics nel caso in cui fossimo già loggati ad un altro servizio della grande G. Diversamente a quanto accade con Gmail, Google reader, google gruppi, adsense e così via, l’accesso alla pagina http://www.google.com/analytics si risolveva sempre e comunque con una richiesta di login, anche se il cookie relativo era appena stato scritto. Da ieri questo comportamento “anomalo” è stato corretto e ora se accediamo alla suddetta pagina (o alla versione italiana) mentre siamo loggati in un altro servizio ci verrà presentato un pulsantone blu come in figura

nuovo pulsante di accesso a GA

premuto il quale si accederà direttamente all’interfaccia di Analytics.

Niente di sconvolgente per noi assidui utilizzatori dello strumento, abituati da molto tempo a digitare direttamente http://www.google.com/analytics/home, vero? 😉

Accadrà a Parigi, l’11 settembre 2008, quando il programma di analisi del gigante californiano dovrà difendersi dall’accusa di essere “anti-concorrenziale”, poiché gratuito.

La società parigina NSP ha citato Google e Google France davanti al tribunale per il commercio perché “il rilascio di un servizio ad alto valore aggiunto, come ad esempio un servizio di misurazione dell’audience di siti web, mentre esistono in commercio servizi analoghi resi da società come NSP, costituisce un caso esemplare di pratica anticoncorrenziale” (traduzione mia). Secondo l’azienda francese Google può permettersi di lasciare gratuito GA grazie alla sua posizione dominante acquisita nel tempo, e inoltre questa situazione danneggia NSP perché i clienti si chiedono come mai debbano pagare un prodotto che esiste anche in versione gratuita. NSP commercializza una soluzione propria di web analytics.
Google France non ha rilasciato commenti.

Per come la vedo io, se una azienda non è in grado di spiegare ai propri clienti quale sia il valore aggiunto delle proprie soluzioni dovrebbe ripensare un momento al proprio business. Se il prodotto di NSP fa le stesse cose di Google Analytics, forse dovrebbero concentrarsi sullo sviluppo di funzionalità che GA non ha (e come sappiamo ce ne sono parecchie). Dovrebbero fornire una assistenza veloce, puntuale e competente. Dovrebbero, in sostanza, saper vendere quello che producono esaltandone i punti di forza.
Io non penso che Google Analytics sia la soluzione di tutti i mali, e non ho nemmeno mai detto che sia il prodotto giusto per tutti. Cerco di conoscerne le funzioni e i limiti, cerco di pensare a come sfruttarlo fino in fondo, ma con 1Kg di farina non ci si fa una torta per 300 persone; per alcune esigenze esistono soluzioni ben più efficaci del prodotto Google. Sta però alle aziende dimostrarlo e pubblicizzarlo, e non farsi scappare i clienti, perché il vero grande merito di GA (e della sua gratuità) sta proprio nel fatto che ora molte aziende e molte persone si avvicinano alla web analytics, e alcune di queste dopo un percorso più o meno veloce passano poi a soluzioni diverse e spesso a pagamento.

Google Analytics avvicina le persone alla web analytics, è una porta di ingresso verso un mondo sconosciuto (o trattato in modo superficiale) ai più. Per questo ha poco senso fare causa a un prodotto che in realtà – almeno per il momento – fa crescere il mercato invece di ridurlo.

[fonte: ZDnet.fr]

Come segnalato dal puntuale e sempre attento Morevisibility, Google ha silenziosamente aggiornato il codice di tracciamento richiamato dal javascript di GA. Ve ne potete accorgere usando al volo la funzione getVersion() come descritto in questo post: al momento la versione è passata a 4.3, e la modifica più evidente è già visibile nella finestra di selezione del codice da incollare nei profili, come riportato in figura:

(clicca per ingrandire l'immagine)

Il nuovo GATC non prevede più la chiamata a initData(), una funzione indispensabile al corretto funzionamento del sistema che è stata quindi – giustamente – resa invisibile all’utente e richiamata sempre e comunque un modo implicito. Google non ha ancora annunciato ufficialmente la modifica, ma sono abbastanza convinto che la cosa non comporterà la necessità di aggiornare di colpo i nostri script.

Come sicuramente saprete e abbiamo avuto modo di dire, Google Analytics è un sistema di web analytics lato client che fa uso di un javascript per raccogliere informazioni da inviare a un server remoto, il quale provvederà ad elaborarle e a produrre i report (vedi lo schema di funzionamento).

Google tuttavia fornisce un altro strumento di analisi degli accessi, Urchin software (al momento versione 6), al costo di 1895 euro; si tratta di un software in grado di analizzare anche i logfiles prodotti dal websever, quindi un principio “opposto e complementare” a quello usato da Google Analytics. Esistono però delle funzioni che possono essere invocate nello script di tracciamento degli utenti che permettono di scegliere dove inviare tutti o parte dei dati.

La funzione _setLocalRemoteServerMode() serve a dire a GA di inviare i dati che registra sia al server remoto di Google sia a un nostro server locale, di fatto permettendoci di effettuare un backup dei dati grezzi (anche se poi sarà necessario Urchin per elaborarli). E’ una funzione senza argomenti che si invoca semplicemente richiamandola così
PageTracker._setLocalRemoteServerMode();
prima della chiamata a trackPageview().

E’ anche possibile fare in modo che i dati vengano inviati esclusivamente al nostro server, escludendo completamente Google dalla gestione dei dati, sempre a patto di possedere Urchin per effettuare le analisi. Bisogna impostare una chiamata alla funzione _setLocalServerMode() in questo modo
PageTracker._setLocalServerMode();
prima della chiamata a trackPageview(). L’utilità di questa funzione per i possessori di Urchin è grande: si possono utilizzare la sintassi e le funzioni del codice di tracciamento di Google Analytics ed elaborare i dati in locale, e contemporaneamente usare Urchin per analizzare i logfiles e capire, ad esempio, il comportamento degli spider (che vi ricordo NON sono tracciati da GA).

La funzione opposta, _setRemoteServerMode(), è quella invocata per definizione da Google Analytics, e invia i dati ai server collettori dell’azienda di Mountain View. Analogamente alla funzione precedente, tuttavia, i possessori di Urchin potrebbero decidere che parte delle analisi debbano essere svolte dai server di Google. Richiamando la funzione in questo modo
PageTracker._setRemoteServerMode();
prima di trackPageview() faremo svolgere allo script proprio questo mestiere.

Esiste un’ultima parte di codice da prendere in esame in questo post, e va usata ogni qualvolta si invochi una funzione che invia i dati a un nostro server: è la funzione _setLocalGifPath(stringa). Al punto 5 del workflow illustrato nel post “l’ordine è importante” ho detto che il GATC richiede una immagine gif trasparente di 1 pixel per 1 pixel; anche nel caso di Urchin – usato utilizzando il GATC e non tramite logfiles – è necessario usare la gif trasparente, e la funzione _setLocalGifPath() serve a specificare il percorso di questo file, e quindi di conseguenza il percorso del webserver che riceverà in risposta i dati tracciati dallo script, e va invocata prima ancora della riga che setta la destinazione dei dati.

Ho sempre detto ai miei clienti di non fare troppo affidamento sul dato “città” del report provenienza geografica di Google Analytics, perché so per esperienza che è una cosa tanto affascinante quanto potenzialmente fonte di grane per il consulente: i clienti sono esterrefatti dalla precisione dei dati e si perdono in quei report, spesso formulando poi strane richieste.
Il mio consiglio quindi era quello di prendere i dati cum grano salis e semmai di soffermarsi su un dato di livello superiore, su un’area geografica maggiore (per l’Italia le regioni, anche se il dato non esiste per GA).

Tecnicamente l’operazione che Google Analytics compie è detta “geolocalizzazione degli IP” (IP location in inglese) e si basa su un grande database che riporta la lista dei possibili IP e la relativa provenienza geografica; più questo database è accurato e più l’informazione è precisa, e poiché gli IP sono di proprietà degli internet providers, i fornitori di connessioni, di norma sono essi che forniscono la maggior parte dei dati. Ad esempio, uno dei database considerati più attendibili è quello fornito da Ip2Location.com, ma ne esistono innumerevoli altri, free o a pagamento.

Google non precisa da nessuna parte se usa un database di terze parti o se ne ha implementato uno proprio (la qual cosa non dovrebbe stupirci, vista la mole di dati che maneggia), ma l’impressione che se ne trae è che in entrambi i casi la precisione dei dati forniti aumenti nel tempo. Non sono l’unico ad essersene accorto, ma per giustificare questa frase ho estratto l’overlay geografico delle visite al mio blog personale nel mese di Luglio con provenienza Norvegia, dove sono stato in viaggio di nozze e da dove mi connettevo per postare un resoconto a puntate e leggere eventuali commenti (e da dove normalmente non ricevo molte visite, ulteriore controprova):

A parte una indicazione (Lesja), i pallini riproducono esattamente le città da cui mi sono connesso: Oslo, Bergen, Trondheim, Tromso, Alesund, Bodo. L’indicazione sbagliata è comunque geograficamente vicina a un posto dove abbiamo dormito, un piccolo paesino che potrebbe “uscire” con quella indicazione, ma anche nel caso in cui fosse errata, cambierebbe di poco la grande precisione del resto dei dati.
In Italia abbiamo un paio di grandi problemi: Fastweb, che per la sua architettura esce da pochi punti collocati in grandi città (in questo momento ip2location mi colloca a Roma, di solito sembro un milanese), e Tele2 che di norma assegna alle ADSL italiane ip geolocalizzati in Svezia. Al primo non si può ovviare, non in tempi brevi, per il secondo ci sono speranze. Di certo da questo momento guarderò con più fiducia all’overlay geografico, anche se la strada da percorrere è ancora lunga e non si arriverà mai ad avere una accuratezza totale…

Sfogliare il feedreader con post vecchi di giorni ha un unico vantaggio: spesso vedi cose che poi gli autori hanno cancellato, se il crawler di GoogleReader è arrivato in tempo. E’ esattamente il caso di questo post di MoreVisibility, di cui riporto uno screenshot:

Il post non esiste più, ma parla di una cosa molto interessante: la possibilità di creare report personalizzati in Google Analytics. I report personalizzati sono rapporti che normalmente non esistono nel prodotto standard e che si ottengono dopo aver detto al programma quali metriche incrociare. L’ottimo sarebbe se contestualmente all’introduzione di questa feature, Google aumentasse il numero di variabili personalizzabili (user defined – definito dall’utente), in modo da poter introdurre come metriche in GA un numero maggiore di dati strettamente correlati all’attività del nostro sito.

Come dicevo però il post è stato rimosso, non è ben chiaro se su richiesta di Google, se fosse stato pubblicato per errore, o se era semplicemente uno scherzo (nel qual caso ho comunque idea che sia solo una questione di tempo: prima o poi questa feature arriverà…)

Le due funzioni di oggi vengono trattate per completezza, ma oltre che essere funzioni di servizio hanno anche una utilità estremamente limitata. _getAccount() restituisce l’identificativo dell’account associato all’oggetto di tracciamento specificato. Può essere utile nel caso di script complessi che istanziano più oggetti di monitoraggio, oppure più semplicemente incollando questa riga di codice nella barra degli indirizzi del browser e premendo invio mentre si sta visitando un sito con lo script di Google Analytics
javascript:prompt("account della pagina", pageTracker._getAccount());void(0);

(oppure potete trascinare il link mostra account GA nella barra dei preferiti di Firefox e premere il pulsante quando vi fa comodo). La sintassi è
pageTracker._getAccount();

La funzione _getVersion() ci restituisce la versione corrente del codice javascript richiamato dallo script. Poiché la chiamata è sempre uguale e le modifiche al codice vengono fatte centralmente e in modo trasparente da Google, essa è l’unico modo per sapere se lo script è stato aggiornato. La sintassi è
pageTracker._getVersion();

ma è più utile incollare questa riga
javascript:prompt("versione di GA", pageTracker._getVersion());void(0);

nella barra degli url e vedere al volo la versione (al momento della scrittura di questo post, ad esempio, è la 4.2)