Nov 12 2015

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

Lo strano caso del campionamento invisibile

autore: Marco Cilia categoria: generale tag:

L’altro giorno mi è capitato uno di quei casi da Sherlock Holmes che all’inizio sembra che vada tutto a rotoli, ma poi si risolve brillantemente escludendo tutte le possibilità e osservando bene, proprio come il buon vecchio investigatore ci ha insegnato a fare (a dire il vero, sono un patito della versione interpretata da Benedict Cumberbatch, così lo sapete 🙂 )

Il problema suona all’incirca così: “Marco, succede che selezionando i dati di un mese ho queste transazioni da cpc, ma se applico la dimensione secondaria categoria del dispositivo, sono meno. I dati non sono campionati”. (se ti serve un ripassino di cosa sia il campionamento…)
Ovviamente la cosa non ha senso, vista da questa prospettiva, per cui come al solito debbo smanacciare un po’ con i dati direttamente per capire sino in fondo cosa succede. Ecco le mie prove:

  • seleziono il mese, vado nel report acquisizione -> tutto il traffico, seleziono solo google / cpc, mi annoto le transazioni (661), applico la dimensione secondaria categoria del dispositivo, guardo le transazioni: 655. L’occhio si sposta sul riquadro del campionamento, il rapporto è basato sul 100% delle visite
  • torno indietro al report tutto il traffico, FILTRO per google / cpc, mi annoto le transazioni (661). Il report è preaggregato, e non sarebbe campionato nemmeno con 20 milioni di visite, quindi il numero è corretto. Applico la dimensione secondaria categoria del dispositivo, guardo le transazioni: 655. Il rapporto è basato sul 100% delle visite
  • mi sposto nel report mobile -> panoramica, applico la dimensione secondaria sorgente / mezzo, FILTRO AVANZATO per google / cpc e guardo le transazioni: 655. Anche qui 100% di campionamento.
  • Applico un segmento avanzato su google / cpc: 655 transazioni. Lo tolgo, 661 transazioni da cpc. Sempre 100%
  • Custom report, stessi risultati
  • Cambio approccio: invece di usare categoria del dispositivo, uso un’altra dimensione: stesso comportamento. Rapporti basati sul 100% delle sessioni. Inizio a temere un bug di Google Analytics
  • Abbandono la ricerca su cpc e faccio le stesse prove sui totali. Invece di 6, mancano in tutto 22 transazion

Ho provato moltissime combinazioni di custom report, segmenti, dimensioni secondarie, ma il problema invariabilmente si presentava. I dati considerati erano quelli di gennaio 2015. Sui dati di novembre, niente problema. Ma allora che cavolo di bug è? proviamo con i dati di febbraio 2015: perfetti, il totale con e senza dimensione secondaria combacia. Marzo 2015, problema presente. Testo i dati 1-15 gennaio, combaciano. 16-31 gennaio, combaciano. Faccio la somma a mano e viene 661. Rimetto tutto gennaio, GA mostra 655. La cosa prende una piega terrificante. Sposto l’attenzione sulle sessioni, anche quel numero non combacia con la dimensione secondaria applicata o senza. Mi gira la testa…

Ci prepariamo a scrivere a Google, con copiosi screenshot a supporto della nostra bizzarra situazione, quando alla review finale ho l’illuminazione. GA ha presumibilmente si un baco, ma non è dove crediamo che sia. Riguardo gli screenshot per assicurarmi che si veda bene che segni sempre 100% di campionamento e noto il numero totale delle sessioni del mese: 503.472. Ferma tutto, da che mondo e mondo, con il selettore su “report più lenti, maggior precisione”, il sistema non campiona se non deve fare calcoli su meno di 500.000 visite. Quindi qui ce ne sono di più, poche di più… vuoi vedere che?

500.000 / 503.472 * 100 = 99,31%

