Jul 06 2016

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

Il più grosso passo indietro di Analytics

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!

Condividi l'articolo:

15 Commenti

  1. Insomma: il cross domain.

    E sì, hai maledettamente ragione, era decisamente più lineare con GA Classico.

  2. non solo il cross domain. Purtroppo come dico nel post vale anche per i sottodomini…

  3. Se i subdomain condividono la stessa proprietà però non ci sono problemi (io di prassi suggerisco sempre lo stesso codice, anche perché i subdomain in UA hanno il cross domain supportato già col codice standard, meno problemi)

  4. Andrea Stefanini

    Ciao Marco, una soluzione potrebbe essere mandare sempre i dati anche ad una property di rollup sulla quale verificare i dati?
    Grazie per gli spunti sempre preziosi!

  5. Ciao Andrea, come dicevo spesso è una questione di “disegno” corretto del piano di tracking (se non siamo in situazioni complicate come quella di esempio).
    Se hai una property di rollup, e fai il cross domain tracking, i dati saranno corretti solo nella rollup. con classic, erano corretti anche sulle singole, dato che le sorgenti passavano in chiaro.

  6. Ciao Marco, francamente a me pare più sicuro il criterio di universal. Se su un sito ci lavorano più agenzie mi darebbe fastidio che i setting che fanno sulla loro property intaccasse la mia. Sono d’accordo che in alcuni casi può fare comodo usare il tracking di qualcun altro ma quello che succede nella sua property non lo voglio nella mia 😛 sono geloso e sospettoso

    Però a questo punto mi sorge un dubbio e mi confuto da solo : se ci sono due agenzie con due property diverse e il cross domain lo fa l’altra agenzia … io sono fregato? non si può appendere più _ga nell’url?

  7. il problema non si pone per due codici sullo stesso sito, anche se di property/agenzie diverse. Si pone se uno lavora solo sul sottodominio, con un UA e l’altro solo sul www con un altro UA.
    sul sottodominio si fa una campagna da 60mila visite da Facebook con i suoi utm, che poi passano al www, e tu vedi un incremento di (direct). A me non sembra normale…

    il cross domain prende il cookie _ga e lo passa dove deve passarlo. A quel punto è la nuova property che deve capire se “conosce” già quel cookie, quindi ha la sorgente e l’utente, o è nuovo e direct o referral. su QUANTE property sono tracciate la pagina iniziale e finale è solo un di cui

  8. Questa è una delle motivazioni che mi fa pensare che usare anche Piwik come motore di Analytics sia una scelta saggia… Cosa ne pensate? Mi piacerebbe saperlo 😉

  9. Fabio: mi risulta che il cookie di Piwick non contenga la sorgente, per cui il funzionamento sembra identico. Inoltre nei doc non si fa menzione di come monitorare molti TLD sullo stesso codice http://developer.piwik.org/guides/tracking-javascript-guide#measuring-domains-andor-sub-domains quindi dare un giudizio è un po’ difficile…

  10. Piwik ha il Plugin “InterSites” che è molto utile (http://plugins.piwik.org/intersites). Pensi che possa essere un aiuto per affrontare le limitazioni di cui parli?

  11. questo tira fuori il numero di unici di due o tre siti, una cosa che GA fa da solo se hai impostato il cross domain tracking correttamente. Ancora non sappiamo come Piwick tratti la sorgente di chi si muove da A a B, però.

  12. Chiediamolo al team di sviluppo… 🙂 …

  13. Do this post have a English translation? sounds very interesting!

  14. Hi Dennis, sorry, this blog is targeted only to italian people. Abstract could be: you cannot rely anymore on source/medium presence in the GA cookies, and this has an impact on how sources are tracked in every case where you mix different UA tracking code; for example if you use UA-1 on a subdomain and UA-2 on the main site an organic visit on subdomain that goes to the main site is still tracked as organic, does not matter which UA you use, using GA classic. Using Universal, is tracked as organic on the subdomain but DIRECT on the www

  15. Hi Marco. Ok. And thank you for the translation.

Scrivi un Commento