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 🙂


Jan 13 2016

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

La dimensione “dimensione del browser”

autore: Marco Cilia categoria: report tag: , ,

Il sempre ottimo blog di e-nor qualche giorno fa ha postato una cosa interessante: è disponibile la dimensione “browser size” nei report (nell’interfaccia italiana si chiama “dimensione del browser”).
Che GA collezionasse questo dato è noto da tempo; possiamo infatti risalire sino a questo post del 2012 e all’uso che ne fecero con il non brillante report “dimensione del browser” all’interno dei non brillanti report di InPage Analytics.

Ora, qualcuno a Mountain View deve averci pensato sopra e deve aver detto “che diamine, lasciamo che le persone ne facciano un po’ quel che gli pare, esponiamo il dato come semplice dimensione”. Detto fatto, tra le dimensioni secondarie ecco comparsa “dimensione del browser“. Attenzione, la dimensione del browser è diversa dalla risoluzione dello schermo: specialmente su schermi grandi è difficile che gli utenti navighino con browser a schermo pieno, e in ogni caso il viewport (lo spazio effettivo per il contenuto) non sarebbe lo stesso uguale allo schermo.

La prima considerazione saltata in mente ai ragazzi di e-nor è “usiamola per vedere chi genera visite fraudolente”, ad esempio con degli iframe a 0 pixels tipici degli affiliation più subdoli. Come vedete dal loro screenshot, si tratta di un fenomeno reale

Il loro consiglio è quello di raggruppare tramite un filtro tutte le dimensioni sospette, per avere il colpo d’occhio della situazione.

La seconda intuizione è nei commenti su Google+: “possiamo usare questa informazione per combattere i ghost referral“? si e no.
Si, perché se fate due prove vedrete che alcuni ghost referral rientrano nella regular expression suggerita: ^0x|x0$
Si, perché altri (molti) ghost referral hanno semplicemente (not set) come dimensione del browser
No, perché anche visite legittime hanno (not set): non sono molte, ma se a GA non arriva quell’info mentre le atre si, ci scrive (not set).
No, perché anche questa dimensione può essere inviata tramite measurement protocol ( si veda qui ) quindi tra qualche tempo gli spammer bypasseranno anche questo blocco

I benefici sono quindi tutti in termini di studio della UI/UX e di effettiva visibilità degli elementi in pagina.


Jan 06 2016

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

Sessioni, utenti, conversion rate

autore: Marco Cilia categoria: generale tag: , , ,

Ciao, e buon anno innanzitutto. Le meritate ferie mi hanno dato il tempo di leggiucchiare qua e là alcune cose su Google Analytics, e sono rimasto un po’ colpito da questo articolo di qualche settimana fa: Why You Shouldn’t Trust the Conversion Rate in Google Analytics. Il titolo, come al solito, mi sembrava un po’ troppo altisonante per essere davvero concreto, per cui mi sono immerso nella lettura.

Il presupposto esplicitamente citato in apertura è: “che succede se il tool non riporta quel che la gente si aspetta che riporti? che accade se non puoi fidarti di tutte le metriche su GA?” roba bella tosta, non credete? e così ci addentriamo nella lettura e scopriamo che il motivo per cui – secondo l’articolo – non potete fidarvi dei dati è che… le sessioni non sono i visitatori. Pensa te! (peraltro l’ultimo dei quattro punti – se un visitatore inizia la sessione su un sottodominio e poi passa al principale, inizia una nuova visita – è anche falso se avete configurato bene tutto o se usate Universal Analytics). L’articolo prosegue, cito traducendo, con la frase “L’errore è di equiparare una sessione a un visitatore”. Il conversion rate dell’ecommerce è calcolato sulle sessioni (transazioni * 100 / sessioni). La soluzione è usare delle custom dimension che registrino uno userID.

PERBACCO NO! la soluzione è: IMPARA A LEGGERE I REPORT PER QUEL CHE SONO! (e se proprio vuoi usare uno userID, abilita una vista userID enabled con Universal Analytics!). Ma chi ha mai detto che il fulcro di GA siano i visitatori? GA è da sempre uno strumento “session based”, e tutti i report sono costruiti su questo concetto. Soltanto da qualche tempo si inizia a parlare di report “user based”, e ovviamente il futuro è di trasformare tutto il sistema in qualcosa incentrato sull’utente. Ma sino a che questo non accade, lo strumento fa i report per come è progettato, e questo non c’entra nulla con la fiducia nei dati sottostanti!

