Aug 29 2016

HelpSemaforoQuesto semaforo indica il livello difficoltà del post
semaforo rosso - articolo per esperti

Tag Manager diventa grande: ecco i workspaces

autore: Marco Cilia categoria: tagmanager tag: ,

Viene sempre un momento, nella vita di un prodotto Google, in cui accadono due cose: il prodotto viene ritirato ( 😀 ) oppure diventa “adulto” a tutti gli effetti. Oggi possiamo dire che il già ottimo Google Tag Manager, compagno quasi inseparabile di ogni installazione di GA che si rispetti, entra nella sua fase matura con il lancio dei workspaces, che sono una cosa diversa dagli ambienti già disponibili da tempo.

Siccome l’ho avuto in anteprima da un paio di mesi, vi dico subito una cosa: se siete alle prime armi o peggio siete ancora nel mondo di coloro che non usano Google Tag Manager, lasciate stare… Il tema è ampio e richiede una certa padronanza dello strumento e dei meccanismi di fondo. Iniziare direttamente dai workspace (“area di lavoro” nell’interfaccia italiana) significa avere una curva di apprendimento ripidissima.

I workspaces nascono per risolvere uno dei dilemmi più grandi della collaborazione tra utenti nel TagManager: come faccio a lavorare su alcuni tag mentre altri lavorano su tag diversi? come ci coordiniamo per le pubblicazioni? perché non posso pubblicare selettivamente i tag?
Ebbene, creare un workspace significa innanzitutto clonare la versione corrente del container, cioè fare quella che nel gergo degli sviluppatori e dei sistemi di versioning e deploy viene definita “una branch“. Creato il workspace io posso iniziare a lavorare in tranquillità alle mie modifiche, senza fretta e senza dovermi preoccupare di rimettere a posto le cose a fine giornata perché qualcuno nottetempo potrebbe pubblicare una versione con le mie cose a metà.
Quindi lavoro per ipotesi per tre settimane alle mie modifiche. Nel frattempo qualcuno fa una modifica banale e pubblica. Cosa accade?

Ipotesi 1: la modifica fatta è completamente scollegata dalle mie. E’ un tag diverso, un trigger diverso, una variabile diversa. Il sistema al mio prossimo login mi notifica che il mio workspace è “fuori sync” e mi invita ad aggiornarlo. Le modifiche fatte vengono importate nel mio workspace, e tutti vivono felici e contenti.
Ipotesi 2: la modifica fatta è in conflitto con una delle mie. Magari hanno cambiato lo stesso tag, magari hanno aggiornato una regola che avevo già modificato nel mio workspace. Il sistema mi dice che il mio workspace è fuori sync, e mi invita a risolvere il conflitto con una elegante interfaccia di questo tipo

conflitti workspaces

In questo caso il tag GA – Pageview – Standard ha 4 modifiche (sono le righe evidenziate, quindi Enable Display Advertising Features, page, userId e cookieDomain), e per ognuna di esse io devo dire al sistema quale versione tenere. Quindi potenzialmente posso “ibridare” il mio tag obsoleto senza dover accettare tutte le modifiche fatte, ma selezionando di volta in volta quel che mi serve.

La cronologia delle modifiche è ovviamente separata per ogni workspaces, mentre un punto a sfavore della feature è l’impossibilità di “bloccare” alcuni utenti su un certo workspace o di creare workspace limitati ad un singolo folder di tag. Questo avrebbe permesso ad esempio di abilitare alcuni utenti esterni per il tempo necessario a fargli modificare dei tag di loro interesse, senza possibilità di fare danni altrove. Ma non è detto che in futuro non si potrà fare anche questo.

Chiaramente la feature è tanto più interessante quanto più grande è il team che lavora sul GTM di turno. E’ una feature rivolta espressamente al mercato Enterprise, e infatti la versione free del GTM può creare un massimo di tre workspace (il default + due custom), mentre la versione 360 di GTM (si, esiste anche la versione a pago, casomai non lo sapeste 😀 ) ne può creare infiniti.

Infine una menzione ad un nuovo livello di accesso utente nel Tag Manager, il livello “approvazione”. Il livello modifica può creare ed editare workspaces, ma non li può pubblicare, mentre il livello approvazione può farlo.

