Google Analytics in 30 secondi

Sul fenomeno dei cosiddetti ghost referrals hanno scritto più o meno tutti, ma come direbbe il buon Corrado Guzzanti interpretando uno dei suoi personaggi più riusciti (Quelo) “la risposta che cerchi è dentro di te. Solo che è SBAGLIATA!” 🙂

I ghost referrals sono delle visite che vengono registrate dai vostri Google Analytics, ma che non sono originate da veri e propri visitatori sul vostro sito. “sono bot?” no, non sono nemmeno bot, o meglio non nel senso classico con cui siamo abituati a pensare a un agente automatico che NAVIGA il sito. La gente ha difficoltà a comprendere ciò che non riesce a visualizzare, e in questo caso ciò che non riesce a visualizzare è che da qualche tempo si possono inviare dati a Google Analytics anche SENZA l’ausilio del tipico codice javascript, attraverso una cosa chiamata Measurement Protocol.

Intendiamoci, è una cosa che si è sempre potuta fare, bastava copiarsi una richiesta HTTP dell’immagine _utm.gif che veniva usata – prima di Universal Analytics – per inviare i dati ai server Google e che conteneva nei parametri tutte le informazioni necessarie al calcolo delle visite. Con il measurement protocol la cosa è stata standardizzata e ufficializzata, dando peraltro l’avvio a tutta una serie di nuove possibilità di tracking veramente incredibili (tracciare la macchinetta del caffé?)
Quello che accade è che un qualche server da qualche parte del mondo viene istruito per comporre ed effettuare centinaia di chiamate fasulle a tutte le property del mondo. Che sia un fenomeno distribuito e completamente automatizzato se ne è accorto il mio amico Enrico Pavan creando una property di un sito inesistente che ha iniziato a tracciare visite da ghost referrer, ed è confermata da alcune opinioni secondo cui le property che terminano con numeri diversi da 1 (tipo UA-XXXXXXXX-2 e oltre) non sono soggette al problema. Ora, perché non potete semplicemente fare un filtro? perché gli spammer vincono sempre, sono troppi e fanno grossi danni con poco sforzo: voi passate 3 ore a configurare 80 filtri? domani qualche spammer cambierà una lettera nel pattern delle informazioni che invia e passerà i filtri. Quindi, tanto per essere chiari:

• potete usare la “lista esclusione referral” che trovate nella configurazione della property? no, per il motivo sopra ma SOPRATTUTTO perché essa serve a trasformare in dirette (e quindi a non sovrascrivere la sorgente di traffico) le visite da alcuni domini. Quindi peggiorereste il problema
• potete filtrare uno a uno i domini referrer? se proprio volete farlo, il buon vecchio Simo Ahava ha creato un tool per voi, lo spam insertion tool che vi evita gran parte del lavoro. Ma tanto poi lo dovrete mantenere nel tempo…
• potete fare un filtro di inclusione che includa solo le visite al vostro dominio/hostname? tra tutte le alternative è forse quella che può mitigare meglio il problema, ma poiché anche l’hostname può essere inviato come parametro del measurement protocol, alcuni spammer particolarmente ostinati potrebbero aggiungere della logica per controllare l’UA su ogni host e bypassare il problema

e quindi? quindi l’unica soluzione secondo me valida dal punto di vista tecnico, ancorché completamente insensata, l’ho letta sul blog di Himanshu Sharma, Optimizesmart e consiste in un complicato metodo di codifica/decodifica di tutte le hit inviate. Per la precisione:

1. Si decide una stringa di sicurezza, ad esempio “dhffjsrr12353fdf4253kc“, per mantenere il suo esempio
2. Si antepone la stringa di sicurezza a tutte le chiamate a GA. Per farlo si modifica il codice di GA ad esempio così
   ga('send', 'pageview','dhffjsrr12353fdf4253kc' + location.pathname); o si usa un TagManager. ATTENZIONE che l’esempio riportato tronca tutte le query interne, quindi ad esempio la pagina /ricerca.html?key=asd viene tracciata solo come /ricerca.html. Dovrete ingegnarvi con un po’ di javascript per gestire tutti i casi.