Il secondo punto è a mio avviso ancora più debole: in soldoni dice che il bounce rate di per sé non indica nulla sulla bontà o meno della qualità della visita ricevuta. Bella forza! Se l’utente arriva, e senza fare nulla legge un numero di telefono sulla pagina, chiama e compra servizi per 4000 euro, GA segna un bounce a fronte di un grosso incasso. L’articolo ci rende edotti sull’esitenza di un “adjusted bounce rate”, di cui ho parlato secoli fa, e su cui ho anche già espresso le mie perplessità: dovrebbe essere basato sullo scrolling? o sul tempo di permanenza? se è basato sullo scrolling e il numero di telefono dell’esempio sopra è above the fold non cambia nulla. Se è basato sul tempo bisogna trovare un tempo sensato, e in ogni caso il sistema continua a non dirci se l’utente ha letto davvero la pagina o se gli ha squillato il telefono e s’è alzato dalla sedia…
Quindi ti ritrovi con più casistiche da interpretare, e con interpretazioni che dipendono strettamente da cosa hai scelto di fare. Anche questo però, ovviamente, non ha niente a che fare con quel che il sistema ti da di base e con la fiducia nei dati sottostanti.

Allora, già che ci sono, voglio porvi una domanda: voi nutrite dei seri dubbi sui dati di Google Analytics? se si, quali, in quale area, per quale motivo? intavoliamo una discussione sensata, nel caso…


Dec 16 2015

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

impariamo a parlare una lingua comune :)

autore: Marco Cilia categoria: generale tag:

Le incomprensioni cliente/fornitore esistono dalla notte dei tempi, sono anche un po’ figlie del fatto che ognuno sa fare il suo mestiere e non quello degli altri. Ma finché io che sono un web marketer non riesco a spiegare che problema abbia il motore della mia auto al meccanico, potrebbe anche starci. Quando fatico a capire quel che mi dice un altro web marketer, abbiamo un problema di comunicazione 🙂

Il web analyst poi è una bestia un po’ speciale, lo sappiamo: è abituato ai numeri e alla logica, e sebbene magari non sia al livello di nerdismo del programmatore, la barzelletta che ultimamente è ritornata in auge sui social

“Caro, stamattina me ne sono scordata… per favore fa’ un salto al supermercato, e compra una bottiglia di latte!”
“Certo cara, vado e torno!”
“ah… se ci sono le uova prendine sei ”
“Sicuro ! Ciao!”

Il marito va, e dopo un po’ ritorna con sei bottiglie di latte. La moglie :

“Ma perché hai preso sei bottiglie !?!?”

“Perché c’erano le uova.”

un po’ gli si addice. Per cui io, che magari sono anche particolarmente problematico, quando leggo una frase tipo

“ho bisogno di una vista delle sessioni organiche (con aggregazione mensile) da gennaio a novembre di tutta l’area XYZ.”

mi faccio tutte le seguenti domande:

  • vuoi una vista nuova filtrata su organic e la sezione? immagino di no, perché i dati varrebbero solo da ora in avanti
  • vuoi un segmento organico di quelli che vedono l’area XYZ?
  • ma quelli che vedono l’area XYZ, per te sono quelli che INIZIANO la visita su una pagina di quell’area o quelli che ci TRANSITANO in un momento qualsiasi della sessione?

Capite che la risposta (e i numeri conseguenti) varia parecchio a seconda di quel che si intende, e che una frase di una riga produce almeno tre domande importanti. Diciamo che con un po’ di fatica immagino cosa vorresti fare, ma tu poi mi rispondi con

“questo mi garantisce di vedere le visite da tutte le pagine dell’area XYZ?”

