Google Analytics in 30 secondi

Inserire transazioni negative in un sistema di web analytics, principalmente quando si parla di e-commerce, ha il vantaggio di tenere sempre allineata la situazione dei ricavi reali con quelli presentati dal sistema. Vediamo come si inserisce una transazione negativa in Google Analytics: innanzitutto è necessario creare una pagina html qualsiasi ed editarla, incollando lo script di Analytics e le funzioni che si vogliono annullare, _addTrans(), _addItem() (o entrambe) e sicuramente _trackTrans().

E’ poi necessario assicurarsi di inserire lo stesso id_ordine della transazione che si vuole annullare. Infine il campo “totale” conterrà un numero negativo, il campo “quantità” un numero sempre negativo ma un “prezzo” positivo (in modo che la moltiplicazione dei due generi un numero negativo), i campi “tasse” e “spedizione” devono azzerare gli stessi campi della transazione con totali negativi.
A questo punto salvando la pagina e visualizzandola su un browser mentre si è connessi ad internet verrà eseguita _trackTrans() e i dati saranno inviati ai server di Google, che provvederà ad annullare la transazione nei conteggi e nei report.
E’ importante notare due cose: la prima è che bisogna assicurarsi di eseguire la pagina una e una sola volta, altrimenti si rischia di inserire transazioni negative pure (+100, -100, -100 fa -200), la seconda è che le singole transazioni restano visibili anche dopo l’annullo. Per cui se il primo del mese si registra una transazione per 3 oggetti e 300 euro, e il 15 del mese una transazione negativa per 1 oggetto e 100 euro, il totale considerando un periodo uguale o superiore al 1-15 del mese sarà 2 oggetti e 200 euro, guardando invece solo l’1 o un suo intorno sempre 3 e 300 e guardando solo il 15 o un suo intorno sarà -1 e -100 (nel caso semplificato in cui non ci siano altre transazioni nel mese).

Alcuni prodotti di e-commerce integrano la possibilità di tracciare le transazioni con Analytics, facilitando la gestione, e alcuni di questi permettono nativamente la gestione di ordini negativi, quindi evitano di dover editare a mano file HTML.

Veniamo alla mia opinione: Brian Clifton nel suo libro sconsiglia l’uso delle transazioni negative, perché falsano la metrica del ritorno dell’investimento. Se investi in advertising una somma X e poi vendi per 10volte X il tuo ROI è quello, e inserendo i resi si modificherebbe falsando le tue decisioni sui prossimi investimenti.

Eppure bisogna anche considerare che indipendentemente da quanto investi, se torna indietro il 100% della merce è giusto che il tuo ROI sia zero: primo perché così sarai costretto a interrogarti sulla qualità dei tuoi prodotti, secondo perché forse non è il caso di puntare su una categoria di prodotti che non soddisfano il pubblico. Quando si tratterà di allocare il prossimo budget di web marketing, si potranno fare scelte più oculate.

Alla fine l’inserimento o meno delle transazioni negative è un’opportunità da considerare attentamente: se si stanno valutando le performance del sito e i ritorni degli investimenti pubblicitari, cioè se si analizza il sito in modo slegato dal mondo fisico, può avere ragione Clifton. Se si fa una valutazione più globale, che abbracci tutta la filiera - dall’acquisizione di un nuovo cliente alla sua soddisfazione finale col prodotto in mano - può sicuramente avere senso inserire le transazioni negative.

[photo credit: jaqian on flickr]

_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

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]
(phoyo credit: MacBuckley on Flickr)

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 InitData().

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 InitData(). 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 InitData() 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à…)