Jun 29 2010

HelpSemaforoQuesto semaforo indica il livello difficoltà del post
semaforo giallo - articolo avanzato

Il filtro per le variabili personalizzate? non si può fare (per ora)

autore: Marco Cilia categoria: filtri tag: , ,

L’altro giorno mi accingevo a mostrare il “famoso” metodo per escludere il proprio IP dalle statistiche quando esso non sia fisso, cioè la pagina nascosta con il valore personalizzato impostato tramite _setCustomVar() (la ex- _setVar() ).
Mi accingevo a mostrare il campo da filtrare nel “pattern filtro” della schermata di GA e non trovavo nessun riferimento. Cerce, cerca e cerca ancora, in effetti non c’è nessun riferimento!.

Questo è assolutamente incredibile, e di certo non è un vanto per Google! Google ha deprecato l’uso di _setVar() – il cui valore era richiamabile nei filtri tramite campo “definito dall’utente” – per consigliare la funzione _setCustomVar(), ma nei filtri non c’è modo di escludere o includere alcunché basandosi sui valori impostati tramite di essa!

E’ invece assolutamente possibile fare segmenti avanzati e report personalizzati usando quei valori, come testimoniato dallo screenshot:

In questo topic del forum ufficiale, ma non è il solo, altre persona lamentano questa mancanza, veramente notevole!


Dec 10 2009

funzioni: _setCustomVar() (e la fine di _setVar)

autore: Marco Cilia categoria: funzioni tag: , ,

A partire dal primo dicembre 2009, la funzione _setVar() è deprecata, il che significa che non va più usata nel proprio codice di tracciamento. Nel contempo sotto al report “definito dall’utente” è stato aggiunto “Variabili personalizzate”, che consente di monitorare quel che viene definito con la nuova funzione. Il vecchio report è adesso popolabile soltanto tramite filtro.

_setVar() è stata invece sostituita dalla nuova _setCustomVar(indice, nome, valore, scopo), che ha le stesse possibilità della precedente, ma aggiunge ulteriori livelli di utilizzo e possibilità di tracciamento. Vediamo come:

  • indice è un numero intero, da 1 a 5, e rappresenta lo “slot” nel quale il valore viene inserito.
  • nome è una stringa, e rappresenta il nome che diamo alla variabile impostato.
  • valore è una stringa e rappresenta il contenuto della variabile personalizzata
  • scopo è una numero intero – opzionale – che possiamo usare per tenere traccia del perché quella variabile viene impostata. Valori tipici sono 1, 2 e 3 che nell’idea di Google Analytics rappresentano nell’ordine variabili impostate a livello di visitatore, di sessione o di pagina.

Dal punto di vista del programmatore la funzione ritorna un valore booleano: true se la variabile personalizzata è stata impostata correttamente, false se qualcosa è andato storto. Tenete a mente che la somma dei caratteri di nome e valore non può sorpassare i 64 caratteri.

Perché è utile dichiarare uno scopo? perché la nuova funzione _setCustomVar() può essere usata in contesti differenti rispetto alla vecchia _setVar(), ad esempio per raggruppare i contenuti senza trucchi. Il codice necessario per raggruppare le pagine della categoria “sport” potrebbe ad esempio essere:
pageTracker._setCustomVar(1,"sezione","sport",3);

Se per adesso non avete voglia di fare troppe modifiche ma vi interessa solo continuare a far fare ad Analytics quello che facevate con _setVar(), la traduzione della vecchia riga

trackPageview._setVar('miovalore');

si fa – ad esempio – con

trackPageview._setCustomVar(1,'valore_pers','miovalore',1);

Si è inserito il valore di 1 nello scopo perché la vecchia funzione impostava SOLO valori a livello utente, che sono appunto quelli con scopo 1.

Ricordatevi sempre che _setCustomVar() va chiamata PRIMA di un trackPageview() o di un _trackEvent(), poiché la funzione imposta il valore ma non comunica niente ai server, mentre le altre due poi inviano tutte le informazioni, quindi anche il valore appena impostato, a Google Analytics


