Google Analytics in 30 secondi

Con alcuni mesi di colpevole ritardo, ho appena confermato la mia certificazione GAIQ. Ho come l’impressione di aver sbagliato esattamente le stesse domande dell’altra volta, perché ho realizzato un punteggio del 95% contro il precedente 94%, ma a mia parziale discolpa vorrei dire che almeno un paio di domande sono molto ambigue: mi sono trovato a dire “vuole una risposta secca ma vanno bene due possibilità, voglio ben sperare che conti esatte una qualsiasi delle due!”.

Comunque, il mio certificato è sempre lo stesso, il numero 186, ed è valido 18 mesi a partire dal 31 gennaio 2011 🙂

Molti di voi avranno tra le fonti di traffico, ed in particolar modo tra i motori di ricerca, qualche visita proveniente da SEARCH. Quelle visite sono portate al vostro sito proprio dal metamotore di www.search.com, e devo dire che in alcuni casi sono stupito da quante persone lo usino. Probabilmente perché digitando “search” nella barra degli indirizzi google lo restituisce in posizione elevata, ovviamente, e da lì partono con la ricerca vera e propria.

Comunque sia, c’è un cavillo: poiché il riconoscimento e l’attribuzione delle visite viene fatta sulla base di due parametri – come vi avevo spiegato tempo fa – e cioè la presenza nel dominio della “parola” che identifica il motore e la corrispondenza del parametro che contiene la ricerca, se ne può dedurre che qualsiasi motore di ricerca che abbia SEARCH nell’url e usi il parametro q verrà conteggiato in quelle visite. Quindi l’ipotetico motore di ricerca personale del vostro network di siti, che magari è attestato su search.nomenetwork.it e usa q come parametro, verrà inglobato nelle visite di search.
Per ovviare a questo problema la guida di Google Analytics dice di usare _addIgnoredRef() per rimuovere il referrer di quelle visite e farle comparire come visite dirette, ma non mi sembra una soluzione ottimale. Trovo invece più corretto aggiungere il vostro dominio come motore di ricerca ed utilizzare il parametro aggiuntivo prepend di _addOrganic(), in modo da inserire il vostro motore in cima alla lista dei search engines riconosciuti, in questo modo:

_gaq.push(['_addOrganic', 'search.nomenetwork.it', 'q', 1]);

Rispondo qui ad un commento che era stato messo in un post off-topic, tanto volevo giusto parlarne:

Anti-tracciamento:
Ma che tu sappia, il “do not Track” di mozilla e Keep My Opt-Outs di chrome, rendono veramente la navigazione “invisibile”? Analytics come si comporta o comporterà secondo te?
Io devo ancora fare i test, ma mi sembra strano che google fornica uno strumento che renda davvero cieco anche analytics. Ho frainteso la notizia?

Do Not Track di Mozilla (annunciato ma non ancora disponibile) e Chrome Keep My Opt-Out sono due strumenti che non hanno a che fare con Google Analytics: entrambi servono ad evitare il tracciamento antecedente la visualizzazione di annunci pubblicitari targettizzati sulle abitudini di navigazione; in sostanza, vi sarete accorti, i motori di ricerca e Google in particolare forniscono pubblicità contestuali che sono tarate sulla nostra storia di navigazione, sulle ricerche pregresse e altre informazioni in loro possesso. Io ad esempio vedo gli annunci che sponsorizzano Google Analytics anche quando guardo un video dei Muse su Youtube, tanto il mio account è associato a quell’argomento. Se volete rendervi conto delle categorie merceologiche a voi associate da Google, potete visitare questo indirizzo www.google.com/ads/preferences/

Analytics quindi non verrà influenzato dalle scelte operate su quei due strumenti, che lo ripeto riguardano solo ed esclusivamente i cookie pubblicitari, anche se il nome “do not track” è fuorviante. Esiste tuttavia un altro strumento che invece fa quel che dici, ne ho parlato qualche tempo fa, e si chiama Google Analytics Opt-out Add-on e funziona esattamente come promesso: una volta installata nessun dato di navigazione verrà più inviato a Google. Testato personalmente. Perché Google lo fa, dandosi la zappa sui piedi, dici? perché è una possibilità che tutti i sistemi di web analytics seri danno, perché il controllo della propria vita digitale deve restare nelle mani degli utenti e, inutile negarlo, perché costretti dalle autorità (Germania in primis)