Oiboh, le visite sarebbero SU tutte le pagine dell’area XYZ (e ancora non sappiamo se vuoi sessioni/landing page, sessioni con segmento su “vede nella visita”, pageview uniche delle pagine dell’area o cos’altro), certamente non DA. le visite DA le pagine dell’area possono essere i referrer interni (ma non sono visite), ma non sappiamo se intendi DA pagina XYZ A pagina XYZ o DA pagina XYZ ad altre sezioni del sito, oppure al limite le visite che ESCONO dal sito (ma al più avremmo i click e i click unici)

Due righe che producono un bel po’ di questioni da risolvere, no? 🙂


Dec 11 2015

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

Smart Goals: lascia che Analytics decida le tue conversioni

autore: Marco Cilia categoria: generale tag: , ,

Se vi ricordate, ad aprile 2014 Google introdusse le liste di remarketing “smart”, ovvero liste create da un algoritmo per targhettizzare utenti ritenuti interessanti e con alta probabilità di convertire.
Oggi il blog ufficiale annuncia che una tecnologia simile, basata sul medesimo algoritmo di machine learning, è ora disponibile per creare Smart Goals (Obiettivi intelligenti nell’interfaccia italiana): ad ogni visita viene attribuito un punteggio, e le migliori vengono conteggiate come smart goal. Per farlo, l’algoritmo seleziona circa il 5% del miglior traffico AdWords e controlla comportamenti similari anche nel resto del traffico, determinando quindi le sessioni “migliori” da conteggiare negli obiettivi intelligenti.

I prerequisiti per usarli sono ovviamente aver collegato AdWords e Analytics, oltre al fatto di aver avuto nel mese precedente almeno 1000 click verso url inclusi nella vista dove si sta cercando di attivare gli smart goals. La view non deve ricevere più di 1 milione di hits al giorno (paradossalmente, gli utenti Premium hanno meno possibilità di usarli) e dovete aver abilitato la spunta nella condivisione dei dati dell’account con altri prodotti e servizi Google: sfortunatamente questo setting è quello più inviso al garante per la privacy sul tema cookielaw.

L’attivazione è abbastanza semplice, se avete tutti i requisiti necessari durante la creazione di un nuovo goal avrete la possibilità di selezionare “obiettivi intelligenti” come tipologia di goal; nessun altro setting necessario. La buona notizia è che in realtà il report relativo funziona già anche se non avete creato il goal (che comunque occupa uno dei 20 slot disponibili, esattamente come gli altri). Questo vi da la possibilità di comprendere come funzionerebbero già prima di attivarli. Perché allora consumare uno slot, direte? perché senza l’attivazione gli smart goal non possono poi essere importati su AdWords per ottimizzare le campagne, o per la creazione di custom report con la metrica apposita che viene creata.

Cosa ne dite, li attiverete o no?


Nov 14 2015

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

I primi dieci anni di Google Analytics

autore: Marco Cilia categoria: generale tag:

Brian Clifton qualche giorno fa postava su G+ che il compleanno di GA era il 10 novembre. Gli ho detto – linkando il post ufficiale del 2005 sul blog Google – che era il 14, e lui ha modificato il post. Due giorni fa Paul Muret ha scritto che era il 12. Noi, come da tradizione (ecco il 2009, il 2010, il 2011, il 2012 l’ho saltato, il 2013, e l’anno scorso) festeggiamo rigorosamente il 14.

Mantenendo il paragone con il crescere di un bambino, questo è l’anno dell’esame di 5° elementare, il primo vero e grande esame nella vita scolastica. Invece di soffermarci sul passato e chiedere, come fanno tutti, quale è la feature più apprezzata mai introdotta, facciamo il contrario: quale feature vi immaginate introdurranno da qui a un anno? e quale invece da qui a tre anni (cioè quando finirà le medie 😀 )?

In ogni caso, nonostante i termini del contratto indichino che i dati possono essere cancellati dopo 24 mesi, ecco uno screen di un profilo che esiste dal primo giorno di vita di GA:

le prime hit di GA
prime-hit

10 anni di dati (click per ingrandire)
10-years-of-data


Nov 12 2015

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

Lo strano caso del campionamento invisibile

autore: Marco Cilia categoria: generale tag:

L’altro giorno mi è capitato uno di quei casi da Sherlock Holmes che all’inizio sembra che vada tutto a rotoli, ma poi si risolve brillantemente escludendo tutte le possibilità e osservando bene, proprio come il buon vecchio investigatore ci ha insegnato a fare (a dire il vero, sono un patito della versione interpretata da Benedict Cumberbatch, così lo sapete 🙂 )

Il problema suona all’incirca così: “Marco, succede che selezionando i dati di un mese ho queste transazioni da cpc, ma se applico la dimensione secondaria categoria del dispositivo, sono meno. I dati non sono campionati”. (se ti serve un ripassino di cosa sia il campionamento…)
Ovviamente la cosa non ha senso, vista da questa prospettiva, per cui come al solito debbo smanacciare un po’ con i dati direttamente per capire sino in fondo cosa succede. Ecco le mie prove:

  • seleziono il mese, vado nel report acquisizione -> tutto il traffico, seleziono solo google / cpc, mi annoto le transazioni (661), applico la dimensione secondaria categoria del dispositivo, guardo le transazioni: 655. L’occhio si sposta sul riquadro del campionamento, il rapporto è basato sul 100% delle visite
  • torno indietro al report tutto il traffico, FILTRO per google / cpc, mi annoto le transazioni (661). Il report è preaggregato, e non sarebbe campionato nemmeno con 20 milioni di visite, quindi il numero è corretto. Applico la dimensione secondaria categoria del dispositivo, guardo le transazioni: 655. Il rapporto è basato sul 100% delle visite
  • mi sposto nel report mobile -> panoramica, applico la dimensione secondaria sorgente / mezzo, FILTRO AVANZATO per google / cpc e guardo le transazioni: 655. Anche qui 100% di campionamento.
  • Applico un segmento avanzato su google / cpc: 655 transazioni. Lo tolgo, 661 transazioni da cpc. Sempre 100%
  • Custom report, stessi risultati
  • Cambio approccio: invece di usare categoria del dispositivo, uso un’altra dimensione: stesso comportamento. Rapporti basati sul 100% delle sessioni. Inizio a temere un bug di Google Analytics
  • Abbandono la ricerca su cpc e faccio le stesse prove sui totali. Invece di 6, mancano in tutto 22 transazion

Ho provato moltissime combinazioni di custom report, segmenti, dimensioni secondarie, ma il problema invariabilmente si presentava. I dati considerati erano quelli di gennaio 2015. Sui dati di novembre, niente problema. Ma allora che cavolo di bug è? proviamo con i dati di febbraio 2015: perfetti, il totale con e senza dimensione secondaria combacia. Marzo 2015, problema presente. Testo i dati 1-15 gennaio, combaciano. 16-31 gennaio, combaciano. Faccio la somma a mano e viene 661. Rimetto tutto gennaio, GA mostra 655. La cosa prende una piega terrificante. Sposto l’attenzione sulle sessioni, anche quel numero non combacia con la dimensione secondaria applicata o senza. Mi gira la testa…

Ci prepariamo a scrivere a Google, con copiosi screenshot a supporto della nostra bizzarra situazione, quando alla review finale ho l’illuminazione. GA ha presumibilmente si un baco, ma non è dove crediamo che sia. Riguardo gli screenshot per assicurarmi che si veda bene che segni sempre 100% di campionamento e noto il numero totale delle sessioni del mese: 503.472. Ferma tutto, da che mondo e mondo, con il selettore su “report più lenti, maggior precisione”, il sistema non campiona se non deve fare calcoli su meno di 500.000 visite. Quindi qui ce ne sono di più, poche di più… vuoi vedere che?

500.000 / 503.472 * 100 = 99,31%

BINGO! il bug è che il riquadro, sebbene normalmente istruito per mostrare due decimali nel fattore di campionamento, arrotonda lo stesso 99,31 a 100. Quindi sta campionando, ma non sembra. Il che significa anche che in quelle 3.472 sessioni che mancano quando campiona su 500k ci sono 22 transazioni, con un conversion rate dello 0,63% che è perfettamente in linea con la media del sito in questione, e che conferma la bontà dell’algoritmo di campionamento.

Moriarty, c’hai provato anche ‘sta volta ma t’è andata male! 😀