Dec 09 2009

Regalo di Natale da Google Analytics

autore: Marco Cilia categoria: generale tag: , ,

Anche io inizio a far fatica a stare dietro agli aggiornamenti del nostro sistema di web analytics preferito, e vi garantisco che ho innumerevoli fonti che leggo spessissimo. Basta distrarsi un giorno e gli ingegneri di Mountain View lanciano nuove funzionalità, aggiornano l’interfaccia, fanno annunci. Vediamo quindi cosa troveremo nel pacchetto che Google Analytics ha deciso di lasciarci sotto l’albero di Natale:

  • Annotazioni: ne aveva già parlato Enrico sul blog di TSW, ma volevo aspettare un post ufficiale. Si tratta di una funzionalità richiesta a gran voce da molti, specie quando si usa GA in team grandi o geograficamente distribuiti. Si tratta di poter aggiungere annotazioni, etichette, scritte, direttamente sui grafici, in modo che sia chiaro a tutti cosa è successo in un dato punto del grafico, oppure che si possa aggiungere un promemoria per una analisi successiva o annotare un down del server. Che siate del reparto marketing, vendite o tecnici informatici, troverete questa funzione molto utile per far sapere a tutti coloro che hanno accesso al profilo cosa succede ai dati.
  • Variabili personalizzate nei segmenti avanzati: vi sarà finalmente la possibilità di utilizzare le nuove variabili personalizzate (di cui parleremo a breve) per definire segmenti basati sui dati in esse contenuti.
  • Variabili personalizzate nei report personalizzati: come conseguenza del punto precedente, le variabili personalizzate appariranno anche nell’interfaccia di creazione dei rapporti personalizzati, e saranno incrociabili con le altre metriche/dimensioni.
  • Nuovo processo di creazione del codice di monitoraggio: questo è interessante. Uno degli scogli più grandi nell’uso di alcune funzioni avanzate è il loro collocamento nello script di tracciamento, dopo aver capito quale fosse la funzione adatta allo scopo (l’esempio classico è il tracciamento multidominio o multisottodominio). D’ora in poi Google Analytics proporrà un processo di creazione del codice guidato, e rispondendo ad alcune domande sarà possibile avere il codice già bello e pronto da incollare. Come bonus c’è la possibilità di inviare per email il codice finito.
    nuovo processo di creazione del codice di monitoraggio
    [immagine di Google]
  • Nuova versione delle API: per ora solo un annuncio, le novità devono essere così corpose che stanno preparando un post a parte solo per le API

Che ne dite, Babbo Natale Analytics è stato buono con noi quest’anno? 😉


Jul 11 2009

Impostare più valori nei segmenti personalizzati

autore: Marco Cilia categoria: javascript tag: , ,

Nel post in cui spiegavo l’uso di _setVar() ho detto che Google mette a disposizione un unico cookie contenente un solo valore e che quindi l’unico modo per avere più dati riferiti ad un unico visitatore dentro al segmento “definito dall’utente” senza sovrascriverne altri era di separarli con un segno pipe (o altri segni convenzionali); inoltre auspicavo che Google aumentasse questo limite di Analytics.

Ebbene, mi ero dimenticato che in realtà il prolifico blog di Lunametrics aveva già ovviato a questa situazione nell’aprile del 2008, con un magnifico lavoro di John Henson. In verità la tecnica non è molto difforme dalla precedente, ma aggiunge dei controlli che potrebbero risultare utili.

Ad esempio – seguendo l’esempio di John – impostando due chiamate a


superSetVar('/eyes=blue');
superSetVar('/hair=blonde');

il cookie __utmv li conterrà entrambi. Ma se l’utente diventasse calvo ( 😀 ) e volesse informarne il sito, John ci mette a disposizione una comoda funzione di “unset”:


unSetVar('/hair=');

