Google Analytics in 30 secondi

Quando si parla di “coda lunga” si intendono, di solito, quelle parole chiave a medio-basso traffico i cui numeri sommati (accessi, ma anche conversioni) possono dar luogo a fenomeni di rilievo, a volte anche maggiori delle equivalenti keyword mainstream. Per intenderci, e a titolo meramente esemplificativo, potremmo associare il concetto alle parole chiave che trovate nei vostri report dalla riga 25 in giù.

Altre persone tendono a definire il concetto come “le parole chiave che contengono più di X parole”, con il numero X variabile. Io non sono d’accordo con questa definizione, ma la regular expression che vi propongo può essere utile a loro ma anche a voi per altri scopi: la regex serve a isolare le keyword con un numero di parole superiore al numero specificato. E’ questa:

^([^ ]+ ){5,}[^ ]+$

e ovviamente in questo caso prende solo le keyword con 6 o più parole (il numero indicato è infatti il numero di spazi). Potete utilizzarla con un filtro al volo direttamente nel report delle parole chiave, oppure creare un segmento avanzato come questo (clicca per ingrandire)

e verificare le performance del segmento rispetto ai dati di tutto il traffico. O crearne vari e controllare le performance di vari segmenti, tenendo ovviamente presente che il segmento con 6 o più parole contiene anche i dati di un eventuale segmento con 3 o più parole chiave.

Prima che me lo chiediate nei commenti, se volete invece la regex che seleziona SOLO le keyword con l’ESATTO numero di parole, dovete togliere la virgola dopo il numero 🙂

Mi ha scritto un lettore chiedendomi come mai il numero indicato nella panoramica dei rapporti e-commerce (le vendite di x prodotti hanno generato…) sia differente da quanto indicato nel report panoramica del prodotto (entrate generate dal prodotto). Il suo problema in realtà è leggermente differente, e vedremo di risolverlo, ma la domanda si pone all’interno di un filone piuttoto ricorrente sulle discrepanze dei numeri tra report differenti.

Spesso è solo un banale problema di traduzione dell’interfaccia, anzi di coerenza, perché Google Analytics dà a volte nomi differenti alle stesse cose. Nella fattispecie, quando guardiamo al report panoramica del prodotto il numero espresso è il prezzo dei prodotti netto, senza spese né tasse. Il numero indicato nella panoramica e-commerce è invece la REVENUE,cioè gli introiti totali comprensivi di tasse e spese di spedizione.
L’interfaccia sbaglia di grosso quando presenta nei due report sottostanti la colonna revenue per entrambi: nel primo caso (prodotti) il dato indicato sono le entrate, nel secondo caso invece (sorgente/mezzo) è davvero la revenue. Non che la cosa sia consolatoria, ma il problema c’è anche nell’interfaccia inglese, quindi si tratta di un vero e proprio errore di etichetta del dato: l’etichetta corretta di quella colonna dovrebbe essere Entrate generate dal prodotto (product revenue in inglese).

Molte persone si sono lamentate che la preview di Google Instant Preview (il nuovo servizio che mostra un’anteprima della pagina direttamente nelle pagine dei risultati, attraverso la lente di ingrandimento) falsa i dati di Google Analytics. Il thread di riferimento sul forum ufficiale è questo.
Prima di generare inutili allarmismi, vi dico subito che il problema è stato risolto ieri, si veda il relativo post ufficiale sul blog di Analytics: Instant Preview issue resolved.

Se volete un metodo per filtrare con un segmento avanzato le non-visite del bot che renderizza le immagini, vi lascio il link al blog di webshare, utilizzate il metodo 1.

Ma la domanda che mi pongo è questa: sono davvero “non visite”? secondo me no, sebbene siano strane, sono visite. In fondo non stiamo parlando di un bot che accede di notte, più volte al giorno, di un sistema automatizzato; stiamo parlando di un utente che, interessato al potenziale contenuto sul vostro sito che dovrebbe corrispondere alla sua ricerca, sceglie di guardare un’anteprima e clicca la lente. Sebbene a lui arrivi un’immagine in jpg, c’è un utente che guarda il vostro sito. A me non da fastidio che Analytics lo conteggi, anzi…

Peraltro John Mu, dipendente Google, nel topic che ho segnalato prima ha precisato che

It is my understanding that these page-views are currently only counted (the Google Analytics JavaScript executed) when we render the preview image on-demand (when a user chooses to view it and when we don’t have one cached already). [Ho capito che queste pagine viste sono conteggiate solo quando forniamo l’immagine di preview su richiesta (dell’utente ndMC) e non ce l’abbiamo già in cache]

