Google Analytics in 30 secondi

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 🙂

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! 😀

[Prima di iniziare il post una doverosa premessa: né Google, né nessun altro, mi paga per “difendere” Google Analytics. Questo post è frutto delle opinioni personali di qualcuno che ha un account GA risalente al 14 novembre 2005, e che in quasi nove anni in qualche modo ha testato praticamente tutto il testabile dello strumento, portandolo fin dove ha potuto pur di capirne il funzionamento. Come dice una persona che stimo moltissimo “tu per capire le cose le smonti a pezzettini e le metti in fila, ragionando su come e perché succede una cosa, su quale azione porti quale reazione, poi fai il processo all’inverso e verifichi, ma non per tutti funziona così. Ricordatelo quando le spieghi”.
Ecco, in alcuni casi questo tipo di pensiero è utile, e questo credo sia uno di quelli…]

Mi è capitato sotto agli occhi un post di Federico Gasparotto, intitolato “I 10 errori del Digital-Marketing più comuni e come correggerli con i modelli di attribuzione“. E’ un ottimo post, lo dico subito a scanso di equivoci e ve ne consiglio la lettura; tra le altre cose riprende anche un video fatto dall’agenzia dove lavoro, ma questo è incidentale perché mi voglio concentrare sul paragrafo 5:

Errore 5: Credo a quel che mi dice Google Analytics

GA è un buon tool ma molto basico e di sicuro vale molto rispetto a quel che costa…. Va bene per capire se si stanno avendo visite, traffico, picchi, ma non è affidabile sotto a nessun punto di vista, a partire dal campione di rilevazione ( sbagliato concettualmente, non posso rilevare uno ogni tanto li devo rilevare tutti uno per uno), ai criteri di attribuzione della vincita, al metodo di analisi per merceologia praticamente assente e via discorrendo.
Certo è comunque settabile in modo da ovviare a tanti dei limiti endemici, ma nessuno piglia un tool gratuito per poi spenderci un botto su, e a quel punto meglio prendere un analitico come si deve per pochi k l’anno, anche perchè se uno analizza le vendite sulla base di dati imprecisi rischia solo di farsi delle gran pippe mentali.

Smonto e analizzo:

“GA è un buon tool ma molto basico”: molto basico rispetto a? se manca il paragone è impossibile determinare la bontà di qualcosa. Rispetto al leader di mercato (secondo Forrester sarebbe Adobe, in un suo recente/a – e stradiscusso – report)? stiamo parlando di un sistema che è installato sul 53% dei siti del campione “The entire internet” di builtwith.com (e su oltre il 20% della top 10k), stiamo parlando di un sistema che ha alcune feature di livello enterprise su una piattaforma gratuita (attribution modeling, tanto per citarne una, cross device report sul vero utente unico, tanto per dirne un’altra recente), stiamo parlando di un sistema scelto da moltissime multinazionali nel mondo.

“di sicuro vale molto rispetto a quel che costa“: questo è indubbio, perché è gratis (o quasi), ma l’equazione gratis = scadente su internet non è più vera da un bel pezzo, in alcuni settori. In ogni caso lo strumento mette a disposizione tante di quelle metriche e dimensioni e report, che la maggior parte delle persone nemmeno li conosce tutti. Sebbene io stesso non confonda certo la quantità con la qualità, man mano che passano i mesi mi risulta sempre più difficile trovare un business, un cliente o una situazione in cui Google Analytics abbia difficoltà ad ottenere il risultato sperato

“Va bene per capire se si stanno avendo visite, traffico, picchi, ma non è affidabile sotto a nessun punto di vista, a partire dal campione di rilevazione (sbagliato concettualmente, non posso rilevare uno ogni tanto li devo rilevare tutti uno per uno)“: il campione di rilevazione non esiste, nel modo più assoluto. Google Analytics registra TUTTO quello che accade sul tuo sito: registra TUTTE le pagine su cui hai messo il codice (se non l’hai messo su alcune pagine è un problema tuo, non suo: ma ho una buona notizia, la nuova funzionalità di diagnostica automatica in alcuni casi ti avvisa! 🙂 ), registra TUTTI gli eventi che hai impostato di registrare, registra TUTTE le transazioni che vengono fatte, registra TUTTE le pressioni a plugin sociali che hai scelto di registrare. Se visiti 89 pagine, lui registra 89 pagine, pacifico. Esiste un solo caso in cui questo non avviene, ed è se tu scegli volontariamente di non farlo avvenire, cioè se imposti la funzione _setSampleRate