BINGO! il bug è che il riquadro, sebbene normalmente istruito per mostrare due decimali nel fattore di campionamento, arrotonda lo stesso 99,31 a 100. Quindi sta campionando, ma non sembra. Il che significa anche che in quelle 3.472 sessioni che mancano quando campiona su 500k ci sono 22 transazioni, con un conversion rate dello 0,63% che è perfettamente in linea con la media del sito in questione, e che conferma la bontà dell’algoritmo di campionamento.

Moriarty, c’hai provato anche ‘sta volta ma t’è andata male! 😀


Oct 22 2015

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

Un esempio d’uso delle nuove metriche calcolate

autore: Marco Cilia categoria: report tag: ,

Come sarebbe a dire “quali metriche calcolate?” Non avete letto l’annuncio sul Google+ di Analytics? 🙂

Le metriche calcolate sono un altro tassello mancante del GAP tra le piattaforme di Analytics considerate storicamente enterprise e Google Analytics; come si può facilmente immaginare dal nome, rappresentano delle metriche che non solo non esistono nativamente in piattaforma (anche le custom metrics non esistono se non le creiamo noi), ma che vengono prodotte attraverso calcoli che il sistema fa al posto nostro. In alcuni casi quindi non sarà più necessario esportare i dati su Excel solo per mettere in relazione due o più metriche già presenti nel sistema. Ad esempio la pagina di help ufficiale riporta come caso d’uso la metrica calcolata “Entrate per utente”, che si calcola con la semplice formula {{Entrate}} / {{Utenti}}

Siccome le ho avute in beta da parecchi mesi, vi riporto un semplice caso d’uso differente da quelli dell’help center: analisi dello sconto medio.
Il business need è quello di fare valutazioni più ampie rispetto alle Entrate riportate dal sistema, che nel caso in esame vengono registrate al netto di sconti; ad esempio una domanda potrebbe essere “quanta revenue ho incassato in meno questo mese per via delle promozioni in corso?”. Oppure “quale è lo sconto medio di tutti i prodotti dello store Svedese?”

Per arrivare al report come concordato con chi ne avrebbe usufruito siamo partiti dal registrare, tramite una custom metric di prodotto, lo sconto percentuale applicato, per cui se compro due prodotti da 100 euro l’uno, uno a prezzo pieno e l’altro in sconto del 15 percento, sulla thankyou page registro:

– prodotto1: entrate 100 sconto 0
– prodotto2: entrate 85 sconto 15
(sconto è la mia custom metric, che in piattaforma chiamo SommaSconto%)

La metrica calcolata “sconto medio” è di tipo “percent” e la formula è questa
{{SommaSconto%}} / {{Quantità}} / 100

che nel caso in esame produce una metrica media del 7,5%, segmentabile e filtrabile esattamente come qualsiasi altra metrica presente in Google Analytics.
Questa metrica non risponde alla domanda “quanta revenue in meno ho incassato”, ma nessuno ci vieta di fare un’altra metrica calcolata (questa volta di tipo “valuta”) con formula

{{Entrate generate dal prodotto}} * 100 / (100 – {{SommaSconto%}})

In questo modo su un custom report possiamo esporre le Entrate reali e quelle potenziali, affiancate, segmentabili per paese, prodotto, categoria, eccetera…

Facile, comodo e veloce, non trovate? 🙂


Oct 13 2015

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

Il conteggio ufficiale delle hit, a portata di mano

autore: Marco Cilia categoria: generale tag: ,

Oggi, mentre mi aggiravo nei meandri più reconditi dell’interfaccia di amministrazione di Analytics cercando di risolvere un problema, mi sono accorto che nelle impostazioni della proprietà (property nell’interfaccia inglese) E’ stato aggiunta una sezione con il conteggio – ufficiale – delle hit del giorno prima, degli ultimi 7 giorni e degli ultimi 30 giorni.

hit-counter-exposed