In soldoni, dopo averlo provato un po’ ribadisco che non è una feature per tutti, e che potenzialmente può incasinare la vita. Ma se niente niente avete messo mano a container giganteschi, o Tag Manager dove ci sono 4 o 5 aziende che ci mettono mano, avrete tutto l’interesse ad imparare ad usare BENE questa nuova attesissima funzionalità.

[In coda, segnalo il sempre ottimo post di Simo Ahava, che come me l’ha avuto in anteprima ma ha avuto molto più tempo per scrivere… un’enciclopedia 😀 ]


Aug 06 2016

Che ci faccio con il demo account?

autore: Marco Cilia categoria: generale tag:

La notizia della settimana è indubbiamente il lancio del demo account di Analytics, una vista perfettamente funzionante e piena di dati reali provenienti dal Google Merchandise Store.

Collegandovi a questa pagina di help e cliccando sull’apposito link, aprirete la vista ed essa sarà automaticamente aggiunta al vostro Google Account.

RT-merchandisestore

Diciamo innanzitutto che non è un account completo al 100%, dove per completo intendo dire che sfruttano TUTTE le feature che Google Analytics mette a dsposizione: alcuni esempi di feature che mancano sono:

  • Metriche personalizzate (ma ce ne sono 5 calcolate)
  • Tracking dei plugin sociali
  • Importazione dei dati di costo non AdWords
  • Resi dei prodotti

C’è però, ed è quasi completamente configurata, la sezione Enhanced Ecommerce. Ad esempio si notano dei problemi nel report Categoria di prodotto (E-commerce avanzato) per cui tutti i prodotti finiscono in categoria (not set). Sicuramente verrà sistemato.

Ci sono due modi per utilizzare questo demo account, secondo me. Il primo è banale da comprendere, ed è quello per cui lo hanno messo a disposizione, ovvero guardare il risultato di report che a volte non si possono attivare o non si sono ancora attivati. Esempio classico è proprio Enhanced Ecommerce.
Il secondo, un po’ più smart, è quello di fare esperimenti. Come vedete dallo screenshot qui sopra, se io faccio una visita con degli utm “miei”, dopo posso fare un segmento che mi isola. Quindi posso fare una visita, fare delle azioni, guardare come sono tracciate e controllare i risultati nel pannello. Lo posso già fare su un account mio, ma dovrei anche configurare tutto, ed avrei solo i miei dati. Nel’account di Google invece sfrutto il lavoro fatto dagli ingegneri, e guardo i risultati in un contesto più reale del mio account di test 🙂


Jul 06 2016

HelpSemaforoQuesto semaforo indica il livello difficoltà del post
semaforo rosso - articolo per esperti

Il più grosso passo indietro di Analytics

autore: Marco Cilia categoria: codice di monitoraggio tag: ,

Ok, alla fine ce l’ho fatta. Dicevamo nello scorso post di quello che considero il più grande passo indietro della storia di Google Analytics, che ovviamente non ha a che fare con i report – quelli vanno e vengono – ma con una funzionalità “core”: il modo in cui i cookie memorizzano le informazioni dell’utente e della sorgente.

Per farla breve:

Finché si usava la versione classica, l’identificativo dell’utente E la sorgente della visita erano scritti “in chiaro” nei cookie. Sharare un cookie tra sottodomini o tra domini diversi (con il cross domain tracking), manteneva la consistenza dell’utente – ove possibile – e della sorgente ANCHE se i tracking avvenivano su property diverse. Usando Universal Analytics, questo si può fare SOLO all’interno della stessa property.

Spiegazione dettagliata:

Partiamo con un po’ di background tecnico. Usando GA classic il cookie _utma contiene l’identificativo dell’utente, il cookie _utmz la combo source/medium/campaign/gclid.
Esempio di cookie _utma:
10143333.1579115142.1467823144.1467823144.1467832867.2
Esempio di cookie _utmz:
10143333.1467823145.1.1.utmcsr=news.google.it|utmccn=(referral)|utmcmd=referral|utmcct=/

