Nov 17 2011

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

Posizione delle keyword nelle variabili personalizzate

autore: Marco Cilia categoria: javascript tag: , ,

Quasi un mese fa su SEOmoz è apparso un articolo su come tracciare il ranking del sito usando le variabili personalizzate. Uno dei tanti della serie, direi, perché ciclicamente l’argomento ritorna (io stesso ne scrissi più di un anno fa). Segnalo questo perché è il primo che compare dopo la modifica al passaggio delle keyword per gli utenti loggati ai servizi Google, e quindi prova ad usare il metodo per “indovinare” quali siano queste keyword (not provided). Ma andiamo con ordine: innanzitutto propongo una modifica al suo codice, che presuppone una funzione e una chiamata sull’onload della pagina. Io farei tutto nello script di analytics, così


<script type="text/javascript">
var url = String(document.referrer);

var _gaq = _gaq || [];
_gaq.push(['_setAccount', 'UA-XXXXXXX-X']);
if (url.indexOf ("google") !=-1)
{  
  var urlVars = {};
  var parts = url.replace(/[?&]+([^=&]+)=([^&]*)/gi, function(m,key,value)
  { urlVars[key] = value; });
  // Push to GA Custom Variables
  _gaq.push(['_setCustomVar', '1', 'Rankings', urlVars["cd"], 1]);
}
_gaq.push(['_trackPageview']);

(function() {
var ga = document.createElement('script'); ga.type = 'text/javascript'; ga.async = true;
ga.src = ('https:' == document.location.protocol ? 'https://ssl' : 'http://www') + '.google-analytics.com/ga.js';
var s = document.getElementsByTagName('script')[0]; s.parentNode.insertBefore(ga, s);
})();

</script>

ho inoltre modificato il check sul referrer da “google.com” a “google”, altrimenti per google.it non funzionerebbe (e poi perché privarsi degli altri TLD?)

A questo punto le posizioni delle parole chiave si trovano dentro al report VSITATORI -> DATI DEMOGRAFICI -> VARIABILI PERSONALIZZATE, nella chiave 1 se avete usato lo script qui sopra o nella chiave corrispondente se la 1 era già occupata e avete deciso di usare un altro slot.
Il report così com’è elenca dei numeri, cioè le varie posizioni aggregate in cui il nostro sito è comparso nelle pagine dei risultati di Google, ma usando la dimensione secondaria impostata su PAROLA CHIAVE possiamo dividere ogni riga del report nella combinazione posizione-keyword (l’immagine è di SEOmoz)

rankings

L’utilizzo possibile di queste informazioni è molteplice: innanzitutto possiamo creare dei segmenti avanzati su gruppi di posizionamenti. Ad esempio:

SEGMENTO AVANZATO: posizioni da 1 a 3
Variabile personalizzata (chiave 1) CORRISPONDE ESATTAMENTE a Rankings
E
Variabile personalizzata (valore 1) CORRISPONDE ALL’ESPRESSIONE REGOLARE ^[1-3]$

è una segmento che individua solo le visite arrivate con keyword tra la prima e la terza posizione (dove per posizione si intende il conteggio dei link nella SERP, occhio a Universal Search che mette più di 10 posizioni su pagina 1!).

L’autore dell’articolo su SEOmoz però si concentra sulla provenienza geografica e sul tentativo di indovinare le keyword che Google Analytics presenta come (not provided). L’esempio che fa è questo: le keyword (not provided) dagli Stati Uniti sono in posizione #1 e #2, quindi dopo aver esportato su Excel sono in grado di restringere il mio dataset a quelle due posizioni e a quel paese.

ranking seomoz excel

Segmentando allora il report delle variabili personalizzate per landing page si vedrà dove atterrano questi (not provided) dalle posizioni #1 e #2, e segmentando poi il report delle keyword sempre per landing pages l’autore immagina che queste keyword nascoste abbiano a che fare con il suo nome, per il quale il sito compare appunto in prima e seconda posizione.

