Google Analytics in 30 secondi

Non passa giorno senza novità per Google nell’ultimo periodo. Quella di oggi sarà particolarmente gradita: il blog ufficiale di webmaster tool e quello di Analytics riportano la notizia che i clic sui pulsanti +1 dei nostri siti, purché verificati in GWT, hanno una sezione di report apposita nel pannello dei webmaster. E sappiamo che prima o poi quei report finiranno dentro a Google Analytics (a proposito, mi hanno attivato nel programma pilota, ma c’è poco da segnalare per adesso). La seconda cosa che dicono, molto più interessante, è che dentro a GA c’è una nuova sezione di report, che si chiama proprio sociale e si trova dentro il gruppo VISITATORI.

E’ composto da un primo report COINVOLGIMENTO, che segmenta le visite tra “socially engaged” e “not socially engaged”, cioè tra chi ha o non ha cliccato un bottone sociale. Il secondo report è AZIONE, e al pari del report degli eventi mostra l’azione compiuta dai visitatori. Nei miei report al momento viene tracciato (automaticamente) il pulsante +1 di Google. Ogni azione ha anche una “sorgente sociale”, cioè google è la sorgente sociale, +1 è l’azione, e le due cose combinate sono google +1; in effetti non mi è al momento chiaro il perché di questa scelta (non è che facebook ha il più uno per cui l’azione +1 possa avere due dirfferenti sorgenti sociali…), ma è così.
L’ultimo report è PAGINE, e ci mostra gli URL esatti delle pagine dove sono stati premuti i pulsanti: il report si presenta come tabella pivot con azioni e sorgenti sociali, ma poiché ho ancora pochi dati non sono riuscito a modificarlo a piacere.

Ecco uno screenshot dal blog ufficiale

Come dicevo sopra, al momento l’integrazione tra pulsante e tracciamento è automatica – ovviamente – solo per il +1 di Google. Se volete aggiungere gli altri pulsanti dovrete fare affidamento su una nuova funzione, _trackSocial(), con la seguente sintassi

_gaq.push(['_trackSocial', network, socialAction, opt_target, opt_pagePath]);

• network è obbligatorio, ed è una stringa con il nome del social network cui il bottone si riferisce
• socialAction è obbligatorio, ed è una stringa con l’azione svolta, ad esempio INVIO, LIKE, SHARE, TWIT, ecc…
• opt_target è opzionale, ed è una stringa che rappresenta la pagina (URL o ID o quel che volete) che genera l’azione sociale. Se omesso viene usato l’url della pagina corrente estratto tramite document.location.href
• opt_pagePath è opzionale ed è una stringa che rappresenta l’indirizzo senza dominio dal quale viene generata l’azione sociale. Se omesso viene usato location.pathname+location.search e in genere si può omettere, tranne nel caso in cui la pagina venga registrata du Analytics con una url diversa dalla corrente tramite l’uso di una pagina virtuale e _trackPageview

Ovviamente non dovete inserire queste funzioni nel normale codice di monitoraggio, altrimenti ogni pagina vista corrisponderebbe a una o più azioni sociali, ma dovete fare in modo che esse siano richiamate alla pressione dei pulsanti. La maggior parte di essi ha infatti la possibilità di specificare la chiamata a qualche funzione quando viene premuto. La pagina di documentazione della funzione fornisce alcuni esempi (tracciare i like di facebook, tracciare i tweet) e un esempio di codice per fare il tutto automaticamente, scritto da Nick Mihailovski).

Questa parte di tracciamento comporta del lavoro aggiuntivo, ma ritengo ne valga la pena. Dopo potrete sapere cosa e quanto condividono i vostri utenti, da dove vengono quelli che condividono di più, come i pulsanti interagiscono col vostro ecommerce, se lo fanno, e usando le campagne generare dei circoli viziosi tipo “4 persone provenienti da quel referrer hanno sharato il contenuto su facebook, che era taggato con una campagna che mi ha portato 347 persone e 14 vendite”. E il tutto senza ancora aver visto cosa ci riserva Google da PostRank 😉

Piuttosto interessante l’ultimo post sul blog ufficiale di Google Analytics: “How to measure the quality of an online form“, che si prefigge lo scopo di usare il sistema di web analytics made in Google per avere un tasso di errore sull’invio delle form, cioè per capire se e quanto gli utenti sbagliano a compilare i campi prima di riuscire ad inviare un modulo. Ovviamente il prerequisito è di avere una form che effettui il controllo dei valori prima dell’invio vero e proprio.

