Google Analytics in 30 secondi

Se siete sviluppatori in erba di applicazioni Iphone, o se semplicemente avete un’idea vincente e vi fate dare una mano da qualcuno per la parte di sviluppo, è giusto che sappiate che da qualche tempo Google Analytics offre la possibilità di tracciare il comportamento degli utenti all’interno di esse (e anche all’interno delle applicazioni Android), esattamente come se si trattasse di siti web (e in effetti molte non sono poi così differenti: pagine con “cose” da cliccare, in questo caso col dito ).

Ecco, in entrambi i casi io non potrò aiutarvi perché non saprei nemmeno da dove partire, ma volevo segnalarvi che invece DevAPP ha scritto un tutorial apposta. Si tratta di un punto di partenza, ma visto che in futuro la App Analytics sarà forse importante tanto quanto l’analisi della navigazione mobile, è giusto prepararsi per tempo.

[Di App Analytics tra l'altro avremo modo di parlare un pochino a Cultura Senza Barriere 2010, il 18 febbraio a Padova. Non ti sei ancora registrato? ]

Anche Google Analytics, come molti altri prodotti Google, ha un posto dove si possono segnalare idee per miglioramenti, bug e si può controllare lo stato delle segnalazioni aperte. Fino a pochi minuti fa non lo conoscevo, e si trova a questo indirizzo: code.google.com/p/gdata-issues/issues/entry. Purtroppo le segnalazioni sono relative solamente alle export API.

Bisogna selezionare nella casella “Template” Analytics (Defect Report) se si vuole segnalare un bug, oppure Analytics (Enhancement Request) se si vuole suggerire una miglioria, e poi bisogna compilare la casella Description con le informazioni richieste: un riassunto del problema, i passi necessari a riprodurlo, le informazioni che ci si aspetterebbe il sistema debba restituire e quelle invece attualmente restituite, ed eventualmente qualche nota. Ovviamente prima di aprire una segnalazione è bene assicurarsi che non ve ne sia già una al vaglio dei tecnici, e questa operazione si può fare dalla schermata “Issues”, eventualmente filtrando solo le segnalazioni relative ad Analytics tramite il menu a tendina che compare cliccando la freccia verso il basso a fianco di API.

Nel momento in cui scrivo – e la cosa è confortante – ci sono 33 segnalazioni aperte: soltanto 5 sono relative a bug, tutte le altre sono suggerimenti di miglioramenti

Google Analytics è pensato per essere usato nella maniera più semplice possibile; ci sono margini di miglioramento, certo, ma nella maggior parte dei casi le cose funzionano da sole, quasi come per magia. Poiché però il web è vasto, e le casistiche possibili sono pressoché infinite, alcune volte c’è bisogno di indagare e capire perché gli ingranaggi si inceppano: è il caso di questo post di Brian Kats su VKI studios, relativo all’uso di setdomainname(), initdata() e le campagne Adwords, e a casi in cui il sito che si sta monitorando compare come referrer di se stesso, falsando quindi l’attribuzione della campagna.

Gli scenari più comuni per questo errore sono:

1. non state usando _seDomainName() su nessuna pagina:

   - il dominio principale (mywidgets.com) non viene rediretto al sottodominio www (www.mywidgets.com). I visitatori potrebbero digitare l’indirizzo sbagliato e poi cliccare su link all’URL completo, generando un referrer inconsistente
   - si usano sottodomini in modo che il navigatore passi da uno all’altro e viceversa.
   - ci sono redirect inconsistenti tra il dominio principale e i sottodomini
   Soluzioni:
   - costringere il webmaster/provider/sistemista a redirezionare il dominio principale sul sottodominio www
   - seguire le best practice seguenti

2. C’è un misto di chiamate a urchin.js e ga.js, risultato di:

   - Una migrazione dal vecchio codice

- La migrazione di pagine che usavano il vecchio codice su un sito col nuovo codice
- La migrazione di specifiche pagine (thank you page, ad esempio)
- L’uso di urchin.js per Google Website Optimizer su un sito che usa ga.js (o viceversa)
Soluzione:
- La vecchia variabile _udn deve essere trasformata nell’equivalente funzione per ga.js _setDomainName() (es: e.g.: _udn =”.MyWidgets.com” diventa _setDomainName(“.MyWidgets.com”))

3. Effettuare test con Google Website Optimizer e usare un codice differente dal resto del sito.

   Soluzione:
   - Correggere il codice di GWO per usare _setDomainName() in modo appropriato (si vedano gli esempi in fondo)

4. Ordine incorretto delle funzioni _set* e di _initData() o altre funzioni che inviano dati a Google Analytics (ecommerce, eventi e la funzione _setVar()).

   - _initData() è deprecata e l’uso è opzionale. In ogni caso, tutte le funzioni che inviano dati a GA la invocano internamente. Questo è il motivo per cui non è più necessario specificarla.
   - Il suo scopo è quello di creare l’oggetto di tracciamento e (ri)creare i cookie __utm*
   - _initData() fa questo lavoro secondo le impostazioni esistenti al momento in cui è chiamata. Tutte le funzioni _set* seguenti vengono ignorate
   Soluzione:
   - tutte le funzioni _set* (a parte _setVar()) devono essere chiamate prima di qualsiasi funzione che contenga la chiamata interna a _initData(), altrimenti le loro impostazioni saranno ignorate.

5. Inconsistenze generali tra le pagine, risultato di manutenzione evolutiva, programmatori o webmaster multipli e altri casi che possono presentarsi nella normale vita di un progetto web

Perché adWords viene derubato della paternità della visita

• Nell’esempio seguente, _initData() è responsabile della creazione di un set di cookie per il sottodominio www.mywidgets.com, perché _setDomainName(“.mywidgets.com”) viene invocata troppo tardi:
  

  var pageTracker = _gat._getTracker("UA-987654321-99");
  pageTracker. _initData();
  pageTracker._setDomainName(".MyWidgets.com"); // ordine errato
  pageTracker._trackPageview();

  Il cookie registra la campagna “IloveWidgtes” così:

  Name: __utmz
  Value: 187400622.1251739746.1.1.utmcsr=google|utmccn=ILoveWidgets|utmcmd=cpc
  Host: www.MyWidgets.com

• In una pagina successiva, il seguente codice crea un altro set di cookie in “.mywidgets.com”
  

  var pageTracker = _gat._getTracker("UA-987654321-99");
  pageTracker._setDomainName(".MyWidgets.com"); // correct order
  pageTracker._initData();
  pageTracker._trackPageview();
  
  Name: __utmz
  Value: 18180582.1251739746.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none)
  Host: .MyWidgets.com