Usando GA Universal, tutto quel che non è identificativo dell’utente è stato spostato “lato server” (server di Google, pensate a quanto storage dedicano per questa attività), alleggerendo il carico dei browser e delle chiamate a GA, che devono portarsi dietro questa informazione per conteggiare le sorgenti correttamente.
Esempio di cookie _ga:
GA1.2.843176649.1467833039

questo basta affinché Google Analytics riprenda il cookie con quell’identificativo – se esiste – e possa continuare le sue analisi da dove le aveva interrotte. Ma attenzione, su GA classic il cookie viene scritto PER DOMINIO, su Universal non lo sappiamo; sappiamo però che lo stesso identificativo mantiene le informazioni precedenti solo se i tracking avvengono nella stessa property. In pratica, ogni property contiene una tabella degli identificativi degli utenti che ha visto, e non “eredita” mai sorgenti da altre property.

Cosa avviene, ad esempio, facendo il cross domain tracking con GA classic? sono sul sito1.com e clicco un link correttamente istruito per fare il cross domain tracking, quindi atterro su sito2.com/pagina.html?__utma=140729130.774561551.1467833502.1467833502.1467833502.1&__utmb=140729130.3.10.1467833502&__utmc=140729130&__utmx=-&__utmz=140729130.1467833502.1.1.utmcsr=(google)|utmccn=(organic)|utmcmd=(none)&__utmv=-&__utmk=98665886
GA prende l’ide dell’utente, la source, il medium e il campaign (nell’esempio su sito1.com era una visita da organico) e scrive anche su sito2.com un set di cookie coerente con il primo. Ora viene il punto importante:

  • SE sito1 e sito2 sono tracciati nella stessa property, GA segna 1 utente unico, 1 sessione (da organic) e 2 pagine viste.
  • SE sito1 e sito2 sono tracciati con property diverse, GA segna 1 utente unico, 1 sessione (da organic) e 1 pagina vista sul GA di sito1, e segna 1 utente unico, 1 sessione (da organic) e 1 pagina vista sul GA di sito2.

Rifacciamo lo stesso esempio con Universal. sono sul sito1.com e clicco il link, atterro su sito2.com/pagina.html?_ga=1.153530484435.69385205830.8479429413352. Non c’è nessun riferimento a organic, naturalmente. Quell’informazione è memorizzata nella tabella della property di sito1. Ecco come i due casi vengono visti nei report:

  • SE sito1 e sito2 sono tracciati nella stessa property, GA segna 1 utente unico, 1 sessione (da organic) e 2 pagine viste. Non cambia nulla
  • SE sito1 e sito2 sono tracciati con property diverse, GA segna 1 utente unico, 1 sessione (da organic) e 1 pagina vista sul GA di sito1, e segna 1 utente unico, 1 sessione (da DIRECT se hai impostato correttamente l’esclusione dei referral, da referral nell’altro caso) e 1 pagina vista sul GA di sito2. il GA di sito2 NON EREDITA l’informazione sulla sorgente originale

La cosa accade anche per i sottodomini: con GA classic bastava assicurarsi che sottodominio e dominio principale scrivessero i cookie allo stesso livello, quindi tutti leggevano _utmz e tutti sapevano quale era la sorgente iniziale. Con Universal questo non è più sufficiente, se si inviano i dati a property diverse.

casi pratici:
Sento già il brusìo di fondo perché pensate che stia parlando di casi rari e remoti. Ne ricordo distintamente tre, nella mia vita lavorativa, in cui il comportamento di GA classic mi è tornato comodo. Ce ne saranno altri, ma li do per scontati sicuramente.

Quello più eclatante era un brand Worldwide che pagava dall’headquarter una campagna per inviare visite a un dominio AD HOC creato dall’internazionale, con varie localizzazioni in sottocartelle, e ogni localizzazione poi inviava gli utenti su una landing dei vari siti locali. Non ci permettevano di mettere il nostro GA su quel sito (ne avrebbero avuto uno per ogni paese), ma hanno accolto le istruzioni per fare il cross domain tracking, quindi a noi sul sito locale arrivavano le visite mantenendo le sorgenti e gli UTM usati dall’internazionale per taggare la campagna, dandoci quindi una corretta rappresentazione del loro apporto al nostro traffico. Con Universal questo non si potrebbe fare stante il no iniziale a mettere il nostro codice.

