Sep 17 2018

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

Il piano B per rendere il cliente padrone del suo account

autore: Marco Cilia categoria: generale

Ancora nell’anno domini 2018 ogni tanto mi imbatto nel caso in cui un cliente, magari non skillatissimo a livello di Analytics, non ha il pieno possesso del suo account Google Analytics: vuoi perché l’agenzia abituata al “lock-in” ha creato una property dentro al suo account (“facciamo sempre così”), vuoi perché chi ha realizzato il sito ha messo Analytics al 90°, sempre partendo dal proprio account (“non sapevo se ne potessero creare altri”), o varie altre versioni più o meno fraudolente volontarie.

Premesso che la configurazione ottimale è sempre e soltanto una: il cliente è ADMIN a livello di ACCOUNT (più MANAGE USERS, naturalmente) del suo o dei suoi account Google Analytics, e le agenzie e i fornitori vengono abilitati di volta in volta per la gestione dei progetti e le necessità. Ma se così non è, tipicamente vi ritroverete nella situazione in cui dovrete chiedere al cliente di chiedere alla vecchia agenzia di abilitarlo come ADMIN + MANAGE USER in modo che lui possa aggiungere voi e farvi iniziare a lavorare. La risposta però potrebbe anche (anzi, è probabile che sia) essere una frase all’incirca simile a “non possiamo. Se vi facciamo ADMIN dell’account, vedreste tutte le property” (sottinteso: vedreste tutti i gonzi che stiamo bloccando nel nostro account e/o gli spending Google Ads).

Se anche vi ricordaste che ormai si possono spostare le property da un account all’altro, sapreste che per farlo è necessario proprio il privilegio di amministratore (edit) e di gestione utenti.

Il piano B prevede che si faccia la procedura al contrario: voi creerete un nuovo account Google Analytics, vuoto e di cui sarete amministratori. Darete accesso pieno all’agenzia, che non vedrà nulla, e fornirete istruzioni affinché sia lei a “spingere” la property nel vostro nuovo account. Fatto quello potrete rimuovere la vecchia agenzia e aggiungere il cliente con pieni poteri. Oppure potrete spostare a vostra volta la property in un account del cliente, consolidando magari situazioni caotiche in cui ci sono diversi GA account con gestioni multiple e disordinate degli utenti.

Sembra una banalità, ma a volte alle soluzioni semplici non ci si pensa 🙂


Sep 12 2018

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

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

autore: Marco Cilia 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!