• Se venisse registrato un obiettivo o una transazione ecommerce adesso, la campagna AdWords sarebbe “derubata” e la conversione sarebbe attribuita a “traffico diretto”. L’uso di funzioni che invocano _initData() prima di _setDomainName() ha lo stesso effetto.
  

  
  Sbagliato:
  var pageTracker = _gat._getTracker("UA-987654321-99");
  pageTracker. _setVar("Leads");
  pageTracker._setDomainName(".MyWidgets.com");
  pageTracker._trackPageview();
  
  Corretto:
  var pageTracker = _gat._getTracker("UA-987654321-99");
  pageTracker._setDomainName(".MyWidgets.com");
  pageTracker. _setVar("Leads");
  pageTracker._trackPageview();

Best pratices raccomandate:

1. usare un solo file .js con il codice di Google Analytics e richiamarlo da tutte le pagine. E’ il modo migliore per evitare problemi di inconsistenza
2. Usare sempre _setDomainName(“.mywidgets.com”), sia che abbiate sottodomini sia che non li abbiate
3. Usare sempre le funzioni _set* prima di quelle che invocano _initData() (le funzioni che tracciano le pagine, gli eventi, setVar e le funzioni ecommerce)

Questo post avrei anche potuto intitolarlo “e questo come lo tracciamo?”, ma ho preferito accordarmi alla serie “everything Analytics”. Dopo aver parlato di Game Analytics, Ebook Analytics eccetera, adesso forse arriveranno anche gli annunci pubblicitari sui cartelloni di Google Maps Street View

la foto è di Ninja Marketing