Ipotizzando che invece Federico si riferisca al fenomeno del campionamento, ho spiegato in passato come e perché questo avviene, ma vale la pena di ribadirlo qui: i report standard (e sono oltre 200) non sono MAI campionati. Se il tuo sito in un mese riceve 19.234.599 visite, accadono due cose: la prima è che hai avuto esattamente 19.234.599 visite, la seconda è che stai violando i termini del servizio e in quel caso si che dovresti usare la funzione _setSampleRate per ovviare. Ma i numeri sono giusti, se non applichi segmenti, dimensioni secondarie o custom report. Se invece applichi una delle cose descritte in precedenza, allora il sistema campiona, effettuando i calcoli su un sottoinsieme del traffico e scalando i risultati proporzionalmente. Gli algoritmi per fare questa operazione non sono noti, ma sono prodotti da un’azienda che vive di algoritmi. Ovviamente più il campione diventa basso più – e qui siamo d’accordo – diventa azzardato fare analisi importanti. Ma più il campione diventa basso, più il traffico diventa alto, e in genere più traffico significa più revenue, e quindi la possibilità di acquistare un prodotto di livello superiore è più tangibile. GA free funziona benissimo sui range di traffico per il quale è “licenziato”.

Infine, se proprio vogliamo essere pignoli, esiste un altro limite tecnico di questo tipo: per ogni report di Google Analytics associato a una tabella, vengono visualizzati – per un singolo giorno – i primi 50.000 record (50k url nel report degli url, 50k keyword nel report delle keyword, 50k risoluzioni dello schermo nel report delle risoluzioni dello schermo, e così via…). Questo però è solo un “problema” di storage, a cui nessuno si può sottrarre, nemmeno le piattaforme leader del mercato: taglio corto con due concetti che gli addetti al settore conoscono, sia in generale sia nello specifico: table limits e bucketing.

“ai criteri di attribuzione della vincita“: ai criteri di attribuzione della conversione? il modello di attribuzione predefinito su Google Analytics è noto da sempre: si tratta del “last click non direct”. Non vi piace? cliccate su “conversioni – attribuzione – strumento confronto modelli” e ne potete scegliere altri 6: last click puro, last click AdWords, first click, lineare, decadimento temporale, sulla base della posizione. Un click e lo applicate ai dati pregressi. Ve ne serve uno diverso? allora siete tosti e sapete di cosa si parla, ottimo! potete creare un modello personalizzato e applicarlo in real time sui dati già registrati. Non mi sembra male per un sistema “molto basico” no?

“al metodo di analisi per merceologia praticamente assente e via discorrendo“: questa non l’ho capita del tutto. Ipotizzando che si riferisca alla scarsità di analisi sui prodotti possibili, convengo con lui che i report E-commerce sono sempre stati limitati nel numero e nelle funzionalità. Le nuove funzioni di segmentazione avanzata e il revamp completo dei report E-commerce però fanno passare il prodotto dalla preistoria al presente (anche leggermente al futuro, unendo le due funzioni e usandole per creare liste di remarketing).

“Certo è comunque settabile in modo da ovviare a tanti dei limiti endemici, ma nessuno piglia un tool gratuito per poi spenderci un botto su, e a quel punto meglio prendere un analitico come si deve per pochi k l’anno, anche perchè se uno analizza le vendite sulla base di dati imprecisi rischia solo di farsi delle gran pippe mentali“: TUTTI i sistemi di digital analytics devono essere settati: alcuni perché sennò nemmeno funzionano, altri perché hanno dei limiti, altri ancora per dare il meglio di sé. Addirittura alcune integrazioni che GA ha con pochi click (AdWords, tanto per citarne una, o Dobleclick su Google Analytics Premium) su altri tool richiedono spese ed effort aggiuntive, e non riescono ad arrivare allo stesso livello. L’approccio di Google Analytics è di tipo incrementale: prendi questo codice e mettilo su tutte le pagine, e intanto ti diamo 200 report. Col tempo capirai cosa ti serve, e molte di quelle cose nuove potrai farle anche senza dover averci pensato a priori, prima di mettere il codice, come al contrario avviene in altri casi. La gratuità dello strumento in ogni caso non va confusa con la semplicità nell’uso e manutenzione, per cui un budget in tal senso andrebbe sempre previsto; un budget per un analitico invece andrebbe sempre stanziato a prescindere. Anzi, per rientrare nel caso citato all’inizio del post di Federico, avere una piattaforma gratuita ma potente permette di avere più budget da dedicare all’analisi dei dati e all’estrazione di insight da parte di un analista. E’ anche grazie a questo fatto che il settore è cresciuto, negli ultimi anni.

