Google Analytics in 30 secondi

Proprio come dicevamo nell’ultimo post, gtag.js ha da poco aggiunto il supporto nativo per AdWords: questo significa che se avete un sito che sta già tracciando tramite il nuovo gtag.js, basterà aggiungere una riga di configurazione specificando l’account AdWords nel quale inviare i dati, così:

<script>
    window.dataLayer = window.dataLayer || [];
    function gtag(){dataLayer.push(arguments)};
    gtag('js', new Date());

    gtag('config', 'GA_TRACKING_ID');
    gtag('config', 'AW-123456789');
  </script>

e tracciare l’azione da monitorare come conversione, così:

<script>
      gtag('event', 'conversion', {'send_to': 'AW-123456789/AbC-D_efG-h12_34-567',
        'value': 1.0,
        'currency': 'USD'
      });
  </script>

Le opzioni per mantenere il conteggio delle conversioni accurato, per prevenire i problemi introdotti da Apple e dal suo Intelligent Tracking Prevention, sono in ogni caso attualmente tre:

1. passare a questo nuovo formato di script. Questo permette di salvare i GCLID di AdWords in cookie di prima parte, che non vengono toccati dall’ITP di Safari/IOS
2. usare Google Analytics collegato ad AdWords. GA già da settembre si occupa di salvare il gclid in un cookie di prima parte, favorendo poi AdWords
3. usare Google Tag Manager per inserire un nuovo tipo di tag, il conversion linker tag su tutte le pagine, che fa sempre la stessa cosa

Interessante anche la conferma finale nel post sul blog di AdWords riguardo al fatto che a Novembre aggiungeranno anche il supporto per DoubleClick Search, confermando quindi che il nuovo gtag.js potrà tendenzialmente gestire anche quella parte di piattaforma, diventando moooolto interessante per chi non può o non vuole passare a GTM.

Ok, alla fine ce l’ho fatta. Dicevamo nello scorso post di quello che considero il più grande passo indietro della storia di Google Analytics, che ovviamente non ha a che fare con i report – quelli vanno e vengono – ma con una funzionalità “core”: il modo in cui i cookie memorizzano le informazioni dell’utente e della sorgente.

Per farla breve:

Finché si usava la versione classica, l’identificativo dell’utente E la sorgente della visita erano scritti “in chiaro” nei cookie. Sharare un cookie tra sottodomini o tra domini diversi (con il cross domain tracking), manteneva la consistenza dell’utente – ove possibile – e della sorgente ANCHE se i tracking avvenivano su property diverse. Usando Universal Analytics, questo si può fare SOLO all’interno della stessa property.

Spiegazione dettagliata:

Partiamo con un po’ di background tecnico. Usando GA classic il cookie _utma contiene l’identificativo dell’utente, il cookie _utmz la combo source/medium/campaign/gclid.
Esempio di cookie _utma:
10143333.1579115142.1467823144.1467823144.1467832867.2
Esempio di cookie _utmz:
10143333.1467823145.1.1.utmcsr=news.google.it|utmccn=(referral)|utmcmd=referral|utmcct=/

Usando GA Universal, tutto quel che non è identificativo dell’utente è stato spostato “lato server” (server di Google, pensate a quanto storage dedicano per questa attività), alleggerendo il carico dei browser e delle chiamate a GA, che devono portarsi dietro questa informazione per conteggiare le sorgenti correttamente.
Esempio di cookie _ga:
GA1.2.843176649.1467833039

questo basta affinché Google Analytics riprenda il cookie con quell’identificativo – se esiste – e possa continuare le sue analisi da dove le aveva interrotte. Ma attenzione, su GA classic il cookie viene scritto PER DOMINIO, su Universal non lo sappiamo; sappiamo però che lo stesso identificativo mantiene le informazioni precedenti solo se i tracking avvengono nella stessa property. In pratica, ogni property contiene una tabella degli identificativi degli utenti che ha visto, e non “eredita” mai sorgenti da altre property.

