Google Analytics in 30 secondi

Ieri Google ha diffuso la notizia che presto sarà possibile trasformare le web property dentro a Google Analytics in property che usano Universal Analytics. Fino ad ora infatti, per usare Universal era necessario aprire una nuova property, e avere un nuovo codice di monitaraggio.

Questo perché il processo di analisi dei dati raccolti da Universal è differente da quello “classico”, si tratta proprio di una linea differente. Fino ad ora, come detto, sono stati semplicemente gestiti come entità separate, mentre da ora in poi sarà possibile passare da Analytics classico a Universal (ma non tornare indietro) con una procedura di upgrade che si riassume in questo modo:

1) Trasferire la property a Universal: nel pannello di amministrazione comparirà una voce di menu specifica per l’upgrade, dalla quale si potrà comunicare a Google che si intende effettuare l’upgrade. E’ bene ricordare che alcune configurazioni, su Universal, si fanno dal pannello di amministrazione e non pià attraverso il codice di monitoraggio; ad esempio se avete aggiunto dei motori di ricerca tramite la funzione _addOrganic o se avete cambiato la durata di una visita tramite _setSessionCookieTimeout. Queste funzioni non esistono in Universal e vanno specificate tramite apposite sezioni del pannello di configurazione del tracking code

2) Ritaggare il sito, manualmente oppure usando un Tag Manager, per aderire alla nuova sintassi nel caso si usi analytics.js. Plus, a questo punto si può decidere di usare anche altre librerie per l’invio dei dati, ad esempio librerire scritte in PHP, Java e altri linguaggi (ce ne sono già parecchie in giro per il web) e di implementare il Measurement Protocol per abilitare l’invio di dati da qualunque “cosa” sia in grado di comunicare con il web: l’esempio classico sono le transazioni offline o le conversioni da call center.

Siccome si tratterà di un momento molto importante e delicato per tutti (si tratta pur sempre di un cambio di versione, ma in realtà si tratta di un cambio epocale di mentalità, per le possibilità che apre) vale sicuramente la pena di riportare qui alcune avvertenze da tenere bene a mente:

– Se iniziate il processo, non potete fermarlo o tornare indietro: una volta che si clicca il pulsante, l’upgrade inizia ed è irreversibile

– AL MOMENTO Universal Analytics non supporta le funzioni abilitate al momento da dc.js, quindi liste di Remarketing da Analytics, info demografiche, impressioni GDN o integrazione Doubleclick. Se usate una di queste funzionalità e volete continuare a farlo, NON DOVETE UPGRADARE fino a che esse non saranno supportate

– Le vostre variabili personalizzate non esisteranno più, e andranno sostituite con le Dimensioni personalizzate. La cattiva notizia è che dovrete cambiare un po’ la sintassi e lavorare un pochino anche sul pannello di amministrazione, quella buona è che invece di 5 variabili personalizzate adesso avete 20 custom dimensions (e anche 20 custom metrics 🙂 )

– L’upgrade va fatto per PROPERTY (per un ripasso di cosa sia una property rispetto a un profilo o un account vi rimando a questo mio post ), quindi va ripetuto per ogni codice UA-xxxxxx che desiderate migrare

– L’ordine dei passi è importante: PRIMA si fa l’upgrade della property e DOPO si cambia il tagging. Se cambiate prima il tagging i dati inviati non saranno processati (state inviando dati in forma “universal” a una linea di analisi classica). Il contrario invece è supportato, ed è infatti come deve avvenire il processo

C’è ancora una nota interessante riguardo all’ultimo punto qui sopra, ed è contenuta in una delle FAQ:

If you send data to a Universal Analytics property using a classic Google Analytics collection method (like the ga.js JavaScript library), your data will be processed during the phases of the upgrade. Your data will not be processed, however, after the classic Google Analytics libraries and SDKs have been deprecated.

Come abbiamo detto, inviare dati dal tagging classico a una property Universal è consentito, ma solo durante la fase di upgrade. Tra le righe lì c’è scritto che prima o poi le librerie classiche saranno deprecate, e i dati non saranno più analizzati. Che sia la “fine finale” del tracking con urchin.js?

La classifica Fortune500 elenca le prime cinquecento compagnie statunitensi in ordine di fatturato. Viene redatta ogni anno dalla rivista Fortune (ma va? 🙂 ) ed è da sempre considerata un indicatore abbastanza valido: entrare nella classifica Fortune è fonte di grande prestigio per le aziende.