Sul fatto che nessuno spende un botto guardando i dati di un tool gratuito, dovremmo certamente fasarci sulla definizione di “un botto”, che magari non collima: nel mio piccolo so che sulla base di quei dati si spendono dalle poche decine di migliaia a qualche milione di euro l’anno. Questi investitori evidentemente si fidano dei dati che lo strumento tira fuori, quindi o sono tutti in errore o c’è qualcos’altro che mi sfugge…
Se prendo la Fortune100 di quest’anno, escluso Google al n #1, le compagnie seguenti sono:
#2 SAS: usa Google Analytics, pur producendo un proprio sistema di analytics
#3 BCG: usa GA
#4 Edward Jones: usa GA
#5 Quicken Loans: usa GA, e Adobe mi sembra
#6 Genetech: usa GA
#7 Salesforce: non usa GA
#8 Intuit: usa GA

Prendendo a caso quelli che immagino essere big adv spender internazionali:
Coca Cola: usa GA (sito IT, l’internazionale non riesco a vederlo per il geoip :/ ) e Webtrends
Procter & Gamble: usa GA
General Motors: usa Adobe
Expedia: usa GA
Vodafone: usa GA e Adobe
Ebay: usa GA

In conclusione penso che nessuno di voi dovrebbe fidarsi ciecamente di quel che qualsiasi sistema di digital analytics gli mostra, nessuno! io in nove anni, su questa piattaforma, ho fatto tanti di quegli esperimenti che sono giunto alle mie conclusioni, la maggior parte delle quali potete tranquillamente andare a rileggere su questo blog; voi dovreste fare altrettanto, nei limiti della vostra curiosità e delle vostre capacità, e trarne le opportune conseguenze. Tuttavia dire che GA è un sistema impreciso e inaffidabile, o che rileva solo un dato ogni tanto, rappresenta un’inesattezza. E siccome sono fatto così, mi piace mettere ordine nelle cose, la smonto attraverso quel che ho imparato.

All’alba del 2014 mi capita ancora troppe volte di vedere account strutturati in maniera tutt’altro che ottimale. E se da un lato posso essere d’accordo che spesso non è facile ricominciare da zero con un account pulito e ristrutturato, dall’altro ci sono tante ottime ragioni per farlo, e tante tecnologie e soluzioni per facilitarlo. In questo post vedremo cosa è e perché accade il fenomeno del campionamento dei dati, perché le soluzioni adottate in passato non sono più ottimali e come si ovvia al giorno d’oggi.

Campionamento 101: di cosa si parla

Il fenomeno del campionamento (box giallo in alto a destra) avviene ogni volta che si chiede a Google Analytics di produrre dati che non sono precalcolati nei report standard. Ho descritto in passato cosa accade e perché nei due post “come funziona il campionamento” e “come funziona il campionamento (ufficiale)“, che ti invito a ripassare prima di proseguire nella lettura.

Per quanto concerne questo post, la parte fondamentale di quei due articoli è quella che dice “E’ importante notare che il campionamento avviene a livello di web property e non di profilo” (oggi i profili si chiamano “viste”). Avere delle viste-copia non risolve il problema del campionamento, se la vista principale conta tantissime visite.

Il fittizio caso esempio

Il famoso brand ACME è una multinazionale globale, con sedi in tutto il mondo e 30 siti in lingua attestati su 30 diversi top level domain. Per le sue esigenze di marketing interne ha bisogno di KPI a livello globale (rollup) e insight a livello di singola country/lingua.