Cosa avviene, ad esempio, facendo il cross domain tracking con GA classic? sono sul sito1.com e clicco un link correttamente istruito per fare il cross domain tracking, quindi atterro su sito2.com/pagina.html?__utma=140729130.774561551.1467833502.1467833502.1467833502.1&__utmb=140729130.3.10.1467833502&__utmc=140729130&__utmx=-&__utmz=140729130.1467833502.1.1.utmcsr=(google)|utmccn=(organic)|utmcmd=(none)&__utmv=-&__utmk=98665886
GA prende l’ide dell’utente, la source, il medium e il campaign (nell’esempio su sito1.com era una visita da organico) e scrive anche su sito2.com un set di cookie coerente con il primo. Ora viene il punto importante:

• SE sito1 e sito2 sono tracciati nella stessa property, GA segna 1 utente unico, 1 sessione (da organic) e 2 pagine viste.
• SE sito1 e sito2 sono tracciati con property diverse, GA segna 1 utente unico, 1 sessione (da organic) e 1 pagina vista sul GA di sito1, e segna 1 utente unico, 1 sessione (da organic) e 1 pagina vista sul GA di sito2.

Rifacciamo lo stesso esempio con Universal. sono sul sito1.com e clicco il link, atterro su sito2.com/pagina.html?_ga=1.153530484435.69385205830.8479429413352. Non c’è nessun riferimento a organic, naturalmente. Quell’informazione è memorizzata nella tabella della property di sito1. Ecco come i due casi vengono visti nei report:

• SE sito1 e sito2 sono tracciati nella stessa property, GA segna 1 utente unico, 1 sessione (da organic) e 2 pagine viste. Non cambia nulla
• SE sito1 e sito2 sono tracciati con property diverse, GA segna 1 utente unico, 1 sessione (da organic) e 1 pagina vista sul GA di sito1, e segna 1 utente unico, 1 sessione (da DIRECT se hai impostato correttamente l’esclusione dei referral, da referral nell’altro caso) e 1 pagina vista sul GA di sito2. il GA di sito2 NON EREDITA l’informazione sulla sorgente originale

La cosa accade anche per i sottodomini: con GA classic bastava assicurarsi che sottodominio e dominio principale scrivessero i cookie allo stesso livello, quindi tutti leggevano _utmz e tutti sapevano quale era la sorgente iniziale. Con Universal questo non è più sufficiente, se si inviano i dati a property diverse.

casi pratici:
Sento già il brusìo di fondo perché pensate che stia parlando di casi rari e remoti. Ne ricordo distintamente tre, nella mia vita lavorativa, in cui il comportamento di GA classic mi è tornato comodo. Ce ne saranno altri, ma li do per scontati sicuramente.

Quello più eclatante era un brand Worldwide che pagava dall’headquarter una campagna per inviare visite a un dominio AD HOC creato dall’internazionale, con varie localizzazioni in sottocartelle, e ogni localizzazione poi inviava gli utenti su una landing dei vari siti locali. Non ci permettevano di mettere il nostro GA su quel sito (ne avrebbero avuto uno per ogni paese), ma hanno accolto le istruzioni per fare il cross domain tracking, quindi a noi sul sito locale arrivavano le visite mantenendo le sorgenti e gli UTM usati dall’internazionale per taggare la campagna, dandoci quindi una corretta rappresentazione del loro apporto al nostro traffico. Con Universal questo non si potrebbe fare stante il no iniziale a mettere il nostro codice.

conclusioni:
Non molte; anche se a prima vista può sembrare un post tecnico, vi invito a riflettere sugli effetti pratici che questo ha sulle vostre implementazioni, presenti e soprattutto future; pianificare in quale property inviare i dati diventa fondamentale già in fase di design, se si sta parlando di un tracking appena sopra alla versione base. E intendo anche con dei banali sottodomini, eh!

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 😀

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.