in grado di ripulire solo i valori associati ai capelli, per poi eventualmente riscriverli.
Per usare questo nuovo set di funzioni è sufficiente scaricare il file super_set_var.js dal sito di Lunametrics e caricarlo sul proprio sito, poi modificare il GATC di Google Analytics aggiungendo una riga


<script type="text/javascript">
var gaJsHost = (("https:" == document.location.protocol) ? "https://ssl." : "http://www.");
document.write(unescape("%3Cscript src='" + gaJsHost + "google-analytics.com/ga.js' type='text/javascript'%3E%3C/script%3E"));
</script>
<script type="text/javascript" src="/path/to/super_set_var.js"></script>
<script type="text/javascript">
var pageTracker = _gat._getTracker("UA-xxxx-y");
. . .
</script>

dove /path/to/ è il percorso dove si trova il file, UA-xxxx-y è il vostro profilo di GA e . . . sono eventuali altre funzioni aggiuntive del codice di monitoraggio.
Una cosa da tenere presente è che le modifiche fatte al cookie __utmv valgono solo dalla sessione successiva del visitatore.


Jul 06 2009

funzioni: _setVar()

autore: Marco Cilia categoria: funzioni tag: , , ,

Mi sono accorto che pur avendone parlato più volte non ho mai scritto il post di riferimento della funzione _setVar(stringa). Questa funzione serve a scrivere un valore all’interno del cookie __utmv, e il valore è a discrezione del webmaster del sito; una volta che il contenuto del cookie è impostato, esso verrà trasmesso in tutti i successivi invii di codice a Google Analytics (ovvero ogni volta che verrà richiamata la gif trasparente), permettendo così di “taggare” il visitatore (attenzione: il visitatore e non le visite).
Un esempio tipico è quello di assegnare tramite _setVar il valore “loggato” a chi effettua il login sul sito, in modo da poter discernere la sua attività da quella di chi non l’ha fatto.

L’uso è molto semplice, si tratta di impostare la riga

trackPageview._setVar('miovalore');

in un punto qualsiasi della pagina, sull’onclick di un elemento, sull’onload del body. Ovunque insomma ci sia bisogno di impostare il cookie che da lì in poi – e per i successivi due anni – manterrà il valore, a meno che esso non sia sostituito da un’altra funzione _setVar impostata dal medesimo codice di GA (quindi le _setVar di due siti diversi non interferiscono, come è ovvio che sia). Su un blog WordPress, ad esempio, sarebbe possibile assegnare un valore corrispondente al livello dell’utente che si collega (Administrator, Editor, Contributor, ecc.).
Il famoso sistema supercookie per tracciare tutte le fonti di una conversione separa diversi valori di setvar con un segno | (pipe), e lo fa per ovviare all’unico vero grande limite di questa gestione da parte di GA: esiste un solo cookie __utmv, quindi si può attribuire un solo valore ad ogni utente; oppure si possono assegnare più valori come nel supercookie, ma essi verranno sempre riportati come aggregati (per intenderci, ogni valore è una riga del report).
La speranza di tutti noi è che un giorno Google decida di aumentare i possibili valori di questo cookie mantenendoli però separati, perché la gestione della funzione _setVar() è molto comoda.

A livello di report il valore impostato da _setVar() viene scritto nel campo “Definito dall’utente” (User Defined se usi l’interfaccia inglese) e lo si può trovare nel report omonimo all’interno del gruppo “visitatori” oppure come valore utilizzabile nel menu a tendina delle segmentazioni. Una lettura esaustiva, in inglese, sui report relativi alla segmentazione viene da morevisibility.com, da cui si evincono due informazioni interessanti:

  • nel caso in cui un utente cambi il valore di _setVar() durante una sessione di visita, GA attribuirà l’eventuale conversione al primo valore letto per quella sessione.
  • le pagine viste, al contrario, vengono tutte attribuite all’ultimo valore

