Google Analytics in 30 secondi

Ecco un interessante script realizzato da Allaedin Ezzedin di e-nor, che permette di conoscere in tempo reale quale è la fedeltà del visitatore. La fedeltà è espressa in Google Analytics dal numero di visite – compresa quella corrente – che ogni utente ha fatto sul vostro sito. Nei report trovate questa informazione cliccando su VISITATORI -> fedeltà visitatori -> fedeltà.

Nei segmenti avanzati è invece possibile guardare solo il traffico realizzato – ad esempio – da chi è alla decima visita (e SOLO alla decima) creando un segmento con i parametri conteggio delle visite -> corrisponde esattamente -> valore: 10.
Se ad esempio vi accorgeste che in generale l’utente converte meglio tra la quarta e la sesta visita, come potreste usare questa informazione? non sarebbe bello potergli presentare una call-to-action personalizzata, magari in una posizione ancora più favorevole? o al contrario, potreste usare l’informazione per cercare di migliorare le conversioni nelle visite che il report vi dice non convertono mai.

Lo script di Allaedin serve proprio a questo: permette di leggere il cookie __utma del visitatore e quindi di sapere il numero di visita nel quale esso ricade. Lo script è questo

function get_visit_count(str)
{
var i, vc='-';
if (str != '-') {
   i = str.lastIndexOf(".");
   i++;
   vc = str.substring(i);
   }
return vc;
}

e restituisce un numero intero corrispondente al numero di volte in cui l’utente che sta navigando è stato sul vostro sito.

Esiste anche la versione con il numero di pagine viste, però all’interno di una sessione: ad esempio potrebbe servirvi per “premiare” un visitatore che ha sorpassato le 20 pagine viste in una sola visita. Di nuovo, ecco il codice, questa volta basato sul cookie __utmb:

function get_pageview_count(utmb,utmc)
{
var i, j, pc='-';
if(utmb != '-' && utmc != '-'){
   utmc=utmc+'.';
   i=utmc.length;
   j=utmb.indexOf(".", i);
   pc=utmb.substring(i,j);
   }
return pc;
}

entrambi gli script sono disponibili in un file, scaricabile dal sito di e-nor.com, che contiene anche un altro pezzo di codice essenziale al funzionamento. Il file è disponibile nel post, e le istruzioni dicono di aggiungere la chiamata a SessionTracker.js subito DOPO il codice di Google Analytics, in modo che alle funzioni vengano passati i valori già aggiornati di visita e numero di pagine viste.

Tracciare cosa cercano gli utenti tramite il motore interno è molto importante quando si fa web analytics, perché è fonte di informazioni dirette sui contenuti più interessanti che spesso non sono abbastanza valorizzati. I dati che si possono estrarre guardando alla ricerca interna sono però molti di più, e combinarli con il resto delle informazioni che il software di web analytics ci fornisce accresce di molto le nostre possibilità di comprendere meglio cosa accade sui siti.

In effetti la ricerca interna è fonte anche di un’altra importantissima informazione, se riusciamo a catturarla: cosa l’utente cerca ma non trova sul nostro sito, cioè contenuti che ci vengono richiesti ma che non forniamo. Questo è il motivo per cui Justin Cutroni ha scritto un interessante post su come tracciare le ricerche con zero risultati (link non più disponibile). Purtroppo è un post molto tecnico e non credo riuscirei e renderlo meno “spesso” di così traducendolo. Se volete tracciare le ricerche con zero risultati, quella è la via.

C’è però una buona notizia: se usate WordPress, monitorate la ricerca interna e avete il plugin per Google Analytics di Yoast (tra l’altro tre condizioni che avevo già raccomandato in passato 😉 ) vi basta aggiornarlo all’ultima versione – cioè la 3.2.3 – e seguire le semplici istruzioni contenute in questo video:

Configuring Site Search Tracking in Google Analytics from Joost de Valk on Vimeo.

Ovvero andare in modifica del profilo, poi dire “Sì” alla domanda “Utilizzi categorie per la ricerca su sito?”, digitare cat come “Parametro di categoria” e infine dire a GA “Sì, rimuovi i parametri di categoria dall’URL” tramite l’ultima opzione. Facile, no? 🙂

Ulteriore segno del grado di interesse che desta la ricerca interna è questo post di Tom Pitts, che consente di tracciare anche il numero di risultati per ogni ricerca. Per utilizzare questo metodo è necessario modificare l’header globale del template, la pagina che mostra i risultati delle ricerche e il codice di monitoraggio di GA.

