L'impatto dell'Intelligent Tracking Prevention (ITP) sull'A/B testing: come superare le restrizioni

I marketer possono far sempre affidamento sul loro tool di A/B testing?

L'uscita dell'ultima versione dell'Intelligent Tracking Prevention di Apple ha posto l'attenzione su diverse questioni legate all'affidabilità dei tool di ottimizzazione del conversion rate. Il rilascio dell'ITP di marzo 2020 ha influenzato il nostro approccio e la nostra tecnologia, portandoci a decidere di cambiare ulteriormente.

L'ITP è un argomento molto tecnico e ha un impatto enorme sui marketer che effettuano A/B test - senza contare che queste decisioni influenzano la presenza del sito sul web ed è il cuore di ogni strategia di marketing che si rispetti.

Abbiamo deciso di intervistare il nostro CTO, Jean-Noël Rivasseau, per andare più a fondo sulla questione ITP, in particolare sulla versione 2.3 che introduce maggiori restrizioni sull'archiviazione delle informazioni del visitatore, con un limite a 7 giorni su tutti gli archivi scrivibili tramite script, cookie ma anche sessioni o archiviazioni locali compresi.

L'ITP è implementata all'interno di Safari e, anche se questo detiene una fetta relativamente bassa del mercato su desktop, la situazione è completamente differente quando si tratta di dispositivi mobile, per i quali Apple arriva anche al 50%. Ciò significa che quasi la metà del traffico web potrebbe essere impattato dall'ITP!

Ecco i punti principali emersi dall'intervista con Jean-Noël:

• Che cos'è l'ITP?
• Come impatta i tool di A/B testing?
• Com'è cambiata l'ITP dal 2019 a oggi?
• Come superare questo problema con Kameleoon 

1 Che cos'è l'Intelligent Tracking Prevention?

L'ITP di Apple mira ad aumentare la privacy dell'utente prevenendo tracciamenti indesiderati da parte dei siti web e dei vari script installati all'interno di essi, ed è implementata in tutti i browser Safari. L'ultima versione, l'ITP 2.3 di marzo 2020, essenzialmente limita l'archiviazione di tutti i cookie di prime e terze parti a 7 giorni, come scritto in questo articolo sul WebKit di Apple.

Limitare i cookie basati su JavaScript a sette giorni è una strategia molto aggressiva, perché a partire dall'introduzione dell'ITP, la maggior parte dei player (piattaforme di advertising e di analytics) si sono orientati su archiviazioni di prime parti (utilizzando i cookie o il Local Storage) per superare le limitazioni iniziali dell'ITP su cookie di terze parti. Questo perché la maggior parte delle piattaforme di analytics (incluso Google Analytics) ha bisogno di conservare l'identificatore univoco del visitatore per tracciarlo lungo il customer journey.

L'identificatore viene generato in modo casuale sulla prima pagina visualizzata durante la prima visita dell'utente sul sito e viene poi riutilizzato per tracciare tutte le visualizzazioni successive e le visite, con lo scopo di identificare quel particolare utente. Questo permette per esempio a Google Analytics di sapere se un visitatore è nuovo (come nuovo identificatore/cookie generato) o di ritorno (quando vede che quel cookie è già stato impostato in precedenza).

Dato che i cookie hanno ora una vita di sette giorni su Safari, la data di scadenza ben più lunga impostata da Google Analytics diventa inutile. Quindi un visitatore che fa la sua prima visita il lunedì e la seconda il martedì della settimana successiva sarà considerato come nuovo utente. La sua nuova visita non sarà collegata alla prima.

I risultati sui nuovi visitatori riportati da Google Analytics sono quindi completamente falsi quando si tratta di traffico su Safari. Come questi, anche altri risultati (come numero di visitatori unici, tempo di acquisto, ecc.) sono completamente sfalsati. In questo modo diventa difficile fidarsi di qualsiasi soluzione di analytics!

2 Qual è l'impatto maggiore dell'ITP 2.1 sui tool di A/B testing?

La maggior parte delle piattaforme di testing e conversion optimization spesso comprendono anche funzioni di web analytics. Ciò significa che soffriranno di quegli stessi problemi descritti qua sopra - e per gli A/B test ci sono ancora più ostacoli. Questo perché ogni volta che un visitatore è soggetto al test viene selezionata una variazione, che deve essere ricordata per essere mostrata al momento che questo ritorna sul sito. 

