Google Analytics in 30 secondi

Oggi è il giorno tanto atteso in cui Google ha introdotto ufficialmente un sistema per accedere ai dati di Google Analytics senza bisogno di aprire l’interfaccia. Ma non solo, poiché in realtà quello era già possibile usando un client Adobe AIR. Da oggi Analytics diventa più modulare, e in futuro vedremo fiorire applicazioni di terze parti che si appoggiano ai dati di GA e li integrano, o li mostrano sotto nuove forme.

Come avevo intuito tempo fa, esistono già aziende che hanno iniziato a sviluppare usando la API in preview: scorrendo l’elenco degli esempi (non più online ora) non possiamo fare a meno di notare Concentrateme di Juice Analytics, di cui vi ho parlato, oppure MailChimp, un altro strumento interessante il cui post è in bozza da mesi. Google ha dato loro un accesso privilegiato in modo da uscire oggi già con alcuni strumenti pronti e funzionanti, che possono motivare ulteriormente altri sviluppatori a gettarsi nella mischia.
Ad esempio, posso ipotizzare l’arrivo di CMS in grado di proporre automaticamente in prima pagina i contenuti più letti, oppure di comporre al volo una pagina con i contenuti più visitati da una determinata keyword se l’utente arriva con la medesima keyword. Non c’è quasi limite alla fantasia, una volta che si possono avere i dati a disposizione.
Un’altra cosa che mi aspetto di vedere quasi subito è un plugin di WordPress per aggiungere un pannello alla dashboard con l’andamento degli accessi presi da GA.

Tecnicamente è anche possibile “farsi un backup” dei dati contenuti in Google Analytics: attualmente il sistema ha un limite di 10.000 richieste al giorno, con un massimo di 100 ogni 10 secondi, e una singola richiesta non può tirare fuori una tabella con più di 1.000 righe, però un bravo programmatore può temporizzare le richieste e immagazzinare i risultati in un proprio database. Come dicevo ieri in chat con Andrea Serravezza, credo anche io come Ian Thomas che in futuro ga.js diventerà uno standard de facto di raccolta dati in web analytics, e l’arrivo di una API di esportazione dei dati è il primo passo della previsione in tre step di Ian. Il secondo passo è appena iniziato, e alcune applicazioni già esistono, per il terzo serve solo tempo. D’altronde l’infrastruttura di rete di Google è impressionante e difficilmente replicabile, quindi i grandi vendor potrebbero decidere di appoggiarsi ed estendere ga.js e usare le API per dare ai propri clienti viste personalizzate sui dati raccolti.

Il mio livello come programmatore purtroppo non è così avanzato da permettermi di sviluppare da solo applicazioni che si integrino con Google Analytics, ma la fantasia non mi manca, e le conoscenze nemmeno 🙂 Darò ugualmente un’occhiata alla documentazione, e chissà che non esca fuori qualche buona idea da sfruttare con l’aiuto di qualcuno di voi…

photo credit aussiegal on flickr

Non appena si è diffusa la voce che Google sta modificando le informazioni passate nei referrer delle ricerche (si veda anche Alessio Semoli) sono fioccate le supposizioni su cosa significhino i nuovi parametri che vengono inviati. Secondo la versione che va per la maggiore, il parametro cd= conterrebbe la posizione del nostro sito nelle pagine dei risultati del motore, consentendo di conoscere il posizionamento del sito per ogni chiave ricercata (e cliccata) dagli utenti.

Mi sono subito messo a scrivere un filtro per mostrare questa importante informazione nei report, ma mentre ero ancora nella fase di affinamento della regular expression (e bloccato soprattutto dal fatto che non ho ancora trovato un referrer “nuovo”) sul sito websharedesign.com è apparso il filtro fatto e finito. Diamo quindi a Cesare quel che è di Cesare, perché intanto stavo percorrendo la stessa strada ma ero solo leggermente più indietro.

Il filtro è di tipo personalizzato/avanzato, e ha i seguenti parametri:

Campo A -> Estrai A: Termine della campagna – (.*)
Campo B -> Estrai B: Referral – (\?|&)(cd)=([^&]*)
Output in -> Constructor: Termine della campagna – $A1 ($B2)
Campo A obbligatorio: SI
Campo B obbligatorio: SI
Sovrascrivi campo di output: SI
Maiuscole/minuscole: NO