Un’altra cosa su cui vale la pena di ragionare è che _setVar() rappresenta l’unico punto di ingresso in GA in cui è possibile inserire un valore arbitrario. Tutti gli altri valori infatti dipendono dall’attività di navigazione e sono dati puri o derivati da calcoli. Questo cosa significa? significa che, fatte salve le limitazioni sulla privacy imposte dai termini del servizio, dentro al cookie __utmv possiamo infilare qualsiasi cosa ci sia utile avere direttamente dentro all’interfaccia di Google Analytics affinché possa essere incrociata con gli altri dati, ad esempio i dati demografici dei visitatori da utilizzare successivamente per il bidding demografico di AdWords.

[edit: è uscito giusto in questi giorni un post sul blog ufficiale che parla dei segmenti definiti dall’utente e di _setVar()]


Jun 16 2009

Super cookie con tutte le sorgenti di una conversione

autore: Marco Cilia categoria: javascript tag: , , , ,

supercookieGiovanni mi segnala per email un articolo molto molto interessante per chi ha il cruccio del last cookie win / first cookie win. Ricordo infatti a tutti che Google Analytics è un sistema “last cookie win”, in cui la conversione viene attribuita all’ultima sorgente che ha portato la visita, con alcune regole specifiche per il traffico diretto. Altri sistemi invece preferiscono la logica del “first cookie win” (e su GA possiamo impostarla sulle campagne taggate tramite il parametro no_override), ma quale che sia la logica applicata il difetto che tutti riconoscono è quello di non consentire di tenere traccia di tutte le diverse sorgenti che hanno contribuito a formare nel cliente la decisione di convertire.

So che alcuni sistemi stanno provando (non l’ho mai provato, e correggetemi se sbaglio, ma mi pare che sitovivo abbia una soluzione di questo tipo) a sviluppare logiche miste di attribuzione di una conversione a più sorgenti, ma da oggi grazie al lavoro di un Google Analytics Authorized Consultant possiamo avere qualcosa di similare – ancorché abbastanza di base – per tracciare tutte le sorgenti che hanno concorso ad una conversione: loro lo chiamano “super cookie“.

Questo super cookie si occupa di raccogliere il referrer di ogni visita, di salvarlo in un nuovo cookie chiamato _utmcw e di chiamare la funzione _setVar() impostando il valore di questo cookie come parametro della funzione stessa. I vari referrer non vengono sovrascritti ma messi in coda e separati da un carattere |.
Attraverso un rapporto personalizzato, composto almeno dal parametro “totale completamenti all’obiettivo” e della dimensione “valore definito dall’utente”, avremo modo di verificare tutte le sorgenti che hanno generato conversioni, nella forma (e nell’ordine esatto) ad esempio di:

direct|google(organic)(keyword1)|yahoo(organic)(keyword2)|direct|referral(www.sitoesterno.it)

che ad esempio si riferisce ad una conversione avvenuta alla quinta visita, la prima delle quali diretta (digitazione dell’url o bookmark, ad esempio), la seconda da google con ricerca keyword1, la terza da yahoo con ricerca keyword2, la quarta diretta e la quinta tramite un link dal sito sitoesterno.it. Tramite il super cookie si possono ad esempio conoscere esattamente TUTTE le parole chiave e le frasi che sono state cercate dall’utente prima di convertire

Il punto forte di questo script è che ricostruisce da solo la sorgente, evitando il problema della discrepanza di scrittura del cookie quando avvengono due referral nella stessa sessione di cui vi ho già parlato.

Il punto debole, come ho fatto notare nel post degli autori, è che non è previsto (ma non saprei nemmeno come implementare) un meccanismo di pulizia del super cookie, che continua ad essere aggiornato anche dopo la conversione. Per un visitatore regolare che non pulisce mai i cookie c’è il rischio che esso si gonfi senza sosta. Un punto intermedio è che il supercookie traccia e scrive solo visite provenienti dalle sorgenti “standard”, quindi traffico diretto, referral, ricerche organiche e CPC. Per tracciare anche le campagne, ad esempio le campagne email taggate, il sorgente javascript dello script andrebbe modificato, e sono sicuro che essendo GAAC loro possono sicuramente farvi avere un preventivo per questa operazione 🙂