Per ottenere ciò, le soluzioni di A/B testing front-end conservano queste informazioni (associazioni fra sperimenti e variazioni) in un cookie. Con l'ITP un visitatore che ritorna sul sito più di sette giorni dopo aver avviato il test corre il rischio di vedere una variazione differente. Fare A/B testing in queste condizioni è inutile e non produce risultati affidabili.

Per superare il problema i vendor di software A/B testing possono decidere di smettere di impostare i cookie nel codice JavaScript e di conservarli piuttosto su server tramite header HTTP. Per farlo avrebbero bisogno di accedere a un codice back-end che aggiunge ulteriore complessità. La maggior parte delle soluzioni esistenti di A/B testing vengono installate perché promettono di essere molto semplici da impostare, offrendo un file statico JavaScript da includere nel codice HTML di origine, o gestite in modo ancora più semplice tramite il Tag Manager. Se un cliente deve fare sforzi eccessivi per installarli e mantenerli è ben probabile che queste soluzioni non vengano utilizzate per niente: ciò significa che qualsiasi soluzione alternativa basata su header HTTP non è veramente utilizzabile per i vendor analytics.

4 Perché Kameleoon è l'unica piattaforma di ottimizzazione che gestisce in modo automatico e trasparente l'ITP di Apple? 

Noi di Kameleoon crediamo fortemente nel potere della sperimentazione per migliorare l'esperienza digitale dei consumatori e aumentare l'engagement. Basare le proprie decisioni su dati incorretti o parziali ottenuti dalla piattaforma di A/B testing non corrisponde al motivo per il quale questi test vengono effettuati, cioè il bisogno di avere risultati precisi.

Per questo ci siamo focalizzati su aiutare i nostri clienti a mitigare l'impatto dell'ITP quando si effettuano A/B test e personalizzazioni.

local storage cross-dominio

Il nostro team IT ha implementato un sistema di archiviazione locale per Kameleoon già nel 2012, lanciato come soluzione di LS cross-dominio al rilascio dell'ITP 2.1.

L'archivio locale (o Local Storage) è una tecnologia web standard supportata da tutti i browser che conserva i dati su browser, per poterli gestire come i cookie.

Date tutte queste caratteristiche, l'archiviazione locale sembra essere il candidato ideale per rimpiazzare i cookie, soprattutto perché l'ITP non vi pone restrizioni. 

Diverse piattaforme di A/B testing hanno già implementato sistemi di archiviazione locale in sostituzione di quelli basati su cookie, ma c'è un grande problema alla base: il LS è limitato a quell'esatto singolo sottodominio.

Il sottodominio / lo schema di partizione del protocollo usato dal Local Storage è il problema: al contrario dei cookie, per i quali il codice JavaScript che avvia http://www.example.com può creare un cookie associato al dominio *.example.com (che significa che puoi accedere a questo cookie da compra.esempio.com o anche da compra.ora.davvero.esempio.com), il Local Storage viene ripartito a partire dall'esatto sottodominio e protocollo. Se scrivi dati sul LS nel sottodominio www.esempio.com non potrai accedere più tardi a http://buy.esempio.com o anche da https://www.esempio.com: protocollo e dominio devono coincidere completamente.

Per questa ragione, a meno di non essere abbastanza fortunati da avere sito e sottodominio singoli, questo problema si presenterà utilizzando una soluzione che si affidi solamente a un'implementazione semplice del Local Storage. Queste problematiche sono molto simili a quelle causate dall'ITP, anche se la ragione alla base è completamente differente.

Per fare un esempio, immaginiamo che la maggior parte dei tuoi siti e-commerce sia ospitata su https://www.randomshop.com, ma che il conversion funnel sia su https://transaction.randomshop.com. Se il tuo ID visitatore è persistente sul LS, la tua soluzione di analytics vedrà due visitatori differenti qualora venga effettuato un acquisto, uno su https://www.randomshop.com e l'altro su https://transaction.randomshop.com. I dati non transitano da un dominio all'altro, e una soluzione simile vedrebbe due sessioni completamente differenti e non una singola per lo stesso visitatore.

Con l'A/B testing le cose peggiorano ulteriormente. Se si avvia un esperimento modificando il menù di navigazione con due variazioni, un utente potrebbe essere esposto alla prima variazione sul sito principale, e alla seconda variazione una volta che si trova nel funnel! Questo è disastroso in termini di User eXperience e rende i risultati dell'esperimento non utilizzabili.