In realtà era già possibile avere questo numero, attraverso un custom report; vedo peraltro adesso che hanno anche sistemato l’interfaccia: prima infatti nell’interfaccia inglese dei custom report c’era la metrica HITS e la metrica VISITS. Poi visits è diventato SESSIONS, ma poco importa. Nell’interfaccia italiana invece hits è stato sempre tradotto con VISITE, e poi c’erano le (vere) VISITE :-/ (poi il caos: visite è diventato SESSIONI e hits/visite è rimasto visite, ma figurati scambiare visite (che erano hits) pensando a sessioni e fare un report così, tremendo!!!). In ogni caso un report costruito così, ad esempio

hit-custom-report

su una property senza filtri, mostrerebbe gli stessi identici risultati del pannello di amministrazione.

Prima ancora il metodo empirico consisteva nella rude somma di pagine viste, eventi, interazioni social, transazioni e item, con l’aggravante del sitespeedsamplerate che si scatena solo in alcuni casi, consumando hit aggiuntive.

In ogni caso mi sembra un’aggiunta interessante, specialmente per chi fa largo uso di eventi ed è vicino alla soglia critica dei 10 milioni di hits mensili, oltre la quale si è fuori dai Termini del Servizio di Google Analytics Free.


Sep 30 2015

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

I dati come i LEGO

autore: Marco Cilia categoria: tagmanager tag: ,

Ultimamente, sempre più spesso, mi è capitato di parlare con persone e intuire come nella loro testa fosse difficile capire le relazioni che ci sono tra gli strumenti che utilizziamo, il modo di trasportare i dati e la loro rappresentazione nel sistema. Grossomodo è la stessa relazione esistente tra chi dice genericamente “il posizionamento” sui motori di ricerca, e un SEO attento che invece conosce la differenza tra fasi distinte di crawling, indicizzazione e ranking (lo so, anche questa è una semplificazione).

La cosa è evidente soprattutto quando si parla di Enhanced Ecommerce e quando di mezzo c’è il/un TagManager. Vediamo di provare a fare chiarezza.

I bei tempi andati

Nei tempi che furono esisteva una relazione stretta, quasi 1:1, tra quel che si faceva in pagina con Google Analytics e la rappresentazione che ne usciva fuori nello strumento: metto il codice di base? ho le pageview. Metto un trackEvent su un pulsante? ogni volta che lo premo avrò un evento su Analytics. Facile, preciso, indolore. Il controllo era assoluto, e ogni azione provocava una reazione. Ho un Ecommerce? metto un ALTRO tag particolare sulla thankyou page per dire ad Analytics che l’utente ha comprato, e cosa, e quanto ha speso eccetera…

l’avvento del TagManager

Il primo “scollamento” tra la relazione stretta è stato l’inserimento del TagManager. Non esiste più una relazione 1:1 tra quel che faccio in pagina e quel che ritrovo sullo strumento (o almeno, non necessariamente anche se si può fare in modo che accada), semplicemente perché in mezzo c’è un altro sistema che possiede una logica propria ed è in grado di “fare cose”. Metto il contenitore del TagManager e dentro c’è il codice di base di GA? ho le pageview. Dentro ci metto un evento GA con la stessa regola? allora avrò per OGNI pagina ANCHE un evento su Google Analytics (non fatelo, non ha senso 🙂 ). Creo un evento GA che parte solo sul click di un bottone, che intercetto con GTM? allora avrò un evento esattamente quando mi serve. Il problema, se così vogliamo chiamarlo, deriva da una scelta infelice degli ingegneri del TagManager, che hanno creato un metodo per pompare informazioni dentro al dataLayer (la struttura di dati che viene letta automaticamente dal GTM) dandogli un naming particolare: event. Ora, quando si usa la sintassi

dataLayer.push({'event': 'video', 'titolo': 'video corso di GA'});

