Jul 06 2016

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

Il più grosso passo indietro di Analytics

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

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!


Jan 06 2016

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

Sessioni, utenti, conversion rate

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

Ciao, e buon anno innanzitutto. Le meritate ferie mi hanno dato il tempo di leggiucchiare qua e là alcune cose su Google Analytics, e sono rimasto un po’ colpito da questo articolo di qualche settimana fa: Why You Shouldn’t Trust the Conversion Rate in Google Analytics. Il titolo, come al solito, mi sembrava un po’ troppo altisonante per essere davvero concreto, per cui mi sono immerso nella lettura.

Il presupposto esplicitamente citato in apertura è: “che succede se il tool non riporta quel che la gente si aspetta che riporti? che accade se non puoi fidarti di tutte le metriche su GA?” roba bella tosta, non credete? e così ci addentriamo nella lettura e scopriamo che il motivo per cui – secondo l’articolo – non potete fidarvi dei dati è che… le sessioni non sono i visitatori. Pensa te! (peraltro l’ultimo dei quattro punti – se un visitatore inizia la sessione su un sottodominio e poi passa al principale, inizia una nuova visita – è anche falso se avete configurato bene tutto o se usate Universal Analytics). L’articolo prosegue, cito traducendo, con la frase “L’errore è di equiparare una sessione a un visitatore”. Il conversion rate dell’ecommerce è calcolato sulle sessioni (transazioni * 100 / sessioni). La soluzione è usare delle custom dimension che registrino uno userID.

PERBACCO NO! la soluzione è: IMPARA A LEGGERE I REPORT PER QUEL CHE SONO! (e se proprio vuoi usare uno userID, abilita una vista userID enabled con Universal Analytics!). Ma chi ha mai detto che il fulcro di GA siano i visitatori? GA è da sempre uno strumento “session based”, e tutti i report sono costruiti su questo concetto. Soltanto da qualche tempo si inizia a parlare di report “user based”, e ovviamente il futuro è di trasformare tutto il sistema in qualcosa incentrato sull’utente. Ma sino a che questo non accade, lo strumento fa i report per come è progettato, e questo non c’entra nulla con la fiducia nei dati sottostanti!

Il secondo punto è a mio avviso ancora più debole: in soldoni dice che il bounce rate di per sé non indica nulla sulla bontà o meno della qualità della visita ricevuta. Bella forza! Se l’utente arriva, e senza fare nulla legge un numero di telefono sulla pagina, chiama e compra servizi per 4000 euro, GA segna un bounce a fronte di un grosso incasso. L’articolo ci rende edotti sull’esitenza di un “adjusted bounce rate”, di cui ho parlato secoli fa, e su cui ho anche già espresso le mie perplessità: dovrebbe essere basato sullo scrolling? o sul tempo di permanenza? se è basato sullo scrolling e il numero di telefono dell’esempio sopra è above the fold non cambia nulla. Se è basato sul tempo bisogna trovare un tempo sensato, e in ogni caso il sistema continua a non dirci se l’utente ha letto davvero la pagina o se gli ha squillato il telefono e s’è alzato dalla sedia…
Quindi ti ritrovi con più casistiche da interpretare, e con interpretazioni che dipendono strettamente da cosa hai scelto di fare. Anche questo però, ovviamente, non ha niente a che fare con quel che il sistema ti da di base e con la fiducia nei dati sottostanti.

Allora, già che ci sono, voglio porvi una domanda: voi nutrite dei seri dubbi sui dati di Google Analytics? se si, quali, in quale area, per quale motivo? intavoliamo una discussione sensata, nel caso…


Jul 17 2014

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

client-ID o CRM-ID?

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

Qualche giorno fa Justin Cutroni ha scritto un bel post sull’integrazione dei dati offline con quelli di traffico online: ve ne consiglio la lettura perché è piuttosto interessante.

Quel che mi ha colpito è stato l’approccio, con cui per una volta non sono d’accordo, e in particolare mi riferisco alla frase “What we need to do is extract the client ID value from the Google Analytics cookies and pass it to your CRM system” (trad: quel che dobbiamo fare è estrarre il client ID da Google Analytics e passarlo al nostro CRM).

Il client ID è l’identificativo univoco che Google Analytics crea di sua spontanea volontà: su GA classico si trova dentro al cookie __utma, su Universal si trova dentro all’unico cookie che viene creato, __ga
Il problema dell’approccio di Justin, è che non risolve affatto il problema del cross-device. Se infatti estraggo il mio clientID da qusto browser, ottengo un valore. Se cambio browser e visito lo stesso sito, ottengo un altro valore. Seguendo il suggerimento del post di Justin, anche se mi identifico (ad esempio loggandomi), il CRM ottiene due valori diversi. Deve salvarli entrambi? deve salvare solo l’ultimo? non si sa.