Fino a qualche tempo fa l’approccio standard era: traccio tutto con una unica web property su GA, quindi con un solo UA, poi creo 30 viste-copia e su ognuna metto un filtro sul nome host.

Questa soluzione si portava appresso alcuni assunti e alcuni accorgimenti da prendere: se il visitatore può passare da un dominio all’altro (ad esempio perché cambia lingua, o perché il sito worldwide ha una spashpage con selezione lingua, o perché il gateway di pagamento ecommerce è uno solo in tutto il mondo ed è attestato in un sottodominio del sito .com, o per qualsiasi altro motivo…) è necessario impostare correttamente il cross domain tracking, altrimenti i conteggi di visite e visitatori unici nel profilo di rollup saranno gonfiati. Inoltre se non si gestisce il passaggio dei cookies, il profilo di rollup vedrà moltissime visite con referral interni (quando un utente passa dal .it al .de diventa un nuovo utente unico, si crea una nuova visita e la sorgente di traffico è un sito ACME). Idem i profili clone, che in assenza del cross domain tracking non conservano la sorgente di traffico originale, ma sono funestati dal fenomeno self referral.

Anche ammesso che questa parte sia stata gestita a puntino, il tutto subirà i nefasti effetti del campionamento se il profilo di rollup salirà molto con le visite. Nel caso in cui il rollup registri 5 milioni di visite, anche una vista copia per un paese nel medesimo periodo segna solo 60 mila visite subirà un campionamento al 5%, perché quando Analytics campiona ritorna sempre ai dati della property per estrarre il campione, e poi rifiltra il risultato secondo le regole impostate nella vista.

Come si riduce, oggi, questo fenomeno?

Oggi non mi sogno più di consigliare le viste clone in casi come questo, gli svantaggi sono evidenti sia in termini di manutenzione (decine o centinaia di filtri da tenere d’occhio) sia soprattutto in termini di performance.
Oggi, grazie soprattutto all’avvento delle tecnologie di Tag Management (ma non è obbligatorio) e di Universal Analytics (soprattutto per quanto riguarda la parte di cross domain tracking) l’approccio che consiglio è quello di “una web property per ogni cosa”:

• Profilo di rollup? una web property! UA-xxxxxx-1
• AMCE.it? una web property! UA-xxxxxx-2
• ACME.de? una web property! UA-xxxxxx-3
• ecommerce globale? una web property! UA-xxxxxx-4
• e così via…

Ovviamente su ogni pagina del sito ci saranno almeno due codici di monitoraggio (il rollup e il singolo dominio, ma potrebbero esserci anche codici per singoli sottoprogetti, non c’è limite alla fantasia…), il cross domain tracking deve essere impeccabile, e per fare queste due cose con semplicità io consiglio l’uso del Google Tag Manager; ma una volta messo in piedi il sistema, i risultati sono garantiti: il numero di visite è sempre congruente tra le property, sebbene non si possa sommare per ovvi motivi. Se passo dal it. al .de sono 1 visita su ognuna delle viste, ma sono 1 sola nel rollup. La sorgente di traffico è sempre quella originale che ha portato l’utente sui siti, e raramente è un referral interno. Ma soprattutto il campionamento viene eseguito sulla base dei reali dati di traffico: con gli stessi numeri dell’esempio precedente il profilo di rollup subisce un campionamento al 5%, ma il profilo con 600 mila visite lo subisce solo al 41%.

Inoltre ogni web property può essere usata singolarmente per produrre viste clone filtrate, su base dominio e non su base rollup. Il che a me sembra un ulteriore vantaggio!

Avevo già scritto come funziona il campionamento, ma era una descrizione semplificata e non approfondita, presa da un episodio della Web Analytics TV.
Sono capitato su questo articolo dell’help ufficiale che invece descrive il processo nel dettaglio, e siccome non è disponibile in lingua italiana può valere la pena di tradurlo, almeno nei concetti principali.

Come funzionano i report standard

Ogni web property in Google Analytics contiene una copia di tutti i dati non filtrati associati all’id della web property. Ogni profilo associato alla web property crea un set di tabelle aggregate e non campionate, che vengono processate su base giornaliera. I report standard di GA si basano su queste tabelle pre-aggregate, in modo da fornire report non campionati in pochissimo tempo.