Sono una voce fuori dal coro, dimentico qualcosa o siete semplicemente in disaccordo? 🙂

Oggi vorrei parlarvi di uno script aggiuntivo per Google Analytics, e vorrei farlo iniziando dal fatto che ancora non l’ho testato. Se ve ne parlo è perché l’autore, Stéphane Hamel, mi è noto ed è conosciuto e stimato in tutto il mondo della web analytics: oltre ad essere nel board della Web Analytics Association (tesoriere), alcuni di voi forse lo ricorderanno come l’autore dell’estensione di Firefox WASP, che serve a controllare la presenza sulle pagine di vari sistemi di web analytics.

Lo script aggiuntivo di chiama GA addons, ed è reperibile nell’apposito mini-sito gaaddons.com: serve ad aggiungere in modo abbastanza semplice alcune funzioni di cui ogni tanto parliamo su queste pagine, ed altre che invece non abbiamo trattato. Dipende da JQuery per il funzionamento, quindi dovrete assicurarvi di avere la necessaria chiamata prima del codice di tracciamento dopodiché dovreste scaricare il file di GAaddons, metterlo nel vostro sito e referenziarlo con una chiamata nelle vostre pagine, ovviamente sempre prima del vostro codice di Analytics.

Che funzioni offre?

• form analysis: traccia l’ultimo campo di una form dove è stato posizionato il cursore, in modo da capire dove gli utenti abbandonano la compilazione. Al momento supporta una sola form per pagina.
• giorno della settimana: crea una variabile personalizzata (di sessione) contenente il giorno della settimana. Utile per le segmentazioni
• dual mode: salva una copia dei dati anche nei logfiles del vostro webserver (nè più né meno che una combinazione di _setLocalRemoteServerMode e _setLocalGifPath)
• track downloads: serve ad automatizzare il tracking dei file scaricabili, specificandone i formati
• track errors: traccia le pagine di errore (per default 404 e 500, ma è configurabile)
• track load time: tiene traccia del tempo di caricamento delle pagine, in millisecondi. Utile per fare debug delle prestazioni in casi di picchi di traffico.
• track mailto: traccia gli invii delle email sui link mailto:
• track outbound: traccia i link esterni (al momento inutilizzabile se usate il cross domain tracking)
• traccia il “vero” bounce rate: se la visualizzazione della prima pagina si protrae oltre un tot di secondi, spara un evento in modo da azzerare il tasso di bounce per quella visita.
• 4Q: se lo usate, si integra con 4Q di iPerceptions, un sistema di sondaggi online per la customer satisfaction

Fattore positivo, ognuna di queste funzionalità ha un settaggio che permette di essere disabilitata se la pagina visitata è la prima della visita. Diversamente, poiché ognuna di esse lancia una chiamata ai server di GA, il bounce rate sarebbe falsato. Altra cosa positiva è che l’intero sistema GAaddons può funzionare con pagine virtuali o eventi, a scelta dell’utente e secondo le esigenze.

In definitiva si tratta di un modo di automatizzare e rendere standard alcune funzioni che sono applicabili a Google Analytics anche senza GAaddons (ad esempio il tracciamento di mailto, donwload e link esterni si può fare con la libreria mia di di Francesco Terenzani), il track load time l’ho presentato qualche giorno fa al corso avanzato, eccetera.

Il sistema è gratuito per uso personale, mentre costa 149 dollari per piccoli siti aziendali. Per professionisti e agenzie che devono implementarlo su siti di clienti, il costo è rispettivamente di 149 e 699 dollari.

Esattamente come nello slogan di un noto operatore telefonico italiano, la web analytics è intorno a voi. Di ritorno dal corso avanzato di Verona, sono stato per tre quarti d’ora buoni in stazione a Milano Centrale, aspettando pazientemente che sul tabellone elettronico venisse indicato il binario al quale avrei trovato la mia coincidenza. Vengo avvicinato subito da un ragazzo, che propone chiavette per collegarsi ad internet a costo zero, pagando poi solo il canone mensile.
Io sono già connesso quanto basta quindi non mi interessa, ma mentre aspetto noto il numero esorbitante di “NO” che lui e le sue tre colleghe ricevono. il 100% in quasi un’ora, e di gente in un’ora a Milano Centrale ne passa parecchia.