Se Google Analytics e il CRM si “parlano”, allora ritengo più intelligente fare esattamente l’opposto: usare il CRM-ID per sovrascrivere il clientID di GA. In effetti non lo si sovrascrive, ma ci si “appiccica” sopra. Per farlo si usa una sintassi di questo tipo


ga('create', 'UA-XXXX-Y');
ga('set', '&uid', 'CRM-ID');   
ga('send', 'pageview');

In questo modo il CRM non deve preoccuparsi di registrare un campo nuovo, possiamo usare lo stesso i report cross device, abbiamo direttamente in piattaforma un ID facilmente riconducibile (per il possessore del dato) all’identità dell’utente, che possiamo usare per segmentare, fare remarketing o estrazione di dati.


Apr 14 2014

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

funzioni display Universal anche su TagManager

autore: Marco Cilia categoria: tagmanager tag: , ,

Lukas Bergstrom ha comunicato su Google+ che da adesso le funzionalità avanzate di remarketing (e quindi i report demografici e le liste di remarketing) sono nativamente disponibili anche nei template Universal Analytics su TagManager. Cade anche l’ultima scusa per non migrare definitivamente a Universal Analytics 🙂

Già che ci sono volevo fare una precisazione su come funziona questa integrazione: in passato era richiesta la modifica del codice di monitoraggio per includere un file (dc.js) che era ospitato sul dominio doubleclick. Questo forzava i browser ad inviare insieme ai dati di Analytics anche i cookie del dominio Doubleclick, che poi provvedevano a inserire l’utente in una lista di remarketing o a fare altre operazioni associate a quei cookie. Con Universal invece questa modifica non è richiesta: è sufficiente aggiungere la funzione


ga('require', 'displayfeatures');

al tag di Universal (o cliccare la nuova opzione su GTM, appunto), che continuerà ad inviare dati al dominio google-analytics.com. Insieme alla prima hit ne verrà inviata ANCHE una ai server Doubleclick, e poi un’altra ogni 10 minuti circa. Questo ha l’indubbio vantaggio di evitare che certe hit vadano perse nel caso in cui, ad esempio, un Adblock particolarmente stretto non permetta l’invio di hits al dominio doubleclick.net.

Già che parliamo di Universal, vi sarete accorti anche del messaggio che compare all’apertura dell’interfaccia di Google Analytics: “Universal properties created prior to December 2013 may temporarily report doubled Visits counts between the hours of 0500-0800 in the View timezone. This issue corrects itself automatically. We are working on a fix to address this issue as soon as possible.

Si tratta di un problema noto da mesi, che speravo si sarebbe sistemato prima del rilascio ufficiale di Universal al pubblico ma che invece è ancora presente, al punto da costringere gli ingegneri a notificarlo in questa maniera. Il problema è fastidioso solo se si ha l’esigenza di analizzare i dati odierni, perché si auto-corregge da solo successivamente, ma si tratta indubbiamente di una situazione affrontata poche volte in passato


Apr 11 2014

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

Come funzioneranno userid e report cross-device

autore: Marco Cilia categoria: generale tag: ,

Il sempre ottimo Justin Cutroni ha scritto un post piuttosto lungo per illustrare nel dettaglio il funzionamento dei nuovi report cross device che si sbloccheranno con l’avvento di Universal Analytics, che ormai uscito dalla beta è in rampa di lancio verso tutti i nostri account e siti.
Oltre che consigliarvi la lettura, mi preme riportare qui alcuni tratti salienti e alcune precisazioni che vale la pena di riportare per tutti:

In primo luogo, l’ho capito da alcune domande che mi hanno fatto recentemente, mettetevi in testa che non è Universal da solo che riconoscerà l’utente unico: sarebbe contro la privacy e sarebbe anche abbastanza spaventoso, no? 🙂 Anche se il sito usa Universal e mi collego con due browser diversi, continuo ad essere due utenti unici diversi ed essere conteggiato due volte. MA – ed è questa la novità – se il webmaster è in grado di riconoscere l’utente (e non parlo PER FORZA di farlo loggare, basta trovare un modo per essere certi della sua identità), allora può indicare questo USER ID a Universal e lui si preoccuperà di “riunire” le sessioni sotto un unico utente unico. Come avviene questa cosa nel codice? così


ga('create', 'UA-XXXX-Y', 'auto');
ga('set', '&uid', {{ USER_ID }});
ga('send', 'pageview');