Questo filtro presuppone che non abbiate campagne Adwords, e se le avete dovrete applicare un’altra procedura in due step.

Il mio consiglio è quello di testare il filtro su un profilo-copia per due motivi: il primo è il solito, ovvero evitare di distruggere dati di produzione ed essere sicuri che il filtro funzioni adeguatamente; il secondo è una domanda che ho postato nei commenti e che al momento è in moderazione: secondo me questo filtro porta ad una disaggregazione delle keyword di ingresso; se prima la keyword “hotel roma” era unica, applicando il filtro potremmo trovarci ad avere sia “hotel roma (5)” che “hotel roma (8)”, poiché è variata la posizione in SERP del nostro sito su una determinata parola chiave. In settori molto competitivi, come ad esempio il turismo, questo potrebbe portare ad avere risultati molto frammentati e la necessità di riaggregare in fase di analisi dati che lo erano già in origine prima di applicare il filtro.

Inoltre, come noto, gli utenti che fanno ricerche mentre sono loggati ad un Google Account visualizzano risultati differenti e personalizzati rispetto a chi non lo è (Google infatti mostra più in alto risultati che abbiamo già cliccato in passato): il rischio è che vi siano una moltitudine di parametri cd= differenti per query uguali, a prescindere dalla reale posizione nelle pagine dei risultati.

Concludo dicendo due cose: la prima è che il nuovo referrer è ancora in “fase sperimentale”, cioè ha iniziato ad essere inviato solo da alcuni server, e probabilmente ci vorrà ancora del tempo prima di vederlo all’opera (ovvero il filtro potrebbe non fornire nessun risultato anche se corretto). La seconda è che, naturalmente, siccome stavo lavorando su un mio filtro analogo non ho testato questo. Prendete la segnalazione così com’è 🙂

Brian Clifton ha scritto un interessante post sulla storia di Google Analytics, da quando esiste Urchin ai giorni nostri, passando per il lancio (disastroso sotto certi punti di vista) di novembre 2005 e per quelle che ha chiamato le fasi due e tre del progetto, ovvero la nuova interfaccia e il lancio delle funzioni enterprise. Se avete dieci minuti, è una lettura interessante.

Ma la parte che più stuzzica la nostra fantasia è la cosiddetta “fase quattro”, che molti sognano e io stesso in passato ho preconizzato, ovvero la fase dall’integrazione totale di Google Analytics con il resto dei servizi Google. L’elenco delle possibili integrazioni secondo Clifton va addirittura al di là delle mie più spinte previsioni, includendo

Website Optimiser, YouTube, AdSense, Google Trends/Insights, Feedburner, Gmail, Google Docs, Widgets/iGoogle, Google Alerts, Google Groups

Alcune di queste sono già possibili oggi (website optimizer, google docs) ma sono abbastanza semplici; Clifton in realtà parla di una piattaforma integrata dalla quale è possibile gestire e analizzare tutto il nostro insieme di attività con Google. In passato lo abbiamo chiamato Google Business Platform, e sebbene quelle di Clifton siano solo congetture non ufficiali, sapere che in passato è stato il direttore dell’area Europa, Asia e Medio Oriente non può che farci ben sperare sull’effettiva fattibilità di un progetto così ambizioso. Ovviamente lo sforzo per arrivare a un risultato simile sarà enorme – e infatti lui ipotizza “dal 2010 in poi” – ma la posta in gioco è enorme e voi tutti siete in grado di immaginare cosa questo potrebbe comportare per le nostre attività online!

Oggi voglio concedermi una digressione rispetto all’argomento principale di questo blog, e rendere onore al bollino verde che campeggia nell’header 🙂

Non so quanti di voi conoscano il gioco Unreal, sparatutto in soggettiva che insieme ai famosi colleghi Doom, Quake e Half Life ha fatto perdere molte ore di sonno a migliaia di persone, e non so quanti altri sappiano che il business dei motori che muovono questi giochi è molto sviluppato: quando una software house scrive un motore particolarmente performante o innovativo, lo rivende ad altre compagnie che ci sviluppano sopra i propri giochi risparmiando tempo e denaro. E’ esattamente il caso del motore Unreal Engine 3, che muove alcuni dei più noti sparatutto usciti nel corso del 2008.

Durante la Game Developer Conference 2009 la Epic Games, creatrice del motore, ha mostrato al pubblico Unreal MCP,