Dopo un pochino mi avvicino, e poiché il ragazzo mi sembra un tipo alla mano, gli dico che secondo me sbagliano l’approccio. Tutti iniziano con la medesima domanda “utilizzi internet?” e io gli dico che quella domanda presuppone due risposte e un bivio: se rispondono “no” lui desiste, se rispondono “si” allora deve fare la domanda successiva “ti interessa la chiavetta eccetera?”. Ma intanto si sono persi secondi (e metri, perché tutti camminano in fretta) preziosi.
Gli propongo – gratis 😀 – quello che ritengo essere un approcio migliore: iniziare con la domanda “ti interessa risparmiare sulla connessione internet?”, che si presta ugualmente a due risposte, ma in modo differente. Se la risposta è “no” lui comunque non vende nulla, tanto quanto prima, ma psicologicamente è più difficile opporre una negazione ad una domanda basata su un fatto positivo (risparmiare soldi).

Dove sta la web analytics in tutto questo? adesso ci arrivo: il ragazzo rifiuta sorridendo la mia versione, dicendo che l’unico trucco è “portare il cliente vicino al bancone” e che poi lì le cose sarebbero state più facili, e che il no iniziale dipende da come è posto. Può darsi, ma io non ho visto risultati nel loro modo di agire “accademico”, passatemi il termine.
Mi sono allontanato pensando: perché invece non fai uno split test, un test A/B? metà del personale insiste con la tua versione, l’altra metà prova per un periodo limitato il mio approccio, e poi vedi chi converte di più in termini di acquisizione nuovi clienti. Per dirla ancora meglio: qualcuno propone una versione modificata (lui pensa “migliorata”) di qualcosa di tuo, non puoi bocciarla solo sulla base delle conoscenze accademiche, fai un test di rendimento delle versioni e poi decidi.

Ovvero “decidi sulla base dei dati”. web analytics, appunto 🙂

Sull’argomento, all’incirca, segnalo anche un interessante post di Jeff Artwood su codinghorror.com, relativo agli AB test nel film “ricominicio da capo” con Bill Murray (Groundhog day in originale)

[photo credit: Saucy Salad on Flickr]

C’è un motivo per cui nell’ultimo periodo ho scritto poco: stavo finendo di preparare/sistemare il materiale per il corso base e l’avanzato della settimana scorsa. Adesso che le date sono passate credo che potrò tornare ad avere un pochino di tempo per riflettere, ideare, sperimentare e rendervene conto qui sul blog.

Già che ci siamo volevo ringraziare tutti gli allievi dei due corsi, per aver sopportato le piccole magagne tecniche, la mia parlantina e il mio accento genovese, per non essersi addormentati platealmente durante le fasi finali di ogni giornata. Devo dire che mi piace stare insieme a persone che come me apprezzano Google Analytics, ascoltare le idee e le domande: anche quelle apparentemente più facili possono essere foriere di spunti interessanti da sperimentare.

Prima di tornare a capofitto nei report, nei numeri e nelle percentuali, volevo anche dirvi che l’anno prossimo parteciperò a due eventi, stavolta non come docente ma come pubblico. A Febbraio partecipo al Corso SEO Swing di YoYo – Formazione rotolante, tenuto da Enrico Altavilla e Piersante Paneghel di SearchBrain. A Marzo invece accorro numeroso al Be-Wizard, dove torna quel ciclone di Avinash Kaushik e dove sarà presente anche Randy Fishkin di SEOmoz.

Se siete da quelle parti – e non mi viene in tasca nulla se vi consiglio di esserci 🙂 – come al solito fate un fischio che scambiamo due parole!

Il 14 novembre è il giorno da festeggiare, per noi specialisti del sistema di web analytics made in Google. Ormai cinque anni fa, a sorpresa, Google trasformava Urchin on Demand in Google Analytics, e iniziava la sua lenta ma inesorabile marcia verso un market share strepitoso e verso un mutamento di tutto il settore della web analytics piuttosto pesante.

In fondo al post dello scorso anno mi chiedevo come sarebbe stato oggi Google Analytics, ma non intendo rispondere e non intendo rifare la stessa domanda: ormai mi sono abituato al fatto che le cose cambiano talmente in fretta che è quasi un peccato stare a immaginare cose fantasmagoriche quando c’è sicuramente qualche ingegnere che le sta già sviluppando 😉

photo credit: janielianne on Flickr

Ci sono due novità nell’intelligence di Analytics. La prima la sbrighiamo abbastanza velocemente, perché in Italia non è disponibile: è la possibilità di essere avvisati via SMS quando si attiva un alert personalizzato, molto comodo se per qualche motivo non si può essere davanti al PC.

La seconda è quella che nell’interfaccia italiana è tradotta come “contributori principali” (post ufficiale): dato un alert personalizzato (ad esempio “taffico sale di oltre il 30% rispetto al giorni precedente”), Google Analytics lo “dividerà” in segmenti riferiti a i termini che siamo abituati a vedere, ad esempio “pagina di destinazione”, “mezzo”, “sorgente”. Di ognuno di questi riporterà la visite nel periodo di riferimento dell’alert e nel periodo di confronto, e infine anche quanta parte percentuale della variazione questo segmento spiega.