[photo credit: goldberg on flickr]

Sul blog ufficiale del Google Code è comparso un annuncio interessante, che ancora non ha seguito su quello di Analytics cui è seguito un post sul blog ufficiale: alle API di esportazione dei dati sono state aggiunte 127 nuove metriche e dimensioni. Esse includono ad esempio:

• Visitatori unici: il calcolo dei visitatori unici è stato rivisto e adesso restituisce il reale numero di unici nel periodo selezionato, invece dei visitatori unici giornalieri. Inoltre adesso si può combinare con più metriche e dimensioni
• Ricerche organiche: restituirà il numero di ricerche organiche in una sessione
• AdWords: 10 nuove dimensioni per i report AdWords, inclusi la query cercata invece di quella comprata, il dominio su cui è esposto l’annuncio nel caso di veicolazione attraverso AdSense, il formato dell’annuncio, il tipo di targeting e altro ancora.
• Risultato della ricerca visualizzato: il numero di volte che viene visualizzata una pagina risultato di una ricerca
• 3 dimensioni relative al tempo: per semplificare la creazione di grafici

Inoltre sono state aggiunte 111 metriche precalcolate, al pari dell’interfaccia, in modo da scaricare i server dall’onere di fare i conti per dati che venivano richiesti molto spesso: ad esempio il bounce rate, il margine, il costo per conversione, ma anche il tempo medio sul sito, il conversion rate successivo a una ricerca interna, il numero di item per acquisto. La lista completa è disponibile nel changelog

La chicca finale, graditissima da chi non è proprio espertissimo di API, è la nuova disponibilità di un tool online che ha l’elenco completo delle metriche e delle dimensioni, e che è in grado di scremare le combinazioni man mano che si digita: se ad esempio si inizia a scrivere “ga:vi” (intendendo magari ga:visitors) il tool si occuperà di mostrare solo le dimensioni e le metriche che generano combinazioni valide, evitando di dover fare noi le prove!

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]

Circa un anno fa intitolai un post “Che cosa è illegale in Germania?” poiché le autorità avevano iniziato un processo di accuse vero il noto sistema di web analytics made in Google. La mia tesi era che il problema del tracciamento non ce lo aveva solo GA, ma era un problema tipico di tutti i sistemi di web analytics, ma evidentemente aveva invece ragione Stefano Gorgoni che nei commenti diceva

google […] in quanto è in grado di tracciare troppe informazioni grazie a google analytics (+ tutte le altre cose messe assieme).

Evidentemente in Germania possono rendere illegale solo Google Analytics (si ipotizzano multe di 50.000 euro a chi lo utilizzerà dopo l’eventuale divieto) e non toccare Adobe Sitecatalyst e tutti gli altri programmi. (alcune fonti in inglese: searchenginewatch e thelocal.de). Questo sulla base generica del fatto che “Google raccoglie anche altri dati tramite altri servizi”.

Allora chiariamo un attimo una cosa prima di andare avanti: io per primo sono uno che non ha mai negato che Google “guadagna” in informazioni invece che in termini monetari se noi usiamo Google Analytics (ecco un post, ad esempio). Ma lo dico sulla base di un ragionamento costi/benefici astratto e sulla base di supposizioni generiche. Quando provo a rispondere concretamente alla domanda “come fa?” non trovo risposte tecnicamente sostenibili. E dubito le possano trovare anche le autorità tedesche. Proviamoci un attimo insieme, e come sempre se avete cose da aggiungere i commenti sono lì ad aspettarvi:

– Una persona naviga su siti che usano Google Analytics, e non usa nessun altro servizio Google. Cosa potrà mai sapere Google di lui? nulla. Saprà che il cookie __utma relativo al sito visitato è alla prima o ennesima visita, che in precedenza ha visto o no questo sito e quando e tutto il resto delle informazioni che sappiamo. Di tutti i siti? NO, SOLTANTO DEL SITO IN QUESTIONE! vi ricordo infatti (e potete verificarlo da soli) che esiste un cookie utma per ogni sito visitato, e che il secondo gruppo di numeri nel contenuto – quelli che identificano univocamente il visitatore – sono differenti per ogni set di cookie. Ammettendo per assurdo che invece Google sia in grado di riunire queste informazioni, avrebbe l’elenco di tutte le visite a tutti i siti di un solo indirizzo IP

