Apr 12 2018

HelpSemaforoQuesto semaforo indica il livello difficoltà del post
semaforo verde - articolo per tutti semaforo giallo - articolo avanzato semaforo rosso - articolo per esperti

Clamoroso! Grazie al GDPR potrete cancellare dati da GA

autore: Marco Cilia categoria: generale

Spesso su questo blog vi ho raccontato che mi pregio di essere un utente “della prima ora” di Google Analytics, ovvero di essermi iscritto e di avere un profilo con dati dal giorno 1 della sua esistenza, il 14 novembre 2005. Da allora, Google non ha mai cancellato niente, nonostante su alcune versioni del contratto di servizio avesse il diritto di farlo per i dati più vecchi di 36 mesi (ora mi sembra questa dicitura sia scomparsa).

Oggi invece gli utenti di Google Analytics hanno ricevuto l’ennesima email di aggiornamento sugli adempimenti che Google sta portando avanti per adeguarsi al nuovo regolamento europeo sulla protezione dei dati (o in breve GDPR), che entra in vigore il prossimo 25 maggio: il contenuto della mail è clamoroso perché per la prima volta nella storia di questo strumento introduce una nuova opzione nel pannello di controllo che permette di cancellare *alcuni* dati più vecchi di una certa data, rolling di mese in mese. L’avviso è riportato anche accedendo all’interfaccia di Google Analytics.

Quali dati si potranno cancellare? tutti quelli legati a un cookie, un identificativo utente (userID) o un identificativo advertiser (Doubleclick cookie, identificativi dei device) o un evento. I dati aggregati invece non saranno cancellabili, il che significa probabilmente che il numero di sessioni non si azzererà mai, mentre il numero di utenti (basato sul conteggio dei cookie unici) potrebbe. Le sorgenti di traffico, quando viste per numero di sessioni, dovrebbero essere un report che non cambia mai, il report degli eventi potrebbe variare. E così via…

Il nuovo setting lo potete trovare se avete privilegi di MODIFICA su una property, andando nelle impostazioni della property, nella sezione Informazioni sul tracking e poi Data Retention.

Come vedete le opzioni disponibili sono da uno a cinque anni + due mesi fissi, oppure disabilitato. ATTENZIONE PERCHE’ DI DEFAULT IL SETTING E’ IMPOSTATO SU 26 MESI

La cancellazione dei dati viene fatta una volta al mese in base al setting che viene scelto. La scelta può essere annullata entro 24 ore, quindi se adesso modifico l’opzione ho tempo fino a domani alla stessa ora per annullare. Dopodiché GA prenderà atto della nuova scelta e alla prossima cancellazione opererà di conseguenza.
L’altra opzione disponibile permette di calcolare il lasso di tempo sulla base dell’ultimo evento inviato da un identificativo. Ovvero se dico che il mio periodo di retention è 14 mesi ma imposto su ON l’opzione “Reimposta in caso di nuova attività”, allora se l’utente visita il sito ogni mese non verrà cancellato mai, se invece non visita per 14 mesi verrà cancellato.

Quindi meglio ripetere il concetto: se lasciate tutto così com’è, a partire da Giugno Google Analytics cancellerà ALCUNI dati associati a cookie che non si sono presentati sul sito per 26 mesi
Non confondete questa cosa con il fatto che di default se un utente non torna per 24 mesi, GA lo considera nuovo utente alla prossima visita. Qui si sta parlando di MODIFICHE ai dati di due anni fa.

Ma c’è una seconda novità, sempre preannunciata dalla mail. Tra poco Google introdurrà uno strumento per cancellare PUNTUALMENTE i dati di un utente, basandosi sul clientID standard del cookie di Google Analytics, su uno userID o su un identificativo app se si usa Firebase. Questo potrebbe anche significare poter cancellare le proprie sessioni e transazioni di test su un ecommerce, tra l’altro.