Guardate l’immagine per capire meglio (cliccate per ingrandire):

magari non sarà una feature che useremo tutti i giorni, ma è comunque una fonte di ulteriori dati e insights, e questo è sempre bene 🙂

Se siete preoccupati perché non vedete i dati di ieri 2 novembre, beh sappiate che non siete i soli. Ci sono decine di post nel forum ufficiale, e Google è al corrente della cosa e ci sta lavorando, come potete leggere dalla Google Analytics Status Dashboard.

Ho fatto un controllo a campione sui miei profili, e anche io ne sono affetto. Non ci sono più i privilegiati di una volta! 🙂

[edit: Matteo Carli mi segnala su Twitter che i dati sono disponibili attraverso le API, e che il problema è solo dell’interfaccia, come tra l’altro si nota guardando la dashboard. il problema è nella riga “rapporto web” e non in quella “raccolta dati” ]

[edit 2: ecco anche il post ufficiale]

Una delle frasi che mi ritrovo più spesso a digrignare tra i denti quando mi fanno domande su Google Analytics è “mapporc… ma possibile che ci siano sempre questi grossi casini?”. Non scherzo. Io sono un programmatore, sono cresciuto con la logica del “keep it simple” e non disdegno di rifare pezzi di lavoro se le soluzioni attuate mi permetteranno di risparmiare tempo in futuro. La web analytics ormai è in giro da un pezzo, e sebbene sia cosciente che i clienti sono a volte impossibili, le richieste assurde e le soluzioni tecniche proposte spesso “fantasiose”, non posso fare a meno a volte di domandarmi “ma perché?”

Qualche tempo fa Robbin Steif di Lunametrics ha scritto un post che mi è piaciuto molto: “designing a Google Analytics friendly site“; se i suoi suggerimenti fossero sempre tenuti in considerazione nel rifacimento di un sito, il lavoro di chi fa le analisi sarebbe più semplice, e questo si tradurrebbe in meno tempo per il debug e più tempo per le analisi. Visto e considerato che la web analytics dovrebbe essere parte integrante di un più vasto processo aziendale, e visto e considerato che il design di un sito non è fine a sè stesso, perché non provare in fase di redesign ad agevolare il lavoro futuro dei web analyst?

Ecco le sue considerazioni:

• Pagina obiettivo: provate ad avere una pagina obiettivo per ogni goal che andrete a misurare. E se possibile raggruppatele anche logicamente a livello di cartelle (per esempio col prefisso /thank/), in modo da poterle tracciare singolarmente o raggruppate. O anche singolarmente E raggruppate!
• cerca sul sito: meglio se la ricerca avviene in GET e c’è un parametro univoco davanti alla parola cercata
• tracciare sezioni del sito: fate in modo che le sezioni del vostro sito da tracciare separatamente siano tutte sotto la stessa directory, così potrete usare il report “dettaglio contenuto” sneza dover ricorrere a complessi filtri. Al massimo userete dei profili-copia con il filtro predefinito “includi solo il traffico verso una sottocartella”
• Il problema dei domini: cercate di usare un solo dominio. Il passaggio da dominio a dominio mantenedo la congruenza del tracciamento è possibile, ma si introducono potenziali e multiple falle nel “sistema”. Se userete altri domini (servizi terzi) almeno assicuratevi di poter inserire il vostro codice di tracciamento!
• Sottodomini: Gestire il tracciamento per un sottodominio non è complicatissimo (è una riga di codice in più), ma se non proprio necessario perché non puntare su una sottodirectory? (Robbin punta sul discorso SEO, questo punto io lo trovo piuttosto debole, dato che è sempre consigliato usare _setDomainName in un nuovo tracciamento, per prevenire la congruenza dei cookie nel caso di aggiungesse dopo un sottodominio)
• Frame e iframe: E’ difficilissimo gestirli. Non è impossibile, ma è dannatamente faticoso. Se proprio dovete usarli, dovreste rispondere alla domanda “è più importante il frame o il tracciamento con Google Analytics?”
• Redirect: Assicuratevi che siano server-side e che passino correttamente tutta la querystring
• Piccole cose: ad esempio evitare di avere /percorso e /percorso/ come finale degli URL. Per Analytics sono due indirizzi distinti, se potete prevenire è meglio che risolvere con dei filtri, specie in siti di grandi dimensioni…

Siete d’accordo?