NON si sta creando un evento Google Analytics con category “video” e action o label “video corso di GA” (infatti il TagMAnager non serve solo per GA, questo in teoria dovrebbe essere sufficiente a chiarire la cosa, ma così non è). Si sta semplicemente dicendo al TagManager che c’è una situazione (purtroppo si chiama evento, ma possiamo chiamarlo message, o push) e che la parte di dataLayer che si chiama titolo va aggiornata con l’informazione “video corso di GA”. Se vogliamo farne un evento GA dovremo configurare un tag GA di tipo evento, con category fissa e action o label presi da una variabile dataLayer che legge “titolo”.
Se questa parte di dataLayer esisteva già, l’event fa l’update, se invece non esisteva la crea. E qui inizia il gioco delle costruzioni con i mattoncini. Per ulteriori dettagli tecnici vi invito a leggere il GTMtips #26 di Simo Ahava

l’Enhanced Ecommerce sul TagManager

Il secondo scollamento totale tra quel che si fa in pagina, come viaggiano i dati e che risultato otteniamo in interfaccia è stato l’Enhanced Ecommerce. Per far si che l’Enhanced Ecommerce funzioni a dovere, è necessario fornire i dati in un certo modo. Se si usa il Google TagManager alla pagina linkata ci sono le istruzioni e le configurazioni necessarie affinché questo accada. Ma sono un po’ fuorvianti 🙂
Bisogna capire per bene i tre momenti distinti che servono per arrivare al risultato finale:

  1. devo mettere nel GTM le informazioni necessarie, facciamo l’esempio di 4 impressions. La parte rilevante è QUANDO riesco ad avere queste informazioni. Il programmatore potrebbe averle già quando si crea la pagina, e metterle nel dataLayer che c’è in HEAD. Oppure potrebbe avercele solo ad un certo punto del sorgente della pagina, e quindi fare un dataLayer.push nel body, dopo il contenitore.
  2. devo inviare le informazioni a GA: se le informazioni sono nel dataLayer in HEAD, mi basta il tag di base di GA opportunamente provvisto della spunta “usa Ecommerce avanzato” e “usa struttura livello dati”. Il sistema accoda le informazioni sulle impression a quelle della pageview, per risparmiare hit. Finito. Se invece il programmatore ha dovuto fare un push dopo il contenitore (quindi al 99% DOPO CHE LA PAGEVIEW è già partita verso i server di Google), allora le mie impressions stanno si nel dataLayer, ma ci restano finché non si comunica di nuovo con i server PRIMA di cambiare pagina: ricordate che il dataLayer riparte da zero ad ogni cambio pagina. Allora mi servirà un evento Google Analytics, anche un evento fake inutile per le analisi, che provvisto delle stesse spunte di cui sopra mi fungerà da trasporto per i dati delle impressions

La cosa è spiegata bene solo nell’esempio della thankyou page

EE-purchase

“pusha i dettagli della transazione nel dataLayer usando l’action purchase, insieme ad un evento che azionerà un tag evento con le opzioni ecommerce. In questo esempio, i dettagli della transazione sono conosciuti nel momento in cui la pagina carica, e saranno inviati con una pageview quando si aziona gtm.js (cioè quando si apre la pagina, ndMC)”

conclusioni

Con gli strumenti a disposizione oggi è necessario comprendere bene quale sia il flusso dei dati in fase di collezionamento e di invio. Dimentichiamoci delle relazioni dirette: la pagina parla col dataLayer, che parla col TagManager, che parla con Google Analytics (che parla con noi 🙂 ). Ognuno di questi passaggi ha delle peculiarità e dei punti di attenzione, ma presenta anche grandi opportunità di modifica, razionalizzazione e pulizia dei dati.


Sep 02 2015

Come funziona Tag Assistant Recording

autore: Marco Cilia categoria: codice di monitoraggio