conclusioni:
Non molte; anche se a prima vista può sembrare un post tecnico, vi invito a riflettere sugli effetti pratici che questo ha sulle vostre implementazioni, presenti e soprattutto future; pianificare in quale property inviare i dati diventa fondamentale già in fase di design, se si sta parlando di un tracking appena sopra alla versione base. E intendo anche con dei banali sottodomini, eh!


Jun 16 2016

HelpSemaforoQuesto semaforo indica il livello difficoltà del post
semaforo verde - articolo per tutti

sondaggio: il più grosso passo indietro di GA

autore: Marco Cilia categoria: generale

Sono mesi che ho in mente di scrivere un post, ma è lungo e ho bisogno di mettere su un test per dimostrare alcune cose. Il titolo del post ce l’ho in mente da sempre e sarà “il più grosso passo indietro di Analytics da quando esiste”.
Nel frattempo mi sono chiesto se voi aveste già un’opinione in merito, e quindi eccomi qui a girarvi la domanda PRIMA di scrivere il post, invece che in fondo (tanto non lo so quanti ci arriveranno a leggerlo tutto, QUANDO avrò il tempo di scriverlo 🙂 ).

Che idee avete? cosa avevate che adesso vi manca? quale è il più grande torto che vi han fatto gli ingegneri di GA?

Via al televoto!


May 26 2016

HelpSemaforoQuesto semaforo indica il livello difficoltà del post
semaforo giallo - articolo avanzato

Il plugin per duplicare gli invii a più property

autore: Marco Cilia categoria: codice di monitoraggio tag:

Inviare gli stessi dati a più property è una cosa che capita spesso, molto più spesso di quanto si possa immaginare; il caso classico è la presenza di una property locale e di una di “rollup” che include anche dati di altre property, ma in realtà i casi sono disparati.
La letteratura classica prevede la doppia sintassi, la presenza di tracker nominati e l’invio di qualsiasi pagina o evento due volte. Ad esempio così


ga('create', 'UA-12345-1', 'auto');
ga('create', 'UA-67890-9', {'name':'b'});

ga('send', 'pageview');
ga('b.send', 'pageview');

Con il TagManager basta duplicare ogni tag e cambiare l’UA al quale si invia.
Ma quel geniaccio di Simo Ahava ha postato un plugin per Universal che invece fa tutto da solo: ecco il post “simple tracker duplication for universal analytics

Non vi voglio riportare tutte le istruzioni, quanto piuttosto segnalare il post. Dopo aver creato il file con il js (o comunque incluso il codice) è sufficiente cambiare il codice base così (uso l’esempio di sopra)


ga('create', 'UA-12345-1', 'auto');
ga('require', 'simolatorDuplicator', {'newId' : 'UA-67890-9'});
ga('send', 'pageview');

e il resto vien da sè. Facile, veloce, pulito, proprio come piace a noi 🙂


May 05 2016

HelpSemaforoQuesto semaforo indica il livello difficoltà del post
semaforo verde - articolo per tutti

L’amore non è bello…

autore: Marco Cilia categoria: generale tag:

…se non è litigarello, dicono. Non ci ho mai creduto troppo, ma tant’è devo dire che ultimamente il nostro prodotto preferito mi ha fatto arrabbiare.
In questi dieci anni di Google Analytics credo di averle viste quasi tutte, ho parlato con tantissime persone che mi hanno sottoposto i casi più disparati di analisi e di setup. Ho seguito le evoluzioni del tool, rilasci, ritiri, nuove feature e annunci, prima da utente poi da professionista del settore.

Ho SEMPRE, e dico SEMPRE trovato una soluzione a tutti i problemi, anche i più disparati. C’era sempre un forum, un blog, una pagina nascosta della sezione developer di GA che sapeva darmi uno spunto utile. Se non c’era una soluzione, ho trovato dei workaround. Alcune volte, rare per fortuna, mi sono dovuto arrendere all’evidenza (abbastanza brutta da confessare, ma terribilmente vera) che banalmente la spiegazione di un certo fenomeno era logica e chiara nella mia testa, ma talmente complessa da spiegare che risultava impossibile da capire per gli altri; e sicuramente io non avrò brillato per chiarezza. Alcuni questo fatto lo accettano, e si fidano, altri pensano che tu non voglia ammettere di avere torto, e restano delusi. Ma in cuor mio ho sempre saputo che i fenomeni avvenivano per questo o per l’altro motivo, e tutto era binario, come deve essere.