Questo ragionamento non mi fa impazzire di felicità, ve l’ho riportato per completezza, ma mi sembra un po’ empirico e soprattutto non sempre applicabile.


Nov 07 2011

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

Il Google Analytics di domani?

autore: Marco Cilia categoria: javascript tag: ,

Qualche settimana fa Google ha presentato l’ultima versione del sistema operativo Android, Ice Cream Sandwich, insieme alla terza incarnazione dei telefonini serie Nexus, il Galaxy Nexus. Curiosando nel relativo sito, il buon Tommaso Galli mi fa notare una chiamata piuttosto strana a qualcosa che somiglia ad Analytics:


<script src="//www.google.com/js/gweb/analytics/autotrack.js"></script>
    <script>
      new gweb.analytics.AutoTrack({
            profile: 'UA-19761916-1'
          });
    </script>

basta, questo è tutto. il file autotrack.js è ovviamente minificato come da tradizione Google, ma alcune parti sono ancora leggibili: ci si ritrova dentro la classica coda _gaq.push che tutti conosciamo, con i classici comandi di setAccount e trackPageview, e altre funzioni tipiche. Il nome però è parlante, e così facciamo un test: ricopio tutto il sito in un mio dominio, cambio l’UA con uno dei miei di test e insieme facciamo qualche visita. Effettivamente quelle due sole righe di codice sono equivalenti al normale codice javascript che Google Analytics ci fa copiare su tutte le pagine del sito, con una sola, notevole eccezione: traccia automaticamente – tramite eventi – anche tutti i click fatti su elementi href, distinguendoli in interni ed esterni; quelli interni finiscono in una categoria NAVIGATION (se sono link a pagine) o LINK CLICK (se sono files), quelli esterni in una categoria OUTBOUND CLICK.

Facendo qualche ricerca sul web scopro che non siamo i primi ad accorgerci di questa cosa, che è precedente al sito del Galaxy Nexus: Mohit Jain l’aveva già notato su Google Plus, ed aveva fatto lui stesso dei test, scoprendo tra l’altro anche la funzione heatMapper, che se impostata a true provvede a registrare automaticamente la posizione del mouse per TUTTI i click fatti sulla pagina, anche quando non sono fatti su elementi cliccabili. Cioè la base per creare una heatmap, appunto.

Ora, io non so esattamente se questo sarà lo script di un Google Analytics di domani, ma ogni volta che c’è una semplificazione per l’utente io sono contento. Portare a 2 le righe di codice necessarie al monitoraggio base è sicuramente un miglioramento, e le funzioni aggiuntive si possono sempre aggiungere come adesso, se servono. Quanto al fatto che parte del lavoro che adesso siamo costretti a delegare a soluzioni esterne (jQuery, cose scritte in casa, o il plugin sviluppato da me e Francesco Terenzani) verrebbe svolto automaticamente e autonomamente, beh direi che si commenta positivamente da solo.


Aug 03 2011

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

Traccia i bot in Google Analytics

autore: Marco Cilia categoria: javascript tag: ,

Google Analytics, ormai dovrebbero saperlo anche i muri, è un sistema di web analytics basato su un codice javascript, motivo per cui i bot non vengono tracciati (con qualche rara eccezione). Quando durante i miei corsi avanzati parlo dello snippet di codice dedicato al tracciamento dei siti mobili, spiegando che è completamente lato server e non ha bisogno di javascript, i presenti più attenti subito incalzano con la domanda “ma allora con quello script si potrebbero tracciare anche gli spider?”. La risposta è no – o almeno lo era quando feci la prova direttamente – perché Google sembra applicare una sorta di filtro per non sporcare i dati delle vere visite.

A livello puramente sperimentale già qualche anno fa lessi di qualcuno che aveva riprodotto le chiamate alla gif di 1×1 pixel che serve al tracciamento senza avvalersi del codice di tracciamento di GA, ma la cosa era morta lì: il codice di Analytics cambia, anche le chiamate cambiano, e cmq un SEO ha metodi più efficaci e robusti per controllare quel che fanno gli spider sul proprio sito. Tuttavia non posso non segnalarvi questo articolo di Cardial Path, che fornisce uno script php già pronto che combina il codice di tracciamento dei siti mobili con alcune modifiche fatte da loro, per permettervi di avere anche i crawler nelle vostre statistiche di Google Analytics.