L’utilizzo dello script è abbastanza semplice. si tratta di scaricare il file dal post linkato, aprire il file cw-algorithm.js e modificare la riga 7
var __ignore = "www.ignore.co.uk";
inserendo l’indirizzo del sito che ospita lo script. Dopodiché caricare i due file sul server web e modificare il codice di tracciamento di Analytics come segue:


<script type="text/javascript"> 
var gaJsHost = (("https:" == document.location.protocol) ? "https://ssl." : "http://www.");
document.write(unescape("%3Cscript src='" + gaJsHost + "google-analytics.com/ga.js' type='text/javascript'%3E%3C/script%3E"));
</script> 
 
<script type="text/javascript" src="/cw-setup.js"></script> 
 
<script type="text/javascript"> 
var cookieTracker = _gat._getTracker("UA-XXXXXX-X");
cookieTracker._trackPageview();
</script> 
 
<script type="text/javascript" src="/cw-algorythm.js"></script> 
 
<script type="text/javascript"> 
cookieTracker._setVar(ConversionWorks);
</script> 
 
<script type="text/javascript"> 
var pageTracker = _gat._getTracker('UA-XXXXXX-X');
pageTracker._trackPageview();
</script> 

sostituendo ai vari UA-XXXXXX-X il vostro numero di UA. Notare che la parte di codice riferita a cookieTracker non è un errore, e serve a non sporcare i vostri cookie di default con i valori del super cookie.

In definitiva mi sembra un’aggiunta utile a chi non è soddisfatto del modo in cui vengono attribuite le conversioni alle sorgenti, e una fonte di informazioni utili a prescindere per tutti gli altri. Se il vostro “Valore definito dall’utente” (e/o la vostra funzione _setVar() ) è vuoto, questo può sicuramente essere un sistema valido per usarlo.

Post originale su conversion works e pacchetto da scaricare

image credit: conversionworks.co.uk


Apr 13 2009

Uso di _setVar() su più domini

Quando le cose da tenere d’occhio iniziano ad essere molte e variegate bisogna fare attenzione: Google Analytics fornisce gli strumenti, ma bisogna stare attenti a possibili effetti collaterali non documentati. Prendiamo ad esempio l’ultimo post di Lunametrics, che riporta una situazione con un codice di monitoraggio per più domini di questo tipo:


var pageTracker = _gat._getTracker("UA-xxxxxxx-y");
pageTracker._setVar(’buyer’);
pageTracker._setAllowAnchor(true);
pageTracker._setAllowLinker(true);
pageTracker._setAllowHash(false);
pageTracker._trackPageview();

questo codice inizializza l’oggetto di tracciamento, poi scrive nel cookie __utmz il valore buyer (ovvero assegna il visitatore al segmento compratori), poi permette l’uso del cancelletto nelle campagne, poi permette di trasportare il cookie da un dominio a un altro, disabilita il check dell’integrità dei cookie basato sul dominio (quando si raccolgono dati da più sottodomini in un unico account), e infine raccoglie i dati e li invia al server di Google.

Quale è il problema di questo codice? il problema è che _setAllowHash di fatto cambia il formato di scrittura del cookie, e ci sono due funzioni che scrivono cookie: _setVar che si trova prima di setAllowHash e trackPageview che invece si trova dopo.
In questo modo GA va in confusione e perde informazioni sulla sessione e sul referrer, assegnando a traffico diretto la seconda – falsa – visita.

La soluzione è quella di chiamare _setVar() sempre dopo _setAllowHash() (o _setDomainName(‘none’); se lo usate); bisogna sempre tenere presente che il javascript di Google Analytics ha a che fare con i cookie, e che alla fine sono loro che “comandano” quel che poi vediamo nei nostri report.


Feb 27 2009

Due codici di monitoraggio nella stessa pagina

autore: Marco Cilia categoria: codice di monitoraggio tag: , ,