Google Analytics è un sistema di web analytics lato client basato su un pezzetto di codice javascript: ne consegue che tutto quel che non è taggato, per lui è invisibile. Detto così sembra banale, però non lo è quando si cerca di rispondere alla domanda “che succede quando si passa da una pagina senza tag?”
Di fronte a questa domanda ho sentito le risposte più fantasiose, e anche le più irrazionali. La risposta è: niente! La risposta completa in realtà sarebbe “dipende da QUANTO tempo trascorre sulla pagina non taggata” e il tutto parte dal presupposto che la pagina sia nello stesso dominio che si sta tracciando.

Se infatti la pagina non tracciata fa parte di un ALTRO dominio, o di un sottodominio che genera un altro set di cookie, o di un dominio terzo con lo stesso codice di GA ma non gestito con le apposite funzioni di passaggio dei cookie, allora il ritorno ad una pagina tracciata rientra nel caso di una visita da referrer: se il cookie __utmz contiene qualsiasi altra informazione, viene cambiato, viene generata una nuova visita e si vede un referrer.

Se invece si sta parlando di una normale navigazione A -> B -> C, dove la pagina B NON CONTIENE il codice di GA e le altre due si, quel che arriva ai server di Analytics è semplicemente A -> C; B non esiste, non avrebbe modo di sapere che esiste e non può essere tracciata. All’arrivo sulla pagina C Analytics si chiede “e questo visitatore chi è, da dove arriva?”, controlla se è presente il cookie __utmb (che scade dopo 30 minuti di inattività dell’utente), e se lo è semplicemente accoda la pagina C alla visita, e la piazza dopo la pagina A.

Se invece sulla pagina B l’utente trascorre più mezz’ora, allora si genera un nuovo cookie __utmb, quindi una nuova visita, con referrer il proprio sito. Ma questo accade in ogni caso in cui l’utente lascia scadere la sessione di visita, anche nei siti taggati perfettamente.

C’è però una cosa da tenere presente, che è una conseguenza del cambio di calcolo delle visite operato da Google Analytics nell’Agosto 2011: siccome prima di allora il modo per controllare se iniziare o meno una nuova sessione era il cookie __utmc (che veniva distrutto alla chiusura del browser), una sequenza come A -> browser chiuso -> B (il tutto entro mezz’ora) veniva vista come due distinte visite. Da dopo il cambio si tratta invece di una sola visita.

Una delle cose che dico sempre a clienti e durante i corsi, e che sottolineo finché non viene recepita bene, è che Google Analytics sottostima il traffico diretto, perché semplicemente le visite potenziali da tracciare come DIRECT non sovrascrivono il cookie __utmz se in esso è presente un’altra campagna (che non sia direct, ovvio). La cosa l’ho spiegata tempo fa nel post in cui illustravo un’eccezione: tabella di conversione delle sorgenti.

La cosa si può spiegare in parte anche con le ipotesi “maliziose”. Se un utente fa un clic su un annuncio AdWords ma non converte, se poi torna con visita diretta e converte, la conversione viene attribuita al cpc, facendolo sembrare più redditizio di quanto non sia realmente. Ma la cosa come abbiamo detto vale anche per ricerche organiche, referral e campagne, vorrei che restasse chiaro. Dal punto di vista dell’analista d’altronde la cosa nemmeno mi dispiace troppo: il traffico diretto è un po’ un punto morto delle analisi, si possono fare ipotesi (e a volte si riescono anche a verificare), si può vedere la landing page, ma non ci sono molti altri spunti possibili, al contrario di tutte le altre fonti di traffico.

Cosa succede però nei Funnel multicanale, dove la sorgente usata (e addirittura l’ordine delle sorgenti) ha un ruolo fondamentale per la comprensione dei report? se si seguisse la stessa logica si avrebbero GROSSI problemi a comporre quei report, e le valutazioni conseguenti ne sarebbero inficiate. Infatti, come ci informa questo articolo della guida, nelle Canalizzazioni Multicanale – E SOLO IN QUEL SET DI RAPPORTI – il traffico diretto è puntualmente tracciato a prescindere dal cookie __utmz. Nell’esempio precedente al cpc verrebbe attribuita una conversione indiretta (e verrebbe raffigurato come una freccia nel report “canalizzazioni indirette”) e al traffico diretto verrebbe attribuita la conversione (e verrebbe indicato con un rettangolo).

