Sep 12 2018

cosa hanno a che fare il 10 luglio 2012 e il GDPR?

autore: categoria: codice di monitoraggio

non ne ho la più pallida idea. Però in qualche modo sono collegati. Ora vi spiego:

Se avete avuto modo di andare un po’ indietro con le date dei periodi di analisi dopo l’introduzione del setting di “controllo conservazione dati“, avrete notato che le cose non sono così lineari come ce le aspettavamo: mi riferisco soprattutto a chi ha lasciato 26 mesi (il periodo che veniva proposto come predefinito) come periodo di conservazione preferito.

Se notate i grafici dello screenshot qui sopra, periodo selezionato 12 agosto 2008 – 10 settembre 2018, noterete come il grafico degli utenti si azzeri per le date più vecchie del 23 agosto 2016 circa, e la stessa cosa accade per le metriche sessioni/utente. Le pageview come vedete ci sono tutte. Seguendo il ragionamento del setting del GDPR, le informazioni sui singoli utenti antecedenti al periodo di retention sono perse, quindi il sistema non può calcolare gli utenti unici e le metriche relative alle “unicità”.

La prima cosa interessante è in realtà che se giochiamo un po’ con le date, la cosa non sembra così categorica: se seleziono 12 luglio 2016 – 10 settembre 2018, vedo i dati del 12 luglio; se seleziono 12 giugno 2008 – 10 settembre 2018, i dati di luglio non ci sono più. Sembra quindi esserci una sorta di filtro di visualizzazione più che una cancellazione vera e propria, o almeno la cosa vale per i mesi borderline con il periodo di retention.
La seconda informazione è che abbiamo detto che ci sono 12,4 milioni di pageview, e che esse sono aggregate e quindi “salve”. Bene, allora apro il report “tutte le pagine” e…

all’apparenza il grafico sembra normale, MA il totale delle pagine in testa alla tabella segna 1,1 milioni invece di 12,4. Decisamente male! inoltre l’indicatore giallo mi dice “Alcuni dati di questo rapporto non sono disponibili perché hanno una data precedente al periodo di conservazione dei tuoi dati.” Ora, potreste scommettere che i dati che mancano a questo report sono quelli più vecchi del 23 agosto 2016, come per il primo grafico… ma perdereste. Infatti un report delle pagine con data 30 luglio 2014 – 10 settembre 2018 ha lo scudetto verde (no campionamento o mancanza di dati) e il numero corretto di pageviews. Anche un report 15 marzo 2013 – 10 settembre 2018 va bene. Anche un report 11 luglio 2012 – 10 settembre 2018 è perfetto e completo con le sue 5.469.365 pageviews.
Invece un report 10 luglio 2012 – 10 settembre 2018 ritorna ad avere lo scudetto giallo, e 1,1 milioni di pagine. Cioè aggiungendo un giorno di report, le pagine scendono di 4,3 milioni.

Ora, se vi state chiedendo PERCHE’ accada, beh non lo so. Ma siccome questa cosa l’ho scoperta qualche settimana fa, posso dirvi cosa so:

  • il 10 luglio 2012 non è una data “rolling”, cioè non si sposta in avanti man mano che passano i giorni. Sembra una data fissa
  • il problema affligge solo – per quanto ho potuto constatare – le property che hanno (o avevano) impostato un periodo di data retention di 26 mesi (potrebbe essere vero per altre retention, ma non ho profili su cui verificare). Se avete selezionato “non scadono mai” dovreste essere immuni
  • si tratta anche qui quasi certamente di un filtro di visualizzazione, ancorché completamente scorrelato temporalmente e apparentemente nella logica dall’impianto del GDPR

Per verificare l’ipotesi che la cosa fosse legata ai dati dei singoli utenti ho costruito un custom report che mimasse il report “tutte le pagine” escludendo le metriche relative alle “unicità”, quindi lasciando solo dimensione PAGINA e metriche PAGEVIEWS, TEMPO MEDIO SULLA PAGINA e ACCESSI. Ebbene, per QUALSIASI range temporale, i dati NON SONO MAI ALTERATI. Ecco la prova sull’arco temporale di partenza:

Insomma, un mistero intricato ma con una soluzione tampone.
A proposito, se volete importare il custom report, ecco il link: https://analytics.google.com/analytics/web/template?uid=VoaUicraRhe2xe3VfelJOA
Se avete idee, parliamone nei commenti!

Condividi l'articolo:

7 Commenti

  1. Ciao Marco,
    bel post con spunti molto interessanti!
    Mi sorgono dei dubbi:
    – perché i dati mancano prima del 23 agosto 2016? Se sono 26 mesi prima del 25/5/2018 non dovrebbe essere il 25/3/2016?
    – perché togliere le pageview uniche dal report elimina il campionamento se l’unicità è rispetto la sessione e non rispetto all’utente?

    grazie,
    G

  2. Ciao Giulio! 🙂
    no, sono 26 mesi ROLLING, ma che io sappia la cancellazione la fa una volta al mese. Dovrebbe quindi andare fino a luglio 2016.
    la seconda è una bella domanda, ma credo che l’unicità della sessione dipenda dall’unicità dell’utente, a meno che Google non memorizzi un ID sessione (che può anche essere, eh).

  3. Ciao Marco,
    vuoi dire che 26 rolling si intende dalla data in cui consulti il report?

  4. sempre per come l’ho capita io, si intende 26 mesi indietro dal mese corrente (credo dal 1 del mese, ma non è specificato da nessuna parte). Lo dice qui
    “if you change from 26 months to 14 months, then any data older than 14 months is deleted during the next monthly process.”
    https://support.google.com/analytics/answer/7667196?hl=en

  5. altra domanda assurda vedendo il tuo primo screenshot: perché non cancella la metrica “nuovi utenti”? 😀

  6. quella è aggregata e storicizzata, come sessioni, non va calcolata sulla base degli unici. Per ogni sessione, o sei nuovo o non lo sei 🙂
    infatti la metrica sarebbe più correttamente nominata “sessioni da nuovi utenti”

  7. Ciao, io ho una domanda sulla cancellazione dei dati. Inizialmente il 25 maggio 2018 era rimasta l’impostazione 26 mesi. Successivamente il 25 luglio mi sono accorto e ho impostato “Non scadono automaticamente”. Il problema è che i dati vengono ancora eliminati, ad oggi 18/10/2018 andando indietro vedo solo i dati fino ad agosto 2016, anche se l’impostazione è stata cambiata il 25 luglio 2018. In realtà dovrei vedere i dati almeno fino a maggio 2016. Quale può essere il motivo?

Scrivi un Commento