un sistema di visualizzazione dei comportamenti degli utenti che usano il gioco, che permette di capire cosa fanno esattamente i giocatori con il software, grazie a mappe di temperatura dell’attività degli utenti nei vari livelli del gioco

come dice Luca Chittaro dal quale ho appreso la notizia. Lui ed alcuni suoi colleghi avevano già esplorato la questione durante il 2003, ma è solo ultimamente che i “mondi virtuali” sono venuti alla luce, grazie soprattutto ai fenomeni Second Life e World of Warcraft. Guardando le immagini del post di Luca, che riporto qui per comodità, non ho potuto fare a meno di associarle alle heatmap che noi amanti della web analytics siamo soliti guardare, ad esempio in sistemi come CrazyEgg o all’analisi dei percorsi degli utenti all’interno delle pagine web.

Ho pensato che questa forse è l’alba di una sorta di Game Analytics, una disciplina che potrebbe analizzare i comportamenti degli utenti nei mondi virtuali, o più in generale nei giochi, in modo da carpire trend di utilizzo, bachi concettuali del programma e migliorare l’esperienza utente delle piattaforme esattamente come la web analytics ci aiuta a migliorare l’esperienza sui siti. Ad esempio posso ipotizzare tre scenari

• la software house monitora il comportamento degli utenti sulle varie mappe, e incrociando questi dati con gli accessi alle mappe stesse può essere in grado di dire quali sono le più e meno giocate, e dove gli utenti che vincono concentrano le loro attività. Può introdurre variazioni sulla mappa e registrare le modifiche del comportamento (una specie di split test A/B), oppure può capire se esistono punti del gioco che sono problematici per gli utenti.
• i giocatori, alla fine della loro esperienza, analizzano le heatmap e incrociano i propri movimenti – o quelli del proprio team – con quelli degli avversari, per capire le dinamiche di gioco ed affrontare le partite successive con azioni correttive. Se ad esempio si notasse che l’80% delle volte che un nemico ha attraversato un certo corridoio si è persa la partita, si potrebbe provare a presidiarlo meglio la volta successiva.
• qualcuno interessato alle posizioni degli utenti monitora tutto, per capire quali siano i punti più strategici del gioco, quello dove i giocatori stazionano per più tempo

ok, l’ultimo punto è volutamente criptico 🙂 Chi è che potrebbe avere interesse affinché gli utenti stazionino in determinate parti del gioco, in modo che si possano guardare in giro? magari qualcuno che ha interesse a piazzare cartelloni pubblicitari dinamici dentro ai giochi, magari proprio Google In-game Advertising. Magari non in giochi frenetici come gli sparatutto in soggettiva online, però è una possibilità da non sottovalutare.
Di conseguenza, se c’è da monitorare un rendimento servono dati, quindi tra qualche anno la Game Analytics potrebbe essere integrata nella web analytics, così come Adsense è integrato in Google Analytics (che nella versione americana permette anche di monitorare, lo ricordo, le campagne in televisione effettuate tramite AdWords TV ads).

Troppo visionario?

Juice Analytics, autrice dello script greasemonkey Report Enhancer di cui vi ho già parlato, ha deciso di trasformare il tutto in un comodo plugin per Firefox, attualmente ancora in fase sperimentale ma già liberamente scaricabile previa accettazione delle condizioni d’utilizzo.

Il passaggio da script a componente aggiuntivo è un passo importante, perché greasemonkey – diciamolo – è un oggetto abbastanza evoluto e che spesso spaventa un po’ i non addetti ai lavori. Le estensioni di Firefox invece sono più familiari, e inoltre ci sono meno clic tra la volontà dell’utente di avere le funzionalità e la loro effettiva disponibilità.

L’estensione non fa niente di diverso dallo script, anche se adesso il pulsante per attivare le righe aggiuntive di report è stato colorato di azzurro e spostato in alto, a fianco di “aggiungi alla bacheca”. Il pulsante è presente solo nei report “siti di riferimento” e “parole chiave”, esattamente come prima.

Il plugin è scaricabile da questa pagina del sito addons.mozilla.org e in combinazione con il plugin “better google analytics” (il plugin è stato dismesso dal suo autore) trasforma Google Analytics in uno strumento decisamente più potente. Sul mio greasemonkey rimane ancora uno script, e cioè GAREnhancer di ROI revolution, che speriamo venga anch’esso trasformato al più presto in plugin (e magari con la scelta di un nome che non lo confonda con gli altri due 🙂 )