E invece in questa settimana confesso che mi sono ritrovato due o tre volte con il punto interrogativo gigante sopra la testa, come un fumetto, a pensare “ma perché? ma perché?” e anche “maledXXXX bastXXXXX” e sinonimi 🙂
In particolare sto sbattendo la testa sul data import e sulle definizioni personalizzate, ovviamente in contesti tutto fuorché minimamente normali e avanzati, ma comunque tecnicamente fattibili almeno sulla carta.

Vabbeh, niente di grave. Volevo solo rassicurarvi che succede anche a me. Vado a comprare un mazzo di rose, chissà che qualche ingegnere(ssa) di Mountain View non si impietosisca 😀


Apr 06 2016

HelpSemaforoQuesto semaforo indica il livello difficoltà del post
semaforo verde - articolo per tutti

Spia il singolo utente (ma teoricamente senza sapere chi sia :) )

autore: Marco Cilia categoria: generale tag: , ,

“posso seguire la navigazione di un singolo utente?” credo sia una delle domande che più spesso mi vengono rivolte durante i corsi di formazione.
La risposta è sempre stata NI:

  • SI, se riesci a creare un segmento che isola la sessione (o le sessioni) di un singolo utente, ammesso che Analytics non campioni pesantemente
  • NO, perché il risultato non è quel che ti aspetti: devi RICOSTRUIRE quel che fa, e spesso non c’è sequenzialità

Questo fino ad oggi, perché sta comparendo negli account di tutto il mondo il nuovo report Esplorazione utente (user explorer su interfaccia inglese): il nuovo report si presenta così (l’ho ordinato per Entrate e non per il default sessioni per renderlo più interessante)

user-explorer-panoramica

Questo report ci dice ad esempio che l’utente identificato dal cookie in riga 1 (e vi prego anche di notare che è la prima volta in assoluto che GA espone l’ID del cookie degli utenti) ha fatto una sessione da 22 minuti, durante la quale ha comprato per un valore di quasi 1200 euro e ha completato 4 goal (da cui il conversion rate del 400%, non è un errore 😀 ).

Se clicco su un record, ottengo una storia – eventualmente multisessione – molto puntuale sulle singole azioni di quel cookie. Ad esempio:

user-explorer-dettaglio

Posso filtrare anche solo le pageview (icona a forma di occhio), le transazioni (icona carrello), i goal (stelline) o gli eventi (campanella). Mi dice la data in cui il cookie è stato visto la prima volta, il canale con cui arrivò allora e con quale tipo di device. Ogni sessione contiene tutte le hit di quei 4 tipi indicati, e se l’utente ha fatto più sessioni esse sono riportate, con data e ora:minuto di ogni hit di ogni sessione. Inoltre posso anche selezionare una o più hit e creare un segmento per ritrovare tutti gli utenti con un comportamento uguale. Viceversa, se ho già creato un segmento a monte dell’apertura del report, esso riporta solo i cookie che sono in quel segmento.

Ora, cosa me ne faccio di questo report?
Beh, tante cose: innanzitutto si vedono a colpo d’occhio i cookie sospetti. Tipo così (dati di un GIORNO SINGOLO)

user-explorer-bot

dai, sul serio hai fatto 17 visite in un giorno ed erano tutte bounce? naaaah
In secondo luogo è un report cross-sessione, ed è molto utile per capire le sequenze di azioni degli utenti più interessanti, ad esempio segmentato per ENTRATE superiori a x mila euro.

Che limiti ci sono? ovviamente più grande è il numero delle vostre visite, più difficile diventa trovare dei singoli utenti da seguire. Poi il report è limitato a 10mila righe, a prescindere dal periodo temporale che si seleziona. Terzo, mi sembra di aver capito che la storia delle sessioni del singolo cookie non vada più indietro di 30 giorni.