Evidentemente dove c’è pubblicità c’è investimento, e dove c’è investimento c’è bisogno di calcolo del ritorno (ROI), e il calcolo del ROI online quasi sempre coincide con web analytics. Prima di fasciarsi troppo la testa sarà necessario vedere in azione questo brevetto, e capire se ad esempio i cartelloni saranno cliccabili (quasi sicuramente si), e se il rapporto sarà un cartellone <-> un inserzionista oppure uno a molti. Nel secondo caso bisognerà capire se gli url di destinazione avranno formati particolari, o se ci saranno dei parametri o dei redirect da tracciare, in modo da separare e analizzare anche questa forma di ingresso dei visitatori al nostro sito internet.

Considerando anche che la visuale in Google Street View è in prima persona soggettiva – esattamente come in uno sparatutto 3D – quando parlavo di analisi del comportamento dei giocatori nei metaversi non ci andavo poi così distante, no?

Il mio intervento al convegno “Cultura senza barriere 2010” a Padova è stato schedulato il 18 febbario alle ore 16:00 in aula A. Se avete intenzione di partecipare, è meglio compilare la form di iscrizione. Comunque se non partecipate al mio seminario ma siete in zona, mi fa sempre piacere scambiare due parole con i lettori: la mia foto è nella pagina About

Qualche giorno fa mi ero messo a scrivere un post in cui sostanzialmente mi chiedevo quanto potesse essere vera l’affermazione che feci qualche tempo fa in occasione della presentazione del tracciamento dei siti mobile tramite script lato server; mi chiedevo se Google Analytics avrebbe abbandonato del tutto l’uso di javascript. Il post non mi soddisfaceva, e l’ho cestinato, ma oggi mentre riordinavo le bozze ho trovato questo articolo di Paul Legutko, datato settembre 2009: Web analytics without javascript? in cui si dice che la previsione secca “javascript sparirà entro cinque anni” è addirittura di Yahoo.

Ad alcune considerazioni ammetto di non aver pensato, sono interessanti. Vediamole:
- mobile. Ho appena detto che la soluzione di Google per il mobile non usa javascript, ma un pezzo di codice lato server (asp, php, eccetera). E’ vero che il supporto a javascript da parte degli smartphone è in costante ascesa, ma perché un colosso come big G – che pure ha fatto del tracking code javascript di Analytics una colonna portante – non crede in questa tecnologia portata sui cellulari?
- integrazione dei dati. Praticamente tutti i sistemi di tagging “sparano” i dati in un datacenter remoto; che sia Google, Webtrends o Omniture importa poco, perché l’esigenza sempre più sentita oggi è quella di integrare i dati della web analytics con tutti gli altri messi a disposizione dalla Business Intelligence. Allora perché inviare i dati per poi cavarli di nuovo fuori? è un processo poco razionale, se ci pensiamo…
- cookie. L’attenzione sempre maggiore verso la privacy e la sicurezza degli utenti online porta quasi sempre a puntare anche il dito contro i cookie. Secondo l’autore dell’articolo la percentuale di rifiuto dei cookie è tra il 3 e il 7%, a seconda della tipologia di sito preso in considerazione. Addirittura, alcuni software antivirus tracciano come “non pericolosi” i cookie traccianti dei sistemi di web analytics, ma ne consigliano comunque la cancellazione.

In passato si è parlato ogni tanto di Flash come sostituto di javascript, poiché Flash è leggero e presente su quasi tutti i computer che navigano in rete, ma è anche vero che ultimamente si sente dire che Flash morirà a causa di HTML5 (ok, in rete si sente dire di tutto, ma stiamo ragionando abbastanza in astratto…). In uno dei commenti al post viene invece suggerito il packet sniffing lato server, ovvero l’apertura di tutti i pacchetti a livello TCP che vengono inviati dal server ai visitatori del sito, in modo da carpire tutte le informazioni che normalmente vengono affidate allo script di tracciamento. Questa però è una soluzione che non è affatto alla portata di tutti, certamente non semplice quanto copiare e incollare un pezzo di codice in tutte le pagine di un sito.
Sia come sia, ritengo difficile pensare di tornare ai file di log, almeno non nella forma in cui li abbiamo conosciuti (e in qualche caso ancora conosciamo). Cinque anni sono un tempo enorme in informatica, e può darsi che la prossima generazione di sistemi di web analytics utilizzerà una tecnologia che non è stata ancora inventata; il dibattito però è affascinante, ed ancora una volta potenzialmente in grado di ribaltare completamente il settore.

