[AGGIORNATO IL 16AGOSTO 2020]
Come annunciato nei miei due webinar del 13 e del 15 marzo 2019, un enorme asteroide ha colpito il mondo della web analytics con conseguenze disastrose sui cookie (almeno per come eravamo abituati): si tratta del Cookiegeddon.
In fondo all’articolo troverai la registrazione del webinar (ma prima di fiondarti in fondo leggiti l’articolo)
Ma cos’è ‘sto Cookiegeddon?
Oh, presto detto.
Non è altro che una serie di regole che limitano l’utilizzo dei cookie.
Naturalmente, Cookiegeddon è un nome di fantasia (ispirato al film “Armageddon” con Bruce Willis) e rende bene l’idea del danno che causerà questo asteroide digitale se non corriamo ai ripari.
Per il momento non facciamoci prendere dal panico: in questo articolo (che è un piccolo riassunto del webinar) cercherò di spiegarti nel dettaglio come cambierà il tracking e ti svelerò 7 (sono diventati 6) #barbatrucchi che possono aiutarti a salvare la web analytics.
Dobbiamo fare un po’ delle premesse. Voglio assicurarmi che tutto ti sia chiaro.
Il cookie è un file che contiene delle informazioni (sotto forma di stringhe, tecnicamente parlando).
Nella pratica funziona così: il browser scarica i cookie direttamente dal sito web e li installa sul dispositivo dell’utente.
Esistono 2 tipi di cookie che si differenziano per il loro ciclo di vita all’interno del dispositivo su cui vengono installati.
Come suggerisce il nome, questi cookie sono legati alla sessione (ossia il periodo di tempo in cui l’utente è attivo sul tuo sito). Quando il browser viene chiuso, il cookie (puff!) sparisce.
Invece di svanire alla chiusura del browser, questi cookie hanno una permanenza più lunga e scadono dopo un determinato lasso di tempo.
Possiamo classificare i cookie anche in base alla loro provenienza: esistono, infatti, cookie di prima parte e cookie di terza parte.
I cookie di prima parte vengono creati dal dominio del sito web, ad esempio www.dominio.it.
Sono gestiti, quindi, dal proprietario del sito e vengono utilizzati per garantirne il funzionamento e tener traccia delle preferenze dell’utente.
Questi cookie vengono impiegati anche dai domini di terzo livello, come blog.dominio.it oppure shop.dominio.it.
I cookie di terza parte vengono creati da domini esterni rispetto a quello mostrato nella barra degli indirizzi.
Questo cosa significa? Che le informazioni raccolte da questi cookie sono trasmesse a domini esterni al sito, allo scopo di tracciare gli utenti.
Hai presente quando tra i banchi di scuola passavi i bigliettini al tuo vicino per scambiarvi delle informazioni, magari le risposte del compito o una caricatura grottesca del professore?
Alzi la mano chi non lo faceva 😁
Ecco, i cookie agiscono allo stesso modo: passano i dati a siti terzi.
Puoi vedere i cookie installati sul tuo PC cliccando:
tasto destro del mouse > Ispeziona > Application (nella barra del menù) > Cookie
Ah, è grazie a questa magia che avviene il remarketing.
Dopo questa premessa, sicuramente vorrai capirne un po’ di più su ‘sto Cookiegeddon.
Andiamo per ordine.
Il Cookiegeddon era stato “avvistato” per la prima volta nel settembre 2017, quando WebKit — il motore di rendering utilizzato da Safari — sviluppò l’Intelligent Tracking Prevention (ITP): una funzione che limita la memorizzazione dei cookie.
La prima versione dell’ITP limita a 24 ore il ciclo di vita dei cookie di terza parte, dopo di che spariscono, lasciando posto solo a quelli di prima parte per i successivi 30 giorni.
Senti già la puzza di bruciato? No?
Allora ti faccio un esempio: immagina che un utente proveniente dal tuo annuncio Google Ads converta DOPO le 24 ore. Cosa succede? La conversione NON viene attribuita alla campagna.
Panico!
Google, però, non è rimasto a guardare con le mani in mano e ha creato il Tag Conversion Linker che bypassa il problema dell’anti-tracciamento creando un cookie di prima parte.
In questo modo, anche se l’IPT bloccava il cookie di terza parte, non c’erano conseguenze sulle conversioni, anche dopo le 24 ore dalla visita al sito.
E dato che sia Google Analytics sia i tool di tracking lavorano con i cookie di prima parte, problemi in vista non se ne vedevano.
Ma… WebKit se ne esce con un bellissimo upgrade.
La restrizione delle 24 ore per i cookie di terza parte rimane. In aggiunta, però, l’ITP 1.1 stabilisce che i contenuti embeddati devono essere gestiti attraverso lo Storage Access API.
Ammettilo: il 2.0 spaventa già di per sé.
Siamo a giugno 2018 e il Cookiegeddon inizia a farsi più vicino e anche più massiccio.
Il 2.0, infatti, implementa la richiesta di consenso dei cookie e cancella la possibilità di utilizzare i cookie di terza parte.
Quindi, per i 30 giorni successivi alla navigazione del sito si possono utilizzare solo cookie di prima parte.
Come prevedibile, si scatena la febbre dei cookie di prima parte.
Bisogna pur scavalcare il problema in qualche modo, no?
Ma l’ITP non si fa prendere in castagna e lancia un upgrade che fa ingigantire l’asteroide.
Presidente: “Che cavolo è quell’affare?”
Scienziato: “È un asteroide, signore”
Presidente: “E quanto è grande?”
Altro Scienziato: “È grande come il Texas, Presidente!”
A febbraio 2019 arriva la notizia: il Cookiegeddon ormai è vicinissimo e sta per dare un duro colpo alla web analytics.
Si tratta dell’ITP 2.1.
Anche se è ancora in beta (Aprile 2019), questo aggiornamento spaventa parecchio.
Con l’avvento dell’ITP 2.1:
Sì, hai capito bene. SOLO 7 GIORNI DI VITA!
Queste nuove restrizioni penalizzeranno i cookie creati con l’istruzione document.cookie tramite JavaScript, come fa la maggior parte degli strumenti online.
Stai già sudando freddo? È normale quando si apprendono certe notizie.
Ti faccio un esempio per capire meglio cosa succederà.
Giorno 1. L’utente (chiamiamolo Mario, c’è sempre uno che si chiama Mario) visita il sito www.ilmiosito.it. Il cookie di Google Analytics viene iniettato nel device e configurato con una durata di 7 giorni.
Giorno 4. Mario ritorna sul sito ilmiosito.it ma naviga su un dominio di terzo livello, ad esempio: blog.ilmiosito.it.
Il cookie precedentemente installato viene rilevato da Google Analytics e, di conseguenza, la sua permanenza viene aggiornata e aumentata di altri 7 giorni.
Giorno 12. Mario ritorna sul sito www.ilmiosito.it, ma il cookie non esiste più. E riparte il ciclo: Google Analytics installa un nuovo cookie di prima parte con una permanenza di 7 giorni.
Per Google Analytics, Mario non sarà un utente di ritorno, bensì un nuovo utente!
Hai già intuito le conseguenze dell’impatto tra Cookiegeddon e web analytics? Dati non corretti!
Panichissimo!
E questo non vale solo per Google Analytics, ma per qualsiasi strumento che utilizzi il JavaScript per creare i cookie, come Hotjar, Cookiebot, Iubenda (potrei continuare all’infinito).
La vuoi sapere un’altra brutta notizia? Anche Firefox sta utilizzando la scadenza dei cookie al settimo giorno. Addirittura ha fatto di peggio.
A maggio 2019 arriva un ulteriore upgrade, ovvero la versione 2.2 che va a intaccare di brutto ulteriormente i cookie di prima parte.
Nel dettaglio questo aggiornamento restringe la durata dei cookie di prima parte impostati lato client utilizzando JavaScript. Inoltre i fornitori di analisi e marketing di terze parti sono stati presi di mira e il risultato è un cookie limitato a un periodo di scadenza di sole 24 ore. Sì hai capito. Un solo giorno.
Ecco le due condizioni:
Facciamo un esempio :
Un utente fa clic su uno dei tuoi annunci su Facebook e viene inviato a:
www.tuosito.com/?fbclid= IwAR1wZSGltSgn490ekIw6uaJvjihaTHS3GhTSIaJ9Pq7_q9i4iSqHJA1y1mw
Una volta che l’utente atterra sul tuo sito Web, Facebook creerà un cookie collegato a questo ID clic in modo che le conversioni successive possano essere attribuite al clic dell’annuncio corretto. Tuttavia, con ITP 2.2 questa conversione dovrà avvenire durante lo stesso giorno, poiché il cookie verrà probabilmente cancellato dopo 1 giorno.
Che bruttissima cosa.
A settembre 2019 arriva un nuovo update.
Questo colpisce localStorage con vita 7 giorni e document.referrer su TLD+1
Il 10 dicembre 2019 arriva il preventing tracking prevention tracking (che sembra uno scioglilinuga).
In breve tutti i cookie di terza parte sono bloccati se l’utente non ha fatto un’interazione diretta con il sito
Da febbraio 2020 il sameSite (parametro presente nei cookie) dovrà essere dichiarato, altrimenti Chrome non lo gestirà (fonte: Blog Chromium). Attualmente avrai un warning di questo tipo:
Proprio per questo ho aggiornato la guida su come creare un Cookie con Google Tag Manager.
Hai visto che macello?
Ma affrontiamo un problema alla volta!
Ho trovato e studiato 7 #barbatrucchi per cercare di mettere i bastoni tra le ruote a questo Cookiegeddon.
Ahimè, tutte le implementazioni che ti spiegherò, anche se non entrerò nei particolari, sono estremamente tecniche.
Il primo #barbatrucco è utilizzare il Local Storage.
Tutti i dati salvati in un oggetto Local Storage sono mantenuti all’interno del browser e resisteranno anche quando l’utente spegnerà il pc.
Non è necessaria alcuna comunicazione con il server, dato che la pagina web interroga direttamente il browser.
Grande pecca di questa soluzione: non è possibile gestire il Cross Domain.
Ciccia. Con la versione ITP 2.3 questa cosa non è più attuabile 🙁
Se invece hai l’esigenza di tracciare il Cross Domain, ti consiglio di utilizzare un postMessage che consente l’invio di informazioni tra iFrame a livello di dominio, salvando comunque i dati in Local Storage.
Il terzo #barbatrucco consiste nell’impostare i cookie lato server e non tramite JavaScript: sarà il server stesso a creare i cookie.
E l’ITP muto!
E qui arriva l’ultima novità di Google Tag Manager, ovvero il GTM Server-Side.
Se il sito è gestito da CloudFlare o Amazon, puoi far in modo che siano questi strumenti a generare i cookie.
Utilizza un CNAME, come fa Adobe.
Un’altra alternativa è fare proxy della libreria.
Ultimo #barbatrucco: utilizza gli hit server-to-server con cookie negli Header.
Nel mirino di questo asteroide digitale c’è il browser Safari e i sistemi operativi macOS e iOS e come già dichiarato anche Firefox.
Quindi, la prima cosa da fare è analizzare il traffico effettivo proveniente da Safari per capire come il Cookiegeddon impatterà sul tuo sito.
In ogni caso, dovrai fare i conti con dati che non tornano e nemmeno corretti nei meandri del web.
Certo, puoi sempre utilizzare uno dei 7 #barbatrucchi che ti ho spiegato qui sopra, ma non ti nascondo che per implementarli ci vuole tempo e, se non hai a disposizione un team di sviluppatori esperti, potrebbe rivelarsi una carneficina.
Io confido sempre in una risposta ufficiale dai Big, come Google e Facebook. Ma per il momento… silenzio radio.
Ad oggi, personalmente intravedo due possibili scenari sul futuro del tracking (non apocalittici, stai tranquillo!).
Chrome ha annunciato che anche lui farà delle restrizioni ma non ha specificato nel dettaglio. Ricordati: tutto l’ecosistema di Google si basa sul fatto di poter tracciare i dati di navigazione al fine di offrire una migliore esperienza utente. Però magari potrebbe ripensarci per non sembrare “il browser cattivo”.
Quindi, lato Google (per il momento) keep calm and carry on!
I cookie sono una tecnologia ormai datata e poco sicura. Spero che in un futuro prossimo i cookie verranno mandati in pensione per utilizzare degli strumenti (magari cross-device) alternativi.
A questo proposito, ti ricordi quando gli iPhone smisero di utilizzare Flash? Questa “chiusura” ha fatto sì che nascesse la tecnologia HTML5. Voglio dire: molto spesso i limiti servono da input per evolversi, no?
Nel corso dei mesi ho trovato la soluzione finale a questo tema. Si tratta del servizio Cookie Saver e lo sto usando su tutti i siti che gestisco 🙂
Se vuoi rimanere aggiornato sull’argomento cookie e sul futuro del tracking, iscriviti alla mia newsletter: www.tagmanageritalia.it/newsletter
Se hai necessità di sistemare una volta per tutte la tua web analytics, puoi richiedere una consulenza con me durante la quale metterò a disposizione le mie competenze per aiutarti a far decollare il tuo business online.
Ho deciso di rendere pubblica la registrazione del webinar che prima era disponibile solo per i membri del Club Tag Manager Italia. Ora è disponibile sul canale Youtube ufficiale di Tag Manager Italia.
Fai attenzione perché c’è un finale diverso che ti porterà ad una possibile soluzione definitiva 🙂
Negli ultimi mesi hai notato in Google Analytics 4 un calo improvviso e inspiegabile nelle…
Se ti trovi su questa guida è perché hai compreso che solo attraverso la Data…
Greenpeace è un'associazione globale che con azioni dirette e concrete denuncia i problemi ambientali e…
Da quando hai configurato la Consent Mode v2 (CM v2) hai notato cali improvvisi o…
Premesso che non è possibile conoscere l'esatto funzionamento né di Chrome, né degli algoritmi di…
Da quale canale di marketing arriva il maggior numero di conversioni? Quale campagna di marketing…
View Comments
Ciao Matteo, ma il barbatrucco di Cookie Saver consigli lo stesso di adottare soluzioni server-side per il tracking o rischiano di entrare in conflitto?
Grazie per super guide
Ciao, sono entrambe valide. Sinceramente con l'avvento del Server-Side di GTM puoi ricreartelo da solo il cookie senza Cookiesaver :)
Ciao, ti posso chiedere qualche dettaglio o dove reperire la documentazione relativa a questo barbatrucco:
#barbatrucco 4
Se il sito è gestito da CloudFlare o Amazon, puoi far in modo che siano questi strumenti a generare i cookie.
Grazie :)
Ciao Sante,
puoi trovare dettagli su questo barbatrucco qui:
per Amazon: https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/private-content-signed-cookies.html
per CloudFlare: https://developers.cloudflare.com/workers/recipes/setting-a-cookie/
Ciao Matte, ma quando scrivi "#BARBATRUCCO 3
Il terzo #barbatrucco consiste nell’impostare i cookie lato server e non tramite JavaScript: sarà il server stesso a creare i cookie." cioe cosa intendi? nel senso come si fa? Facebook, GA noi semplicemente copiamo e incolliamo lo script che ci danno nell' oppure via GTM. Nel senso, fisicamente come si impostano questi cookie a lato server? cosa vuol dire? Non devo caricare gli scritp con GTM o nell ? Dove vanno messi?
Significa che tutti i vari servizi (GA, FB etc) se voglio cookie lato server dovrebbero darci una libreria (o plugin) da installare lato SERVER, quindi niente GTM :\