– Una persona naviga su siti che usano Google Analytics, e nel contempo sta usando Gmail, Calendar e tutti gli altri servizi. Dentro a Gmail c’è nome e cognome e un sacco di altre cose, diciamo che diamo per buona l’associazione Gmail = Nome e Cognome, in quel caso allora Google saprebbe (meglio: potrebbe ricavare) che Marco Cilia sta guardando la pagina X del sito Y nel dato momento del tale giorno. Ma se invece fossi iscritto a Gmail ma non l’avessi aperta in quel momento, cioè se i cookie e l’ip che sto usando non possano essere associati a Gmail per quel periodo? allora non si potrebbe fare nulla. L’associazione varrebbe solo nel caso di utilizzo contemporaneo delle due applicazioni.

– Una persona naviga su siti che usano Google Analytics, e nel contempo sta usando Gmail e il resto, mentre è all’interno di una rete aziendale da 5000 client. Guardando la cosa dal “lato Google”, Marco Cilia e altre – ipotizziamo – 348 persone (precisi a livello do nomi e cognomi) sono perfettamente pronte ad essere associate ai siti che si stanno navigando. Arrivano migliaia di informazioni tramite Google Analytics, ma l’IP registrato è sempre e soltanto quello del proxy aziendale. Nei cookie di GA, lo ripeto, non c’è nè nome e cognome, nè l’associazione a Gmail. Come può Google attribuire correttamente le 18 pagine visitate nel secondo 31 del minuto 14 delle quattro del pomeriggio a 18 delle 348 persone che lui sa essere online in quel momento?

Per associare due informazioni – e questa è informatica, non Google Analytics – serve un dato comune alle due informazioni: che sia un ID di una tabella di relazione di database, una chiave univoca, un tag testuale o un cookie, senza questa relazione l’associazione è impossibile: poiché voi potete benissimo sapere che cosa inviate a Google tramite Analytics (vi ricordo che questo sito ha un tutorial) potete anche guardarle e provare a capire se e come si potrebbe risalire alle vostre informazioni personali. Se lo capite, ne parliamo nei commenti.

Altrimenti, dire “Google Analytics viola la tua privacy perché traccia anche l’IP e Google sa tante cose di te” lascia piuttosto il tempo che trova 🙂

[photo credit: francescomucio on flickr]

Approfittando del ponte del 6 gennaio ho dato un’accelerata alla lettura del libro Google Analytics di Justin Cutroni edito dalla O’Reilly: devo dire che quando l’ho ricevuto sono rimasto stupito nel constatare la sua “magrezza” in termini di pagine, abituato a tomi ben più spessi.

Justin è noto da anni come uno dei maggiori esperti mondiali di Google Analytics, io stesso l’ho nominato a più riprese in questo blog, quindi ero abbastanza sicuro di quel che andavo a leggere. Il libro è scorrevole e affronta l’argomento a tutto tondo, partendo dalle basi e arrivando a tecniche più avanzate, senza tuttavia divenire mai troppo complesso; credo che la scelta di Justin e della O’Reilly sia stata proprio quella di fornire un libro diverso da tutti quelli che ho letto finora sull’argomento, una specie di manuale base, un prontuario “inizia col piede giusto”. A me, ad esempio, non ha aggiunto niente di nuovo alle conoscenze che ho dello strumento, e soltanto in tre casi mi sono ritrovato a dire “ecco una cosa da tenere a mente”, ma questo non vuole sminuire assolutamente il libro. Per dovere di cronaca devo segnalare che uno script verso la fine del libro (quello dell’integrazione GA-CRM) contiene degli errori e non funziona, ma sicuramente è un “peccato” da prima stampa e sarà corretto nelle edizioni successive).

In buona sostanza è quindi un libro che consiglio ai principianti e alle persone che ritengono di avere lacune nei concetti alla base del funzionamento di Google Analytics. Gli utenti più esperti possono rivolgersi altrove, e non appena avrò finito il resto della pila sul comodino scriverò delle recensioni anche per loro 🙂