Quando le cose da tenere d’occhio iniziano ad essere molte e variegate bisogna fare attenzione: Google Analytics fornisce gli strumenti, ma bisogna stare attenti a possibili effetti collaterali non documentati. Prendiamo ad esempio l’ultimo post di Lunametrics, che riporta una situazione con un codice di monitoraggio per più domini di questo tipo:

var pageTracker = _gat._getTracker("UA-xxxxxxx-y");
pageTracker._setVar(’buyer’);
pageTracker._setAllowAnchor(true);
pageTracker._setAllowLinker(true);
pageTracker._setAllowHash(false);
pageTracker._trackPageview();

questo codice inizializza l’oggetto di tracciamento, poi scrive nel cookie __utmz il valore buyer (ovvero assegna il visitatore al segmento compratori), poi permette l’uso del cancelletto nelle campagne, poi permette di trasportare il cookie da un dominio a un altro, disabilita il check dell’integrità dei cookie basato sul dominio (quando si raccolgono dati da più sottodomini in un unico account), e infine raccoglie i dati e li invia al server di Google.

Quale è il problema di questo codice? il problema è che _setAllowHash di fatto cambia il formato di scrittura del cookie, e ci sono due funzioni che scrivono cookie: _setVar che si trova prima di setAllowHash e trackPageview che invece si trova dopo.
In questo modo GA va in confusione e perde informazioni sulla sessione e sul referrer, assegnando a traffico diretto la seconda – falsa – visita.

La soluzione è quella di chiamare _setVar() sempre dopo _setAllowHash() (o _setDomainName(‘none’); se lo usate); bisogna sempre tenere presente che il javascript di Google Analytics ha a che fare con i cookie, e che alla fine sono loro che “comandano” quel che poi vediamo nei nostri report.

Quando fradefra, io e alcune altre persone diciamo che “la web analytics non dà risposte, ma genera altre domande” usiamo un misto di provocazione, boutade e verità. E’ chiaro che alcune risposte si possono avere, altrimenti fare analisi sarebbe sprecare tempo, ed è altrettanto chiaro che molte volte da una risposta nascono altre tre o quattro domande, spesso molto più interessanti della prima. Ma è un dato di fatto che in alcuni casi tutti noi prima o poi ci troviamo di fronte a fenomeni, numeri e grafici che sembrano non avere spiegazione, e che alcune volte proprio non la trovano.

Ve ne mostro uno:

Questo è il grafico dei soli accessi diretti di un sito il cui gestore mi ha chiesto “perché accade?”. In blu c’è il totale, in arancione i visitatori nuovi, in verde quelli di ritorno. A partire da inizio 2009 i nuovi visitatori smettono pesantemente di atterrare sul sito digitando l’url, usando bookmark o cliccando link da client di posta e affini, mentre i returning proseguono nelle loro solite attività. Francesco Gori, che ho interpellato in proposito, dice giustamente “sembra che prima ci fosse qualcosa offline che spingeva a visitare il sito, sembra il risultato di una campagna offline ben fatta”.
Il problema naturalmente è che non c’era nessuna campagna offline, e se anche ci fosse stata difficilmente avrebbe avuto tali proporzioni. Il resto del traffico è assolutamente normale, i referrer sono costanti e gli accessi da motore anche, anzi lievemente compensano. Il totale del traffico quindi è pressoché costante.

Ho guardato grafici, pensato e analizzato ma non sono giunto a nessuna conclusione. Ve ne parlo per due motivi: il primo è sapere se avete delle idee in proposito, e il secondo è sapere se siete d’accordo con me quando dico che non sempre c’è una risposta e/o se avete mai affrontato casi in cui non siete stati in grado di dare una spiegazione a fenomeni che avete monitorato con la web analytics.

Royal Pingdom, il blog ufficiale del servizio di monitoraggio dell’uptime dei siti pingdom, ha pubblicato un interessante post dopo aver condotto un test sui diecimila siti più popolari secondo la classifica di Alexa, trovando che almeno la metà di essi usa Google Analytics, e che il 40% di questi usa ancora il vecchio codice.