L’utente potrebbe però chiedere informazioni con delle interrogazioni ad hoc, tipicamente quando applica segmenti avanzati, aggiunge una dimensione secondaria o guarda un report personalizzato. Quando l’interfaccia interroga il database, Analytics controlla le tabelle pre-aggregate per vedere se la query può essere soddisfatta con i dati in esse presenti; se non è possibile, allora si rivolge ai dati grezzi per estrarre i dati al volo. Quando questo accade e i dati sono campionati, vi appare il box informativo giallo.

Quando è il momento di una interrogazione ai dati grezzi, GA controlla per prima cosa il numero di visite registrate nel periodo selezionato; se questo numero è superiore a 250 mila (o al valore risultante dalla vostra selezione tramite lo slider), verrà applicato l’algoritmo di campionamento e scelto un sottoinsieme di 250 mila visite, proporzionali alla distribuzione delle visite nel periodo temporale di riferimento. Ne consegue che il campionamento è differente per ogni query fatta a seconda di quante visite debba “scomodare” per ricavare il dato.

Implicazioni per i profili filtrati e i segmenti avanzati

E’ importante notare che il campionamento avviene a livello di web property e non di profilo. Per i profili filtrati, il campione di 250 mila visite viene scelto dai dati grezzi, e soltanto dopo vengono riapplicati i filtri di profilo, quindi il numero di visite nel campione di questi profili potrebbe essere minore di 250 mila. La stessa cosa avviene con i segmenti avanzati, che vengono applicati solo dopo aver isolato il campione

Dimensioni aggregate, come funzionano i report standard

Le tabelle pre-aggregate naturalmente non contengono dati infiniti, esiste un limite anche per esse (nota 3: Le tabelle possono corrispondere a un singolo report o a multipli report. Possono contenere una singola dimensione (es. la keyword) o dimensioni multiple (es. gruppo annunci e campagne). Al livello più granulare possibile, i report conterranno 50mila righe). Google Analytics aggrega i dati che eccedono le 50mila righe per tabella per giorno. Ovvero, quando esistono più di 50 mila righe per una certa tabella, GA prende gli N valori più importanti (N è determinato in base alle metriche rilevanti per quella tabella) e aggrega gli altri nel valore (other)

Implicazioni per le richieste su più giorni
Questo viene fatto su base giornaliera; se ad esempio selezionate un singolo giorno del report Pagine, vedrete al massimo 50 mila valori. Le altre pagine sono aggregate nel valore (other). Però una pagina potrebbe essere aggregata nel valore (other) un certo giorno ma non il giorno successivo (magari peché riceve più visite e viene “scelta” per finire nelle 50 mila di quel giorno), quindi se fate un report per un periodo di più giorni potreste avere delle inconsitenze perché un certo valore alcune volte viene incluso nel gruppo (other) e alcune volte no.

In aggiunta, quando si fanno interrogazioni su più giorni, il numero massimo di righe lette per giorno è 1 milione diviso n, dove n è il numero di giorni della query. Di conseguenza per ogni query che abbracci più di 20 giorni, GA potrebbe troncare il numero di righe lette per giorno, se ci sono più di 50 mila righe di dati.
Ad esempio:

• un report per gli ultimi 30 giorni leggerebbe all’incirca 30 mila righe per giorno (1.000.000/30)
• un report per gli ultimi 60 giorni leggerebbe un massimo di 16 mila righe per giorno (1.000.000/60)

Siccome i valori delle dimensioni spesso si ripetono nel tempo (URl del sito o keyword in ingresso), questo problema tipicamente affligge siti con molti contenuti unici o keyword molto variegate.

Campionamento di altri report

Le canalizazioni multicanale sono basate su un massimo di un milione di conversioni. Se ve ne sono di più, GA campionerà usandone un milione, questa volta per profilo e non per web property.
Il numero massimo di percorsi di conversione è di 200 mila al giorno. Il resto finisce nell’aggregato (other)

I report sui flussi di visitatori sono generati da un sottoinsieme di 100 mila visite, campionate a livello di web property. Quindi usarli su profili filtrati o in combinazione con segmenti avanzati può ridurre ulteriormente il valore del campione utilizzato.

