May 26 2010

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

Dati più inaccurati, in nome della privacy

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

Con un post sul blog ufficiale, Amy Chang ha informato il mondo della disponibilità del famoso plugin per evitare di essere tracciati da Google Analytics.
Installando sul proprio browser (per adesso soltanto Firefox 3.5 e superiori, Google Chrome 4 e superiori e Internet Explorer 7 e 8) il plugin disponibilie alla pagina http://tools.google.com/dlpage/gaoptout si diventerà completamente invisibili al sistema di web analytics di Google (e solo a quello. Per altri sistemi cosiddetti di opt-out vi rimando all’apposita raccolta di link del world privacy forum). Ne consegue che dal punto di vista di chi le statistiche le guarda, cioè il nostro, la fetta di utenti che installeranno questo plugin diverrà completamente invisibile ai nostri occhi, esattamente come coloro che non hanno javascript abilitato sul browser.

Mi sembra una scelta coraggiosa, che eleva ancora di un gradino la serietà del prodotto: potenzialmente questo plugin è in grado di azzerare completamente i dati dentro a GA, nell’iperbolica ipotesi in cui sia adottato dal 100% dei navigatori.

L’altra novità del giorno è l’introduzione di un metodo per ridurre l’accuratezza delle informazioni geografiche sui visitatori: il metodo si chiama anonimizeIp() e serve ad eliminare dall’ip del visitatore l’ultima parte dell’indirizzo. Un indirizzo come 213.145.23.78 verrebbe trasmesso a GA come 213.145.23.???
Da un lato questo non cambia assolutamente la precisione del riconoscimento del visitatore unico, perché basato su cookie rilasciato sul computer del visitatore, ma dall’altro lato costringe Google Analytics ad essere meno accurato quando calcola la provenienza geografica del visitatore (con l’operazione di geolocalizzazione degli ip).

Nel codice di tracciamento standard il metodo andrebbe chiamato prima della creazione dell’oggetto, 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">
try{
_gat._anonymizeIp();
var pageTracker = _gat._getTracker("UA-xxxxxx-x");
pageTracker._trackPageview();
} catch(err) {}</script>

Vi potete rendere conto del funzionamento usando un tool per vedere gli header HTTP e controllando che nella richiesta che viene inviata ai server di Analytics sia presente il parametro &aip=1. Non sono ancora riuscito a far funzionare il metodo col nuovo codice asincrono (ovviamente senza iniettare la vecchia funzione, cosa sempre possibile).

L’ultima “novità”, positiva o negativa dipende dai punti di vista, è che da qualche giorno Google permette di effettuare ricerche tramite SSL (Secure Sockets Layer), o se preferite visitando httpS://www.google.com.
In questo caso la connessione tra l’utente e il server è protetta, ma a noi fino a qui interessa poco: Analytics interviene se e solo se poi un utente trova il vostro sito e fa click sul risultato mostrato nel motore. Ecco, se la cosa avviene sul Google “classico” Analytics vede che il referrer è www.google.com, quindi assegna la visita al traffico organico, estrae la keyword usata, la mette nel report delle keyword e così via. Se la ricerca è fatta sulla versione SSL di Google, il referrer non viene passato, e Analytics (ma in reatà qualsiasi sistema di web analytics) sarà costretto ad assegnare la visita al traffico diretto.


Mar 24 2009

Cosa filtro? come lo filtro?

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

Il mio post di ieri sugli IP ha innescato un paio di domande in privato che mi hanno convinto a fare un post di approfondimento.
Riassumo la situazione: una grande azienda, sparpagliata in tutto il territorio e con una infrastruttura di rete molto ampia, gestisce centinaia di siti web. Su uno di questi viene implementato Google Analytics, con un normale filtro sugli indirizzi di rete pubblici dei due proxy aziendali. Normalmente questo è sufficiente a filtrare il traffico degli impiegati.

Ci sono due complicazioni, una gestita e una no. La prima complicazione è che gli impiegati dell’azienda, quando richiedono il sito web, non passano attraverso il proxy ma si presentano al server web direttamente con il loro indirizzo di rete interna (10.10.1.76 o 192,168.1.34 o simili, dipende dalla rete). Il proxy serve solo a veicolare le richieste a risorse esterne. In questo caso però non è necessario filtrare gli indirizzi interni, perché la GIF trasparente di 1×1 pixel che serve a Google Analytics per registrare i dati si trova all’indirizzo (esterno) http://www.google-analytics.com/__utm.gif, quindi passa dal proxy. L’indirizzo IP che GA registra, quindi, è quello del proxy e il filtro funziona. Chiarisco con una immagine (cliccala per ingrandirla):

gaext
(tutto il contenuto della pagina viene servito dal server web, tranne una immagine linkata su un server esterno e il codice e la GIF di Google Analytics. Questi due elementi vengono a tutti gli effetti richiesti dal proxy al posto del computer interno).
Questo caso viene quindi ovviato dal filtro imposto al profilo.