E’ una differenza fondamentale da tenere ben presente quando si guardano i funnel multichannel.

Nel proseguo dell’articolo vengono menzionati altri due fatti interessanti, che riporto per comodità:

• ci possono volere fino a due giorni di tempo per vedere i dati delle canalizzazioni multicanale. Meglio non fare analisi per il giorno precedente.
• Il totale conversioni indicato è sempre dato dalla somma di GOAL + transazioni ECOMMERCE

Nel complesso mi sembrano tre cose molto utili da tenere a mente quando si analizzano i multichannel funnel. Voi li usate? li avete personalizzati?

Se vi ricordate, a maggio scrissi un post lamentandomi dei concetti relativi alla web analytics contenuti nella versione preliminare delle linee guida per i siti web della Pubblica Amministrazione. So di essere una persona che si lamenta molto (sono genovese, ce l’ho nel DNA 🙂 ), ma siccome è un argomento cui tengo mi armai di buona pazienza e feci l’iscrizione al forum dove si raccoglievano le osservazioni: le potete leggere a questo indirizzo.

Ieri è uscito l’aggiornamento delle linee guida, la versione finale, e indovinate un po? le mie osservazioni sono state prese in considerazione, infatti la nota è diventata

Il conteggio dei visitatori unici dipende da molteplici variabili. Ai fini statistici, si consiglia di calcolare, tramite cookie, il numero complessivo di visitatori unici in un periodo di tempo limitato a 30 giorni

(ancora perfettibile ma sicuramente migliore di prima), in compenso mi è caduto l’occhio su un’incongruenza mica male. Infatti a pagina 54, nella nota sopra riportata, si raccomanda l’uso dei cookies come avevo suggerito, mentre a pagina 53 essi sono vietati! Cito:

né debbono essere utilizzati cookies persistenti di alcun tipo, ovvero sistemi per il tracciamento degli utenti. L’utilizzo di cookies permanenti è ammissibile unicamente qualora esso sia necessario alla resa di un servizio che rientri nelle funzioni istituzionali dell’Amministrazione.

e direi che la web analytics non è un servizio istituzionale delle Pubbliche Amministrazioni.

In sostanza è obbligatorio pubblicare i dati di visite (v. pagina 55), pagine viste e visitatori unici, si raccomanda di distinguere gli unici tramite cookie, ma è vietato usare i cookies!

Bravi, bene, avanti così! :-/

Per lavoro mi occupo di siti per la pubblica amministrazione, e per questo motivo mi sono trovato davanti agli occhi la versione 11 maggio 2011 delle linee guida per i siti web della PA. Mentre mi addentravo nella lettura mi è caduto l’occhio su questa pagina del capitolo 4 e in particolare sulla nota a fondo pagina

[21] Si raccomanda di considerare, per le statistiche web, un visitatore unico ogni 30 minuti per IP.

La cosa ovviamente non ha senso: un visitatore unico prescinde da un intervallo di tempo, e di sicuro se io faccio una visita di un’ora e mezza non sono tre visitatori, ma uno solo. Inoltre sono anni che si dice che basarsi sugli IP è arcaico, perché le visite aziendali fatte da dietro a un proxy (ma anche gli accessi dalla rete geografica di Fastweb) vengono “annegati” dietro a un unico indirizzo. Migliaia di persone che risultano come una sola, che però ogni mezz’ora va conteggiata come fosse un’altra :-/

Perché – mi direte voi – una scelta così palesemente sbagliata? non lo so, ma di sicuro fa il paio con quanto scritto nel paragrafo “Policy” a proposito dei cookies, che sarebbero la soluzione al problema di cui sopra:

…né debbono essere utilizzati cookies persistenti di alcun tipo, ovvero sistemi per il tracciamento degli utenti. [omissis] L’utilizzo di cookies permanenti deve essere strettamente limitato all’acquisizione di dati statistici relativi all’accesso al sito e/o per mantenere le preferenze dell’utente (lingua, layout, etc.)