3. Si crea un filtro di inclusione di tipo custom con “includi – URI della richiesta – corrisponde a espressione regolare – ^/dhffjsrr12353fdf4253kc
4. Si crea un filtro cerca e sostituisci per evitare di avere nei report degli URL orrendi. quindi filtro custom – cerca e sostituisci – URI della richiesta – cerca ^/dhffjsrr12353fdf4253kc/ – sostituisci con /. Nell’ordine dei filtri questo deve stare sotto al precedente, altrimenti non funziona nulla

Come vedete è una soluzione radicale, che va aggiustata e testata per bene prima di essere portata in produzione, e che a me sinceramente fa anche abbastanza orrore, concettualmente, perché costringe tutti a un lavoro grande e potenzialmente pericoloso per i dati. Ma è anche vero che se dovessi pensare a un metodo radicale per Google di evitare a tutti noi i ghost referrals senza uccidere il measurement protocol non mi viene in mente qualcosa di tanto diverso. Magari la chiave di sicurezza potrebbe essere generata direttamente da GA, e così il filtro di inclusione e replace, e il codice di monitoraggio potrebbe già essere fornito funzionante, ma la sostanza del problema non cambia di molto.

Sono appena tornato da dieci giorni di vacanza in Grecia, posti magnifici, cibo ottimo, relax, mare e cultura.
Perché ve ne parlo qui? perché c’entrano Google Analytics e il digital marketing. Seguitemi:

Appena esaurita la prima carica del MacBook Air estraggo l’alimentatore solo per scoprire con orrore che il mio cavo terminale finisce con una spina a tre denti (tipo L italiana, con messa a terra) mentre in Grecia usano prese con Europlug (due fori) o comunque Schucko. Figure su Wikipedia.
Chiedo al ragazzo dell’hotel in cui alloggio se ha un adattatore, e me ne procura uno, ma il Mac non si ricarica. “Che computer hai?” mi dice. “MacBook Air” rispondo. “Gimme five! anche io. Ti presto il mio alimentatore”.
Ovviamente lui aveva il modello vecchio (connettore MagSafe) e io quello nuovo (MagSafe 2 – grazie Apple!) quindi al mattino sono punto e a capo, col computer morto. “Ti presto il mio, che lavoro fai?” “mi occupo di digital marketing” “fantastico! sai che ho appena rifatto il sito? magari puoi darmi qualche consiglio!”. Mi sembra ovviamente il minimo, data la sua estrema gentilezza, e quindi iniziamo a parlare dopo che gli ho precisato che in particolare mi occupo di Digital Analytics.

“ah si! ho Google Analytics, te lo faccio vedere, dimmi se secondo te è a posto, perché io ho dei dubbi”. E inizia a mostrarmi il pannello spiegandomi i problemi: i dati del sito vecchio non ce li ha più, gli hanno fatto aprire un account nuovo “perché era meglio” (in realtà la vecchia agenzia lo ha tagliato fuori dai vecchi dati). Il sito ha un booking engine esterno, niente cross domain tracking. Il profilo non ha nemmeno un goal configurato, gli dico che almeno almeno dovrebbe avere la thankyou post prenotazione e l’invio della form dei contatti.
“ma questa Agenzia è partner certificato?” gli chiedo; non perché questo sia una garanzia assoluta, ma insomma un minimo… “si si” mi assicura, eppure io sull’elenco dei partner non la trovo. “guarda la firma nelle mail”, che ovviamente riporta il logo Google Analytics Qualified Individual.

Insomma, dopo due in ogni caso piacevoli sessioni da mezz’ora (si, perché anche dopo aver switchato i cavi terminali non andava – alla fine era proprio morto l’alimentatore) sono costretto a sentenziare “mi dispiace, cambia agenzia. In questo campo non mi sembrano proprio a loro agio”. La morale che ne ho tratto è questa: lavora sempre al meglio delle tue possibilità, non approfittarti di nessuno, non mentire, ammetti i tuoi limiti, non fare (male) cose che non sai fare bene. Sii onesto e cerca sempre sempre di migliorare, perché anche se lavori per il cliente microscopico nel più remoto angolo del paese, prima o poi alla lunga i nodi vengono sempre al pettine 🙂