All’interno del post che contiene l’ultimo video della serie Web Analytics TV c’è una spiegazione semplificata di come funziona l’algoritmo che determina il fenomeno del campionamento all’interno dei nostri report, che lo ricordo interviene quando l’interrogazione che facciamo ha una base di oltre 250.000 visite.

Il campione usato nel sampling è random ed uniformemente distribuito nell’arco temporale selezionato. Vediamo nel dettaglio l’esempio del blog: se un sito riceve 500mila visite il giorno 1, 250mila il giorno 2 e 500mila il giorno 3, nell’arco del periodo ha un totale di 1 milione e 250 mila visite. come fa Google Analytics a determinare QUALI di queste sessioni di visita usare per calcolare i valori mostrati nel vostro report campionato?

Per prima cosa calcola un moltiplicatore, dividendo il totale delle visite per il numero di visite scelto dallo slider di controllo. Nel caso dello slider impostato sul valore predefinito, 1.250.000 / 250.000 = 5. A quel punto le visite di ogni giorno vengono divise per il moltiplicatore, e viene preso un numero casuale di visite che combaci con quel numero.
Nel nostro esempio:
– 500mila / 5 = 100mila visite casuali dal giorno 1
– 250mila / 5 = 50mila visite casuali dal giorno 2
– 500mila / 5 = 100mila visite casuali dal giorno 3

A questo punto I VALORI che abbiamo richiesto all’interno di queste visite totali vengono conteggiati tutti, ma vengono mostrati dopo essere stati ri-scalati secondo il moltiplicatore.

Ad esempio: “quanti visitatori nel periodo selezionato usano Opera e sono visite di ritorno?”. Ipotizziamo 1200 dei 100mila del giorno 1, nessuno dei 50mila del giorno 2 e 2700 dei 100mila del giorno 3. Totale 3900 * 5 = 19500. Questo è il valore che verrà mostrato nel report campionato che risponde alla domanda. I singoli valori saranno rispettivamente 6000, 0 e 13500.

Statisticamente ha senso, a meno di improvvisi sbalzi dei valori il numero campionato dovrebbe essere fedele al numero reale. E vien da sè, tanti più giorni ci sono nel periodo temporale, tanto più l’effetto di questi eventuali sbalzi è mitigato.

[image credit: [F]loximoron on Flickr]

Qualche mese fa scrissi un post (aggirare il limite dei 50.000 URL giornalieri) con una tecnica per venire a capo di situazioni in cui si vuole analizzare il report delle pagine ma si ha a che fare con siti che inviano più di 50 mila diverse pagine al giorno.
Il problema in realtà si presenta per qualsiasi dimensione: 50 mila è un limite invalicabile del processo di precalcolo dei report di Google Analytics. Nessun dato viene perso, sia chiaro, semplicemente i dati relativi alle eccedenze vengono memorizzati ma mostrati aggregati sotto la riga (other). Ce lo spiega Nick Mihailovski su Google+.

Però… c’è un però. Il limite interviene nel precalcolo dei report, cioè nei report che GA calcola normalmente e che ci mostra quando apriamo il prodotto. Esistono situazioni in cui il motore di Analytics calcola i dati al volo, ad esempio quando creiamo e/o applichiamo un segmento avanzato, che di norma non può essere precalcolato perché dipendente da infinite combinazioni.
Per questo motivo Nick semplifica l’intuizione dei ragazzi di Tatvic di cui vi parlai a Ottobre, e la rende il classico uovo di Colombo: se creiamo un segmento avanzato che intercetti TUTTE le visite, il motore è costretto a interrogare il database e a mostrarci anche quel che c’è dentro ad (other). Ad esempio un segmento così

(INCLUDI – Tipo di visitatore – con espr. reg – .*)

è nominalmente la stessa cosa che applicare il segmento TUTTE LE VISITE, ma essendo un segmento avanzato costringe GA a interrogare il database e a fornirci quel che cerchiamo.

Il limite superiore di questa tecnica è il limite del campionamento: se in dato periodo abbiamo più di 50.000 record per la dimensione, possiamo applicare questo trucco purché l’interrogazione non coinvolga più di 500.000 visite, poiché altrimenti interverrebbe il campionamento.
Spero che vi possa essere utile nelle vostre analisi. E grazie Nick! 🙂