Come prima cosa è consigliato creare un nuovo profilo. Non un profilo copia – che usa lo stesso codice UA dell’originale – ma un nuovo profilo con un nuovo UA. Poi bisogna scaricare il file dal loro sito e decomprimerlo sul proprio computer. Bisogna copiare il contenuto del file sample.php nel proprio sorgente php (tutte le pagine, ovviamente), sostituendo alla riga 5 il proprio account UA-XXXXXX-YY (mi raccomando, UA e non MO) ed eventualmente modificare la riga 6 con il percorso al file ga.php in accordo alla sua posizione sul server. Dopo aver copiato la cartella sul server se tutto è stato configurato per bene inizierete a vedere le visite degli spider nel nuovo profilo creato.

Poiché gli spider non hanno sorgente – vengono di loro spontanea volontà – l’autore dello script ha pensato di usare la sorgente per memorizzare lo User Agent del bot, per averlo a portata di mano nei report drilldown. Inoltre ovviamente il post di Cardinal PAth ci ricorda di focalizzarsi sulle pagine viste e non sulle visite (dato che oltre a non eseguire javascript, i bot mal digeriscono anche i cookies). L’ultima nota riguarda il fatto che per ogni pageview il codice invia anche una variabile personalizzata, di livello pagina appunto, con il timestamp al secondo di quando è stata richiesta, così da sapere chi guarda cosa e quando :)


Jul 20 2011

HelpSemaforoQuesto semaforo indica il livello difficoltà del post
semaforo rosso - articolo per esperti

trackPageLoadTime senza campionamento, ma simulato

autore: Marco Cilia categoria: javascript tag: , ,

[traduzione del post di André Scholten Simulate Google trackPageLoadTime without sampling]

Poco dopo aver descritto un metodo per tracciare i tempi di caricamento delle pagine in Google Analytics, Google ha tirato fuori la propria tecnica per fare la stessa cosa, ma entrambi i metodi hanno alcuni svantaggi. Per chiarirvi le idee vi mostro questa immagine:

timing

Questa immagine mostra tutti i passaggi dall’inizio della richiesta di una pagina fino alla fine. I tempi di queste operazioni sono memorizzati in un oggetto javascript chiamato “performance”. E con un semplice script potete leggere questi valori e calcolare i tempi di caricamento. Tutto questo deriva direttamente dalle specifiche “Navigation Timing” del W3C.

La linea verde sono i tempi che misuro con il metodo descritto in precedenza, il che significa: solo i tempi da quando l’HTML inizia a caricarsi fino a che non accade l’evento onload.
La linea rossa sono i tempi che Google usa per misurare il load time in GA. Un numero molto più verosimile perché include anche i tempi di risposta del server. Ma Google usa solo un campione di dati per calcolare i tempi di caricamento.

Il metodo migliore è una via di mezzo: il metodo più affidabile usato da Google ma senza il campionamento. Tutto questo può essere ottenuto con una semplice aggiunta al codice di monitoraggio di Analytics:


if (typeof performance == "object")
{
  var loadtiming = parseInt(performance.timing.loadEventStart - performance.timing.fetchStart);
  if ((loadtiming > 0) && (loadtiming < 40))
  {
    _gaq.push(['timer._setAccount', 'UA-XXXXXX-X'], ['timer._trackPageview'], ['timer._trackEvent','w3c-navigationtiming',location.pathname,,loadtiming]);
  }
}

potete eseguire questo codice dopo l’onload, così i visitatori non saranno rallentati, e mi raccomando di usare un nuovo profilo, e non il vostro profilo normale, perché questa funzione rovinerà il vostro bounce rate. Le funzioni LoadEventStart e fetchStart sono le stesse che Google usa nella sua trackPageLoadTime.
C’è solo un piccolo problema con questo script: non tutti i browser supportano l’oggetto “performance” (che è piuttosto nuovo ndr), al momento solo Chrome lo fa. Ma poiché la velocità del sito sta diventando sempre più importante, probabilmente in futuro anche gli altri browser aggiungeranno il supporto.


