Dec 24 2017

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

“Utenti” in tutti i report, ma fate attenzione!

autore: Marco Cilia categoria: report tag: , ,

Qualche giorno fa il blog ufficiale di Analytics ci ha informato di alcune novità apportate al prodotto:

  1. introduzione della metrica “utenti” in molti report
  2. Lifetime value nel report esplorazione utenti
  3. Audience nei report
  4. Probabilità di conversione

Sono tutte cose molto interessanti, ma vorrei soffermarmi in particolare sulla prima. Le tre metriche standard dei report che seguono il modello Acquisizione/Comportamento/Conversione per la sezione Acquisizione al momento sono Sessioni, % nuove sessioni e nuovi utenti. Andando nelle impostazioni delle proprietà si potrà scegliere se abilitare il flag Abilita la metrica utenti nei report per far si che questo trittico cambi in Utenti, nuovi utenti e sessioni.

La prima nota è che la metrica di default diventerebbe Utenti, e così anche il grafico standard che adesso invece è impostato su Sessioni. In alcuni casi le due metriche hanno andamenti molto diversi, e la cosa ha un impatto visivo non da poco.

Users everywhere

La seconda nota è più importante, e ha a che fare con il campionamento. Come abbiamo detto più volte su questo blog, i report standard non sono mai campionati, tranne alcune notabili eccezioni. Ovvero, se apro un report che esce “così com’è” dalla mente degli ingegneri, e non applico segmenti o dimensioni secondarie (insomma, se non faccio fare calcoli a GA), il report non è campionato. Questo accade perché i calcoli vengono fatti in fase di analisi, e le metriche intermedie (giornaliere, tipicamente) vengono poi sommate per il periodo temporale che selezioniamo.

Ma quindi cosa succede se abilitiamo la nuova funzione?
Nella sostanza succede che stiamo cambiando lo schema di interrogazione dei dati, trasformiamo TUTTI i report in report non standard, quindi soggetti a campionamento. Questo accade per due motivi:

  1. la metrica utenti non si può sommare mai. Come ci ricorda il famoso problema dell’hotel, 1 utente ogni giorno non necessariamente sono 3 utenti in 3 giorni, potrebbe essere sempre lo stesso e “sommerebbe” 1. Nella pratica questo si traduce nell’impossibilità di precalcolare il numero di utenti di un qualsiasi periodo temporale.
  2. Per venire incontro a questo problema, Google Analytics sta “predigerendo” questa metrica in qualche modo che non mi è chiaro, ma non lo può fare per il passato. Hanno iniziato a farlo in un momento imprecisato del passato, ma qualsiasi interrogazione che vada a chiamare dati precedenti produce un calcolo, quindi potenzialmente produce campionamento.

In sostanza se le vostre analisi sommano spesso più di 500k sessioni o se avete l’abitudine di fare analisi su lunghi periodi temporali passati, potrebbe non convenirvi abilitare questa metrica. Per fortuna a quanto ne so la cosa è reversibile, quindi potete provare e semmai tornare indietro, fintanto che la cosa non sarà forzata dagli ingegneri.


Dec 05 2017

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

il report dei contenuti a 1M di righe

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

Qualche settimana fa mi sono imbattuto in un fenomeno curioso, ma prima di scrivere un post aspettavo conferme; qualche giorno fa ho visto fugacemente un post su Google+ per la stessa cosa e m’è tornato in mente di verificare. Ora vi spiego tutto, ma prima un minimo di ripasso delle basi.

quante righe può contenere ogni report?

La domanda sembra banale, specialmente se si ha a che fare con siti di piccole dimensioni, o se il setup è stato fatto cum grano salis, ma non lo è affatto quando si guarda l’Analytics di siti grandi o giganteschi. La risposta infatti non è “infinite” 🙂
Il numero di righe di un report in gergo tecnico viene definita cardinalità, e prima di proseguire la lettura vi consiglio un ripassino di questo post evergreen: la voce (altro) nei report

Detto fatto, più un sito ha un distinto numero di pagine univoche (vere pagine uniche, o anche semplicemente parametri non filtrati nell’URL), più la voce (other) pesa nel report dei contenuti; parliamo di contenuti perché difficilmente si arriva a 50k record al giorno su altre dimensioni, in ogni caso il problema si porrebbe su qualsiasi tabella.

Cosa è cambiato di recente?

Di recente, da qualche settimana, il valore di (other) nel report dei contenuti è sceso moltissimo sugli analytics di siti giganteschi cui ho accesso, ed è praticamente sparito su siti grossi. Possiamo affermare con relativa tranquillità che il nuovo limite massimo giornaliero è passato da 50k a 1 milione, un incremento pazzesco se ci pensate. Oltretutto dai primi riscontri sembrerebbe che la cosa valga anche sugli Analytics standard, non è una prerogativa di Premium/360. Il cruccio delle analisi sui contenuti, tanto care anche ai nostri amici SEO, è adesso minore e non costringe ad artifizi e trucchi vari per venire a capo lo stesso del problema. Ma c’è di più:

Le custom tables (se hai GA360) e il loro ruolo nei report standard

Se hai accesso a un GA360, e hai i privilegi sufficienti, puoi creare le custom tables, o tabelle personalizzate nella UI italiana, che sono praticamente dei custom report che vengono permanentemente salvati ed elaborati preaggregati. Significa cioè che su quelle tabelle i dati sono sempre puntuali e mai campionati, entro 1M di righe e a patto che eventuali dimensioni secondarie o segmenti siano specificati già in fase di creazione della custom table.
Bene, ma questo cosa c’entra col problema iniziale? ecco, ora ti spiego la magia: quando tu fai una qualsiasi richiesta a GA, lui interroga uno schema, ovvero una “mappa” delle combinazioni possibili di dimensioni e metriche. I report preaggregati hanno uno schema predefinito, l’aggiunta di una dimensione secondaria tra quelle previste provoca l’interrogazione di uno schema diverso, ma non predefinito.

Però se tu crei una custom table (che un limite di cardinalità di 1M di righe) che ricalca esattamente lo schema di un report preaggregato (che ha un limite di cardinalità di 50k righe), quando tu chiedi il report standard, lo schema “punterà” alla custom table, regalandoti il report standard con 1M di righe, anche se non è il report dei contenuti che abbiamo visto poco sopra. Fico eh? 🙂

L’unica cosa da tenere presente è che ovviamente le custom tables non sono retroattive, o meglio vengono rimpolpate con i 30gg precedenti alla creazione, non oltre. Meglio di niente, in ogni caso…