E-nor, uno dei più grandi GACP americani, ha preso i siti principali delle aziende della Fortune 500 di quest’anno e ha controllato quali strumenti di web analytics usano: il 63,2% usa Google Analytics, il 25,4% Adobe, il 14,8% Webtrends. (in realtà il post di E-nor si apre con una disquisizione sulla posizione che sta assumendo Google Analytics Premium; in realtà “da fuori” non c’è modo di sapere se un Analytics è free o Premium, a meno di non avere la fortuna di imbattersi in configurazioni che esplicitamente usano più di 5 variabili personalizzate – o 20 dimensioni personalizzate).

Questa percentuale è in salita costante: nel 2011 era il 45%, l’anno scorso era il 51%, ora siamo al 63%. In particolare il trend dei singoli strumenti vede GA in crescita del 24% rispetto all’anno scorso, Adobe digital marketing suite in calo dell’1,6%, Webtrends in calo dell’8,6%. Prodotti IBM sono in progressione del 21%.

Sebbene questi numeri non rappresentino trend costanti e mondiali, sapere che il 63% delle top 500 aziende USA si affida (anche) a Google Analytics da una prospettiva di un certo tipo rispetto a chi ancora lo considera “un giocattolo”.

In passato abbiamo parlato di siti come gacrowd.com o customreportsharing.com, che mettono a disposizione della comunità dahsboard, segmenti personalizzati e custom report. Siccome l’idea è buona, e siccome la community intorno a GA è molto grande, ora è possibile fare la stessa cosa direttamente da dentro all’interfaccia di Analytics, e la solution Gallery è stata rifatta.

Quando si condivide qualcosa, ad esempio una dashboard, è possibile condividere il link al template che costruisce una dashboard uguale, oppure la si può mandare alla Solution Gallery. Qui essa potrà essere valutata dagli altri utenti, potrà ricevere una categorizzazione e sarà a disposizione della comunità, che a sua volta potrà importarla attraverso l’apposito tasto. Stessa sorte anche per i segmenti avanzati e i custom report. In futuro, dice il post ufficiale, sarà probabilmente possibile esportare ed importare anche raggruppamenti di canali personalizzati, modelli di attribuzione e tutte le altre modifiche che ha senso si possano condividere.
Anzi, in realtà in un post successivo il primo passo è già stato annunciato: è adesso possibile condividere con un link sia i modelli di attribuzione sia i custom channel grouping

E’ inoltre possibile condividere anche dei “pacchetti” (bundle in inglese) di queste tre cose: ipotizziamo che abbiate due dashboard SEO, tre segmenti SEO e un custom report molto bello orientato sempre orientato all’ottimizzazione organica. Per creare un bundle dovete cliccare su Amministrazione, in alto a destra, poi su Condividi gli Asset, in basso a destra nelle risorse personali della vista corrente, poi selezionare tutto quel che volete finisca nel bundle e infine cliccare su Condividi e su Galleria Soluzioni: dovrete dare un nome a voi stessi, al bundle, dare una descrizione e assegnare le categorie.

Il rilascio graduale dell’annunciata ristrutturazione dei report di traffico sta procedendo, e ormai molti di voi li possono già vedere e usare. E’ quindi il momento di venire in aiuto di chi fra voi si trova più spaesato da uno dei più grandi cambiamenti che quella serie di report abbiano avuto.
Partiamo dall’ABC, come si suol dire (ok lo confesso, sono mesi che medito questo sottile gioco di parole in questo post 😛 ), ovvero come bisogna pensare e guardare i nuovi report: in passato avevamo il gruppo di report Sorgenti di traffico, il gruppo Contenuti e il gruppo Conversioni. Ogni gruppo conteneva specifici report, ognuno con le metriche tipiche, fatta salva la possibilità di personalizzazione degli stessi.

Il concetto dietro ai report ABC (Acquisition, Behaviour, Conversion) è quello di replicare nello strumento il flusso ideale di un visitatore: prima di tutto lo si deve Acquisire, cioè far arrivare sul sito, poi lui avrà un comportamento, che va studiato al fine di farlo giungere a una conversione. Questo concetto di “flusso” viene espresso in due direzione nel “nuovo” Analytics, verticale e orizzontale (clic per ingrandire)

In verticale, il gruppo di report Acquisizione contiene tutti i report relativi a come i visitatori arrivano sul sito, quindi il nuovo report dei canali (ne parliamo tra poco), il vecchio “tutto il traffico”, le campagne, le keyword (residue), i report social e Adwords e le altre forme di pubblicità. Il gruppo Comportamento invece contiene i report relativi a cosa avviene sul sito, quindi contenuti, velocità del sito, ricerca interna, eventi, AdSense, Esperimenti. Infine il gruppo Conversioni contiene tutti i report relativi ai goal, i modelli di attribuzione e il multichannel funnel, questi in effetti non sono cambiati.

