[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.

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.

Cosa sono i cookie?

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.

Cookie di sessione

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.

Cookie persistenti

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.

Cookie di prima 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.

Cookie di terza parte

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.

Cos’è il Cookiegeddon

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.

ITP 1.0

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.

ITP 1.1

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.

ITP 2.0

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.

ITP 2.1

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:

• i cookie di terza parte (se sono classificati cross-site tracking) dovranno utilizzare lo Storage Access API;
• Safari non supporterà il Do Not Track, dato che non garantisce in modo assoluto il rispetto della privacy dell’utente;
• i cookie di prima parte avranno un ciclo di vita di soli 7 giorni.

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.

ITP 2.2

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:

• Il traffico proviene da un dominio che, per Safari, è classificato come dotato di funzionalità di tracciamento di terze parti.
• L’URL finale (al tuo sito Web) include una query o un frammento identificato (ad esempio un ID clic).

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.

ITP 2.3

A settembre 2019 arriva un nuovo update.

Questo colpisce localStorage con vita 7 giorni  e document.referrer su TLD+1

Preventing Tracking Prevention Tracking

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

La gestione SameSite warning

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.

Cosa puoi fare per salvarti dal Cookiegeddon

Ahimè, tutte le implementazioni che ti spiegherò, anche se non entrerò nei particolari, sono estremamente tecniche.

#barbatrucco 1

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 🙁

#barbatrucco 2

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.

#barbatrucco 3

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.

#barbatrucco 4

Se il sito è gestito da CloudFlare o Amazon, puoi far in modo che siano questi strumenti a generare i cookie.

#barbatrucco 5

Utilizza un CNAME, come fa Adobe.

#barbatrucco 6

Un’altra alternativa è fare proxy della libreria.

#barbatrucco 7

Ultimo #barbatrucco: utilizza gli hit server-to-server con cookie negli Header.

Quale sarà il futuro del tracciamento

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.

Un barlume di speranza per il tracking

Ad oggi, personalmente intravedo due possibili scenari sul futuro del tracking (non apocalittici, stai tranquillo!).

Il primo.

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!

Il secondo.

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?

La soluzione finale

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 🙂

Link utili

• Il post di Simo Ahava
• Intelligent Tracking Prevention 1.0
• Intelligent Tracking Prevention 1.1
• Intelligent Tracking Prevention 2.0
• Intelligent Tracking Prevention 2.1
• Intelligent Tracking Prevention 2.2
• Intelligent Tracking Prevention 2.3
• Preventing Intellinget Tracking Prevention
• Mozilla: limit the maximum life-time of cookies set through document.cookie to seven days

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.

La registrazione del webinar (con il finale cambiato)

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 🙂

Cookie Wars: una nuova speranza (webinar)

 

GTM Server-Side