Jul 01 2011

HelpSemaforoQuesto semaforo indica il livello difficoltà del post
semaforo verde - articolo per tutti

Posso usare il file ga.js salvato localmente?

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

Questa è una delle domande che mi vengono rivolte più spesso: molte persone, per motivi disparati che vanno dal non pervenuto a problemi di performance, vorrebbero salvarsi sul server una copia dello script sorgente di Google Analytics – cioè quel che trovate su www.google-analytics.com/ga.js e che viene richiamato dal codice di GA in modo automatico – ed evitare di fare la chiamata remota ai server di Google.

E’ sicuramente possibile, così come potete decidere se mettere ad esempio JQuery sul vostro server o usare una libreria online che fornisce sempre l’ultima versione, ma il problema è per l’appunto il medesimo: il codice di GA cambia, a volte rapidamente a volte meno, però cambia. Stanotte, ieri notte e la notte prima è stato modificato, dopo settimane di stasi. Se usate il codice fornito da Google siete certi di richiamare l’ultima versione, di avere tutte le funzionalità e gli ultimi bugfix; se decidete di fare le cose localmente dovrete controllare gli aggiornamenti e ogni volta che viene fatta una modifica aggiornare anche il vostro codice (compresi i casi in cui vengano fatte più modifiche al giorno, quando si presentano).

Non è impossibile, è solo un po’ più laborioso del normale. Comunque sia, se volete essere informati quasi in tempo reale delle modifiche al file sorgente, potete usare un servizio di alert via feed rss o email. Io ad esempio uso Page2RSS


Jun 14 2011

HelpSemaforoQuesto semaforo indica il livello difficoltà del post
semaforo verde - articolo per tutti

Attenzione agli apostrofi nel codice ecommerce

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

“Per un punto Martin perse la cappa” è un vecchio detto popolare che mette in guardia da un errore apparentemente di scarsa entità ma che invece comporta conseguenze spesso disastrose. E’ il detto che mi è venuto in mente rileggendo un vecchio articolo di AnalyticsPros riguardante gli errori dei codici di tracciamento e-commerce. Probabilmente un problema che noi italiani sentiamo meno, ma che vale la pena comunque di sottolineare.

Le funzioni javascript del codice asincrono (ma anche quelle del vecchio codice asincrono per la verità) vanno incapsulate tra apici singoli (carattere sotto al punto interrogativo nella tastiera italiana). Questo è un requisito fondamentale affinché il codice funzioni. Ma cosa succede se un prodotto ha un apostrofo nel suo nome? vi ricordo che il nome del prodotto non è un parametro strettamente necessario al funzionamento del sistema, ma non ho mai visto un e-commerce che omette i nomi dei prodotti e valuta le prestazioni del suo sito con Google Analytics usando solo gli SKU code.

Quindi, se nella nostra thank-you page abbiamo un codice così:


  _gaq.push(['_addItem',
      '1234',         // order ID
      'DD44',         // SKUcode
      'Nettare d'ambrosia',      // nome del prodotto
      'bevande', // categoria
      '11.99',        // prezzo unitario
      '1'             // quantità
   ]);

il sistema va a scatafascio perché nella riga del prodotto ci sono tre apostrofi. Il prodotto diventa nettare d, ambrosia sarebbe la categoria, bevande il prezzo, 11.99 la quantità, 1 sarebbe ignorato. E peraltro mancando una virgola dopo il nome del prodotto Google Analytics non ci capirebbe nulla.

La checklist proposta nel post è piuttosto semplice: se sapete di avere prodotti che contengono l’apostrofo nel nome andate in Analytics, report dei prodotti, e cercate \’ (backslash e apostrofo, senza spazi); se non vedete nessun risultato significa che quei prodotti non vengono mai registrati da GA, e che siete affetti dal problema.
Le soluzioni possibili sono:

  1. Modificare i nomi dei prodotti
  2. Operare una sostituzione lato server PRIMA di eseguire il comporre il codice di Google Analytics
  3. inserire un backslash prima dell’apostrofo in modo che la riga diventi ‘Nettare d\’ambrosia’, // nome del prodotto