“Analytics mente” è una frase che in qualche forma esce regolarmente sui blog di tutto il mondo. E durante le conversazioni. E nei seminari. E durante i corsi. Cioè sempre. Ma “mente” rispetto a cosa, se mi è permesso? mente rispetto a una qualche forma di “verità” assoluta, che dovrebbe essere – vediamo se indovino – il reale numero di visite e visitatori di un sito? ah si? e, di grazia, chi è che decide quale sia questo reale numero? perché dire “Analytics mente” sulla base di una sensazione è inaccettabile. Dirlo sulla base del fatto che un altro sistema di web analytics fornisce numeri differenti è una ovvietà, e dirlo sulla base di considerazioni su fattori tecnici insensati è una cosa ai limiti del ridicolo.

Anche se so che questo post mi farà indossare la maschera di “difensore d’ufficio”, voglio andare a commentare un articolo portatomi sotto gli occhi da Francesco Tinti su twitter: Google Webmaster Tools Expose Analytics Lies. Vediamo un po’ quali sono le tesi di Brian Ussery, autore dell’articolo:

• BU: dopo aver indicizzato apples.html con keyword sulle mele, la redireziona con un 301 su oranges.html: Analytics dice che quella pagina riceve traffico attraverso ricerche con chiavi relativi a “mele”.
  MC: bella forza! i redirect 301 sono completamente trasparenti per GA. E se proprio devo dirla tutta, quel che accade è che una persona cerca “mele” e finisce sulla pagina oranges.html, quindi GA non sta nemmeno mentendo troppo.
• BU: page1.html redirige con un 302 su page2.html, che redirige a su volta con un 301 su una pagina di un altro dominio: per GA tutto questo è invisibile.
  MC: non viene mai eseguito il codice di tracciamento di GA (le redirezioni avvengono infatti lato server), il comportamento di Analytics è tecnicamente ineccepibile
• BU: se non si installa il codice di monitoraggio GA riporta traffico 0, mentre GWT riporta il reale traffico da Google.
  MC: GWT riporta il solo traffico da Google (e solo il traffico organico), ed è normale che sia così. Ci si sta peraltro perdendo tutto il resto del monitoraggio, campagne, cpc, altri motori, referral, traffico diretto, e tutto il resto dei dati che GA mette a disposizione
• BU: se il sito va offline, GA riporta traffico 0 mentre GWT riporta che ci sono problemi.
  MC: GA è un servizio lato client, e il client non vede il sito. Un sistema di web analytics lato server si comporterebbe nello stesso modo (a seconda del tipo di down, ma tipicamente se il webserver è giù i log non sono collezionati). Se Brian vuole gli faccio un’ipotesi contraria e fantasiosa tanto quanto la sua: un sito con enormi problemi di indicizzazione è perfettamente online: GWT riporta zero visite, mentre GA ne riporta migliaia, da cpc e visite dirette. Chi è che mente? 🙂

Quello che Brian intendeva dimostrare, a mio avviso piuttosto goffamente, è che GA non è un sistema adatto ai SEO; e su questo siamo perfettamente d’accordo: sebbene io stesso abbia in passato illustrato dei metodi e dei report utili ai fini dell’addetto al posizionamento (qui, qui e qui, tanto per citarne tre), non ho mai detto che quelli erano gli unici strumenti necessari; il vero SEO sa benissimo che il suo unico e migliore amico è l’analizzatore di logfiles.
Affermare che “Webmaster Tools dice la verità e Analytics mente” è una sciocchezza colossale: sono due sistemi destinati ad usi differenti, che in alcuni casi sono utilizzati dalle medesime persone e per finalità simili, ma che usano dati ed espongono situazioni che spesso non sono lontanamente paragonabili.
Semplicemente, il suo post non ha nessun senso!

Era solo questione di tempo, ed era anche già stato annunciato, il passaggio alla versione asincrona del tag anche per Google Website Optimizer, lo strumento di split test e test A/B di Google.

Direttamente dal post sul blog ufficiale, ecco cinque cose da sapere sul nuovo codice:

1. Lo script tradizionale ovviamente continuerà a funzionare, come per Analytics. Il nuovo codice viene proposto automaticamente alla creazione di nuovi esperimenti
2. Il nuovo codice usa un unico snippet di codice sia per la parte di controllo sia per quella di tracciamento; ora c’è un unico script da incollare sulle pagine invece di due.
3. Esattamente come per Google Analytics, il nuovo codice non va più prima della chiusura /BODY, ma va posizionato appena dopo l’apertura di HEAD; quindi addirittura prima dello script di GA
4. Nel caso in cui lo script necessiti di personalizzazioni (come per esempio nel caso di test tra più domini), allora c’è ancora bisogno della sintassi tradizionale.
5. Gli articoli delle pagine di help sono stati aggiornati di conseguenza