Secondariamente, Google Analytics non tornerà indietro nel tempo per ripescare tutto quel che l’utente ha fatto nelle sessioni precedenti, quando non era loggato, dopo che assocerà un certo cookie id con lo user id fornito dal sito. Ancora una volta, si tratta di una scelta conservativa nei confronti della privacy degli utenti. Quel che invece sicuramente farà sarà unificare le sessioni che hanno uno user id in comune, calcolando un solo utente unico. Come? anzi dove?

Lo farà in un’altra vista, che dovrà essere creata apposta ed essere specificatamente marcata per funzionare con lo user id. Si tratterà, come è facile intuire, di una sotto-vista della principale, con meno dati (o al massimo con gli stessi dati, se per assurdo identificassimo il 100% delle visite) e con la possibilità di selezionare un range temporale massimo di 90 giorni, come già avviene nei multichannel funnel.

Quali report ci saranno, quindi?
Il primo report sarà una panoramica della percentuale di utenti che finiscono nella vista con user id: più è alta la percentuale, più dati “unificati” ci saranno nella vista. Il secondo è un report che mostra le sovrapposizioni tra i diversi device, alla stregua della panoramica dei multichannel funnel. Il terzo mostra quanto ogni tipologia di device “assista” gli altri nel processo di conversione, e quanto sia in alto (awareness) o in basso (closing) nel processo di conversione. Il quarto mostra esattamente come ogni device sia interconnesso agli altri, in un processo sequenziale del tipo Desktop -> Mobile -> Desktop (conversione).

Se date un’occhiata agli screenshot di Justin e poi considerate che il tutto è segmentabile, potete capire effettivamente che si tratta di un grosso balzo in avanti nella comprensione delle meccaniche del processo di conversione.


Apr 02 2014

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

Universal esce dalla beta. Ora il gioco si fa duro!

autore: Marco Cilia categoria: generale tag: ,

Il bello di stare a 9 fusi orari di distanza dal “centro del (mio) mondo” è che quando loro pianificano una big news tu sei fuori a cena. Mentre annunciavano Google Analytics Premium ero in pizzeria, oggi che Universal Analytics esce dalla beta ero a cena dai miei genitori (e dire che avrei potuto preparare un post in anticipo, ma che vuoi farci? 🙂 ).

Quindi la news è questa, fresca fresca dal blog ufficiale, e da oggi le cose cambiano VERAMENTE per tutti coloro che vogliono fare digital analytics ad un certo livello. Vediamo le novità principali:

  • Ora Universal supporta tutte le feature dello strumento: quindi si potrà fare remarketing e usare i report demografici, avere l’integrazione con AdSense, insomma avere tutto quel che abbiamo sempre avuto nel Google Analytics “classico”.
  • Controllo dello UserID: si tratta del nocciolo di Universal, ovvero della possibilità di tracciare il vero utente unico, a prescindere da dove, come e quando si connette; ho un’app mobile, un sito mobile e un network di tre siti? non importa, se li traccio tutti nella stessa property e posso riconoscere l’utente, il sistema registrerà sempre un solo visitatore unico!. Il tutto tra l’altro è già disponibile anche su TagManager
  • Cross device report: in conseguenza di ciò, saranno introdotti i nuovi (oddio, mi fa un po’ sorridere, dato che li ho usati in beta parecchi mesi fa) report cross device, cioè dei report simili ai multichannel funnel focalizzati non sulle sorgenti ma sui dispositivi che lo stesso utente unico usa per arrivare alla conversione. Come si sovrappongono mobile e desktop? quale dei due è più utile per fare awareness e quale invece “chiude” la conversione? quale è la sequenza migliore di categorie di dispositivi che converte di più?
  • Processing basato sui fusi orari: fino ad oggi le property Universal venivano processate in base al fuso orario del Pacifico, anche se non saprei dire il motivo. In ogni caso su alcuni account più grandi questo determinava l’impossibilità di avere dati precisi fino al pomeriggio italiano. Uscendo dalla beta tutto tornerà come prima, almeno per quanto riguarda le property con meno di 200.000 visite al giorno
  • Possibilità di specificare l’IP nelle chiamate server side: il protocollo di misurazione, ce ne siamo accorti subito, è una grande cosa ma soffriva di un problema piuttosto grande: le chiamate venivano viste come provenienti dall’IP del server che le effettuava, annullando la possibilità di usare i report geografici. Da ora in poi questa cosa sarà falsa, e si potrà passare l’IP del client, ottenendo la stessa precisione cui siamo abituati per i report geografici