Che dire, si tratta di un cambiamento epocale per come siamo abituati a pensare al prodotto e alle sue caratteristiche più intrinseche: il famoso detto “i report vecchi non cambiano mai” non sarà più del tutto vero, e finalmente quando un cliente dirà “ho rifatto a distanza di mesi lo stesso esatto report e i risultati sono diversi” avremo qualcosa a cui pensare davvero, invece di liquidarlo perché sappiamo (sapevamo, tra poco) che non è possibile…


Aug 02 2015

HelpSemaforoQuesto semaforo indica il livello difficoltà del post
semaforo verde - articolo per tutti semaforo giallo - articolo avanzato semaforo rosso - articolo per esperti

Non ti funzionano più i filtri IP? colpa del garante :)

autore: Marco Cilia categoria: codice di monitoraggio

Una delle azioni che praticamente tutti si sono prodigati a mettere in atto, per trasformare il cookie di Google Analytics da profilazione terza parte a tecnico secondo le indicazioni del garante, è stata quella di anonimizzare l’invio dell’indirizzo IP completo ai server di Google. Io stesso sulle prime ho risposto a chi mi chiedeva quali fossero le conseguenze con un laconico “perdi un po’ di precisione nei report geografici, ma niente altro”.

Al fine di salvaguardare l’impegno preso Google invece procede ad eliminare l’ultimo ottetto degli indirizzi IP ricevuti insieme ai dati di GA prima possibile, in modo da ridurre praticamente a zero le possibilità di registrarlo da qualche parte. Con “prima possibile” purtroppo si intende PRIMA dell’elaborazione, quindi anche prima dell’applicazione dei filtri.

La cosa (“in nessun momento viene scritto su disco l’indirizzo IP completo“) è chiarita in modo limpido in questa pagina dell’help:

Ad esempio, l’indirizzo IP 12.214.31.144 potrebbe essere modificato in 12.214.31.0. Se l’indirizzo IP è un indirizzo IPv6, gli ultimi 80 bit dei 128 vengono impostati su zero. Solo al termine di questo processo di anonimizzazione la richiesta viene scritta su disco per l’elaborazione. Se viene utilizzato il metodo di anonimizzazione IP, in nessun momento viene scritto su disco l’indirizzo IP completo, in quanto tutta l’anonimizzazione avviene nella memoria quasi istantaneamente dopo che la richiesta è stata ricevuta.

Se quello fosse proprio l’indirizzo IP dei dipendenti di un’azienda che prima dell’anonimizzazione era filtrato da un normale filtro IP, di colpo il 144 non viene più trovato (è sostituito da 0) e il filtro smette di funzionare.

La soluzione “cambio 144 con 0 nel filtro” sarebbe praticabile, ma escluderebbe anche altri 255 indirizzi IP validi. Al momento vedo alcune altre soluzioni percorribili, ma quelle più solide comportano un discreto sviluppo per comprendere anche i casi più difficili (configurazioni di rete particolarmente complesse in aziende medio-grandi). Ovviamente il TagManager ci può venire in aiuto, ma è basato su javascript e javascript non conosce l’indirizzo IP del client dove gira, quindi serve comunque uno sviluppo più o meno complesso, sempre a seconda della complessità in gioco.
Per tutto il resto, prendetevela col garante 😀


Jan 26 2012

HelpSemaforoQuesto semaforo indica il livello difficoltà del post
semaforo verde - articolo per tutti semaforo giallo - articolo avanzato semaforo rosso - articolo per esperti

Due novità degli ultimi giorni

autore: Marco Cilia categoria: report

Periodo di fervore anche per tutto ciò che sta “intorno” a Google Analytics: prima di tutto Google ha annunciato che dal primo marzo farà un upgrade della sua privacy policy, che diventerà comune a tutti i servizi. Il nodo principale delle nuove regole è che se si è loggati in un servizio Google, loro potranno combinare i dati ricavati da quel servizio con altri ricavati da altri servizi, sempre mentre eravamo loggati (quindi ad esempio se facciamo una ricerca per “hosting ad alte prestazioni”, potremmo poi trovarci annunci di hosting su Gmail anche se stiamo leggendo una mail che parla di tutt’altro).