La killer feature però c’è: se state usando un profilo USERID, allora tutto questo viene raggruppato per userID (e lo userID è esposto in chiaro). E mentre Google non sa chi sia l’utente abx6578re, voi sul vostro CRM invece lo sapete benissimo 🙂


Mar 16 2016

HelpSemaforoQuesto semaforo indica il livello difficoltà del post
semaforo verde - articolo per tutti

Svolte epocali di un martedì qualsiasi: Google Analytics 360 suite

autore: Marco Cilia categoria: ga-premium tag: , , , ,

Quando annunciarono Google Analytics Premium ero in pizzeria. Ieri mentre annunciavano Google Analytics 360 suite ero in hamburgeria. Il connubio tra i balzi avanti del mercato delle analisi dei dati e la mia pancia è evidente, e sicuramente c’è correlazione e consequenzialità 😀

Quindi, quando agli albori di questo blog parlavo della cosiddetta “business platform“, credo – col senno di poi, è facile 🙂 – che parlassi proprio di questa suite, anche se non lo sapevo.

La nuova Google Analytics 360 suite, proprio come si intuisce dal nome, è un insieme di prodotti noti e nuovi che vengono unificati affinché possano esprimere insieme il proprio potere dirompente. Tutto nasce da Google Tag Manager 360, una specie di Tag Manager Premium che costituisce le fondamenta del sistema. Immaginiamo che avrà le stesse funzionalità del TagManager che già conosciamo, più qualche feature espressamente rivolta al mondo Enterprise e utile per l’integrazione con gli altri strumenti della suite. Google Analytics Premium diventa Google Analytics 360: al momento non hanno annunciato nessuna novità, ma è facile immaginare che una suite che produce più dati avrà bisogno di report e funzionalità nuove anche nel sistema che nella suite è preposto ad analizzare i dati e fornire gli insights. Adometry, comprato tre anni fa da Google, diventa Google Attribution 360 ed è stato riscritto da zero per meglio integrarsi nell’ecosistema di BigG. Attraverso Attribution 360 è possibile calcolare complessi modelli di attribuzione e media mix, anche on/offline (in USA ad esempio attraverso Adometry si può calcolare il ritorno dell’online sugli spot TV).
Google Optimize 360 è un nuovo strumento di test&target (il nome vi ricorda qualcosa? 😀 ): nelle intenzioni dovrebbe, a partire da un normale segmento di GA, creare un pool di utenti che possono essere oggetto o di un test (A/B test o multivariato, con interfaccia grafica per creare le varianti senza intervenire nel codice) o di una personalizzazione (mostrare contenuti diversi al pool selezionato).
Google Audience Center 360, altra grossa novità, è la DMP (Data Management Platform) powered by Google, in grado di prendere una utenza (ad esempio sempre dal classico segmento GA), espanderla con dati integrati come una qualsiasi DMP e sincronizzarsi con altri tool esterni. Sarà interessante capire come si integra con Doubleclick, perché sarebbe decisamente promettente!
A fare da collettore per tutto questo, Google Data Studio 360, uno strumento di reporting grafico collaborativo con i presupposti di Google Drive (collaboration, condivisione), l’import dei dati da prodotti Google (e sis spera terze parti) e una potente interfaccia grafica customizzabile per manipolare e mostrare i dati. Tanto per rendere l’idea, è qualcosa che si avvicina a un Tableau o un Klipfolio.

Come per tutte le novità succulente, non vedo l’ora di metterci le manine sopra e giocarci a più non posso! voi? 😀


Mar 06 2016

HelpSemaforoQuesto semaforo indica il livello difficoltà del post
semaforo giallo - articolo avanzato

modi nuovi per tracciare cose nuove

autore: Marco Cilia categoria: codice di monitoraggio tag: , ,