Analizzando in orizzontale la nuova struttura di tutti i report, troviamo lo stesso concetto segmentato per i soli dati mostrati dal report; quindi il report di AdWords mostrerà come prima le sole visite da campagne cpc, mostrando sulla stessa riga metriche di Acquisizione (visite, % nuove visite e numero di nuove visite), di Comportamento (bounce rate, pagine/visita e durata media) e Conversioni (tasso di conversione, numero di goal raggiunti (finalmente! 🙂 ) e valore del goal. Questa sezione di tutti i report si può personalizzare, ovvero è possibile scegliere se mostrare le metriche per un solo goal, per tutti i goal o per l’ecommerce se configurato sul sito).

A mio avviso si tratta di una razionalizzazione molto importante, che pone un forte accento sull’analisi del flusso di utenti che arrivano (o non arrivano) alla conversione.

Come se non bastasse però, all’interno del gruppo di report Acquisizione, abbiamo anche l’introduzione di un nuovo concetto, e di un nuovo report: il concetto è quello dei Canali, il report è la panoramica dell’Acquisizione.

Che cosa sono esattamente i canali, e come si usano?

I canali sono dei raggruppamenti automatici di visite, accomunati da alcune caratteristiche; il concetto alla base di questa strutturazione e di questo report, se vogliamo, sembra controintuitivo rispetto a quanto abbiamo sempre detto in passato, ma in realtà è un concetto in affiancamento. Per anni io e molti altre persone abbiamo stressato le persone affinché taggassero tutte le loro campagne per bene, ordinatamente e nel modo più preciso possibile: alcune volte ho visto risultati addirittura esagerati, con taggature atomiche che costringevano a ri-raggruppare visite con filtri di visualizzazione, espressioni regolati ed export. In ogni caso che cosa si è visto in questi anni? che le combinaizoni di mezzi, campagne e sorgenti di traffico sono diventate tantissime, centinaia, a volte migliaia in alcuni account, e che alla fine spesso tutto si traduceva in una difficoltà di fare analisi ad un livello alto.
Per questo motivo gli ingegneri hanno introdotto il concetto di Canale, per affiancare al report “tutto il traffico” (che è ancora presente, in ogni caso) un report più snello che consentisse di avere il polso della situazione di salute del sito con poco sforzo.

Se non avete toccato niente, come spero, i canali che troverete all’interno del vostro Google Analytics sono questi, con le relative definizioni:

• Direct: source = direct AND medium = (not set), OPPURE medium = (none)
• Organic Search: medium = organic
• Referral: medium = referral
• Email: medium = email
• Paid Search: medium corrisponde a regex ^(cpc|ppc|paidsearch)$ AND Ad distribution network diverso da Content
• Other advertising: medium corrisponde a regex ^(cpv|cpa|cpp|content-text)$
• Social: social source referral = Yes, OPPURE medium corrisponde a regex ^(social|social-network|social-media|sm|social network|social media)$
• Display: medium corrisponde a regex ^(display|cpm|banner)$, OPPURE Ad Distribution Network = Content AND Ad Format diverso da Text

I canali e gli istrogrammi si riordinano automaticamente agendo sulle intestazioni delle colonne, mentre cliccando su un canale si accede al dettaglio delle visite che sono state assegnate a quel canale: è da qui che bisogna passare se si vuole accedere, per esempio, al vecchio report del traffico diretto che adesso non gode più di una voce dedicata nel menu laterale.

Come avrete già intuito la vera potenza dei channel è la possibilità di personalizzazione: attraverso l’apposita voce nella panoramica, o comunque attraverso l’interfaccia di amministrazione, si accede a una schermata del tutto simile a quella dei canali delle canalizzazioni multicanale – solo meno colorata 🙂 – che permette di aggiungere propri canali o modificare quelli esistenti. Se ad esempio siete soliti taggare le newsletter con il medium “mail” anziché il predefinito “email” avrete bisogno di aggiungere una regola di questo tipo

(naturalmente è possibile ottenere lo stesso risultato anche in altri modi).
Se avete notato, prima ho detto che spero che non abbiate ancora toccato niente. Questo perché i nuovi canali hanno alcune restrizioni che vi vado ad elencare, è che è bene conoscere prima di agire:

1. L’ordine dei canali è importante: per decidere in quale canale infilare una visita, Google Analytics analizza le corrispondenze in ordine discendente, partendo da 1 (quindi direct, nelle impostazioni di default): se una visita può ricadere in più condizioni, vince quella con il numero minore.
2. I canali esistono dal 25 luglio, quindi non potete vedere i dati tramite i canali per tutto il 2013, ne tantomeno fare comparazioni tra canali su periodi che sforano all’indietro quella data. Non ci è dato sapere se Google procederà ad un allineamento dei dati passati, la mia personale opinione è no.
3. Le modifiche che apportate ai canali valgono per tutti gli utenti che hanno accesso ai profili. Non si tratta di una personalizzazione, come una dashboard, che vive nel proprio account fino a quando non la si condivide. Una modifica in questo senso va vista alla stregua di un filtro di profilo. Attenzione!
4. Le modifiche apportate a un canale, esattamente come quando si agisce su un filtro, sono operative da quando si salva in avanti. Assicuratevi quindi di fare modifiche che vi permettano di mantenere la possibilità di fare comparazioni con il passato, e soprattutto di non sbagliare qualcosa nelle configurazioni.

L’altro nuovo report disponibile è quello dei canali, ovvero un report “tradizionale” che però mantiene i raggruppamenti e vi permette ad esempio di applicare una dimensione secondaria ai canali, di fare ricerche e di segmentare per metrica.

In conclusione ritengo che il concetto di report ABC (o ACC in italiano, ma preferirei che si diffondesse la dizione inglese) sia un buona passo in avanti nell’analisi del dato perché presenta un’immagine più completa di prima delle tre fasi critiche di una visita; inoltre i nuovi canali sono un metodo molto potente per avere insights veloci sullo stato di salute del sito, senza per questo rinunciare ad avere la possibilità di andare subito nel dettaglio per approfondire.
La vostra opinione quale è?

Quando dico che ormai gli annunci di novità sul prodotto si susseguono a ritmo forsennato, la maggior parte di voi immagina uno o due novità al mese, abituati come eravamo fino a qualche anno fa quando si stava anche mesi “in tranquillità”. Ma che ingegneri Google sarebbero, se non tenessero conto preciso di quel che fanno? durante il keynote di apertura del Google Analytics Summit – che è stato trasmesso in diretta streaming – hanno dato il numero esatto delle novità introdotte dallo scorso Summit: 70.

E per non farsi mancare niente durante lo stesso keynote ne hanno annunciate altre 14, che vado a riportarvi qui linkando ove già presenti i post ufficiali:

1. Auto Event Tracking per il Tag Manager: un sistema per far sì che pressoché qualsiasi cosa sia tracciabile dal Tag Manager senza bisogno di far inserire codice in pagina. Le potenzialità sono enormi, l’ho provato brevemente nella sua forma base e sto fantasticando di usi incredibili 🙂
2. SLA sul Tag Manager per clienti Premium: se un cliente Google Analytics Premium si vuole affidare a GTM, adesso è presente anche un Livello Minimo di Servizio, per essere sicuri che i propri tag siano sempre “consegnati” correttamente.
3. Processo di upgrade delle web property a Universal Analytics: ovvero la possibilità di passare a Universal senza dover creare un nuovo codice di monitoraggio, novità attesa a lungo da molti.
4. API per enterprise: si tratta di un set nuovo di API che consentono di automatizzare i processi di creazione di account, property e view e anche utenti, delegando il tutto a uno script invece che a un processo manuale. Un salvagente incredibile quando si opera in contesti con centinaia di siti e di utenti, con permessi incrociati…
5. report ABC: rimpiazzeranno completamente i report del traffico attuali, secondo la logica “acquisizione, comportamento, conversioni”. Le attuali fonti di traffico, granulari, potranno essere raggruppate logicamente in “canali”, sui quali l’utente avrà il pieno controllo. Di questi sarà necessario fare un post a parte appena saranno lanciati, perché rappresentano una novità molto grossa e che va maneggiata con cura.
6. Nuovi segmenti: in realtà una nostra vecchia conoscenza, non so esattamente perché li abbiano spacciati per nuovi. (forse per non fare 13 annunci 😛 )
7. Audience reporting: altra novità molto grossa, si tratta di report che mostrano età, sesso e interessi dei navigatori, in modo che sia poi più efficace creare target sul Google Display Network
8. Dati demografici nei segmenti unificati: la naturale conseguenza del punto precedente, è la possibilità di creare segmenti usando i dati demografici appena introdotti.
9. BigQuery integration: esce dalla beta questa integrazione, presentata già allo scorso Google I/O. Limitata ai clienti Premium, ho visto la demo ed è IMPRESSIONANTE (oltre che essere una cosa maneggiabile solo da esperti/nerd/geek): si tratta di esportare i dati da Google Analytics su Big Query, integrarli eventualmente con dati proprietari, ed interrogarli in qualsiasi modo possibile con un linguaggio molto simile a SQL. La demo vista al Summit era paurosa!
10. integrazione con DCM: DCM è il DoubleClick Campaign Manager, cioè il prodotto per la gestione delle campagne Display su DoubleClick. L’integrazione con GA Premium apre un ventaglio di scenari ampissimo, tutti estremamente interessanti, e a mio avviso si tratta della più forte integrazione tra strumenti Google e GA mai fatta dai tempi di AdWords.
11. Dati della rete Display in MCF e Attribution: Al pari dell’annunciata integrazione con il display AdWords, anche i dati Doubleclick finiranno nei Multi Channel Funnel, e anche nei modelli di attribuzione, permettendo di avere una visione completa sulle interazioni dell’utente anche in assenza del clic e della visita.
12. Integrazione con Google Play: anche questa mostrata al Google I/O, sarà disponibile per tutti a breve. Permetterà di controllare quali fonti di traffico portano visite alla pagina dell’applicazione sul Google Play, quante view fa la pagina, quanti install vengono fatti (e da quale sorgente) e di legare ogni installazione alla fonte originaria, attribuendo poi goal e revenue in-app a quella sorgente.
13. GA Academy: un progetto di education targato Google/Justin Cutroni che mira a diffondere le corrette basi della cultura della digital analytics, soltanto in parte declinata sullo strumento Google
14. Help in linea nel prodotto: una serie di aiuti direttamente dentro all’interfaccia, per non perdere il focus sulle analisi e avere risposte veloci e rapidamente.

Se vi siete persi il keynote, è stato postato sul canale Youtube ufficiale. Eccolo:

Come nota conclusiva, sono stato contento di aver finalmente conosciuto di persona alcuni nomi della bella community che gira intorno a Google Analytics: Phil Pearce, Julien Coquet, James Standen di Analytics Canvas, ma non solo ovviamente, e aver avuto la possibilità di parlare con alcuni degli ingegneri che plasmano ogni giorno il prodotto: sono persone che sanno davvero ascoltare se hai un’idea, e se è valida la portano realmente all’attenzione del resto del team. Sembra una cosa banale, ma non è affatto così scontata…

Alla fine è arrivato il fatidico giorno, il “giorno dell’apocalisse SEO” predetto da quell’Ottobre 2011, quando Google iniziò a eliminare le keyword passate negli url referrer per gli utenti loggati ad uno dei suoi servizi. La percentuale dei (not provided) – questo il cappello che racchiude tutte le visite SEO senza keyword in chiaro – è andata via via crescendo di mese in mese, e da qualche settimana è schizzata in alto, come conferma il sito notprovidedcount.com.

La motivazione ufficiale è che adesso Google ha forzato le ricerche su protocollo SSL anche per i non loggati, la realtà (come ha scritto su Google plus il buon Enrico Altavilla) è che Google ha semplicemente smesso di passare la keyword, togliendola da suo primo redirect interno: altrimenti non si spiegherebbe come mai le keyword sono perse anche nei passaggi SSL -> SSL, che invece teoricamente dovrebbero preservarle.
Comunque sia, presto il report delle keyword conterrà l’unica chiave (not provided) nel 99% dei casi di visite da Google, e quindi perderà il suo peso per l’analisi disaggregata di quei visitatori, a meno che non si intervenga con dei filtri per spostare il focus sulla landing page, ad esempio.

La lamentela che sento andare per la maggiore è relativa al fatto che le query di ricerca sono ancora passate quando si clicca un annuncio pubblicitario; questo viene visto come una mossa di Google per vendere più pubblicità AdWords. Può anche darsi, ma vorrei esporre un ragionamento – del tutto personale – rispondendo alla domanda come farei io se fossi Google:

il problema “di sicurezza” non è tanto se dare o non dare la chiave, ma QUANDO dare questa chiave. Posto che quando nel 2011 Google iniziò a oscurare le keyword qualcuno dimostrò fisicamente che era possibile risalire a nome e cognome delle persone loggate, nel momento in cui il click viene fatto e il referrer è passato al client c’è effettivamente questa possibilità: la visita, l’identità e la keyword sono nello stesso istante nello stesso browser.
Nel momento in cui invece viene cliccato un annuncio AdWords, viene passato solo un gclid, totalmente anonimo. In modo asincrono poi Google prende quel gclid e interroga AdWords, facendosi restituire la keyword comprata, e di contorno anche quella ricercata. In tutto questo passaggio – che peraltro avviene non nel momento della visita e avviene completamente lato server – l’identità e i cookie del visitatore non sono tirati in ballo. Quindi secondo me, almeno da questo punto di vista, la posizione di Google è legittima.

Detto questo anche a me dispiace che il report delle keyword diventi inutile, quantomeno perché ciò inficia sulla valutazione delle performance di brand. Ho sentito proporre anche cose fantasiose tipo “Google dovrebbe criptare le keyword in hash alfanumerici, in modo da preservare la disaggregazione quantitativa tra le chiavi”, ma se posso vedere la query iniziale e il risultato criptato, a lungo andare l’algoritmo può essere scoperto, e ovviamente cambiarlo porterebbe all’impossibilità di comparare i risultati su archi temporali lunghi.

Quindi temo che a meno di cambi di idee dell’ultimo minuto, dovremo tutti farcene una ragione 🙁

Tutto si può dire del team di Google Analytics tranne che non ascoltino gli utenti, su questo spero che converrete con me. Quando fu chiaro che l’algoritmo dei content experiment non distribuiva in modo uguale il traffico sulle variazioni (se vuoi più dettagli avevo scritto un articolo apposta) le persone chiesero a gran voce un modo per tornare al classico modello di Google Website Optimizer, cioè quello con traffico ripartito 50/50 – per 2 variazioni – 33/33/33 – per tre variazioni – e così via…

Detto fatto, da qualche settimana nella creazione di un esperimento esiste un’opzione apposita che consente di controllare quell’aspetto. Inoltre per chi ha collegato il proprio account AdSense, la revenue dei clic sugli annunci può ora essere impostata come il goal dell’esperimento.

Altra notizia che farà felici le aziende più esigenti in termini di sicurezza del dato è che Google Analytics e il fratello maggiore Google Analytics Premium hanno ottenuto la certificazione ISO 27001, uno standard internazionale che attesta che l’intero processo di gestione e sicurezza del sistema è studiato e realizzato a regola d’arte. Il processo include gli aspetti logistici, fisici e organizzativi che sono alla base della sicurezza delle informazioni memorizzate nel prodotto.

Infine il Summit: il Google Analytics Partner Summit è stato per anni l’evento più “cool” e supersegreto del mondo che ruota intorno a GA: non se ne sapeva nulla, ne prima ne dopo, se non qualche post con racconti di contorno e d’atmosfera sulla vita nel campus di Google.
Poi, probabilmente convinti dal successo dell’organizzazione di eventi come il Google I/O, l’anno scorso la prima giornata fu “aperta” a tutti tramite condivisioni sui social network e annunci pubblici: fu durante lo scorso Summit che venne annunciato Universal Analytics, e la cosa ha riempito le tastiere della community per giorni e giorni 🙂
Quest’anno il team di Analytics vuole andare oltre, e insieme all’apertura ai social della prima giornata aggiunge il live streaming dei keynote iniziali: orologi sincronizzati quindi sulle ore 18:00 di martedì 1 ottobre 2013, quando Paul Muret salirà sul palco e darà il via al Summit 2013, che si intitola quest’anno “Access, Empower, Act” e troverà spazio sui social network con l’hashtag ufficiale #GASummit. Se avete il dubbio che possa non valerne la pena, vi incollo questo pezzo di post ufficiale: “You will learn about new products we’re launching” 🙂
Se non volete essere “bloccati” davanti allo schermo dallo streaming e preferite seguire in modo più leggero, sono certo che Twitter potrà compensare piuttosto bene (@goanalytics è il mio account, casomai volessi i miei pareri a caldo sugli annunci 🙂 )

[a proposito: se usate Internet Explorer 8, sappiate che da fine anno l’interfaccia di GA non vi funzionerà più. Aggiornate a una versione più recente!]

Sin da quando il Google Tag Manager ha fatto la sua comparsa nel panorama web, una delle critiche maggiori che gli è stata mossa era “eh, ma non ci posso mettere il tag xyz”. Non perché il GTM sia uno strumento su misura solo per i tag di Google – anche se ovviamente questi hanno dei template già pronti – quanto perché una delle restrizioni maggiori era data dal fatto che il codice del tag manager agisce in modo asincrono: ovvero viene eseguito “quando si può”, indipendentemente dallo stato di caricamento della pagina.

