Feb 14 2016

HelpSemaforoQuesto semaforo indica il livello difficoltà del post
semaforo verde - articolo per tutti semaforo giallo - articolo avanzato semaforo rosso - articolo per esperti

back to basics: la voce (altro) nei report

autore: categoria: report

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 🙂

Condividi l'articolo:

Scrivi un Commento