Lego gemelliUna delle domande che mi viene rivolta più spesso – e che noto essere un evergreen tra le frasi di ricerca dei visitatori in arrivo – riguarda la presenza di due o più codici di monitoraggio di Google Analytics sulla stessa pagina/sito. Con la vecchia versione dello script, quella che fa riferimento a urchin.js, le cose erano leggermente più complicate di adesso, ma non ne parleremo. Cosa aspettate ad aggiornare il GATC a ga.js? 🙂

Poiché il nuovo codice di monitoraggio è scritto seguendo la logica della programmazione a oggetti, per inviare i dati a due profili differenti è sufficiente creare due distinti oggetti di tracciamento. In GA gli oggetti di tracciamento sono quelli identificati dalla riga di codice
var pageTracker = ...

In effetti quando nei post ci si riferisce a pageTracker si commette una imprecisione: quello è il nome dell’unico oggetto creato per definizione dal codice che Google ci mette a disposizione, ma nulla vieta di cambiargli nome o, appunto, crearne più d’uno. Ecco allora che un codice fatto così:


<script type="text/javascript">
var gaJsHost = (("https:" == document.location.protocol) ? "https://ssl." : "http://www.");
document.write(unescape("%3Cscript src='" + gaJsHost + "google-analytics.com/ga.js' type='text/javascript'%3E%3C/script%3E"));
</script>

<script type="text/javascript">
var pageTracker = _gat._getTracker("UA-12345-1");
pageTracker._trackPageview();

var MarcoTracker = _gat._getTracker("UA-99999-3");
MarcoTracker._trackPageview();
</script>

è perfettamente legale e funzionante, ed invierà i dati all’account 12345 profilo 1 e 99999 profilo 3. Se la necessità è quella di inviare dati a più di due account si procederà di conseguenza creando ulteriori oggetti di tracciamento con nomi differenti. Questi oggetti sono (o meglio, dovrebbero essere, ma lo vediamo più tardi) completamente indipendenti l’uno dall’altro, per cui è possibile aggiungere funzioni al primo piuttosto che al secondo.

Nella realtà le cose sono leggermente differenti, e Lunametrics ci spiega perché: nonostante i codici di tracciamento facciano riferimento ad account differenti, i cookie – che ricordo sono scritti in base al dominio e non all’account Analytics – sono gli stessi per tutti e due (o più) oggetti di tracciamento.
Tra i casi di “sicuro insuccesso” relativi alla presenza di più codici di monitoraggio in una stessa pagina, Lunametrics ne cita tre che vale la pena di riportare:

1 – Codici differenti


var pageTracker = _gat._getTracker("UA-11111-1");
pageTracker._setAllowHash(false);
pageTracker._setAllowLinker(true);
pageTracker._trackPageview();

var MarcoTracker = _gat._getTracker("UA-22222-1");
MarcoTracker._trackPageview();

Nell’esempio di Lunametrics il primo oggetto di tracciamento include le funzioni _setAllowHash e _setAllowLinker e il secondo no. In questo caso i due oggetti tentano di scrivere lo stesso cookie con intenzioni e formati diversi.

2 – Pagine differenti

Nel caso in cui uno dei due codici non sia inserito in tutte le pagine, magari in seguito a una condizione if impostata male o non realizzata, alcune pagine vengono tracciate in un account e in un altro no. Il codice di tracciamento “in difetto” vedrà i cookie che erano originariamente stati creati da una pagina che non ha quel codice. La prima pageview registrata dal secondo codice avrà informazioni di referrer diverse, poiché penserà di essere la prima pagina della visita mentre in realtà è la seconda, e così via…

3 – Segmenti personalizzati in base a _setvar()

Il segmento personalizzato “Valore definito dall’utente” viene impostato tramite la funzione _setVar() e immagazzinato nel cookie __utmv. Siccome i due codici usano gli stessi cookie, un segmento personalizzato creato dal primo codice è automaticamente creato e disponibile anche per il secondo. Questo comporta l’impossibilità di avere, ad esempio, un valore impostato su “loggato/non loggato” per il primo oggetto e “maschio/femmina” per il secondo. Poiché l’esecuzione di javascript è sequenziale nella pagina, il secondo codice sovrascriverà sempre il cookie e l’unica informazione disponibile per il segmento, alla visita/pagina successiva, sarà quella impostata dal quell’oggetto di tracciamento.