Come sempre in questi casi vi lascio un po’ di link utili, in aggiornamento man mano che li trovo in giro per il web:

Justin Cutroni con un post generale.
Daniel Waisberg, con un dettaglio sui report cross device


Oct 24 2013

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

Cosa devi sapere se vuoi upgradare a Universal Analytics

autore: Marco Cilia categoria: codice di monitoraggio tag:

Ieri Google ha diffuso la notizia che presto sarà possibile trasformare le web property dentro a Google Analytics in property che usano Universal Analytics. Fino ad ora infatti, per usare Universal era necessario aprire una nuova property, e avere un nuovo codice di monitaraggio.

Questo perché il processo di analisi dei dati raccolti da Universal è differente da quello “classico”, si tratta proprio di una linea differente. Fino ad ora, come detto, sono stati semplicemente gestiti come entità separate, mentre da ora in poi sarà possibile passare da Analytics classico a Universal (ma non tornare indietro) con una procedura di upgrade che si riassume in questo modo:

1) Trasferire la property a Universal: nel pannello di amministrazione comparirà una voce di menu specifica per l’upgrade, dalla quale si potrà comunicare a Google che si intende effettuare l’upgrade. E’ bene ricordare che alcune configurazioni, su Universal, si fanno dal pannello di amministrazione e non pià attraverso il codice di monitoraggio; ad esempio se avete aggiunto dei motori di ricerca tramite la funzione _addOrganic o se avete cambiato la durata di una visita tramite _setSessionCookieTimeout. Queste funzioni non esistono in Universal e vanno specificate tramite apposite sezioni del pannello di configurazione del tracking code

2) Ritaggare il sito, manualmente oppure usando un Tag Manager, per aderire alla nuova sintassi nel caso si usi analytics.js. Plus, a questo punto si può decidere di usare anche altre librerie per l’invio dei dati, ad esempio librerire scritte in PHP, Java e altri linguaggi (ce ne sono già parecchie in giro per il web) e di implementare il Measurement Protocol per abilitare l’invio di dati da qualunque “cosa” sia in grado di comunicare con il web: l’esempio classico sono le transazioni offline o le conversioni da call center.

Siccome si tratterà di un momento molto importante e delicato per tutti (si tratta pur sempre di un cambio di versione, ma in realtà si tratta di un cambio epocale di mentalità, per le possibilità che apre) vale sicuramente la pena di riportare qui alcune avvertenze da tenere bene a mente:

– Se iniziate il processo, non potete fermarlo o tornare indietro: una volta che si clicca il pulsante, l’upgrade inizia ed è irreversibile

AL MOMENTO Universal Analytics non supporta le funzioni abilitate al momento da dc.js, quindi liste di Remarketing da Analytics, info demografiche, impressioni GDN o integrazione Doubleclick. Se usate una di queste funzionalità e volete continuare a farlo, NON DOVETE UPGRADARE fino a che esse non saranno supportate

– Le vostre variabili personalizzate non esisteranno più, e andranno sostituite con le Dimensioni personalizzate. La cattiva notizia è che dovrete cambiare un po’ la sintassi e lavorare un pochino anche sul pannello di amministrazione, quella buona è che invece di 5 variabili personalizzate adesso avete 20 custom dimensions (e anche 20 custom metrics 🙂 )

– L’upgrade va fatto per PROPERTY (per un ripasso di cosa sia una property rispetto a un profilo o un account vi rimando a questo mio post ), quindi va ripetuto per ogni codice UA-xxxxxx che desiderate migrare

L’ordine dei passi è importante: PRIMA si fa l’upgrade della property e DOPO si cambia il tagging. Se cambiate prima il tagging i dati inviati non saranno processati (state inviando dati in forma “universal” a una linea di analisi classica). Il contrario invece è supportato, ed è infatti come deve avvenire il processo

C’è ancora una nota interessante riguardo all’ultimo punto qui sopra, ed è contenuta in una delle FAQ:

If you send data to a Universal Analytics property using a classic Google Analytics collection method (like the ga.js JavaScript library), your data will be processed during the phases of the upgrade. Your data will not be processed, however, after the classic Google Analytics libraries and SDKs have been deprecated.

Come abbiamo detto, inviare dati dal tagging classico a una property Universal è consentito, ma solo durante la fase di upgrade. Tra le righe lì c’è scritto che prima o poi le librerie classiche saranno deprecate, e i dati non saranno più analizzati. Che sia la “fine finale” del tracking con urchin.js?


Mar 23 2013

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

Ora potete provare Universal Analytics, se volete

autore: Marco Cilia categoria: generale tag: ,