Tutto questo lavoro per un semplice apostrofo? pensate a Martin! ;)


Jun 01 2011

HelpSemaforoQuesto semaforo indica il livello difficoltà del post
semaforo verde - articolo per tutti

Due concetti basilari che vale la pena ricordare

autore: Marco Cilia categoria: javascript tag: ,

Di recente mi è capitato di dover dare un’occhiata all’Analytics di due grandi siti italiani, di cui ovviamente non posso/voglio fare i nomi (anche perché irrilevante), e di riscontrare errori. Banali errori o semplici sviste che però sono in grado di inficiare i dati.

Il primo concetto da tenere sempre a mente è che javascript è case sensitive, cioè è sensibile al fatto che il codice sia scritto con le maiuscole e le minuscole corrette. Se avete mai personalizzato almeno una riga di codice dello script di Google Analytics, avrete forse notato che le funzioni sono scritte con la notazione che i programmatori chiamano “CamelCase“: per cui _trackPageview (con la P maiuscola), _setDomainName (con la D e N maiuscole), _addTrans (T maiuscola) e così via. Scrivere la funzione _trackpageview invece di _trackPageview porta al risultato di non vedersi tracciate le pagine, perché il codice cerca una funzione che non esiste.

Il secondo fatto sconcertante è che ad alcune persone non è ancora chiaro che il codice deve stare su tutte le pagine, e non solo sulla home page. Analytics non è un polipo vorace in grado di insinuarsi nel vostro sito, non germoglia tra i rami del vostro albero di navigazione, è semplicemente un codice javascript che viene eseguito insieme alla pagina. Ho usato il singolare appositamente, viene eseguito insieme alla pagina. Ad ogni pagina. Il flusso concettuale è facile:

  1. vedo una pagina
  2. viene eseguito il codice
  3. l’informazione sulla pagina (e quindi visita e tutti i correlati) viene inviata subito a Google

Se manca il passaggio due, niente passaggio tre. Lineare :)

Bonus: il dominio che indicate in fase di apertura di un account GA non è rilevante o vincolante ai fini della raccolta dei dati. Analytics raccoglie i dati da qualsiasi pagina su qualsiasi dominio nella quale ci sia il vostro codice di monitoraggio (a meno che non abbiate dei filtri sul nome host, chiaro). Per questo motivo alla domanda: “devo fare qualcosa al codice se sposto il sito da un dominio a un altro”? la risposta è sempre “se non hai filtri sull’host, no!”.


Oct 22 2010

HelpSemaforoQuesto semaforo indica il livello difficoltà del post
semaforo verde - articolo per tutti

Pagine virtuali e 404 not found

autore: Marco Cilia categoria: javascript tag: ,

Qualche tempo fa FradeFra mi sottopose un quesito interessante: mi disse che nel suo Webmaster Tools vi erano parecchie segnalazioni di errori 404, e tutti relativi a pagine “virtuali” create con la _trackPageview di Google Analytics. Faccenda strana, in effetti, che non mi era mai capitata e che a prima vista sembra impossibile.

Ci penso un po’, ma senza avere davanti tutti i dati e i pannelli non è facile… non mi viene in mente niente altro che Googlebot che esegue javascript, cosa che forse ai più non è molto nota ma che è perfettamente e tecnicamente possibile, tanto è vero che sporadicamente potete trovarlo tracciato nei report di GA guardando alle versioni del browser (vedi immagine):

Quindi Googlebot esegue javascript, trova l’indirizzo della pagina virtuale di Analytics (che non esiste) e la passa da segnalare ai Webmaster Tools come “404 not found“.