Guardo spesso Analytics, ma non mi era mai capitato di vedere andare online una nuova feature
Giusto pochi minuti fa mi ero chiesto “che fine hanno fatto le annotazioni annunciate?” e mi ero subito risposto tramite il forum ufficiale: andranno online a metà Gennaio.

Ho quindi ripreso a navigare tra i report del mio cliente e di colpo… PUFF! è comparsal a freccina magica sotto al grafico, cliccata la quale ho avuto la possibilità di verificare che si trattava proprio di quella funzionalità

OK, sono le 21.55 del 14 gennaio 2010. Stavolta non mi batte nessuno sul tempo

Ho saputo da non molto tempo che esiste un sistema per “condividere” con tutti le proprie statistiche di Google Analytics; questo sistema si chiama sharega.com e fondamentalmente vi permette di mettere sul vostro sito un contatore delle visite registrate da Analytics.

Tralasciando un momento il fatto che anche io fornisco un contatore simile (non è questo il motivo del post), anchee ammettendo che dietro ci siano le persone più oneste del mondo la modalità di fruizione mi lascia parecchio perplesso. Leggendo la guida all’utilizzo di sharega.com si nota come uno dei presupposti per l’utilizzo sia l’aggiunta di uno specifico utente (ga@sharega.com) al profilo di cui si vogliono condividere i dati.

Sostanzialmente per condividere il numero delle visite, date accesso a sharega a tutti i dati del profilo (compresi, ad esempio, i report Adwords e i guadagni Adsense, se li usate e li avete collegati a Google Analytics). So che in passato io stesso ho consigliato due strumenti che facevano la stessa cosa – Concentrate e AnalyticsView – ma all’epoca non avevo ancora visto in azione la modalità corretta per sfruttare le API (quella che usa il Data Feed Query Explorer, ad esempio). Inoltre dietro a quei due strumenti ci sono Juice Analytics e EpikOne, due Authorized Consultants molto conosciuti nel settore, dietro a sharega non si intravede nessun nome noto.

Non date mai accesso a servizi se non siete sicuri dell’identità del fornitore, e ricordate sempre che le API di Google Analytics forniscono un comodo sistema di autenticazione che non rende affatto necessario l’aggiunta di utenti ai propri profili!

Soltanto i più attenti sanno che Google Analytics offre alcune metriche e dimensioni “nascoste”, cioè calcolate ma non accessibili dai report. Il perché si comporti così fa parte di quella percentuale di imperscrutabilità che spesso governa i prodotti di Mountain View (oppure sottostà alla regola della grandi compagnie “la mano destra non fa cosa fa la sinistra), ma la cosa importante è che esse esistono.
Chi tra di voi usa il report enhancer di ROI revolution oppure l’estensione per Firefox Better Google Analytics (l’estesnione è stata dismessa dall’autore) se ne sarà già accorto, perché ha il menu a tendina delle dimensioni molto più popolato del normale, per tutti gli altri viene in soccorso Caleb Whitmore, che abbiamo già conosciuto perché era l’autore della metrica RefreshRate dentro al Report Enhancer.

Caleb ha creato Dimensionator una specie di toolbar – in realtà è un bookmarklet ma poco importa – che all’interno di Google Analytics per mette di avere acesso alle seguenti nuove dimensioni:

• Market DMA
• Affiliation
• Regione *
• Pagina *
• Titolo *
• Second page viewed

(le voci contrassegnate con l’asterisco * sono già presenti, ma solo in alcuni report. Dimensionator le sblocca per tutti gli altri). Ovviamente non è detto che tutte le voci funzionino su tutti i report, ma Dimensionator vi dà l’accesso ad esse, non controlla se esistono o meno. L’ho testato su Firefox 3.5.7 e devo dire che qualche problema lo noto (ad esempio spesso mi si disattiva il menu a tendina delle dimensioni). Per utilizzarlo su Firefox non dovete far altro che trascinare il bookmarklet nell’apposita barra e premere il pulsante mentre siete dentro ai report di Google Analytics (oppure seguire le istruzioni nella pagina apposita se avete Internet Explorer).
Le nuove dimensioni possono infine essere usate come colonna primaria, secondaria o come nuovo campo di una tabella pivot.

