Google Analytics in 30 secondi

In verità una delle tre “cose nuove” è in giro da un po’ di tempo, ma soltanto ora Google mette a disposizione uno strumento nativo.
Autotrack.js è una libreria made in Google per il tracking dei cosiddetti siti monopagina, o applicazioni monopagina: quei siti che si risolvono tipicamente solo con uno scrolling o con ancore che fanno scrollare i contenuti.
Il post ufficiale ci informa che con una semplice modifica del codice di monitoraggio possiamo importare il plugin autotrack e iniziare a modificare il codice della pagina in modo che comunichi da sola le azioni dell’utente a GA. Le azioni che possono essere monitorate in modo semplice sono:

• click su link esterni e compilazione di form
• cambio di url su applicazioni monopagina (tipicamente con l’uso di #ancore alla fine dell’url)
• eventi tracciati con la sola modifica dell’HTML della pagina
• tracking delle media query e dei cambi, ad esempio se cambia l’orientation del device o viene stretta la finestra

Tutte queste operazioni sino ad ora non erano impossibili da tracciare, ma richiedevano comunque un effort discreto a seconda delle possibilità e delle tecnologie utilizzate. Avere una libreria ufficiale indubbiamente sarà di aiuto.

La seconda novità è il lancio ufficiale delle pagine AMP, introdotte in beta in autunno per farle conoscere ai publisher e adesso sdoganate da Google: si tratta di un progetto per rendere il caricamento degli articoli editoriali pressoché istantaneo sui dispositivi mobile, aumentando l’esperienza d’uso. Ora, come si tracciano queste pagine che hanno una struttura particolare e imposta da Google? per prima cosa va dichiarato dentro a un tag CHE COSA andremo a tracciare e DOVE invieremo i dati, attraverso una struttura di dati particolare. Questo funzionerebbe per qualsiasi richiesta di tracking per la quale si sa come costruire l’invio dei dati, ma ovviamente i maggiori vendor hanno collaborato con Google e quindi esistono delle sintassi “facilitate”: ad esempio alcuni nomi che troviamo sono Adobe, Chartbeat, comScore e ovviamente Google Analytics, la cui documentazione specifica è qui. Ad esempio, ecco uno script molto semplice per il track delle sole pageview

<amp-analytics type="googleanalytics" id="analytics1">
<script type="application/json">
{
  "vars": {
    "account": "UA-XXXXX-Y"  // Replace with your property ID.
  },
  "triggers": {
    "trackPageview": {  // Trigger names can be any string. trackPageview is not a required name.
      "on": "visible",
      "request": "pageview"
    }
  }
}
</script>
</amp-analytics>

Aggiungere eventi significa dichiarare a priori che un click su un certo elemento dovrà essere trattato come tale, con quale categoria vada tracciato e con quale action; idem per le interazioni sociali o altri elementi. A seconda quindi del numero di interazioni possibili lo script potrebbe essere anche lunghetto da gestire, ma di contro il numero di diverse azioni possibili su una pagina AMP non è così elevato. Si possono comunque prevedere tracking aggiuntivi lavorando un po’ con i dev, ad esempio vi suggerisco di leggere questo post di E-nor.

Terza novità di questi giorni sono gli instant articles di Facebook, lo stesso concetto delle pagine AMP ma calate nel contesto di Facebook, ovvero leggere il contenuto senza abbandonare l’esperienza utente di FB. Anche in questo caso, il tema di come tracciarli è trattato in un capitolo apposito della documentazione, e non richiede modifiche pesanti alla pagina perché il tutto viene incluso con un iframe. In questo caso quindi si può utilizzare un TagManager senza grossi problemi, almeno sulla carta. L’instant article viene in ogni caso trattato come una pagina del vostro sito aperta tramite il browser interno dell’applicazione di Facebook.

E’ un mondo che cambia in fretta, bisogna sapersi adattare in fretta 🙂

L’altro giorno ho trovato la segnalazione di questa discussione nel forum di Giorgio Taverniti: “a che ora i miei fan interagiscono di più?“. Niente da eccepire sul contenuto del post, se non che come dico nel primo commento la mancanza di un filtro nel custom report mi costringe a fare dei clic in più. Siccome noi siamo analisti precisini, noiosi e ripetitivi, ogni clic risparmiato è un clic guadagnato 🙂

Quindi, siccome l’obiettivo del post è l’analisi delle interazioni orarie per le provenienze da Facebook, ne approfitto per ribadire un concetto che molto spesso non vedo applicato come si dovrebbe: il custom report filtrato all’origine. Un custom report è un rapporto che in Google Analytics non esiste, e che viene calcolato “al volo” sulla base delle nostre indicazioni. Ad esempio proprio quello discusso sul forum GT, cioè le ore di arrivo delle visite per ciascuna sorgente.
Però il custom report così come viene proposto risponde (con DUE clic) alla domanda: “a che ora interagiscono tutti i miei utenti, divisi per sorgente?”. Per rispondere alla domanda originale propongo due variazioni:

La prima è appunto l’inserimento di un filtro direttamente nel custom report: si elimina la prima dimensione (la sorgente) e si usa il filtro per mostrare SOLO facebook. Il filtro si trova subito dopo la sezione delle dimensioni nel custom report, come in figura (clicca per ingrandire):

In questo modo aprendo il custom report si hanno SOLO le visite provenienti da Facebook, esplose per ora e senza necessità di clic aggiuntivi.

La seconda modifica è l’aggiunta di una seconda tab, che se trovate migliore potete anche spostare come prima (o usare solo questa), e cioè una tabella piatta con sorgente / ora e metrica visite. Questo report permette di distinguere le varie tipologia di sorgente Facebook (sito, app, sito mobile, campagna se avete usato facebook come source…) ma di avere lo stesso a portata di mano già all’apertura le ore in cui sono divise le visite. Vedasi screenshot (clicca per ingrandire):

.

Se volete, potete scaricare il tutto e salvarlo direttamente nel vostro Google Analytics: basta cliccare questo link mentre si è loggati nel proprio account Google.
Ripeto, nulla di eccezionale, ma solo un modo più veloce per arrivare al dato. Alternativamente potete usare il custom report proposto nel forum di Giorgio e usare le scorciatoie per arrivare direttamente alle sorgenti desiderate, se ne avete più d’una.

[in questo periodo sono talmente impegnato che ho dimenticato il terzo compleanno di questo blog! il 22 maggio 2011 🙂 ]

Da qualche tempo a questa parte Facebook ha dato la possibilità di inserire sulle proprie pagine dei frame contenenti sorgenti esterni, ad esempio pagine ospitate sul nostro dominio, o pagine del nostro sito esistente. Questo porta alla non trascurabile possibilità di “iniettare” Google Analytics per tracciare cosa accade lì sopra; in passato avevamo già visto alcune soluzioni per provarci, ma erano tutte poco pratiche e anche piuttosto inefficaci a causa di problemi tecnici in larga parte attribuibili a Facebook stesso.

Inserire un frame con una pagina che possiede il necessario codice di GA invece porta al risultato atteso: si può tracciare l’interazione tra gli utenti e il contenuto del frame (ma non ad esempio con quel che accade in bacheca). Per farlo è necessario usare come sorgente del frame una pagina che contenga il nostro codice di Google Analytics, magari dopo aver creato un profilo-copia che include solo le pagine del frame per poterle analizzare in dettaglio. Se state usando lo stesso codice del sito, ad esempio, i cookies saranno i medesimi quindi GA sarà in grado di riconoscere gli utenti e tracciarli come di ritorno, di conteggiare gli unici, eccetera.

Esiste una modifica interessante, che ci suggerisce Lunametrics, e che riguarda le fonti di traffico; se stiamo usando Facebook come landing page di una campagna (ad esempio una pagina tipo apps.facebook.com/my-app-name), usaremo i soliti tag delle campagne per valorizzare correttamente la sorgente di visita.
Se stiamo mandando gli utenti alla pagina con il frame (un tab di un profilo, ad esempio), Facebook oscura il referrer e non lo rende disponibile al frame, per cui sarà sempre qualcosa del tipo static.ak.facebook.com/platform/page_proxy.php. Il workaround consiste nel creare una pagina sul sito con un redirect al tab di Facebook, e impostarlo come landing page della campagna con gli appositi tag delle campagne. Su questa pagina prima di fare il redirect vero e proprio è necessario eseguire il codice di Analytics. Aggiungere poi la funzione _addIgnoredRef(“static.ak.facebook.com”) al GATC della pagina contenuta nel frame.

In questo modo il cookie __utmz viene impostato quando si è ancora sul nostro sito, e ha i parametri corretti, poi quando si arriva su Facebook esso non viene aggiornato per via della funzione addIgnoredRef.

Un po’ macchinoso, forse, ma ingegnoso! 🙂

Facebook è ovunque, e forte dei suoi 400 milioni di utenti macina record su record. Facebook è sulla bocca di tutti, e tutti vogliono sfruttarlo per promuovere se stessi o la propria attività, a volte anche in modo inappropriato (per non dire peggio). A prescindere da tutte queste considerazioni – però – non è mai stato possibile inserire il codice di Google Analytics sulle fan page del famoso social network. Al massimo si poteva utilizzare un tag di FBML (una versione modificata di HTML che si usa nelle pagine di FB), ma esso poteva venire usato solo sulla pagina di presentazione di un’applicazione.

Da qualche giorno è invece disponibile uno strumento esterno che si basa sull’uso di una immagine generata “al volo” da php, in grado di intercettare i dati necessari e di inviarli ai server di Google al posto del javascript che usiamo normalmente. Senza dilungarmi troppo vi segnalo il post di Tiziano Fogliata e il post originale degli autori, dove è anche possibile scaricare il tutto e ospitarlo sui propri server per avere ulteriori personalizzazioni possibili.

E’ un primo timido tentativo di unificare dati provenienti da fonti diverse, problema sempre più annoso, ma secondo me questa mossa a Facebook non piacerà affatto e temo che lo strumento presto cesserà di esistere. Facebook non ha mai supportato troppo l’inserimento di script esterni sulle proprie pagine, basti pensare che il codice di GA generato dal tag usa ancora la vecchia versione dello script, quello con urchintracker().