Pagine AMP: come tracciare le azioni utente tra dominio e cache
La gestione delle pagine e delle interazioni degli utenti nelle pagine AMP servite con cache è stato a lungo uno dei punti critici di questo framework, uno dei fattori che destava maggiori perplessità nei proprietari di siti. Dal blog ufficiale del progetto arriva però una pratica guida per riuscire a risolvere il problema del tracking e, in particolare, per eseguire il monitoraggio delle azioni dell’utente tra le pagine originali e quelle servite con cache AMP.
User state e cache AMP
L’articolo di Ben Morss, Developer Advocate presso Google, parte appunto da un aspetto rilevante per i siti che usano AMP e che spesso potrebbe apparire problematico: se un utente visita una pagina servita su una cache AMP e poi torna successivamente sul dominio originale, potrebbe non essere immediato riconoscere che si tratta della stessa persona.
Un esempio concreto per questa situazione riguarda gli eCommerce: volendo raggiungere meglio gli utenti, un sito decide di creare pagine prodotti con AMP e “quando i web spider come Google e Bing scoprono queste pagine AMP, le archivia nelle cache AMP e le mostra agli utenti in un iframe che passa attraverso un sito come google.com o bing.com, pubblicando la pagina da una cache AMP, come cdn.ampproject.org o bing-amp.com”.
Come tener traccia delle azioni degli utenti
Fin qui tutto nella norma: ma cosa succede se un utente scopre la pagina su una cache AMP, aggiunge prodotti al carrello e più tardi nel giorno visita di nuovo il sito digitando il dominio normale? Quei prodotti saranno ancora nel suo carrello o lo troverà vuoto?
Cache AMP, come evitare i problemi
Come sappiamo, una soluzione immediata a questo problema c’è già grazie al Signed Exchange, la certificazione che consente di mostrare l’URL origine del sito anche per le pagine servite da cache AMP, che si è estesa a vari browser, ma non è ancora supportata da Firefox e Safari e non è ancora diffusa tra i siti.
Le cache AMP aiutano “a velocizzare le tue pagine Web preservando la privacy degli utenti”, introducendo però un ulteriore livello di complessità: “gli utenti possono accedere al tuo sito non solo sul tuo dominio, ma anche sul dominio della cache”.
Riconoscere gli utenti
E quindi, nel caso esemplificativo di prima, il sito può seguire la pratica web standard e tener traccia dello stato di un utente rilasciando un cookie che contiene un ID di sessione: ogni volta che l’utente visita le pagine dal dominio originale, “il server recupera il cookie, legge l’ID di sessione e ripristina lo stato dell’utente dai dati memorizzati sul server associato a tale ID”.
Quando l’utente visita la pagina del prodotto, vede degli articoli e li aggiunge al carrello facendo clic su un pulsante, il sito invia i dati al server:
<form action-xhr=”/add-to-cart” method=”POST”>
Se l’utente è di origine, spiega Morss, “la richiesta arriva con un cookie di sessione, con una richiesta che in parte è sarebbe simile a questa:
POST /add-to-cart HTTP/2.0
Cookie: session_id=12345”
Se però “l’utente visita il tuo sito su una cache AMP, quella richiesta al tuo server potrebbe effettivamente provenire da ampproject.org o bing-amp.com – un dominio diverso!”. Il browser associa il cookie al dominio regolare, rendendolo di fatto un cookie di terze parti: la maggior parte dei browser li invierà tranquillamente insieme, “ma gli utenti potrebbero aver impostato il proprio browser per bloccare i cookie di terze parti e alcuni browser li bloccano in determinate circostanze”.
Ciò renderebbe “la richiesta simile a questa, senza intestazione di cookie:
POST /add-to-cart HTTP/2.0”.
Come risolvere il problema del tracciamento utente
Insomma, quello che all’apparenza è un fattore secondario rischia di essere un piccolo problema, poiché i browser bloccano sempre più cookie di terze parti: c’è però una soluzione, spiegata qui in breve e in maniera più dettagliata nell’articolo originale, essenziale per consentire agli utenti di utilizzare il sito senza problemi attraverso le cache di origine e AMP.
Si parte dall’identificare gli utenti con un cookie di sessione sul sito, nella maniera solita; faremo la stessa operazione “nella cache e su un browser che accetta cookie di terze parti”. Negli altri casi, “ogni volta che un utente intraprende un’azione che modifica lo stato dell’applicazione, reindirizzalo immediatamente alla tua origine, dove puoi accedere o creare un cookie memorizzato nel tuo dominio e quindi apportare la modifica desiderata”.
Reindirizzare gli utenti sulla pagina origine
In altre parole, “se l’utente desidera aggiungere prodotti al proprio carrello e tu non riesci a leggere i suoi cookie, non farti prendere dal panico! Basta reindirizzare gli utenti alla tua origine, dove puoi cambiare il loro carrello in base al contenuto che preferisci”.
Questo reindirizzamento è reso possibile da un’intestazione HTTP specifica di AMP chiamata AMP-Redirect-To: se una pagina AMP effettua una richiesta server utilizzando <amp-form> e la risposta del server contiene questa intestazione, AMP reindirizzerà alla pagina desiderata.
Come usare l’header HTTP AMP-Redirect-To
L’articolo descrive l’intero flusso di questo processo.
- L’utente naviga la pagina del prodotto: se l’utente è sull’origine, la pagina imposta un cookie di sessione laddove non sia già presente.
- L’utente esegue un’azione per modificare ciò che è nel carrello.
- Il browser invia i dati sulla modifica all’origine tramite POST XHR.
- L’origine controlla se la richiesta non conteneva cookie di sessione e proveniva dalla cache
Se questo è vero:
- La risposta dice a AMP di reindirizzare a un URL sull’origine, includendo una stringa di query che descrive la modifica dell’utente.
- Quando l’origine vede quella stringa di query, legge o crea il cookie, apporta la modifica e reindirizza nuovamente a un URL sull’origine che non ha quella fastidiosa stringa di query.
Se ciò non è vero:
- Possiamo semplicemente recuperare la sessione dell’utente e apportare le modifiche. Saremo o sull’origine o nella cache con un browser che consente i cookie di terze parti.
Sia che l’utente inizi nella cache o l’origine, al termine di questo processo ha generato una sessione e le sue modifiche si riflettono sul server.
AMP e ID client, un compromesso con difetti
Chi ha dimestichezza con AMP sa che “esiste l’ID client, che consente ai pacchetti analytics di tracciare il percorso di un utente dalla cache all’origine”, che nella pagina origine – quella del dominio classico – viene memorizzato in un cookie e dura un anno.
Anche nella cache l’ID cliente è memorizzato in un cookie e, se non è nel cookie, “può essere creato con una chiamata all’API ID client”.
Quindi potrebbe apparire “allettante utilizzare questo per identificare in modo coerente un utente” e in effetti i siti utilizzano spesso questa soluzione che, “sfortunatamente presenta dei difetti”.
In particolare, l’ID client “identifica un singolo utente in modo univoco per determinati viaggi tra origini e cache, ma non tutti, e il suo comportamento tra siti può essere bloccato da alcuni browser”.
Si potrebbe usare l’AMP Linker per rendere più affidabili “questi viaggi cross-site, dal momento che conserva l’ID cliente come un parametro query string”. Ciò però significa che l’identificatore univoco dell’utente sarà visibile nel suo URL: gli URL tendono ad accedere ai server e, a volte, i bad actors scoprono i file di registro. Peggio ancora, l’utente potrebbe benissimo condividere pubblicamente il proprio URL, esponendo il proprio identificatore al mondo. In entrambi i casi, la loro sessione è vulnerabile all’hacking e questo è il motivo per cui “abbiamo usato POST invece di GET nei nostri esempi sopra”.