E’ una modifica che è stata richiesta a gran voce dalla comunity degli utenti di Google Analytics, e non sarà nemmeno l’ultima: presto o tardi anche Adsense e tutti gli altri script usati da Google passeranno ad una versione asincrona, in accordo al nuovo dettame “web più veloce” che l’azienda americana sta portando avanti da un po’ di tempo a questa parte.

Eccoci al solito appuntamento annuale con le previsioni sul futuro 🙂
Iniziamo col riprendere il post dell’anno scorso e controllare quanto si era detto:

• GA sarà quasi real-time: Le ultime volte che mi è capitato di controllare dati del giorno stesso, l’analisi era ferma all’ora precedente, confermando quanto predissi, ma so che la cosa non è ufficiale e non è nemmeno vera per tutti gli account. Credo di non potermi attribuire un punto pieno.
• più API per tutti: sono state ampliate, e sono state anche introdotte le Management API. Tramite l’introduzione della galleria delle applicazioni, moltissime persone possono usufruire di nuove funzionalità senza dover per forza scrivere del codice (prendete BIME, ad esempio). Addirittura esistono applicazioni che tramite le API fanno cose che Google Analytics ancora non fa: PadiTrack, ad esempio, è in grado di segmentare un funnel. PREVISIONE CORRETTA!
• dimensioni/metriche personalizzate. Purtroppo restano ancora un sogno. PREVISIONE ERRATA
• (da Francesco Gori) migliore integrazione tra Google Analytics ed AdWords: beh, direi di si, visto che è stato rifatto la sezione di report AdWords e sono state introdotte novità, come ad esempio la query cercata dall’utente (con tutti i limiti del caso, lo so FradeFra! 🙂 )

Poiché è tanto che il team di Analytics tace, mi aspetto a breve un colpo a sorpresa, qualcosa di grosso. E’ nell’aria, me lo sento. Vediamo comunque di tentare di indovinare cosa succederà nel 2011:

• link in uscita: la funzione è già pronta, se non la annunciano quest’anno perdo tutte le speranze 🙂
• social media come fonte separata: riesumo una previsione di inizio 2009, ma penso che questo sia l’anno cruciale.
• Google TV tracking: appena Google TV risolverà i suoi piccoli problemi, Google Analytics annuncerà una SDK dedicata (anche se in realtà si potrebbe già fare con quella Android) per tracciare la navigazione e l’uso delle TV multimediali, chiudendo il cerchio con la già esistente funzione di monitoraggio degli spot pubblicitari televisivi
• novità nella gestione di account e profili: credo che durante questo anno verranno abbassati alcuni limiti attuali del sistema: i 50 profili per account, la gestione un po’ complessa degli account, e verrà finalmente data la possibilità di migrare gli storici da un account a un altro

Fuori lista, proprio una sparata di fanta-web analytics: un’acquisizione. Le possibili prede si sono ridotte, dopo la campagna acquisti di IBM dello scorso anno, ma c’è ancora una compagnia che potrebbe essere fagocitata: Webtrends. La cosa avrebbe senso per due motivi, il legame piuttosto stretto che c’è tra WT e Facebook (e la rivalità nemmeno tanto velata che corre tra FB e Google) e il portafoglio clienti di Webtrends. Inoltre questa mossa metterebbe finalmente in scacco tutti quelli che chiedono una piattaforma. Purtroppo non essendo una società quotata non trovo i dati sulla capitalizzazione. Sappiamo che Google ha in cassa moltissimi dollari e stava per sborsare 6 miliardi per Groupon. Non so sinceramente valutare il valore di WT.
Se dovessi proprio dirne un’altra ancora più grossa, direi Adobe. Con un colpo solo Google si garantirebbe la proprietà di Flash fino a quando HTML5 non sarà abbastanza supportato, metterebbe in difficoltà Apple e i possessori di Mac che usano prodotti Adobe per il design e avrebbe in mano la tecnologia (e i clienti) di Omniture da integrare ad Urchin per fare finalmente un “Google Analytics a pagamento” definitivo e in grado di convincere anche i più restii.

Dai, dateci dentro anche voi, sono proprio curioso di sapere cosa prevedete!