In verità una delle tre “cose nuove” è in giro da un po’ di tempo, ma soltanto ora Google mette a disposizione uno strumento nativo.
Autotrack.js è una libreria made in Google per il tracking dei cosiddetti siti monopagina, o applicazioni monopagina: quei siti che si risolvono tipicamente solo con uno scrolling o con ancore che fanno scrollare i contenuti.
Il post ufficiale ci informa che con una semplice modifica del codice di monitoraggio possiamo importare il plugin autotrack e iniziare a modificare il codice della pagina in modo che comunichi da sola le azioni dell’utente a GA. Le azioni che possono essere monitorate in modo semplice sono:

  • click su link esterni e compilazione di form
  • cambio di url su applicazioni monopagina (tipicamente con l’uso di #ancore alla fine dell’url)
  • eventi tracciati con la sola modifica dell’HTML della pagina
  • tracking delle media query e dei cambi, ad esempio se cambia l’orientation del device o viene stretta la finestra

Tutte queste operazioni sino ad ora non erano impossibili da tracciare, ma richiedevano comunque un effort discreto a seconda delle possibilità e delle tecnologie utilizzate. Avere una libreria ufficiale indubbiamente sarà di aiuto.

La seconda novità è il lancio ufficiale delle pagine AMP, introdotte in beta in autunno per farle conoscere ai publisher e adesso sdoganate da Google: si tratta di un progetto per rendere il caricamento degli articoli editoriali pressoché istantaneo sui dispositivi mobile, aumentando l’esperienza d’uso. Ora, come si tracciano queste pagine che hanno una struttura particolare e imposta da Google? per prima cosa va dichiarato dentro a un tag CHE COSA andremo a tracciare e DOVE invieremo i dati, attraverso una struttura di dati particolare. Questo funzionerebbe per qualsiasi richiesta di tracking per la quale si sa come costruire l’invio dei dati, ma ovviamente i maggiori vendor hanno collaborato con Google e quindi esistono delle sintassi “facilitate”: ad esempio alcuni nomi che troviamo sono Adobe, Chartbeat, comScore e ovviamente Google Analytics, la cui documentazione specifica è qui. Ad esempio, ecco uno script molto semplice per il track delle sole pageview


<amp-analytics type="googleanalytics" id="analytics1">
<script type="application/json">
{
  "vars": {
    "account": "UA-XXXXX-Y"  // Replace with your property ID.
  },
  "triggers": {
    "trackPageview": {  // Trigger names can be any string. trackPageview is not a required name.
      "on": "visible",
      "request": "pageview"
    }
  }
}
</script>
</amp-analytics>

Aggiungere eventi significa dichiarare a priori che un click su un certo elemento dovrà essere trattato come tale, con quale categoria vada tracciato e con quale action; idem per le interazioni sociali o altri elementi. A seconda quindi del numero di interazioni possibili lo script potrebbe essere anche lunghetto da gestire, ma di contro il numero di diverse azioni possibili su una pagina AMP non è così elevato. Si possono comunque prevedere tracking aggiuntivi lavorando un po’ con i dev, ad esempio vi suggerisco di leggere questo post di E-nor.

Terza novità di questi giorni sono gli instant articles di Facebook, lo stesso concetto delle pagine AMP ma calate nel contesto di Facebook, ovvero leggere il contenuto senza abbandonare l’esperienza utente di FB. Anche in questo caso, il tema di come tracciarli è trattato in un capitolo apposito della documentazione, e non richiede modifiche pesanti alla pagina perché il tutto viene incluso con un iframe. In questo caso quindi si può utilizzare un TagManager senza grossi problemi, almeno sulla carta. L’instant article viene in ogni caso trattato come una pagina del vostro sito aperta tramite il browser interno dell’applicazione di Facebook.

E’ un mondo che cambia in fretta, bisogna sapersi adattare in fretta 🙂


Feb 14 2016

HelpSemaforoQuesto semaforo indica il livello difficoltà del post
semaforo rosso - articolo per esperti

back to basics: la voce (altro) nei report

autore: Marco Cilia categoria: report tag: ,

Se siete abbastanza fortunati da avere un sito molto grosso, o se al contrario siete funestati da problemi SEO con migliaia di pagine duplicate o decine di parametri inutili e diversi negli URL, ci sono buone probabilità che vi siate imbattuti nella voce (altro) nei vostri report dei contenuti.
In realtà la voce (altro) può comparire in qualsiasi report, a seconda della sua cardinalità: la cardinalità di un report è il numero di diverse combinazioni di dimensioni (righe) del report stesso, per cui il report “tipo del visitatore” ha cardinalità 2 (può avere solo due righe, “new” o “returning”), il report del tipo dispositivo ha cardinalità 3 (desktop, tablet e mobile), quello dei channel di default ha cardinalità massima 11 (Direct, Organic Search, Social, Email, Affiliates, Referral, Paid Search, Other Advertising, Display) e così via.

Ora, il report “tutte le pagine” all’interno dei contenuti può avere cardinalità elevatissima, e caricare un report del genere sarebbe mortale per le performance del sistema Google Analytics (e per la vostra pazienza nell’attesa 🙂 ), quindi gli ingegneri hanno limitato la VISUALIZZAZIONE del report a 50.000 righe univoche per giorno (75mila se avete GA Premium). I primi 50mila URL in ordine di pagina visualizzate sono mostrati nel report, gli altri sono raggruppati nella voce (altro) (come avevamo già visto nel 2008, agli albori di questo blog).
Primo problema da risolvere: “posso, conoscendo uno specifico URL che so esistere ma non vedo nel report, tirarlo fuori con una ricerca?” la risposta è NO, non puoi. Se in un dato giorno un URL è in (altro), il numero di pageview che ha ricevuto fa parte del KPI riferito alla riga (altro) (insieme a tutte le altre URL comprese), ma non puoi isolare quel numero. Quel che puoi fare è giocare con le dimensioni secondarie, perché esse costringono il sistema a fare delle query e quindi a tirare fuori i dati dal database, ma di contro c’è la possibilità che così intervenga il problema del campionamento.
In ogni caso, se anche non campiona, quando GA fa una query non estrae mai più di 1 milione di record; il resto va di nuovo in (altro).
Se hai GA Premium e chiedi un report unsampled invece, hai il dettaglio di ogni singola riga del report sino a un massimo di 3 milioni di record.

Saliamo di un livello: come avviene questo fenomeno? qui dobbiamo rifarci un momento alla guida ufficiale in proposito, disponibile a questo indirizzo: voci di tipo (other) nei rapporti
Per accelerare la visualizzazione dei dati, in un dato giorno e per ogni report esiste una tabella preaggregata (già elaborata) che contiene i dati del report; questa tabella come abbiamo detto ha un limite di visualizzazione di 50mila righe, per cui per rifarci all’esempio nella pagina di help

supponiamo che il 1 marzo la pagina “/categorie/cappelli” si sia classificata al 49.999esimo posto tra gli URL più visitati con 3 visualizzazioni di pagina, ma il 2 marzo sia scesa al 50.001esimo posto con 1 visualizzazione di pagina. Se richiedi un rapporto di Google Analytics che includa entrambi i giorni, l’URL “/categorie/cappelli” viene visualizzato con 3 visualizzazioni di pagina perché la visualizzazione di pagina del 2 marzo viene integrata nella riga (other).

A seconda della posizione di ogni url nella “classifica” giornaliera, essi saranno o meno aggregati nella riga (altro), e quindi compariranno o meno nel report, ovvero saranno ricercabili liberamente. Il KPI totale è integro, i KPI degli URL visualizzati sono integri, il resto è aggregato in (altro).

Saliamo ancora di un livello: per accelerare anche i report su più giorni, GA preaggrega anche i dati in tabelle che contengono 4 giorni di dati, ma in questo caso il limite è 100mila righe (e non 200mila, come ci si potrebbe aspettare). Le tabelle di 4 giorni non sono, ovviamente, la somma algebrica delle quattro tabelle giornaliere, per questo motivo mi è di recente capitato un caso molto strano in cui i dati di un report di pageview di un singolo giorno fossero più alti dei dati per lo stesso report su più giorni, compreso quello iniziale. Quel timerange probabilmente prendeva una tabella di 4 giorni più una o due tabelle di giorni singoli, generando quell’errore nel macro KPI.

Mi rendo conto che è semplicissimo da visualizzare, soprattutto nei casi borderline in un alcuni URL fluttuano tra le ultime posizioni di un report giornaliero e l’essere aggregati in (other), o peggio quando questo non accade nelle tabelle dei giorni singoli ma invece accade nella tabella di 4 giorni, ma è un fenomeno che esiste e che potrebbe darvi dei grattacapi, quindi è bene conoscerlo 🙂