Questo determinava l’impossibilità di usare, all’interno dei custom HTML tag, codici che contenessero la direttiva “document.write”, che invece agisce in modo sincrono modificando l’output generato dal browser per inserire “pezzi” a partire da istruzioni javascript. Quasi tutti i pixel di tracciamento usano document.write per fare i tracciamenti, e fino a ieri non si potevano inserire nel GTM.

Da qualche giorno invece quando si crea un custom HTML tag esiste una checkbox – opzionale – che permette proprio di inserire codici con document.write nel tag manager. Quale tipo di “magia” tecnica ci sia dietro non me lo chiedete, non arrivo così in là con la comprensione di queste cose, ma da qualche test veloce sembra funzionare come ci si aspetta: in ogni caso tenete presente che si tratta di una funzione NUOVA, e che la dovrete usare a vostro rischio e pericolo.

Un’altra novità riguardante il tag manager è l’introduzione delle custom javascript macro, ovvero macro che non dipendono più dalla presenza o meno di un valore all’interno di URL, dataLayer, variabili o testo della pagina, ma che consentono di scrivere funzioni che dato un valore in ingresso lo elaborano e restituiscono un valore in uscita: questo consente tra le altre cose di aggiungere della “logica” (se… allora…) a uno strumento che fino ad ora ne era sprovvisto, e di fare tante altre cose carine che sto sperimentando in questo periodo 🙂

Infine una nota di colore: la settimana scorsa sono incappato in un errore strano facendo delle prove con Tag Manager, e non trovavo bibliografia in merito. Prova e riprova non ne venivo a capo, e quindi ho fatto una segnalazione: si trattava in effetti di un baco (o meglio di un caso particolare che generava un problema). La cosa è stata risolta in pochi giorni, e devo dire che mi ha fatto piacere sentirmi parte del continuo miglioramento di uno strumento che sta aiutando moltissime aziende e persone a velocizzare tantissimo i processi interni di gestione e delivery dei tag, e quindi ad avere risposte dagli strumenti in tempi incredibilmente ridotti!

EDIT, pochi minuti dopo: siccome le novità non sono mai troppe, apprendo or ora che esiste anche una V2 del dataLayer, impostabile quando si crea una macro, che consente di accedere ai valori nidificati tramite notazione javascript standard. La frase di help esatta è:
“Versione 2: i punti accedono a valori nidificati. I valori inviati al livello dati contenente punti nel nome verranno considerati valori nidificati in base alle regole JavaScript standard.”
Su questo però devo fare prima dei test, perché l’ho appena vista anche io 🙂

Chi ha configurato la ricerca interna sul proprio profilo (anzi, sulla propria VISTA, che è il nuovo nome dei profili) sa che Google Analytics chiede una e una sola cosa per capire se si tratta di una ricerca interna: il parametro dell’URL che contiene il termine ricercato.
Se ad esempio la vostra ricerca interna produce pagine di risultato come questa

/search/search.asp?txtsearch=genova

basta impostare “txtsearch” nella casella apposita e il report della ricerca interna inizierà a popolarsi. Ma cosa succede se il vostro CMS produce url più “SEO friendly” e quindi scrive cose tipo

/search/search/genova ?

Non c’è nessun parametro da indicare. In passato eravamo costretti a produrre un’altra pagina – virtuale – oppure a riscrivere completamente la pagina corrente per venire incontro alle ridotte capacità di questa parte dello strumento; questo perché, incredibile ma vero, NON SI PUO‘ fare un filtro search&replace sull’url, perché il sitesearch interviene PRIMA dell’applicazione dei filtri.

Però qualche tempo fa c’è stato un corposo aggiornamento dei campi filtro disponibili, e tra questi c’era anche il Site Search, che fino ad allora non era invece presente. Alcuni volenterosi, tra cui Lunametrics, si sono messi a fare prove e sono giunti alla conclusione che adesso le cose si possono risolvere più elegantemente di prima.

Sarà sufficiente fare un filtro personalizzato avanzato del tipo

Campo A -> Estrai A | URI della richiesta | /search/seach/(.*)
Campo B -> Estrai B VUOTO
Output in -> Constructor | Termine di ricerca | $A$1

Campo A obbligatorio SI
Campo B obbligatorio NO
Sovrascrivi campo output SI
Maiuscole/minuscole NO