Il primo concetto introdotto è il FER, cioè il Form Error Rate (tasso di errore della form), e viene calcolato dividendo il numero di invii rifiutati per il numero totale di invii tentati, e moltiplicando per cento. Se per esempio un visitatore deve compilare una form con 25 campi, e ci riesce al terzo tentativo, il FER è 2/3*100, cioè il 66%. Se un visitatore ce la fa alla prima, il secondo alla terza e il terzo visitatore non ci riesce dopo tre invii, il FER sarà 5/7*100, cioè 71%. Più il tasso è alto e più la nostra form risulta problematica e ostica per gli utenti.

Come hanno pensato di fare questa analisi in Google Analytics? usando la funzione _trackPageview() per generare pagine virtuali “codificate” in modo da avere nel nome della pagina il numero di campi compilati male. Nel post si fa riferimento ad una semplice form con due campi, in cui ognuno di essi viene codificato a 1 se non riesce ad essere validato (se l’utente ha commesso un errore, quindi) e a 0 se invece è correttamente valorizzato. Ad ogni invio della form bisogna chiamare la funzione _trackPageview(“/onlineform/00”); dove 00 sono le due codifiche dei campi menzionati poco fa. Ad esempio una form con il primo campo errato e il secondo corretto genererà una pagina virtuale che si chiama /onlineform/10, mentre una con entrambi i campi errati genererà /onlineform/11.

L’analisi è piuttosto semplice: fatto un filtro di visualizzazione nel report “contenuti principali” che mostri solo le pagine /onlineform/ bisognerà prendere il numero totale di pagine viste meno quelle della sola /onlineform/00 e dividerlo per la somma delle pagine viste. Sempre ricalcando l’esempio del post sul blog ufficiale, in una situazione del genere, in cui i successi sono stati 5,

il FER è 18/23*100, cioè il 78%. La form in questione, pur avendo due soli campi, risulta parecchio problematica per gli utenti e necessita di revisione, o di maggior chiarezza nelle istruzioni. Se la vostra form ha otto campi, naturalmente, avrete pagine virtuali tipo /onlineform/00000000 e così via.

Sono rimasto molto colpito dal post, che nella sua semplicità mette a disposizione uno strumento molto potente per l’analisi delle interazioni utente-sito. Fare form analysis con GA è sempre stato un mio pallino, ma non ho mai trovato un modo soddisfacente; questa non sarà form analysis vera e propria, ma è un buon inizio!

Se siete interessati all’analisi delle form tramite GA, vi ricordo anche questo vecchio post

Sempre il buon Andrea mi pone una domanda, e ne approfitto di nuovo per un post: mi fa sempre piacere scoprire cosa non è chiaro alle persone, dato che io con Google Analytics ci faccio anche colazione e quindi tendo a dare per scontate troppe cose 🙂

Il suo quesito è all’incirca “Non sono d’accordo con una persona che sostiene che trackpageview può essere utilizzato anche per rimappare l’url corrente della pagina e fare in modo che sia possibile poi utilizzare il nuovo indirizzo all’interno dei goals per verificare chi converte e chi no. Io ritengo che la funzione del trackpageview è quella si di assegnare una pagina virtuale, ma nel caso in cui si scateni un evento a cui questo è stato associato”

L’errore nasce dal fatto che _trackPageview noi lo vediamo solo in due forme. La prima è all’interno del codice di monitoraggio classico, dove viene sempre richiamata senza parametri, la seconda è quando creiamo pagine virtuali e quindi le passiamo come parametro un indirizzo fittizio. La funzione in realtà è sempre la stessa, e il suo scopo è quello di “fare il punto della situazione” nel codice di monitoraggio, scrivere i cookie nel computer del visitatore e sparare i dati verso i server di Google. Se non gli si passa un parametro, essa invia per impostazione predefinita l’url corrente della pagina così com’è.
Ma nessuno ci vieta, ad esempio, di usare una funzione lato server per inserire dinamicamente all’interno di un codice di monitoraggio degli indirizzi più leggibili ai fini delle nostre analisi.