Si parla di grossi nomi come foxnews.com, wired.com, istockphoto.com, e ironicamente anche di blogger.com e doubleclick.com, che sono di proprietà di Google stessa. Dei 9758 siti che sono stati in grado di rispondere alle chiamate automatiche di pingdom.com, 4872 hanno lo script di GA sulla home page, e di questi 1992 ancora chiamano urchin.js, che è la vecchia versione dello script.

Questi siti, tra le altre cose, non possono avvantaggiarsi di una serie di funzionalità che sono specifiche di ga.js, la nuova incarnazione del javascript introdotta nel dicembre del 2007:

• logica ad oggetti
• interazioni più facili con elementi AJAX nelle pagine
• monitoraggio degli eventi
• un codice più leggero e veloce da eseguire
• auto riconoscimento del protocollo usato dalle pagine, se http o https

Stando alle informazioni disponibili, e a una frase di un Google Analytics Authorized Consultant nel post citato, il supporto al vecchio urchin.js cesserà in qualche momento durante l’estate, intorno ai famosi diciotto mesi proclamati quando venne introdotta la nuova versione.

Se nel vostro sito state ancora usando urchin.js, è bene sapere che probabilmente avete ancora solo tre o quattro mesi di tempo per migrare. Se fatta con le dovute cautele la migrazione è indolore, e vi permetterà di dimenticarvi della “dead line” di Google; inoltre avrete accesso alle nuove funzionalità. Anzi, la transizione potrebbe essere un buon momento per applicare tutte quelle piccole migliorie che avete letto in questo blog e che avete sempre rimandato per mancanza di tempo. Se il sito è generato dinamicamente da un sistema di gestione dei contenuti, ci sono buone probabilità che il vostro programmatore di fiducia sia in grado di effettuare la transizione in poco tempo, e spesso modificando un solo file. Se avete centinaia di pagine statiche in HTML, è adesso il momento buono per iniziare, giacché è possibile far convivere urchin.js e ga.js sullo stesso sito MA NON sulla stessa pagina.

In ogni caso avrete a che fare con la pagina ufficiale della migrazione, che vi linko per comodità

[edit 11 aprile: In questo post sul blog ufficiale Brett Crosby smentisce che urchin.js sarà dismesso durante l’estate, contraddicendo sia quanto venne detto all’introduzione del codice a oggetti sia quanto detto dal Google Analytics Authorized Consultant. Io continuo a rimanere dell’idea che compatibilmente con tempi e costi di ognuno sia bene migrare tutto a ga.js, e mi comporto di conseguenza con i clienti]

Una domanda che spesso mi sento rivolgere è come si cambi l’ordine dei filtri su Google Analytics. È in effetti una di quelle questioni che a prima vista sembrano banali, ma che ad un occhio meno esperto portano via abbastanza tempo.

Innanzitutto è bene ricordare che i filtri in Google Analytics sono delle operazioni che il sistema effettua sui dati in ingresso prima di processarli e memorizzarli nel database. Filtri basilari sono l’esclusione delle visite provenienti da un determinato IP, oppure l’inclusione di dati provenienti solo da una determinata cartella. Filtri di media difficoltà possono essere quelli che sostituiscono o raggruppano parte degli URL delle pagine, e filtri avanzati sono quelli che estrapolano parti di informazioni, le trasformano e le memorizzano per usi successivi.

Perché c’è un ordine nei filtri?

Perché è impensabile che possa esistere un filtro unico che faccia tutto quello di cui abbiamo bisogno, e perché alcuni dati richiedono più passaggi (cioè più filtri) prima di giungere alla forma di cui abbiamo bisogno. Ad esempio il filtro per ricostruire la pagina esatta delle SERP dei motori di ricerca da cui è arrivato il click dell’utente, nella sua forma avanzata, ha bisogno di almeno cinque passaggi prima di arrivare al dato definitivo. Ne consegue che in determinati casi l’ordine dei filtri attraverso cui il dato passa è importante o addirittura fondamentale per la buona riuscita dell’operazione.

Il problema di AND e OR

Le cose sono leggermente complicate dal fatto che i filtri più classici, quelli di inclusione e di esclusione, si comportano in modo leggermente differenti gli uni dagli altri. Più nello specifico, se il dato considerato combacia con un filtro di esclusione, esso viene “buttato via” e GA passa ad analizzare la hit successiva. Al contrario, se non combacia, GA trasmette il dato al filtro successivo, se ce n’è uno, oppure lo processa e lo memorizza. Quindi nel caso di più filtri di esclusione in cascata, se il dato combacia con uno solo di essi non arriverà mai in fondo al processo (si dice che i filtri di esclusione sottostanno alla logica dell’operatore booleano OR).