Due frasi in antitesi tra di loro: da un lato sembrerebbe che non si possano utilizzare cookies per il tracciamento, ma per le statistiche si. Ma allora se posso utilizzare i cookies, perché definire gli unici attraverso gli IP?

Infine, tanto per non farsi mancare nulla, le linee guida impongono che i dati del monitoraggio vengano pubblicati periodicamente. Tralasciamo un attimo il fatto che se ogni PA usa un sistema di web analytics differente, i dati non saranno mai confrontabili, e concentriamoci su un altro aspetto: i tre dati da pubblicare sono (sic!) pagine viste, sessioni utente (visite) e visitatori unici.

Solo che, se non si da un intervallo di tempo, parlare di unici non ha senso, per il noto “problema dell’hotel“. Alla linea guida manca fondamentalmente l’indicazione del periodo di tempo da considerare per l’indicazione degli unici. Ogni mese si deve dare il totale annuale degli unici, oppure ogni mese si deve dare il numero di unici del mese precedente?

Traduco un post di ROIrevolution, perché mi sembra interessante: riguarda alcuni consigli per il tracciamento dei sottodomini

Non esiste un articolo specifico nell’help ufficiale dedicato al tracciamento dei sottodomini. Il più vicino è questo, che raccomanda quanto segue:

// questa è solo la parte modificata
var _gaq = _gaq || [];
_gaq.push(['_setAccount', 'UA-12345-1']);
_gaq.push(['_setDomainName', '.example-petstore.com']);
_gaq.push(['_setAllowHash', false]);
_gaq.push(['_trackPageview']);

Propongo invece alla maggior parte dei siti con sottodomini, di usare il codice seguente:

// questa è solo la parte modificata
var _gaq = _gaq || [];
_gaq.push(['_setAccount', 'UA-12345-1']);
_gaq.push(['_setDomainName', 'example-petstore.com']);
_gaq.push(['_addIgnoredRef', 'example-petstore.com']);
_gaq.push(['_trackPageview']);

Cosa c’è di sbagliato nel codice raccomandato da Google? ci sono tre aspetti che potrebbero generare problemi evitabili:

1. Disabilitare l’hashing è male

Disabilitare l’hashing del sito, tramite [‘_setAllowHash’, false] oppure [‘_setDomainName’,’none’] è necessario affinché il tracciamento cross-domain abbia successo. E’ una necessità sfortunata, tuttavia, perché l’hashing del dominio è una cosa veramente utile.

Per definizione, uno script non può identificare il dominio di un cookie; questa informazione non è disponibile a meno che essa non faccia parte del nome del cookie o sia scritta nel suo contenuto. Includere l’hash fornisce quella informazione, così il codice di Google Analytics può leggere il set di cookie corretto in situazioni dove potrebbero essercene più d’uno.

Disabilitare l’hash significa che il codice non ha modo di capire quale set di cookie sia quello corretto. La maggior parte delle volte esiste un solo set, quindi non è un problema. Ma se avete già usato Google Analytics senza il tracciamento dei sottodomini, allora finirete per avere due set di cookie per lo stesso dominio nel caso di un visitatore di ritorno (dopo la modifica, ndMC): un set creato dal codice vecchio, e un set creato dal codice nuovo. Questo accade più spesso nei sottodomini, ma può anche accadere sul dominio principale.

Eduardo Cereto ha un post che approfondisce questo problema con più dettagli e fornisce un altro caso in cui _setAllowHash genera problemi. La morale qui è che avete bisogno di _setAllowHash per il tracciamento cross-domain, ma se invece avete solo a che fare con sottodomini non è necessario e anzi potrebbe causarvi problemi.

2. Il punto messo come prefisso causa il reset dei cookie

Le pagine del Google Code offrono la seguente spiegazione per l’uso del punto prima del dominio quando si usa _setDomainName:

“se volete tracciare attraverso differenti sottodomini:
* dogs.petstore.example.com e
* cats.petstore.example.com

è richiesto un punto prima del nome di dominio”.

Se il vostro sito usa sottodomini allora avrete indubbiamente bisogno di quel punto, pena il non funzionamento del tracciamento. Se il vostro sito non usa sottodomini, comunque,sarebbe meglio non usare il punto.
Il motivo è ancora una volta l’hash. L’hash che viene generato dal codice di Google Analytics quando si usa il punto è differente da quello generato quando invece il punto non si usa. Ma l’hash generato quando non si usa il codice per tracciare i sottodomini sul sito principale è identico a quello generato quando si tracciano i sottodomini senza l’uso del punto.

Questo significa che se non si stavano tracciando i sottodomini in precedenza, usare il punto istruirà il codice di GA a distruggere i vecchi cookie perché l’hash non combacia, che è appunto simile a quanto descritto al punto 1.

Semplicemente, non includere il punto se non è necessario significa avere minori probabilità di reset dei cookie, cosa che facilità la transizione al tracciamento dei sottodomini.

3. Non utilizzare _addIgnoredRef causa problemi di auto-referrer

Se il vostro sito non ha sottodomini il GATC è capace di riconoscere quando la sessione di visita è scaduta tra due pagine visualizzate ed evitare di sovrascrivere il referrer esistente con un auto-referrer o un referrer-interno (cioè evita di far comparire il vostro stesso sito come referrer ndMC).

Questa “protezione” è tuttavia rimossa quando ci sono dei sottodomini, anche se il vostro codice usa la soluzione standard per il loro tracciamento. Questo può risultare in una percentuale elevata di auto-referrer anche se sembra che abbiate fatto le cose per bene.

La soluzione è usare _addIgnoredRef, ma come usarla spesso non è capito fino in fondo. Le raccomandazioni di Google sono di usare un codice simile a questo:

_gaq.push(['_addIgnoredRef', 'www.sister-site.com']);

Ho guardato in profondità nel sorgente di ga.js e osservato che una cosa così effettivamente non funziona. La ragione è che il codice di tracciamento considera www.sister-site.com identico a sister-site.com, quindi aggiungere www.sister-site.com come referrer ignorato non risolve granché. Usare un punto prima del dominio fallisce anche qui. Questo invece funziona benone:

_gaq.push(['_addIgnoredRef', 'sister-site.com']);

e ancora meglio

_gaq.push(['_addIgnoredRef', 'sister-site']);

Il GATC controlla ogni riga di referrer ignorati che aggiungete e usa il metodo javascript IndexOf per determinare se la stringa è contenuta o meno nel dominio referente. Se uno di questi controlli risulta essere positivo, allora il referrer è ignorato. Poiché il dominio principale senza il punto sarà contenuto anche in tutti i sottodomini, passarlo a _addIgnoredRef funziona bene. Questo elimina anche la necessità di aggiungere un _addIgnoredRef separato per ogni sottodominio.

Possono comunque esserci auto-referrer residui, ma non più di quanti ce ne sarebbero senza i sottodomini. La ragione è che _addIgnoreRef funziona soltanto quando il cookie contiene già informazioni di referrer. Se un nuovo visitatore arriva al vostro sito su una pagina senza codice di Analytics e poi naviga verso una pagina che invece ce l’ha, il risultato sarà che il vostro sito compare tra i referrer, a prescindere dalle accortezze che avrete usato per evitarlo.

Questi tipi di auto-referrer possono essere evitati assicurandosi di aver taggato ogni pagina del sito. Quindi se ci sono pagine che hanno questo problema, potete utilizzare GA per determinare esattamente quali esse siano, e siccome state usando _addIgnoredRef sarà facile isolarle dato che non avrete altri falsi positivi generati senza apparente ragione.

La cosa importante da ricordare, quindi, è che _addIgnoredRef dovrebbe essere inclusa per definizione ogni volta che si tracciano sottodomini, non solo se si notano auto-referrer