In passato ho parlato spesso dei cosiddetti “profili-copia” o “profili-clone”, ovvero profili di Google Analytics che si basano sugli stessi dati in ingresso del profilo di cui sono copie (quindi non c’è bisogno di incollare un altro codice di monitoraggio) ma cui si possono applicare filtri differenti, goal differenti, accessi differenti.
Si è detto che anche con l’introduzione delle più recenti funzionalità quali i segmenti avanzati esistono ugualmente buone ragioni per usare i profili copia.

Purtroppo l’interfaccia di Google Analytics in questo frangente è piuttosto deficitaria, e molte persone non capiscono bene come clonare un profilo. Per farlo bisogna andare dentro all’account che contiene il profilo da copiare e premere “Aggiungi nuovo profilo”, esattamente come si farebbe per un nuovo sito. A questo punto la prima selezione si trova su “Aggiungi un profilo per un nuovo dominio”, invece noi dobbiamo spostarla su “Aggiungi un profilo per un dominio esistente“. Fatto questo apparirà un menu a tendina con l’elenco dei profili già esistenti per quell’account, dal quale selezionare il profilo da clonare.
Le parole nuovo dominio e dominio esistente sono fuorvianti per la maggior parte delle persone, ma non si riferiscono ovviamente all’effettiva registrazione del dominio presso gli enti preposti. Significano più banalmente “aggiungi un nuovo profilo” e “copia un profilo esistente”. Anzi, la formula che propongo è ugualmente errata, perché va sempre tenuto presente che i profili-clone non copiano i dati già processati, ma iniziano a riceverli dal momento della creazione.

Clonare un profilo, però, lo rende vergine rispetto a tutte le impostazioni che sono state fatte sull’originale. Quindi i settaggi andrebbero reimpostati manualmente, i filtri riassegnati uno ad uno e i goal ricreati, sempre ammesso che si voglia avere gli stessi filtri e gli stessi goal. Ma non è difficile immaginare uno scenario simile: avete un profilo esistente, con alcuni filtri avanzati e 4 goal. Stringete un accordo con un partner per alcuni link di riferimento, con pagamento in base al raggiungimento dei 4 goal. Quel che vi serve per dargli l’accesso alle statistiche è un profilo-clone completamente identico al principale con in più un filtro sul referrer, in modo che il partner veda solo ed esclusivamente i dati dei visitatori che ha inviato lui.

Invece di copiare a mano tutte le impostazioni, ROI Revolution ha prodotto uno script GreaseMonkey in grado di copiare le impostazioni e i goal da un profilo ad un altro (anche se i link puntano a pagine diverse, lo script è unico ed è indifferente da dove lo scaricate). In questo modo con pochi click avrete una copia perfetta del profilo, cui potrete facilmente aggiungere o cambiare alcune cose senza dover rifare tutto daccapo. Mancano i goal, ma a quello ha pensato Lunametrics, con una intera estensione per Firefox e relativa toolbar.

Con questi tre strumenti (anche se fisicamente sono due) sarete in grado di replicare interamente un profilo in pochi secondi, e avrete così modo di fare esperimenti senza paura di rovinare dati, potrete dare accessi differenziati alle statistiche o potrete fare analisi più approfondite su alcuni segmenti di visitatori.

[photo credit: adactio on Flickr]

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.

Una delle più accese discussioni nel forum ufficiale e nella twittersfera ultimamente è quella relativa ad un presunto problema di sicurezza del codice di Google Analytics, per cui i visitatori vengono infettati. Un ottimo riassunto della questione la fa Stéphane Hamel sul suo blog.

Il problema non è relativo al codice di GA, ma prende di mira il codice di GA. In sostanza attraverso un accesso non autorizzato allo spazio sul server che ospita il sito, viene introdotta una regular expression javascript nel codice del sito in grado di cambiare la chiamata a http://www.google-analytics.com/ga.js in ttp://91.212.65.148/ga.js. Questo file poi esegue un’altro script php che sfrutta una vulnerabilità di Adobe Reader per infiltrarsi nei PC dei visitatori. Come già detto, questo non è un problema di Google Analytics, ma è un problema che prende di mira Google Analytics per via del fatto che è molto usato sui siti (ricordate? più del 50% dei diecimila siti più popolari secondo Alexa) di tutto il mondo.