Ipotizziamo di non avere modo di riscrivere le URL attraverso i metodi “normali” – quali .htaccess o filtri ISAPI per webserver Microsoft – e di aver scritto una funzione in PHP (abbellisciURL() ) che ci restituisce un simil-URL nella forma /categoria/marca/nomeprodotto.html

Se modificassimo il GATC così

<script type="text/javascript">
var gaJsHost = (("https:" == document.location.protocol) ? "https://ssl." : "http://www.");
document.write(unescape("%3Cscript src='" + gaJsHost + "google-analytics.com/ga.js' type='text/javascript'%3E%3C/script%3E"));
</script>
<script type="text/javascript">
try{
var pageTracker = _gat._getTracker("UA-xxxxxx-x");
pageTracker._trackPageview(<?php abbellisciURL(); ?>);
} catch(err) {}</script>

dentro a Google Analytics avremmo SOLO ED ESCLUSIVAMENTE i nostri url abbelliti.

Potrete poi usare questi url per definire gli obiettivi? ASSOLUTAMENTE SI, dato che non sappiamo esattamente QUANDO GA elaborerà i dati, e dato che gli url modificati sono I SOLI ad essere stati inviati ai server di Google, è assolutamente lecito e possibile definire dei goal usando gli url fittizzi. Anzi, non potreste fare altrimenti!

_trackPageview() quindi si rivela anche un potente strumento per rendere i vostri report più semplici e chiari, più leggibili, ed eventualmente anche per facilitarvi la vita nell’impostazione degli obiettivi.

In passato vi ho descritto l’uso della funzione _trackEvent(), utile per usare il tracciamento degli eventi sulle pagine ed evitare di generate troppe pagine virtuali o per tracciare comportamenti complessi dell’utente indipendentemente dalla sua attività (ad esempio per tenere traccia degli eventi in AJAX, che tipicamente non ricaricano la pagina e quindi non generano un nuovo invio di dati a Google Analytics).

Un caso un po’ anomalo è capitato ad un utente del forum di supporto: venablc ha bisogno di chiamare la funzione _trackEvent() senza richiamare anche _trackPageview(), probabilmente perché sta inviando i soli dati degli eventi ad un altro profilo e non vuole vedere le pagine viste; omettendo semplicemente la chiamata il codice non funziona e la consolle degli errori javascript riporta un laconico errore di “oggetto non definito”.

La soluzione al problema è resuscitare la defunta funzione _initData(), soppressa qualche tempo fa. L’oggetto che manca a _trackEvent infatti viene creato da _initData(), che a sua volta è richiamata automaticamente da _trackPageview(). Ma nessuno ci vieta di chiamarla esplicitamente, evitando di inviare i dati della pagina vista ma consentendo a _trackEvent() di funzionare regolarmente!
[ovviamente quanto detto vale per il caso specifico e può essere adattato alle vostre esigenze senza dimenticare quanto detto in questo altro post: o initData ce l’avete in tutte le pagine o non ce l’avete in nessuna, per quanto riguarda il profilo che raccoglie i dati]

Oggi voglio segnalarvi uno script che alcuni di voi potrebbero trovare utile, e che serve a tracciare i click sui link esterni e sui download tramite gli eventi di Google Analytics, anziché tramite il classico metodo delle “pagine virtuali”. E’ una tecnica descritta da Stephane Hamel sul blog immeria, e ve la posso presentare senza averla provata perché gli autori sono gli stessi dell’estensione WASP, per cui possiamo fidarci!

I click sui link esterni saranno tracciati con un evento di nome “outbound”, una action “click” e una label uguale all’url visitato. I download invece avranno un evento “download”, la stessa action “click” e una label uguale al nome del file scaricato. L’espressione regolare predefinita è questa
/\.(docx*|xlsx*|pptx*|exe|zip|pdf|xpi)$
e cerca sostanzialmente eseguibili, pdf, archivi zip, estensioni di Firefox e documenti Office 2007, ma siete ovviamente liberi di modificarla come più vi pare cercando nel file gaAddons.js la riga
var fileTypes = new RegExp(/\.(docx*|xlsx*|pptx*|exe|zip|pdf|xpi)$/i);
e modificandola in base ai tipi di file che il vostro sito propone agli utenti.