Uno dei due ingegneri a capo del Google Tag Manager – Brian Kuhn – ha da poco annunciato una novità molto importante: il prodotto ora introduce uno standard aperto per la creazione dei template dei tag, e soprattutto demanda ai singoli vendor la loro creazione tramite un processo di iscrizione – submit, testing&verifica e approvazione: il tag template program.

Se avete mai fatto delle installazioni un po’ corpose avrete usato quasi sicuramente tag di Analytics e AdWords: per essi ci sono dei comodissimi template che rendono il lavoro veloce, facile e praticamente a prova di errore. Se avete aggiunto dei tag diversi (Criteo fino a qualche tempo fa, ma anche solo un conversion pixel di Facebook al quale passare la revenue di un acquisto) avrete dovuto giocare con i tag HTML custom, con il rischio di perdere tempo nel capire come mai il tag non funzionava o peggio il contenitore non validava. Una volta ho perso più di mezz’ora su un tag HTML custom perché mancava un apostrofo su migliaia di caratteri.

Questo da ora in poi potrebbe ridursi, perché ogni strumento di marketing che richiede tag ha la possibilità di iscriversi al programma e di creare in autonomia i suoi template, che dopo essere stati validati da Google saranno resi disponibili agli utenti di tutto il mondo. La prima infornata di questi nuovi tag comprende:

• Affiliate Window
• Ve Interactive
• Neustar
• Eularian
• Mouseflow
• Nudge
• SearchForce
• TradeDoubler
• Google Consumer Surveys

Il Tag Manager vuole diventare uno strumento sempre più facile da gestire e alla portata di tutti, e questa mossa sono certo che vada nella direzione giusta

Vi sarete accorti che non ho scritto nulla sulla cosiddetta cookielaw, e per chi mi segue sui social network, che mi sono tenuto a distanza da quasi tutte le conversazioni. E’ stata una scelta deliberata, quando ho capito mesi fa che le cose non sarebbero andate affatto lisce come qualcuno sperava. Qualcuno si aspettava un post almeno a proposito dei cookie di Analytics, ma nemmeno su quelli ci sono certezze.

Per lavoro, so di questa norma da più di un anno, quando ancora era in discussione. Io e l’azienda dove lavoro abbiamo tentato di fornire materiale e risposte per provare a chiarire i punti critici del provvedimento quando ancora non era una legge. Nonostante tutto, è uscita come tutti la conosciamo. La prima cosa che ho capito quando abbiamo iniziato a lavorarci è stata questa: l’interpretazione legale è imprescindibile, e quindi qualsiasi cosa avessi detto o scritto, sarebbe stata sbagliata, semplicemente perché – ed è assurdo, me ne rendo conto – ognuno in quella norma ci legge cose diverse.

Ho finora lavorato con 4 legali diversi, e non c’è una installazione uguale ad un’altra. Ho letto i post di molte persone sui social e sui blog, e ognuno dice tante cose giuste e tante cose enormemente sbagliate, ma poiché tutto si basa su interpretazione, hanno ragione tutti.

Il più grande demerito di questa legge è quello di aver trasformato per sempre i concetti alla base dei cookie. Una cosa universalmente nota (oserei dire binaria) come “cookie di prima parte e cookie di terza parte” (cookie salvati nello stesso dominio che si visita = prima parte, salvati su altri domini = terza parte), un concetto cristallino e inoppugnabile, è diventato un problema insormontabile una volta trasformato in legalese “cookie DELLA prima parte e cookie DELLA terza parte” (cookie creati dal gestore del sito o creati da “altri”): i casi si moltiplicano e si complicano, perché ad esempio un “pezzo di sito” fatto e hostato da un partner diverso dal gestore è una terza parte? quindi i loro cookie tecnici sono di terza parte? e se quel pezzo di sito c’è un pulsante di Facebook, è una terza parte che crea cookie su una terza parte? se invece vale “chi ha deciso di mettere quel pulsante” e sto usando un template già pronto? insomma le complicazioni di questo modo di chiamare le cose sono infinite.

Fine della digressione e del rant, non credo ci saranno ulteriori update in materia su queste pagine.