Il modo migliore per capire se si ha a che fare con il problema è dare un’occhiata al codice sorgente di una propria pagina: se il codice di GA è sempre il solito, come lo conosciamo, non c’è problema; Se al contrario sono presenti caratteri strani ( @ # $ eccetera) allora è il caso di preoccuparsi. Nel qual caso è bene pulire il proprio PC con antivirus, antitrojan e antispyware, cambiare le password FTP del sito (e magari usare sFTP (secure File Transfer Protocol) invece del normale FTP, e reincollare il codice corretto di GA, che trovate ovviamente in modifica del profilo -> verifica stato

Quello che vedete nell’immagine qui a fianco è un pezzo del codice sorgente del javascript di Google Analytics, per capirsi quello che è visibile all’indirizzo http://www.google-analytics.com/ga.js. Si tratta del file contenente tutte le funzioni di base che permettono al codice di catturare ed inviare i dati che poi leggiamo nei nostri report.

A tutti gli effetti è un normale file javascript, ma per contenerne le dimensioni gli ingegneri di Google hanno fatto due cose: hanno eliminato gli spazi superflui e gli “a capo” e hanno chiamato tutte le variabili e le funzioni con nomi di lettere, due cose che gli esseri umani non fanno mai quando scrivono codice, per leggibilità e manutenzione, ma che non dà nessun fastidio ai computer che le istruzioni le eseguono.

Se per caso avete necessità di leggere il sorgente, perché volete capire cosa fa una certa funzione, perché volete estenderla o per curiosità, è indubbiamente più utile far tornare almeno gli spazi e i ritorni di riga, visto che non è possibile riassegnare alle funzioni nomi parlanti in modo automatico. Per avere un file leggibile basta andare all’url del sorgente, selezionarlo tutto e copiarlo, e poi incollarlo nello strumento Javascript Beautifier, che ce ne renderà una versione decisamente più digeribile per i nostri occhi. Le prime righe ad esempio diventano:

var _gat = new Object({
    c: "length",
    lb: "4.3.1",

il che tra l’altro mi fa notare al volo che la versione corrente dello script è passata da 4.3 a 4.3.1. Probabilmente in concomitanza con l’introduzione di Bing tra i motori di ricerca riconosciuti.

[tnx to AnalyticsPros]

Giovanni 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

La domanda che mi fa Francesca in un commento è semplice:

Ciao!
La mia è più che altro una curiosità:
ma se inserisco due volte lo stesso identico codice in una pagina cosa succede? Raddoppiano tutti i dati??

La risposta avrebbe dovuto essere abbastanza semplice, ma siccome avevo tempo ho messo su un piccolo esperimento per avere più dati. All’inizio, lo ammetto, ero sconcertato; poi mi sono accorto di un mio errore e la cosa è tornata ad avere un senso.
La situazione, piuttosto atipica invero, è quella in cui lo stesso identico codice di monitoraggio è presente due o più volte sulla stessa pagina. Potrebbe essere perché due persone differenti lo hanno inserito – magari uno in header e uno prima di /body – o perché si sta usando un plugin automatico ma il codice era già stato messo a mano nel template. Quali che siano le ragioni, Google Analytics non effettua nessun tipo di controllo su questa casistica, quindi i javascript vengono eseguiti entrambi e i dati vengono inviati due volte.

Questo però non si traduce in un raddoppio totale di tutti i dati. O meglio, raddoppiano solo i dati che ha senso siano doppi, quelli che tecnicamente potrebbero effettivamente derivare da una situazione di quel tipo. Ad esempio le visite non raddoppiano, perché una visita ha una durata predefinita di trenta minuti. Il fatto che in in una frazione di secondo vengano viste due pagine non intacca il concetto di sessione, per cui le due esecuzioni del GATC sono attribuite correttamente alla visita giusta. Raddoppiano invece le pagine viste, poiché vi sono due chiamate alla funzione trackpageview(). Queste chiamate, tra l’altro, avvengono a una frazione di secondo di distanza l’una dall’altra, per cui non falsano il tempo medio trascorso sulla pagina. Falsano invece, e di molto, il bounce rate. Poiché un bounce è una visita di una sola pagina vista, se sono presenti due codici di monitoraggio sulla pagina, ogni visita sarà composta sempre di almeno due pagine viste, per cui il vostro sito avrà un bounce rate dello 0%.

Il modo più semplice per accorgervi di un errore simile è appunto quello di guardare il bounce rate. se è zero o siete bravissimi o potete avere un errore di questo tipo. Un altro modo, meno immediato, è quello di guardare la pagine viste: con un doppio codice esse non possono mai essere in numero dispari 🙂

Royal Pingdom, il blog ufficiale del servizio di monitoraggio dell’uptime dei siti pingdom, ha pubblicato un interessante post dopo aver condotto un test sui diecimila siti più popolari secondo la classifica di Alexa, trovando che almeno la metà di essi usa Google Analytics, e che il 40% di questi usa ancora il vecchio codice.

Si parla di grossi nomi come foxnews.com, wired.com, istockphoto.com, e ironicamente anche di blogger.com e doubleclick.com, che sono di proprietà di Google stessa. Dei 9758 siti che sono stati in grado di rispondere alle chiamate automatiche di pingdom.com, 4872 hanno lo script di GA sulla home page, e di questi 1992 ancora chiamano urchin.js, che è la vecchia versione dello script.

Questi siti, tra le altre cose, non possono avvantaggiarsi di una serie di funzionalità che sono specifiche di ga.js, la nuova incarnazione del javascript introdotta nel dicembre del 2007:

• logica ad oggetti
• interazioni più facili con elementi AJAX nelle pagine
• monitoraggio degli eventi
• un codice più leggero e veloce da eseguire
• auto riconoscimento del protocollo usato dalle pagine, se http o https

Stando alle informazioni disponibili, e a una frase di un Google Analytics Authorized Consultant nel post citato, il supporto al vecchio urchin.js cesserà in qualche momento durante l’estate, intorno ai famosi diciotto mesi proclamati quando venne introdotta la nuova versione.

Se nel vostro sito state ancora usando urchin.js, è bene sapere che probabilmente avete ancora solo tre o quattro mesi di tempo per migrare. Se fatta con le dovute cautele la migrazione è indolore, e vi permetterà di dimenticarvi della “dead line” di Google; inoltre avrete accesso alle nuove funzionalità. Anzi, la transizione potrebbe essere un buon momento per applicare tutte quelle piccole migliorie che avete letto in questo blog e che avete sempre rimandato per mancanza di tempo. Se il sito è generato dinamicamente da un sistema di gestione dei contenuti, ci sono buone probabilità che il vostro programmatore di fiducia sia in grado di effettuare la transizione in poco tempo, e spesso modificando un solo file. Se avete centinaia di pagine statiche in HTML, è adesso il momento buono per iniziare, giacché è possibile far convivere urchin.js e ga.js sullo stesso sito MA NON sulla stessa pagina.

In ogni caso avrete a che fare con la pagina ufficiale della migrazione, che vi linko per comodità

[edit 11 aprile: In questo post sul blog ufficiale Brett Crosby smentisce che urchin.js sarà dismesso durante l’estate, contraddicendo sia quanto venne detto all’introduzione del codice a oggetti sia quanto detto dal Google Analytics Authorized Consultant. Io continuo a rimanere dell’idea che compatibilmente con tempi e costi di ognuno sia bene migrare tutto a ga.js, e mi comporto di conseguenza con i clienti]

Durante i giorni scorsi, poco prima del Festival di Sanremo, all’indirizzo www.rai.it è andato online il nuovo portale internet della televisione pubblica italiana, che fa uso della tecnologia Microsoft Silverlight per lo streaming dei contenuti. Per chi non lo sapesse, Silverlight è il “concorrente” di Adobe Flash per quel che concerne le cosiddette “Rich Internet Application”, ovvero quelle applicazioni – soprattutto web – sofisticate che difficilmente riescono ad essere realizzate con i canonici HTML, CSS e Javascript.

Nei sistemi Windows, se non erro, Silverlight dovrebbe essere installato insieme agli aggiornamenti di Miscrosoft Update, ma è sempre comunque possibile installarlo a mano la prima volta che si tenta di accedere ad un contenuto realizzato con quella tecnologia. Google Analytics contiene un intero report dedicato a Flash player che riepiloga quali versioni di Flash sono installate nei browser dei visitatori e in che percentuale essi hanno visitato il sito, ma non ha nessun tipo di report per Silverlight. Se avete la necessità di conoscere anche le percentuali delle due versioni esistenti di Silverlight, Hello Szabi! ha migliorato un precedente script di Mark Monster per farlo.

Dopo aver scaricato e uploadato sul sito lo script ufficiale per il test della versione Silverlight (fornito da Miscrosoft stessa) sarà sufficiente aggiungere queste righe di codice

<script type="text/javascript" src="silverlight.js"></script>
<script type="text/javascript">
  var hasSilverlight = Boolean(window.Silverlight); 
  var hasSilverlight1 = hasSilverlight && Silverlight.isInstalled('1.0'); 
  var hasSilverlight2 = hasSilverlight && Silverlight.isInstalled('2.0'); 
  if (hasSilverlight1) { pageTracker._trackEvent("silverlight", "v1"); }
  if (hasSilverlight2) { pageTracker._trackEvent("silverlight", "v2"); }
  if (!hasSilverlight1 && !hasSilverlight2) { pageTracker._trackEvent("silverlight", "none"); }
</script>

subito DOPO la chiusura del tag SCRIPT di Google Analytics. Nella sezione eventi del vostro profilo troverete un evento di nome “silverlight” con tre azioni: none, v1 e v2. “none” è naturalmente il numero di visitatori che non hanno il plugin installato, mentre v1 e v2 sono rispettivamente il numero di coloro che hanno la prima e la seconda (l’ultima disponibile al momento in cui scrivo) versione