Viceversa i filtri di inclusione “buttano via” il dato se esso NON COMBACIA con le regole impostate nel filtro. Se vi sono più filtri di inclusione in cascata, il dato deve soddisfare TUTTI i filtri per poter arrivare in fondo al processo (in questo caso viene applicata la logica dell’AND). E’ utile un esempio pratico: un cliente attiva su un profilo-copia due filtri di inclusione: il primo controlla se la città di provenienza è Savona, il secondo se la città è Genova. In questo modo – pensa – includerà solo le visite delle persone di Savona e di Genova. Invece il profilo segna perennemente zero visite, perché in realtà il doppio filtro agisce sempre: se sei di Savona passi il primo filtro ma non il secondo, se sei di Genova non passi nemmeno il primo. Per passare la cascata, entrambe le condizioni dovrebbero essere verificate, il che ovviamente non è possibile.

La soluzione è aggiungere il segno pipe ( la barretta | che si ottiene con SHIFT+ backslash ) e fare un unico filtro di inclusione su

Savona|Genova

Come si varia allora l’ordine dei filtri?

Non si varia premendo “Gestione filtri” come quando se ne crea uno, e come molti credono. La gestione filtri è relativa all’intero account, tanto che quando se ne crea o modifica uno, è possibile dalla stessa schermata indicare a quali profili esso deve essere applicato. Ne consegue che la schermata è incentrata sul filtro e non sul profilo. Quando più filtri sono applicati ad uno stesso profilo, serve una schermata incentrata sul profilo. L’ordine dei filtri può dunque essere variato accedendo alla modifica del profilo, e poi cliccando su “Assegna ordine filtri” sopra all’elenco dei filtri applicati al profilo. Da quella schermata si potrà selezionare il filtro che deve essere spostato e tramite i pulsanti “sposta in alto” e “sposta in basso” potremo finalmente assegnare l’ordine corretto.

In figura una spiegazione visuale (clicca per ingrandire):

Se il vostro sito offre una funzione di invio degli articoli per email, ha una newsletter o semplicemente i vostri lettori usano segnalare pagine ad altre persone utilizzando la mail, è probabile che guardando il report “tutte le sorgenti di traffico” dentro a Google Analytics abbiate molte righe del genere:

wmail-new.libero.it / referral
webmailcommunicator.alice.it / referral
mail.google.com / referral
mail.tiscali.it / referral
it.mg40.mail.yahoo.com / referral
fastmail.fastwebnet.it / referral
it.mg41.mail.yahoo.com / referral
it.mc236.mail.yahoo.com / referral
co109w.col109.mail.live.com / referral
it.mc238.mail.yahoo.com / referral
co115w.col115.mail.live.com / referral
it.mc279.mail.yahoo.com / referral
by110w.bay110.mail.live.com / referral
by111w.bay111.mail.live.com / referral
by104w.bay104.mail.live.com / referral
webmail.interfree.it / referral

questo accade perché le webmail, specialmente quelle dei grandi provider che ne gestiscono decine di migliaia, risiedono su differenti server, e generano di conseguenza referrer differenti. Per ovviare a questo problema il blog francese wagablog.com propone un filtro avanzato di riscrittura, che permette di raggruppare le visite da uno stesso provider di posta elettronica.
Il filtro prende come campo A il “sorgente campagna” con espressione regolare:

mail(.*)\.(.*)\..{2,4}

Il campo B non è necessario.
L’output (il constructor) è lo stesso campo “sorgente campagna” con espressione:

webmail - $A2

In pratica effettua una sovrascrittura del campo eliminando le parti superflue, come il nome esatto del server della webmail. Non ho testato il filtro in sé, ma ho fatto parecchie prove con il mio programma preferito di test delle espressioni regolari, verificando che la regex è buona e funziona per bene anche con i provider italiani. Per i più curiosi, l’espressione regolare guarda dove vi sia scritto “mail” nel dominio, e raggruppa qualsiasi cosa vi sia da lì fino al dominio primario memorizzandolo dentro alla variabile $A1. Il dominio (con esclusione dell’estensione) viene estrapolato e memorizzato nella variabile $A2, che è poi quella che viene mostrata nei report.