Questo ovviamente non ha nessuna implicazione sui dati memorizzati da Analytics, che riguardano i nostri visitatori (in forma anonima e aggregata), e che rimangono nostri.

Quel che invece potrà cambiare, dice il post ufficiale, è che potranno usare i dati di navigazione all’interno dell’interfaccia di GA; perché molti non lo sanno, ma sull’interfaccia di Analytics… c’è Google Analytics, anche se in un forma meno canonica. Ecco qua:

<script type="text/javascript" async="" src="https://ssl.google-analytics.com/u/ga_beta.js"></script>

e poi questa chiamata


<script type="text/javascript">ga.webanalytics.header.setHeaderInfo({"email":"LAMIAEMAILINCHIARO","gUrl":"https:\/\/www.google.com\/accounts\/","tabs":{"H":1,"D":1,"CR":1,"IN":1,"A":1,"R":1,"BF":1,"GO":1,"EC":1},"style":"ANALYITCS","tab":null});ga.webanalytics.header.setLoadBaseData(true);</script>

dal che si evince anche che loro, invece, tracciano eccome i dati personali che a noi sono proibiti.

La seconda novità è che il team di Google Webmaster Tools cambierà la metrica “posizione del sito nelle SERP” che viene riportata da GWT, e di conseguenza importata da Google Analytics. Prima la metrica era la media delle posizioni rilevate, e infatti aveva anche i decimali. Se per una data keyword il sito compariva in 2° e in 5° posizione, la posizione riportata era 3.5; che aveva poco senso in sè, ma ce l’aveva eccome se si teneva presente che era appunto una media. In base alle ricerche del team, secondo loro i webmaster vogliono invece sentirsi dire la “migliore posizione tra quelle riscontrate” e quindi nell’esempio precedente la posizione riportata sarà 2.

Tenendo presente che i dati già registrati non cambieranno, per un certo periodo avremo tutti dati magnifici 🙂 dopo bisognerà tenere conto di questa modifica.


Sep 21 2011

HelpSemaforoQuesto semaforo indica il livello difficoltà del post
semaforo verde - articolo per tutti semaforo giallo - articolo avanzato semaforo rosso - articolo per esperti

Analytics risolve il suo problema con la Germania

autore: Marco Cilia categoria: generale

Quasi due anni fa, a novembre 2009, la Germania iniziò una procedura per dichiarare illegale il tracciamento dei dati tramite Google Analytics. Una delle necessità ribadite dal governo tedesco era la possibilità di evitare il tracciamento, e a quello Google rispose quasi subito con un sistema di opt-out in forma di plugin per browser, ma la questione era ancora aperta.

Dico “era” perché in questo post del conversion room tedesco (in tedesco, traduzione automatica piuttosto pessima) si annuncia la fine della diatriba, e che le autorità di Amburgo hanno dato il via libera all’uso di GA sui siti senza rischio di multe. Per essere aderenti è necessario indicare chiaramente nella privacy policy del sito che si usa GA, implementare la funzione anonimizeIp() che maschera l’ultima parte dell’indirizzo IP dei visitatori e informare i visitatori circa la possibilità di scaricare il plugin per browser che evita il tracciamento.

Tutto è bene quel che finisce bene si dice in questi casi, no?


May 26 2010

HelpSemaforoQuesto semaforo indica il livello difficoltà del post
semaforo verde - articolo per tutti semaforo giallo - articolo avanzato semaforo rosso - articolo per esperti

Dati più inaccurati, in nome della privacy

autore: Marco Cilia categoria: codice di monitoraggio

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 23 2009

HelpSemaforoQuesto semaforo indica il livello difficoltà del post
semaforo verde - articolo per tutti semaforo giallo - articolo avanzato semaforo rosso - articolo per esperti

Perché non posso avere l’IP dei visitatori?

autore: Marco Cilia categoria: codice di monitoraggio

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.