Google Analytics in 30 secondi

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):

(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” 🙂 )