Per abilitare questo tracciamento è sufficiente scaricare il file gaAddons.js dal sito di immeria, caricarlo sul proprio server e aggiungere una riga al codice html delle pagine, prima della chiusura di BODY, non importa se prima o dopo la chiamata al GATC. La riga da aggiungere è
<script src="/js/gaAddons.js" type="text/javascript"></script>

nell’ipotesi in cui il file risieda nella sottocartella /js/, altrimenti dovrete indicare il percorso per trovare il file dello script.

E’ una soluzione che ritengo valida, ma che non implementerò a tappeto sui profili che gestisco, miei o dei clienti. Valuterò caso per caso se il beneficio ottenuto vale lo sforzo (sforzo di installazione, ma anche di manutenzione e di interpretazione dei report). Il criterio sul quale mi baserò è puramente numerico, infatti ritengo che questa implementazione tramite gli eventi porti benefici su siti con grandi numeri, dove il numero di click su link esterni e download è significativo e quindi il numero di pageviews virtuali ha un impatto di un certo tipo sui totali visualizzati da GA. Per siti di piccole dimensioni, al momento, non ritengo necessario l’uso degli eventi per questo tipo di monitoraggio, e resta sempre valido il sistema automatizzato realizzato da me e Francesco Terenzani

La funzione di tracciamento degli eventi è una conseguenza della riscrittura a oggetti del codice di tracciamento di Analytics, come dicevo nel post precedente. Javascript infatti è un linguaggio orientato agli oggetti, e senza entrare in dettagli troppo tecnici diremo che questo tipo di paradigma della programmazione comporta alcuni indubbi vantaggi che gli ingegneri di Google hanno ritenuto utile implementare nel GATC.

Un evento, secondo la definizione (bozza del 22/9/2008) della Web Analytics Association, è una qualsiasi azione registrata che ha un timestamp attribuito dal browser o dal server; sono esempi di azioni il display di un banner o l’invio di una richiesta asincrona tramite AJAX in una porzione di pagina web.
La funzione che Google Analytics usa per tenere traccia degli eventi è _trackEvent(categoria, azione, descrizione, valore).
I valori passati come parametro a questa funzione sono:

• categoria [obbligatorio]: è una stringa che identifica il “gruppo” di eventi cui l’azione appartiene. Poiché possono coesistere più eventi nella stessa pagina è un parametro che non può essere omesso.
• azione [obbligatorio]: è una stringa che identifica l’azione svolta dall’utente e strettamente correlata alla categoria. Anche in questo caso è un parametro che non può mancare.
• descrizione [facoltativa]: è una stringa che si può usare per aggiungere ulteriori informazioni all’evento. Nel caso di eventi complessi o presenza di molti eventi contemporanei può essere utile per districarsi nella lettura dei report.
• valore [facoltativo]: è un numero intero che si può indicare per associare un valore all’evento.

Un esempio tipico di tracciamento degli eventi è un video comandato via javascript da pulsanti personalizzati. Il pulsante play potrebbe avere questo codice assegnato:
<a href="#" onClick="pageTracker._trackEvent("Video", "Play", "video-compleanno-2008", 0);">Play</a>

Analogamente si potrebbero passare a Google Analytics anche i valori di pause e stop, magari dopo aver scritto un paio di funzioni javascript per razionalizzare e ottimizzare il codice, e poi leggere nella sezione eventi dei report i risultati. La sezione eventi non è ancora stata ufficializzata, ma in un profilo in cui ho fatto alcune prove essa è comparsa da sola. Probabilmente viene attivata quando iniziano ad arrivare i primi dati sotto forma di eventi.

Il vantaggio del tracciamento eventi è che non si ricorre al metodo delle pagine virtuali di _trackPageview(), e che quindi non si inflaziona il relativo conteggio. Tramite gli eventi, con un po’ di lavoro, è anche possibile monitorare in forma più estesa i donwload di materiali e documenti dal sito.

Una form è pur sempre una form, e molti utenti non amano questa forma di interazione che invece spesso è fondamentale per entrare in possesso di informazioni più o meno vitali per la vita del proprio sito web. Ci sono centinaia di pagine e scritti sull’usabilità delle form e sulle best-practice per invogliare l’utente a compilarle, o per non distruggere la sua esperienza sul nostro sito.