Il caso non gestito è quello in cui mi sono trovato io: alcune porzioni della rete escono da proxy differenti dai due noti, ma non c’è modo di sapere quali e che indirizzi pubblici abbiano. Solo dopo aver isolato gli IP interni dei dipendenti che accedevano alle pagine tramite l’uso che vi ho mostrato di _setVar() (che incapsula l’IP e lo spedisce in chiaro a GA) si è potuto risalire alla porzione di rete che sfuggiva al filtro e al relativo proxy.

Il disegno che ho inserito è secondo me la chiara dimostrazione che è difficile fare web analytics senza conoscere il funzionamento basilare della rete: bisogna conoscere il funzionamento del TCP/IP e dell’HTTP, capire come funziona un proxy, come e perché alcune cose passano da lui e altre no, eccetera. Senza sapere queste cose si possono leggere lo stesso i dati di GA e degli altri programmi, ma si dipenderà sempre da qualcun altro per risolvere i propri problemi sui profili. In un sistema di web analytics “as a service” senza la possibilità di riprocessare i dati passati come è Google Analytics, ogni giorno perso è un giorno in cui si hanno dati “sbagliati”, e i dati sbagliati in ingresso sono dati sbagliati in uscita (gli anglofoni dicono molto saggiamente “garbage in, garbage out” 🙂 )


Mar 23 2009

Perché non posso avere l’IP dei visitatori?

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

Domanda ricorrente, risposta breve: perché Google non vuole, considera l’IP un dato personale e poiché è sempre nell’occhio del ciclone per le questioni di privacy, taglia corto e non lo consente.

Risposta articolata: i termini del servizio di Google Analytics, al punto 8.1 escludono questa possibilità tramite la dicitura

Google non assocerà il vostro indirizzo IP a nessun altro dato posseduto da Google

Un’altra conseguenza di questa regola, che con gli IP non c’entra, è che in Google Analytics non si possono tracciare o ripercorrere i path delle singole visite, cosa che invece altri software riescono a fare senza sforzo. Probabilmente avrete letto o avrete sentito dire da me in tempi remoti che con un banale trucco la cosa era ancora fattibile: infatti creando un filtro personalizzato di tipo avanzato il campo “indirizzo IP visitatore” è presente, come testimoniato dallo screenshot qui sotto (e come potete verificare voi stessi guardando il sorgente della pagina di creazione di un filtro come quello)

ip-nascosto

ecco come FireBug presenta la riga incriminata


<option value="31" style="display: none;">Indirizzo IP visitatore</option>

ma è selezionabile solo tramite tastiera, scorrendo la select tramite freccia su/giu. Io dicevo, ed era vero, che un filtro avanzato poteva prelevare l’intero campo IP e trascriverlo nel campo “Definito dall’utente”; la cosa è stata sanata da tempo da Google e un filtro come quello, al momento, semplicemente non fa nulla.

Allora, quale altra soluzione rimane?

ATTENZIONE! la procedura seguente viola i termini di servizio di Google Analytics e potrebbe risultare in un blocco della fornitura del servizio da parte di Google. Il mio non vuole essere un invito a violare alcunché, ma in alcuni casi è necessario effettuare un debug avendo gli IP dei visitatori. Terminato il debug conviene riportare il codice alla condizione precedente.

rimane la possibilità di estrarre a mano l’indirizzo IP del visitatore e di scriverlo direttamente nel campo “definito dall’utente”, tramite la funzione _setVar() richiamata subito dopo _trackPageview().

Quindi in ASP


pageTracker._setVar("<%=Request.ServerVariables("REMOTE_ADDR")%>");

in ASP.NET


pageTracker._setVar("<%= Request.UserHostAddress>");

in PHP


pageTracker._setVar("<?php echo $_SERVER['REMOTE_ADDR'];?>");

in SHTML (server side include HTML)


pageTracker._serVar("<!--#echo var="REMOTE_ADDR"-->");

Proprio oggi ho dovuto ricorrere a questa tecnica: una grossa azienda con una infrastruttura di rete molto ampia (con decine di sistemisti sparsi sul territorio) implementa Google Analytics su un sito, ma nonostante due filtri per escludere le visite dei propri proxy, il report “Ubicazione di rete” riporta visite provenienti dal nome di rete dell’azienda. Poiché non se ne viene a capo, sistemo la funzione _setVar per catturare gli IP dei navigatori (in questo caso gli IP di rete interna, poiché i siti visti dall’interno non necessitano di proxy, ma l’immagine trasparente 1×1 di GA invece si), e dopo un paio d’ore sono già in grado di chiedere al sistemista dove siano ubicati e con che proxy escano gli IP del gruppo che “sfuggono” dai due filtri.

Risolta la questione ho eliminato la funzione setVar e sono ritornato nelle grazie di Google Analytics.