Ovviamente la vostra espressione regolare per il Campo A dipende strettamente dalla vostra struttura degli URL, il mio è solo un esempio. Ma una volta fatto questo, il vostro report delle ricerche interne verrà popolato. Se il vostro sito usa anche le categorie di ricerca, potete fare la stessa cosa, con un altro filtro, per popolare la “Categoria di ricerca su sito”.

Come dicevo nel post precedente, anche durante la settimana di Ferragosto il team di Google Analytics non riposa, ed in effetti ci sono state un po’ di novità sugli strumenti che usiamo tutti i giorni. Iniziamo dai post apparsi sul blog ufficiale:

• Tag Manager Mobile e GA Services SDK: vi avevo già parlato del Tag Manager per applicazioni mobile in occasione della sua presentazione al Google I/O 2013. E’ venuto il momento di farlo conoscere al grande pubblico e il blog ufficiale ce ne da riscontro. Degli indubbi vantaggi che esso apporta ad una applicazione mobile vi ho già detto (vi ricordo solo la killer feature di bypassare le richieste di ripubbliccazione agli store), mentre una novità è che da adesso gli SDK di Analytics e del Tag Manager sono racchiusi in un unico set di files, chiamato Google Analytics Services SDK. Questo significa che importare il file nel progetto consente di utilizzare sia GA sia il Tag Manager Mobile.
• Data Driven Attribution Tool (Premium only): si tratta di un sistema automatizzato di analisi del miglior modello di attribuzione disponibile in base ai dati presenti nel proprio account. Fino ad ora il Multi Channel Funnel e i modelli di attribuzione ci hanno aiutato a capire meglio il cosiddetto customer journey, ma si trattava pur sempre di rendicontazione di qualcosa che accade. Questo nuovo set di tool si spinge oltre, e permette di esplorare le variazioni basando le sue decisioni su algoritmi e probabilità di conversione. Una volta definito il proprio goal, il modello analizza i path di conversione e crea il “modello ideale” di attribuzione, e lo aggiorna con regolarità, permettendo anche di confrontare i risultati del modello automatizzato con uno dei modelli predefiniti disponibili nel sistema. E’ disponibile soltanto ai clienti GA Premium
• Metadata API: si tratta di un nuovo set di API, in grado di semplificare la vita a chi usa le API 🙂 sembra un gioco di scatole cinesi, ma in effetti non lo è. Al momento, se Google rende disponibile una nuova metrica o dimensione attraverso le API lo sviluppatore di un tool deve prima sapere che questo è accaduto e poi modificare la sua applicazione di conseguenza. Se è un servizio web gli utenti sono facilitati, se si tratta di un software si rende necessario far scaricare una nuova versione. Usando le Metadata API questo fatto verrebbe automaticamente esposto all’applicazione, che potrebbe semplicemente leggere il nuovo valore, il suo nome e i suoi attributi ed essere programmata per esporre sempre tutti gli attributi presenti. Faccio un esempio pratico: per una certa dimensione GA mi permette di fare query su 3 diverse metriche. L’applicazione visualmente me le propone. Google espone nelle API una nuova metrica per quella dimensione. Dopo aver fatto “un giro” con le metadata API l’applicazione mi presenta automaticamente anche la quarta metrica come disponibile per quella dimensione. Si tratta di un’automazione molto importante affinché le applicazioni che si basano sulle API siano sempre aggiornate. E’ una innovazione talmente importante che Google ha deciso di applicare una nuova policy di deprecation ovvero di cessazione del supporto a cose obsolete riguardante le API: se qualcosa viene deprecato le metadata API restituiranno DEPRECATED per almeno 6 mesi, e poi BAD REQUEST, consentendo anche in quel caso di aggiornare le applicazioni in modo automatico
• Supporto document.write nel Tag Manager: da qualche giorno utilizzando un tag HTML custom nel Tag Manager appare la scritta “Supporto document.write. Google Tag Manager offre un nuovo motore sperimentale per il rendering dei tag HTML personalizzati. Include un supporto per le chiamate a document.write()”. Questa cosa era impossibile sino a qualche tempo fa, ma è molto importante perché di fatto consente di infilare dentro al Tag Manager qualsiasi tag, anche quelli che fino ad ora si era detto che non si potevano inserire perché – appunto – ristretti dal fatto che contenessero una direttiva document.wirte. Va notata la parola “sperimentale”, quindi usate questo tipo di tag ancora con cautela; come tutte le novità è bene fare delle prove prima di mandare cose in produzione 🙂