Se decidete di implementare più codici di monitoraggio di Google Analytics su uno stesso sito, o una stessa pagina, dovete prestare attenzione alle possibili conseguenze.
[photo credit: oskay su flickr]


Jan 28 2009

Il vostro bounce rate salirà, ma niente panico!

autore: Marco Cilia categoria: generale tag: , ,

Bounce by GreencolanderHo letto questa notizia su tre diversi blog, ma ho aspettato a segnalarla finché non è apparsa su una fonte che ritengo autorevole: Google ha modificato il modo in cui conteggia i bounce rate in presenza della funzione _setVar(). [edit: ecco il post sul blog ufficiale | e in italiano]

Fino ad oggi se un visitatore guardava una sola pagina, non veniva conteggiato come bounce se nella stessa pagina chiamavate la funzione _setVar(), che serve ad attribuire il visitatore ad un segmento personalizzato tramite scrittura del cookie aggiuntivo __utmz. Infatti per ovviare a questo problema Lunametrics aveva proposto un workaround che vi segnalai a tempo debito.

Da oggi questo fatto non è più vero, e una visita di una sola pagina vista sarà considerata un bounce a prescindere dalla presenza della funzione. Tra le altre cose questa modifica si rifletterà anche sul tempo medio sul sito e sulla pagina, poiché in presenza di due timestamp GA è in grado di calcolare un tempo, cosa che invece ovviamente non può essere vera per un utente che rimbalza. In precedenza invece Analytics assegnava tempi brevissimi (zero, uno o due secondi, a seconda della velocità di caricamento della pagina e del tempo trascorso tra la chiamata a _trackPageview() e _setVar() ) alla pagina.

Da quel che ho capito, il comportamento non cambia in presenza di un evento, come scrissi in questo post

Image credit: Greencolander on Flickr


Sep 15 2008

1 visita, 1 pageview e tasso di rimbalzo 0%

autore: Marco Cilia categoria: codice di monitoraggio tag: , ,

Questo è un articolo che interesserà sicuramente Fello, che ci ha proposto una questione simile nei commenti al post “keyword con valori a zero” e io non sono mai riuscito a riprodurla nei miei report. Adesso Lunametrics ci spiega per filo e per segno perché questo accade: io non ci sarei mai arrivato, devo ammettere i miei limiti, perché comunque sia mi sembra un comportamento sbagliato da parte del codice di tracciamento. La sostanza del problema è che se avete la funzione _setVar() che imposta un valore nel cookie del visitatore, essa subito dopo aver scritto o modificato il cookie lo comunica a Google Analytics.

Quindi anche nel caso di una visita di una sola pagina vista, se c’è _setVar avvengono DUE interazioni con GA, e lui le interpreta come se non fossero un bounce, anche se di fatto non sono due pagine viste.

La soluzione è un workaround che inganna il codice di Analytics, creando un oggetto di tracciamento legato a un account che non esiste, e facendo scrivere il cookie a lui, e poi chiamando _trackPageView() usando l’oggetto legato all’account corretto, che genererà la pagina vista corretta portandosi già dietro il valore della variabile definita dall’utente tramite setVar, così:


var fakeTracker = _gat._getTracker("UA-1");
fakeTracker._setVar('/eyes=blue');
var pageTracker = _gat._getTracker("UA-xxxxxxx-y");
pageTracker._trackPageview();

L’ho verificato personalmente e funziona senza problemi. i cookie scritti sono infatti indipendenti dall’account analytics specificato usando solo queste funzioni. Il rovescio della medaglia è che se usate questo metodo dovrete portarvi dietro il secondo oggetto di tracciamento per tutte le altre funzioni di GA che vorrete usare.