Uno dei passi principali del processo di ottimizzazione dei moduli è quello che porta all’eliminazione dei campi “inutili”, dove per inutili si includono anche i campi non obbligatori che gli utenti non compilano. Se l’informazione richiesta ci serve, converrà rendere la compilazione del campo obbligatoria, altrimenti dovremo arrenderci all’evidenza che la form non funziona. Ma come possiamo rendercene conto? con uno strumento di web analytics, ad esempio. In questo caso un post su e-nor.com ci illustra come piegare Google Analytics a questa esigenza, come asservirlo alle esigenze di progettisti e di coloro che hanno a cuore la user experience degli utenti.

il primo passo è quello di aggiungere una un evento onClick ogni volta che la form viene inviata
<input type="submit" name="Submit" value="Submit" onClick="return validate(this.form);"/>

il contenuto della funzione validate() è invece il seguente

function validate() 
{ 
isEntered(document.getElementById('name'),'name');
isEntered(document.getElementById('email'),'email');
isEntered(document.getElementById('phone'),'phone');
isEntered(document.getElementById('company'),'company');
isEntered(document.getElementById('comments'),'comments');

frm.action='/thankyou.aspx?src=contact_us.htm'; 
} 

function isEntered(el, field_name)
{ 
     if((el.value=="") || (el.value==null))
     {
     pageTracker._trackPageview('/contact_us.htm/empty/'+field_name); 
     }

     else
     {
     return false;
     }
}

ovviamente serve una riga per ogni campo della vostra form, e gli id devono corrispondere. Non è molto differente dalle molte funzioni di validazione delle form che si trovano in giro per il web, ma questa ha la particolarità di aggiungere una chiamata a _trackPageview() ogni volta che uno dei campi risulta vuoto al momento dell’invio. La scelta in questo caso è di creare una pagina /contact_us.htm/empy/nome-del-campo.

Per leggere i dati l’articolo consiglia anche di creare un profilo-copia e di mettere un filtro di inclusione solo per i dati provenienti dalle form inviate, in modo da non perdere troppo tempo a cercare i risultati nei report. Il filtro sarebbe fatto così:

Nome: URL Filter – Contact Us Form
Tipo: filtro personalizzato, di inclusione
Campo filtro: URI della richiesta
Pattern filtro: contact_us\.htm
Maiuscole Minuscole: No

il report CONTENUTI PRINCIPALI di un profilo con questo filtro applicato conterrebbe solo URL riferiti alla pagina di contatto, con le evidenze del numero di volte in cui ogni campo è stato inviato vuoto, permettendoci di trarre le dovute conseguenze sul proseguo della vita della nostra form.

Come nota personale aggiungo che la soluzione mi piace, ma non mi fa impazzire. Ne ho in testa una versione evoluta, che permetterebbe anche di conoscere quante volte le persone cliccano su ogni campo per compilarlo o quanto tempo viene impiegato per la compilazione della form e del singolo campo. E’ uno dei tanti progetti che prima o poi riuscirò a realizzare.

Uno dei possibili parametri per definire delle KPI (Key Performance Indicator) su un sito è il tempo trascorso dai visitatori sulle nostre pagine. Questo dato è presente in Google Analytics, ed è conforme agli standard della Web Analytics Association, ma spesso noto molta confusione nell’interpretazione dei report relativi. Cercherò di farvi capire come funziona con esempi pratici:

La domanda tipica che mi sento rivolgere è all’incirca questa: “perché nella bacheca GA mi segna un certo tempo medio sul sito e nel dettaglio contenuti un altro?” (vedi la figura sotto)

(valori di tempo sul sito in GA)

La risposta secca è: perché il primo valore è la media del tempo sul sito, il secondo è la media delle medie del tempo su ogni singola pagina.
Google Analytics calcola il tempo su ogni pagina tramite la differenza tra il timestamp (preciso al secondo, calcolato in UNIX time) di ogni pagina meno il timestamp della pagina precedente. E di conseguenza il tempo sul sito è il timestamp dell’ultima pagina visitata meno il timestamp della prima.
Chiariamo con una schema: Continua a leggere “Comprendere appieno il tempo sul sito”