La novità dell’estate del mondo Google Analytics, anche se arriva a fine agosto, è la disponibilità di Tag Assistant Recording, una sorta di v3 del plugin di controllo/debug dei tag Google, di cui vi avevo già accennato in questo post.

Se non sapete di cosa si tratta, partite dallo scaricare l’estensione di Chrome da questo link. In breve l’estensione controlla su ogni pagina la presenza di tag di marketing by Google, quindi Google Analytics, AdWords, Doubleclick, Google Tag Manager. Per ognuno di questi sono disponibili molte informazioni, e si può cambiare il livello di dettaglio di esse utilizzando le opzioni dell’estensione; ad esempio l’estensione potrebbe dire che su una pagina ci sono due Floodlight, due Analytics versione classica e uno Universal dentro a un container TagManager. Che uno dei tag è nella posizione sbagliata, che altri tag non funzionano come previsto, insomma una marea di informazioni utili.

La funzionalità nuova e più interessante però è quella di recording, ovvero l’estensione registra una navigazione e poi vi consente di riguardarla step-by-step con vari livelli di informazioni. Per utilizzarla è necessario premere il pulsante “RECORD“, nella parte bassa dell’interfaccia dell’estensione: da quel momento un classico pallino rosso ci avvisa che l’estensione sta registrando. Dopo aver navigato le pagine che ci interessano ed aver fatto tutte le azioni che desideriamo controllare si può stoppare la registrazione ed avere un rapido sommario che somiglia a questo:

TA-recording-sommario

Il click su “show full report” ci porta ad una interfaccia divisa in due macrosezioni: la prima riguarda un report sui TAG che vengono inviati, quindi tutti quelli supportati da Tag Assistant. Le seconda invece è prettamente dedicata a Google Analytics. Ma andiamo con ordine: il report dei Tag su un sito complesso può assomigliare a qualcosa del genere

TA-vg

e subito notiamo la possibilità di filtrare solo i tag che ci interessano. Di base, il sistema permette di vedere le pagine registrate e per ogni pagina mostra: URL, timestamp della richiesta, tempo di caricamento, numero di tag totali, numero di errori, warning e suggerimenti. Per ogni tag di ogni pagina mostra i metadati, ovvero un riassunto di cosa fa un tag (advertiserID per Floodlight, o UA di Analytics, per esempio), le ottimizzazioni possibili se ce ne sono e le richieste (un tag potrebbe infatti generare più richieste). Per ogni richiesta generata, infine, mostra i metadati, ovvero l’elenco dei parametri, alcuni dei quali sono tradotti in un linguaggio comprensibile mentre altri restano da decifrare.

Spostandosi nella sezione “Google Analytics report” invece l’interfaccia cambia, e a seconda che la mail con la quale siete loggati in Chrome/Analytics abbia o no accesso alla property GA che state analizzando, le possibilità variano. Innanzitutto il menu laterale, che è fatto così:

TA-GA-section

  1. Update report permette di ricaricare il report dopo aver fatto modifiche nella configurazione.
  2. Select Views permette di switchare tra i vari recording di GA, se le pagine inviavano dati a più properties. Nel caso in cui non abbiate accesso ai dati, esce il messaggio “The recording contains hits sent to this property, but you (email@email.ext) don’t have permissions in Google Analytics for its views. You won’t be able to see view-specific information.
  3. Change Location permette di simulare la visita come proveniente da una differente località o da un diverso indirizzo IP
  4. Open permette di caricare un file con una sequenza di hit e Save di salvare la sequenza corrente, per riusi futuri

Nella parte destra invece troviamo un recording summary, con informazioni generali come l’ora della registrazione, il totale delle pagine e dei tag, la property selezionata, ecc, seguita da una sezione di alert, in cui il sistema da una valutazione di quel che ha visto, una sezione di “views summary” che esiste solo se state guardando i dati che andrebbero ad una property cui avete accesso, e che riassume così la visita (clicca per ingrandire)

TA-behavior