Ieri Google ha aperto a tutti la possibilità di provare analytics.js, il file che abilita le nuove funzioni di Universal Analytics annunciato durante lo scorso Summit. In realtà non basta cambiare il file che si richiama sulle pagine, c’è anche bisogno di creare un nuovo profilo. Nelle prossime settimane verranno fornite, probabilmente, delle guide per il passaggio.

Universal Analytics, ve lo ricordo, permetterà di incentrare le analisi sul visitatore, nella sua forma più “pura”, riuscendo a tracciarlo durante tutti i suoi movimenti – a determinate condizioni – e riuscendo quindi a fare segmentazioni per visitatore e non più per visita. Un vantaggio sarà ad esempio poter riconoscere una stessa persona quando usa device multipli.
Altra novità è la possibilità di usare un tracking server-side, usando un protocollo di invio dei dati ideato da Google.

Le possibilità che Universal Analytics apre sono moltisisme, molte più di quelle che riusciamo a immaginare fino ad ora, e sicuramente l’apertura a beta pubblica denota un grado di maturazione sufficiente e fa ben sperare sulla data di rilascio finale (che comunque non reputo vicina). In questo periodo le persone potranno provarlo e capire se e come potrà essere utile, studiarlo, creare framework di tracciatura e insomma arrivare preparati quando Universal farà il suo debutto ufficiale.


Nov 18 2012

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

Universal Analytics per SEO: GA senza javascript

autore: Marco Cilia categoria: API tag: , ,

Una delle cose più belle (e incredibili, se ci pensiamo un attimo) di Universal Analytics è la possibilità di tracciare qualsiasi cosa, in qualsiasi modo, attraverso il Protocollo di Misurazione ideato dagli ingegneri di Google.
In buona sostanza fintanto che si inviano richieste nella forma corretta, Analytics le riceverà e le elaborerà proprio come ha sempre fatto. Il nuovo SDK per Android – se non ho capito male – si basa su questo tipo di interazione, valorizzando opportunamente i campi app name e il tipo di hit inviata.

Poiché non mi piace parlare di cose che non conosco, prima di scrivere qualcosa in proposito mi sono dotato di un accesso alla beta pubblica e ho “giocato” un pochino con la nuova funzione. Allo stato attuale dello sviluppo tracciare con analytics.js invece di ga.ja comporta poco più di un cambio di sintassi, e parecchie funzioni in meno da ricordare poiché molte cose possono essere configurate lato server. Ma non è questo il punto importante, perché subito dopo aver inviato una hit valida attraverso il javascript mi sono concentrato sul measurement protocol: volevo mandare una hit senza usare il file di Google.

E trattandosi di una API ufficiale, ovviamente funziona: ho inviato delle pagine viste e delle visite attraverso PHP, ancora prima che la pagina venisse mostrata al mio browser. Naturalmente l’ho fatto male, usando degli assunti che mi facevano comodo (ad esempio, un cookie col nuovo formato deve già essere presente nel browser) e con del codice che mi vergogno a mostrare, ma funziona, è fattibile.

Subito dopo mi sono interrogato sul come e sul quando questa cosa poteva dimostrarsi utile, dandomi alcune prime risposte, ma soprattutto pensando a una certa categoria di utenti che non accettano mai javascript e cookie: gli spider. Se è possibile inviare hit ad Analytics senza usare javascript (non è una novità, ma questo è il metodo ufficiale, che si presume molto più robusto e a lungo termine), allora un SEO potrebbe usare Universal Analytics per tracciare anche – o solo – gli spider, mimando esattamente le stesse informazioni contenute nei logfiles che è costretto ad utilizzare adesso. Potrebbe avere qualche vantaggio a farlo perché così potrebbe usare l’interfaccia di Analytics per le sue analisi, quindi segmentazione avanzata, dimensioni secondarie, report personalizzati… pensiamo un secondo soltanto al real-time, quali spider sono sul sito in quale momento (magari sapendo anche in base a quale avvenimento questo accade). Carino no?

Addirittura creando un hash che comprenda indirizzo ip, user agent e qualche altro parametro si potrebbe pensare di assegnare un ID differente per ogni spider, aumentando le possibilità di personalizzazione e i casi d’uso possibili. Insomma le possibilità sono tante, e la tecnica – ufficiale – adesso c’è: basta risolvere un paio di problemini e adattare il tutto alle proprie esigenze, ma non ci vedo particolari impedimenti. Credete che diventerà una pratica normale?

[a proposito di web analytics senza javascript, c’è chi lo dice da anni: “il futuro della wa è senza javascript?“]