[update 27/1: Analyticpros chiarisce ancora meglio come funziona la routine per l’aggiornamento del cookie __utmz; le condizioni per aggiornarlo sono due: se nel DOM document.referrer è diverso da document.domain e se si tratta di una nuova sessione. Ne consegue che anche nell’ipotesi di codice ottimale se un visitatore è nel sito principale e ci resta 40 minuti, e poi clicca un link che lo porta ad un sottodominio, poiché entrambe le condizioni sono verificate il codice di GA provvederà ad aggiornare il cookie, causando un auto-referrer]

Come ho detto più volte su questo blog, Google Analytics è un sistema di web analytics “last cookie win”, dove cioè la conversione all’obiettivo viene attribuita all’ultima fonte di traffico che ha generato la visita. Per la precisione il modello esatto è descritto nel mio vecchio post “tabelle di conversione delle sorgenti“. Per non sovrascrivere la fonte di traffico è necessario che la pagina di atterraggio del visitatore abbia il parametro “no_override”.
Altri sistemi invece usano il paradigma contrario, cioè il “first cookie win” dove la conversione è attribuita alla PRIMA fonte di traffico e le successive non apportano modifiche a questa informazione. Infine in passato abbiamo parlato anche di sistemi che cercano di ovviare a questo problema con metodologie varie, una su tutte il supercookie ideato e sviluppato da ConversionWorks.

Tutto questo preambolo serve a fare il punto della situazione prima di introdurre un nuovo sistema di cattura e calcolo della cosiddetta “multitouch analytics”, cioè l’analisi delle varie sorgenti che hanno portato ad una conversione: www.multitouchanalytics.com. Il sistema è composto da uno script da scaricare, mettere online e richiamare sulle proprie pagine (e nelle pagine di conferma dell’ordine) e da un pacchetto di report che però – ahinoi – necessitano di un server dove gira Perl per poter essere usati. Questo fatto limita parecchio le possibilità di adozione da parte dei semplici utenti e lo relega al momento solo agli esperti, o a chi ha un esperto a disposizione. Ma confidiamo che in futuro riescano a renderlo più accessibile.
I dati vengono raccolti tramite gli eventi di Google Analytics, immagazzinati in un cookie nel computer del visitatore, e vengono poi interrogati tramite il pacchetto Perl che si poggia sulle API di GA. Un esempio dei report disponibili è nella pagina Examples

In questo report ad esempio vi è l’elenco delle combinazioni dei canali e i relativi conteggi: la maggior parte degli acquisti viene fatta con una sola attribuzione, un po’ meno con due e solo 149 hanno bisogno di quattro differenti canali. Più sotto c’è il dettaglio di quanto è stato incassato ad esempio grazie alla combinazione di Adwords + Campagne email + referral (11 transazioni, 651 dollari di revenue). I report possibili sono:

• Channel Overlap: un riepilogo delle sovrapposizioni dei canali e delle loro combinazioni
• All attribution: mostra tutte le transazioni e le revenue in cui compare almeno una volta un canale
• Even Attribution: Attribuisce conversioni e revenue in proporzioni uguali ad ogni canale
• Distribuited Attribution: Attribuisce conversioni e revenue in proporzione al numero di visite generate da ogni canale
• First Touch, Last Touch, 50-50: Le attribuzioni sono basate sul canale della prima visita (first cookie win), dell’ultima visita (last cookie win) oppure divise al 50% tra il canale della prima e dell’ultima visita
• Transaction Distribution: mostra il numero di transazioni con un solo canale, con due, tre, eccetera…
• Transactions Report: mostra ogni singola transazione i canali che hanno contribuito
• Touchlist: mostra ogni singola transazione e la sequenza dei canali, in ordine cronologico

Sostanzialmente permette di fare quel che oggi si può fare con i Search Funnel Reports di Adwords (e anche qualcosa in più) senza però essere limitati al solo canale Adwords. Una aggiunta mica da ridere per chi ha bisogno di conoscere puntualmente le ripartizioni dei budget di investimento sui vari canali di promozione online.