Ricordate che siamo FUORI da GA, quindi se avere informazioni su Browser e OS è banale, vi invito a guardare la sezione “conversions” 😉
Il caso d’uso praticamente è questo: voi su un Analytics settate una conversione, poi andate sul sito e registrate la sessione mentre convertite, poi chiedete a Tag Assistant se quella sarebbe stata una conversione; se vi dice no, modificate il setting del Goal, tornate su Tag Assistante e fate Update Report e controllare in tempo reale se la modifica ha senso. Notevole no?
Altra cosa che potete fare, questa però non l’ho provata, è vedere se una richiesta passa indenne o viene modificata da un filtro, nella sezione FLOW -> Hit -> Mutuations

Per finire, se salvate una sessione la potete riusare in futuro; i file hanno estensione .harz
Già questo può essere interessante perché potete scambiarvi o farvi inviare da un cliente la sua navigazione, e controllare come la vede GA senza essere fisicamente da lui o nelle sue “condizioni di rete” (proxy, location, rete, eccetera). Più interessante ancora è che i file HAR sono uno standard per gli archivi di richieste HTTP, e quindi ci sono moltissimi software che possono generarli (un semplice Chrome dal pannello NET, Fiddler, Firefox dalla versione 41 in su, secondo questa lista).
Altro caso d’uso quindi: per strettissime policy aziendali e insormontabili problemi tecnici, è impossibile vedere gli ambienti di staging del nuovo sito del cliente, quindi si dovrebbe configurare alla cieca o quasi. Si va dal cliente, si fa esattamente il percorso di conversione e si registra con Tag Assistant. Dopo si torna in ufficio e lo si testa infinite volte man mano che la configurazione dell’account procede.

Non c’è praticamente limite alle possibilità di debuggare ogni più piccola virgola, in tempi sempre più ristretti e con risultati sicuramente più veloci.


Aug 25 2015

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

Sequenze di tag nel TagManager

autore: Marco Cilia categoria: tagmanager tag: ,

Una delle più recenti e utili aggiunte al TagManager è quella delle “sequenze di tag“: si è sempre detto infatti che i tag lanciati sono tutti asincroni, e che il TagManager li lancia appena può. Questo è sempre vero, anche se in realtà esistono da tempo almeno alcuni strumenti che provano a mitigare il problema.

agganciare i tag a diversi eventi del TagManager: un tag agganciato a gtm.js verrà SEMPRE sparato prima di uno agganciato a gtm.dom, a sua volta lanciato prima di gtm.load. Si tratta di conoscere l’ordine con cui sono eseguiti i tre eventi fondamentali che avvengono sempre al caricamento di una pagina

– usare la “priorità di attivazione dei tag” nelle opzioni avanzate di un tag: di default i tag hanno tutti priorità 0, ma se si varia quel numero con uno maggiore, il GTM proverà a inviare prima quelli con il numero più alto. Nessuna garanzia di successo, in ogni caso…

– usare eventCallback o “hit richiamata”, che sono proprietà che hanno gli eventi su TagManager e i tag di Analytics: ogni volta che un push viene fatto o un tag GA viene eseguito, si può conoscere lo stato di OK o KO ed eseguire un altro comando. Maggiori dettagli in questo post di Simo Ahava

– giocare – pericolosamente – con catene di dataLayer.push(), custom HTML tag e attivatori specifici

L’opzione nativa di sequenza dei tag invece permette di specificare, dato un tag che chiameremo PRINCIPALE, un tag da eseguire PRIMA di esso (Simo li chiama setup tag) e un tag da eseguire DOPO di esso (cleanup tag). E’ possibile specificare se i tag dipendenti devono essere lanciati o no quando un tag non completa con successo il suo compito. Di default le opzioni dicono che non si blocca nulla, ma avete comunque la possibilità di variare la scelta. La cosa funzione anche per i tag di tipo custom HTML, anche se in maniera un po’ più complessa e tramite l’uso della nuova variabile HTML ID: per questo punto vi rimando direttamente al post di Simo che è sufficientemente articolato.