Quando vi proposi la libreria di Brian Clifton per tracciare automaticamente link e download, dissi che soffriva di un problema. A molti sembrerà un problema di poco conto, una cosa che usano in pochissimi, ma ha realmente una sua utilità che vado a spiegarvi: la libreria di Clifton funziona solo con l’oggetto predefinito di GA, pageTracker. Se voi istanziate più oggetti per più profili, non va. Dovete modificare il sorgente e conoscere a priori il nome dell’oggetto di monitoraggio. Insieme a Francesco Terenzani (lui l’autore materiale del codice, io ci ho messo alcune idee e test) ci siamo subito messi a pensare a una soluzione più snella ed efficace per colmare questa lacuna, e l’abbiamo trovata e descritta nel post di Francesco.

Le istruzioni sono molto chiare e non ve le riporto (e tra l’altro non c’è nemmeno bisogno di una chiamata onload), vorrei invece porre l’accento ancora una volta sulla flessibilità della soluzione che abbiamo trovato. Possiamo istanziare due o più oggetti di tracciamento e tracciare gli stessi download su due o più account diversi, oppure possiamo tracciare cose diverse su account diversi come mostrato da Francesco. Invece di fare dei filtri a monte di profili-copia, con una semplice riga nel GATC otteniamo lo stesso risultato.

Guardate questo codice (realmente testato):

<script type="text/javascript">
var gaJsHost = (("https:" == document.location.protocol) ? "https://ssl." : "http://www.");
document.write(unescape("%3Cscript src='" + gaJsHost + "google-analytics.com/ga.js' type='text/javascript'%3E%3C/script%3E"));
</script>
<script type="text/javascript" src="_ftTrack.js"></script>
<script type="text/javascript">
var pageTracker = _gat._getTracker("UA-XXXXX-5");
pageTracker._initData();
pageTracker._trackPageview();
_ftTrack(pageTracker, "link|doc|rtf|pdf|zip");

var miopersonalTracker = _gat._getTracker("UA-XXXXX-12");
miopersonalTracker._initData();
_ftTrack(miopersonalTracker, "doc|rtf");
</script>

se notate, al secondo oggetto di tracciamento manca la chiamata a trackpageview(), che è quella che trasmette i dati ai server di Analytics. Questo perché trackpageview viene richiamata già al momento della creazione delle pagine virtuali, cui viene passato come argomento il percorso delle pagine virtuali stesse. Con il codice che ho scritto sopra avremo due profili, magari copie, il primo dei quali traccia tutto come sempre con in più i link esterni, i documenti doc, rtf e pdf e gli archivi zip, mentre il secondo traccia SOLO i documenti doc e rtf. ma avendo escluso la chiamata ordinaria di trackpageview, questo oggetto non traccia tutte le altre pagine, la home page ad esempio. Traccia SOLO i documenti, così possiamo fare analisi segmentata già dall’origine (ad esempio, gli arrivi da motore di ricerca ci indicheranno quali sono i documenti meglio indicizzati e per quali keyword).
Ecco un esempio di bacheca nel profilo copia di cui ho parlato:

Brian Clifton ha appena pubblicato una versione aggiornata del suo script per taggare automaticamente tutti i link in uscita, i download e i click sui mailto:, indirizzata a chi usa ga.js come codice di monitoraggio.

Il sorgente è abbastanza chiaro, per essere utilizzato dovete salvare quel file e personalizzare la variabile extTrack con il dominio (o i domini) su cui lo script è installato e che quindi saranno considerati “interni” e la variabile extDoc con le estensioni dei file da monitorare. La variabile extTrack è interesante, e ci permette anche di escludere dal tracciamento tutti i link verso un intero dominio esterno.
A quel punto dovrete includere nella sezione HEAD delle vostre pagine una riga come
<script type="text/javascript" src="addLinkerEvents-ga.js" />

Dopo di che la funzione va richiamata sull’onload del BODY, modificandolo come segue
<body onload="addLinkerEvents();">

Nei report i link esterni sono tracciati come pagine virtuali della cartella /ext/, i download come pagine virtuali della cartella /downloads/ e i clic sulle email come pagine virtuali della cartella /mailto/.

E’ una soluzione interessante che ci permette di automatizzare un lavoro fondamentale come il tracciamento dei download e dei click esterni, che incorpora una buona idea ma che ne manca completamente un’altra, anche se minore: nei prossimi giorni conto di segnalarvi una risorsa cui sto lavorando insieme a un amico che dovrebbe includere l’idea che manca allo script di Clifton. (eccola: the italian way)