Qualche giorno dopo aver impostato il plugin GA di Yoast per creare un po’ di pagine virtuali su questo blog mi sono trovato centinaia di errori 404 anche io, ma poiché stavo preparando l’intervento allo SMAU non ho potuto fare debug seriamente. Adesso sono quasi tutte scomparse, ne resta una sola:

e non ho trovato poi tante informazioni in giro, ne sul forum di supporto di Analytics ne su quello dei Webmaster Tools. Se la cosa in qualche modo vi da fastidio, dovrete fare in modo di aggregare tutte le pagine virtuali sotto una stessa directory e provvedere ad escluderla tramite robots.txt


Oct 01 2010

HelpSemaforoQuesto semaforo indica il livello difficoltà del post
semaforo verde - articolo per tutti

GA per SEO: Posizione in SERP nelle variabili personalizzate

autore: Marco Cilia categoria: javascript tag: ,

Ieri mentre ero in treno un twit mi ha avvisato di questo post di SEOmoz sull’uso di Google Analytics ai fini del tracciamento della posizione sulle SERP di Google. Niente di nuovo in realtà, se non che questa volta invece di modificare le keyword o inserirle nei valori definiti dall’utente, si preferisce l’uso delle variabili personalizzate, che l’autore indica come più appropriate e flessibili rispetto alle altre soluzioni.

La prima cosa che ho notato è che Mike Pantoliano, l’autore, utilizza una parte di codice php, quindi lato server, per estrarre il parametro dal referrer. La mia obiezione è stata che si poteva fare benissimo in javascript e integrarlo meglio con Google Analytics, ma non potevo scrivere un post tecnico in treno. Ovviamente nei commenti è subito intervenuto Richard Baxter, collega di Joost De Valk e ha postato il codice javascript necessario. Per cui su quello mi concentrerò, anche se Joost che l’ha ripreso in un post lo considera ancora sperimentale:


if (document.referrer.search(/[\?|&]cd=/) != -1
  && document.referrer.search(/google\./) != -1) {
  var rank=document.referrer.match(/[&|\?]cd=([\d]+)/);
  _gaq.push(['_setCustomVar',3,'rank',rank[1],2]);
}

questo pezzetto di javascript si occupa di controllare se il referrer è google e se è presente un parametro cd=. Se le due condizioni sono verificate, inserisce nella coda dei comandi asincroni di Google Analytics la chiamata a _setCustomVar. Nell’esempio scrive il valore nello slot 3, ma ovviamente potete modificarlo come meglio vi pare. Il codice può essere inserito ovunque, ma comunque prima della chiamata a trackpageview o prima di un trackevent.

Rispetto allo snippet di Joost, ho preferito settare lo scope della setCustomVar a 2 (sessione) in modo da non generare possibili problemi. Alla fine della sessione lo slot viene svuotato e ritorna disponibile per la visita successiva dell’utente, che può di nuovo arrivare da una SERP. Diversamente potrebbe tornare con una visita diretta e portarsi dietro il valore “vecchio”

Alcune interessanti analisi che SEOmoz propone sono il ranking segmentato per città, paese, continente, per mostrare le differenze di posizionamento in varie parti del mondo, oppure l’analisi del bounce rate per posizione. Il fatto che anche le variabili personalizzate siano legate al tempo permette inoltre di poter fare raffronti di posizionamento in differenti periodi temporali. Inoltre con un segmento avanzato potete facilmente isolare i gruppi di keyword per posizione, o per range di posizione. Sempre nel post suggeriscono di creare un segmento per le posizioni 11-15, che – tolto Universal Search – sarebbero le prime cinque di pagina 2 e che ben si prestano a ricevere attenzione nel migliorare il posizionamento per farle salire a pagina 1. A proposito di Universal Search, vi ricordo che il parametro cd= numera in ordine TUTTI i risultati di una SERP, link, immagini e video compresi, come avevamo già avuto modo di dire tempo fa giocherellando con le immagini.

Comunque guardando questa foto (sempre by SEOmoz) avrete tutto più chiaro
universal search


Feb 15 2010

Usa attivamente la fedeltà dei visitatori

autore: Marco Cilia categoria: javascript tag: ,

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.