Poiché uno stesso tag può essere chiamato con un evento principale (ad esempio, l’apertura di una pagina) e anche come tag di setup e cleanup di un altro tag su un’altra pagina o di un evento sulla stessa pagina, si pone il problema di evitare gli invii multipli: questo compito è assolto da un’altra nuova opzione che si chiama “opzioni di attivazione del tag” e che presenta le seguenti scelte: illimitata (il tag viene sparato sempre), una volta per evento (il tag viene sparato solo una volta all’interno dello stesso evento GTM), una volta per pagina (il tag viene sparato solo una volta sulla pagina corrente).
Quest’ultima opzione ci viene in aiuto anche in altri casi particolari dove vogliamo evitare la duplicazione dell’invio di tag particolari (penso ad esempio ai contatori) nel caso in cui la configurazione corrente consenta di farlo; prima era necessario scrivere e duplicare parecchie regole ed eccezioni, adesso possiamo demandare questo lavoro direttamente al Google Tag Manager.


Aug 12 2015

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

La trasformazione del report AdSense

autore: Marco Cilia categoria: report tag: ,

Stando a quanto dichiarato qualche giorno fa dall’account ufficiale Google+ di Analytics, presto vedremo comparire nei nostri Google Analytics una nuova sezione all’interno del gruppo di report “comportamento”: si tratta dei report “publisher”. In sostanza i report AdSense vengono assorbiti dentro a questa nuova sezione, e per chi usa solo questa piattaforma non cambia nulla se non il nome dei report. Tuttavia, ci tiene a precisare Google, dentro a quei report possono finire – previo collegamento da fare tramite il pannello di amministrazione – anche le performance di Ad Exchange Seller
Purtroppo al momento vedo in un mio account i nuovi report, ma se provo ad iniziare la procedura di collegamento mi viene fuori sempre un errore di risorse non disponibili, per cui non riesco a dare dettagli aggiuntivi rispetto a quanto dice Google nel suo post.


Aug 02 2015

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

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

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

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 😀


Jul 15 2015

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

L’unico sensato – ma ancora da venire – modo di bloccare i ghost referrals

autore: Marco Cilia categoria: generale tag: , , ,

Questo post è il complementare dello scorso “L’unico vero – ma insensato – modo per bloccare i ghost referrals” e ne riprende naturalmente il titolo 🙂

Si diceva che se Google dovesse fare un sistema di blocco preventivo dei ghost referrals dovrebbe studiare un sistema simile a quello descritto nel post, almeno a detta del sottoscritto. Si diceva nei commenti che forse un altro modo potrebbe essere un “segnala come spam” simile a quello di Gmail, ma che la cosa potrebbe avere problemi di workflow di approvazione.

Com’è, come non è, oggi thesempost.com ci informa che Adam Singer, Analytics advocate a Google, ha detto chiaramente durante il Mozcon che Google sta lavorando per risolvere il problema alla radice. Non ci sarà quindi da rivolgersi a terze parti ma soprattutto Singer – secondo l’articolo – ha detto che Google sta lavorando al problema in modo che la soluzione sia scalabile, ovvero che possa risolvere il problema adesso e per sempre, anche se gli spammer cambiassero i loro pattern di invio dei dati fasulli. Sembrerebbe quindi un qualcosa più simile ai filtri antispam di Gmail, ma ovviamente senza prima vederlo in azione non possiamo sbilanciarci troppo.

La creazione di un sistema definitivo spiegherebbe anche la relativa latitanza da parte di Google negli ultimi mesi durante i quali il problema è balzato alle cronache. Meglio tardi che mai, no? 🙂


Jun 30 2015

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

L’unico vero – ma insensato – modo per bloccare i ghost referrals

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

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.