Ci siamo spinti oltre e abbiamo creato un'implementazione completamente cross-dominio del Local Storage, in quanto anche una piccola percentuale di pagine su un sottodominio differente del sito può significare risultati errati per gli A/B test.

SOLUZIONI DAGLI A/B TESTING PROVIDER

L'ultimo aggiornamento dell'ITP di Apple impone gli stessi vincoli sul Local Storage come cookie di prime e terze parti: ciò significa che i vendor di tool di A/B testing che utilizzano il LS devono sviluppare ulteriormente il loro approccio per assicurarsi che i loro clienti sfruttino i vantaggi di dati di A/B testing e personalizzazione accurati.

L'ITP non impone restrizioni sui cookie creati in server-side dal sito, perché necessari per far funzionare il sito. Per questo qualche vendor ha deciso di creare snippet server-side che permettono di impostare cookie server-side. Questo potrebbe avere un impatto sulla performance, a seconda del numero di cookie e dei dati raccolti all'interno di ciascuno. Altri non sono andati oltre al Local Storage, a significare che i dati raccolti su Safari non saranno affidabili, soprattutto se questi non hanno un approccio cross-dominio.

Esistono però approcci alternativi e i brand possono:

• Inserire un valore DNS sul dominio principale per impostare cookie server-side,
• Modificare la configurazione del server web front facing (o CDN) per generare e aggiungere il cookie richiesto.

Per saperne di più su tutte le opzioni: https://developers.kameleoon.com/visitorcode-synchronization-methods.html

cookie sincronizzati in server-side e local storage

Abbiamo deciso di andare più lontano. La nostra soluzione crea uno snippet server-side che si sincronizza automaticamente con il Local Storage. Ciò che raccomandiamo ora è di installare uno snippet server-side che sincronizza automaticamente il cookie kameleoonVisitorCode tra il front e il back-end, il quale contiene l'importantissimo identificare visitorCode.

L'ITP non impone restrizioni sui cookie su server, quindi questo cookie avrà una data di scadenza sufficientemente lunga.

Lo snippet andrà a creare il cookie KameleoonVisitorCode in server-side quanto non sarà trovato alcun cookie (cioè non ancora creato in front-side) O andrà a recuperare il valore esistente, ricreando il cookie in server-side per evitare problemi di ITP. Con questa sincronizzazione gli identificatori non saranno rimossi dopo sette giorni e che quindi non ci saranno impatti sulla performance o sulla UX in quanto viene conservato un unico cookie.

Ma, dato che Kameleoon conserva altri dati nel Local Storage, cioè quelli necessari per azionare esperimenti in real-time senza chiamate extra al server, abbiamo implementato un meccanismo di sincronizzazione del LS.

Su Safari, una volta che Kameleoon ottiene il suo suo visitorCode leggendo il cookie kameleoonVisitorCode (lato server, quindi affidabile), controllerà se il suo LS attuale è vuoto. In quel caso, che significa che probabilmente l'ultima visita è avvenuta più di sette giorni prima, Kameleoon avvierà una Server Synchronization Call (SSC) per prendere tutti i dati che erano presenti nel Local Storage dai nostri stessi server backend. Una volta che la chiamata si è conclusa, i dati saranno ripristinati nello stato in cui si troverebbero se l'ITP non li avesse cancellati. Le operazioni normali li possono riattivare.

Nonostante possiamo garantire che i nostri analytics non siano affetti dall'ITP e che tutti i dati relativi al traffico siano affidabili, non possiamo garantire lo stesso per piattaforme di web analytics di terze parti. I nostri ponti di integrazione con i tool partner continuano a lavorare come prima. Raccomandiamo che i clienti parlino di questa situazione direttamente con i vendor.

Per una spiegazione tecnica dell'ITP 2.3 e di come Kameleoon riesce ad aggirarla, visita la nostra sezione documentazione, ma sostanzialmente puoi avviare A/B test sull'intera base visitatori, a prescindere dal browser utilizzato. I dati sono accurati e possono essere utilizzati per migliorare e ottimizzare l'esperienza digitale di ogni cliente.

L'ITP nel prossimo futuro

Continueremo a monitorare l'evoluzione della tecnologia ITP di Apple, insieme ad altre iniziative di vendor browser (Firefox ha una tecnologia simile all'ITP, ma non così estrema). Qualsiasi nuovo cambiamento verrà analizzato e offriremo soluzioni il prima possibile per permettere ai nostri clienti di continuare a fidarsi dei dati su A/B test e personalizzazione.