Iniziamo questo nuovo anno con un fact check, ossia un controllo di aderenza alla realtà rispetto a cose dette in passato; nello specifico le previsioni fatte da Joe (e in parte da me) in questo post dell’anno scorso:

• urchin.js sarà eliminato e tutti saranno costretti a migrare a ga.js: SBAGLIATO! sebbene si siano diffuse voci incontrollate, poi messe in riga da Google, e sebbene sia stato introdotto un terzo codice di tracciamento – asincrono – urchin.js è ancora lì, vivo e vegeto, anche se ovviamente è sconsigliato usarlo in nuovi progetti e anzi la migrazione è consigliata per poter godere appieno delle funzionalità più avanzate
• Google Website Optimizer sarà integrato dentro a GA: SBAGLIATO! GWO è ancora un prodotto stand-alone. Continuo comunque a ritenere sensato che la sua fine naturale sia dentro a GA.
• Saranno aggiunte nuove sezioni di report, come “blog”, “social media” o “mobile”: SBAGLIATO PER 2/3 nessuna sezione blog e nessuna sezione dedicata esclusivamente ai social network (e di conseguenza nessuna nuova funzione per il controllo di questi referrer, come avevo pronosticato). E’ stata invece aggiunta – anche se io ancora non la vedo – la sezione mobile, figlia del nuovo codice di tracciamento server-side per le versioni mobili dei siti.
• Sarà aggiunta una sezione di path analysis: SBAGLIATO!; tutto invariato in questa sezione, che non viene toccata ormai da tempo immemore.
• La sezione di report subirà una pesante ristrutturazione: SBAGLIATO!, anche qui non è stato toccato niente
• (da Marco Cilia) integrazione Feedburner-GA: CORRETTO! Non è proprio come me la immaginavo, ma è un discreto passo avanti che permette di comprendere meglio quel che accade ai nostri feed RSS
• (da Francesco Gori) sistemazione dell’overlay: SBAGLIATO! L’overlay del sito è sempre – inutile – uguale.

Cosa non è stato predetto: è sempre difficile puntare sul futuro, ma davvero qualcuno un anno fa avrebbe immaginato l’integrazione con Adsense, le API pubbliche, le tabelle pivot e le dimensioni secondarie, nuovi tipi di goal, variabili personalizzate multiple, Analytics Intelligence e lo script asincrono, tanto per citare solo le più eclatante delle novità del 2009, riassunte in questo post di Google?

Previsioni per il 2010: nessun blogger nella cerchia delle mie letture si è azzardato a fare previsioni sul 2010 di Google Analytics, perché in effetti il 2009 è stato spiazzante. Ma potrei in qualche modo esimermi?

• GA sarà quasi in real-time: sono convinto che a causa della mole di dati e dell’infrastruttura del sistema, Google Analytics non potrà mai essere un sistema veramente in tempo reale, ma credo che nel 2010 Google abbasserà un po’ la soglia delle tre ore che adesso ci separa da quel traguardo. Fermo restando il fatto che un “fix” correttivo al giorno andrà fatto, penso che un’ora di ritardo sia alla sua portata.
• più API per tutti/o: Google proseguirà lo sviluppo accelerato delle API, che presto saranno in grado di replicare completamente tutti i dati che ora vediamo nell’interfaccia classica. Entro la fine del 2010 ogni nuovo annuncio di funzionalità sarà accompagnato dalla frase “… e naturalmente tutto questo è da subito disponibile anche tramite le API”
• dimensioni/metriche personalizzate: verrà data la possibilità di utilizzare dimensioni e metriche impostate secondo le nostre esigenze, o calcolate a partire da altre già esistenti. E’ chiaro che la mezza pagina vista non ha nessun senso per la maggior parte di noi, ma in questo campo non c’è mai limite alla fantasia e alle esigenze, per cui è una possibilità da non sottovalutare. Se utilizzata con criterio – sempre che la introducano davvero – questa sarà una possibilità assolutamente esplosiva!

E voi? fatemi sentire le vostre previsioni!