Guida all'integrazione del consenso ai cookie per la digital experience e la session replay di FullStory: Playbook 2026
FullStory è la piattaforma dominante nella categoria digital experience analytics per un motivo: acquisisce tutto per impostazione predefinita. Mentre gli strumenti di analisi tradizionali registrano eventi discreti che lo sviluppatore ha strumentato, e le piattaforme di product analytics registrano interazioni più un supplemento autocatturato, FullStory acquisisce il DOM completamente renderizzato, il tracciato del cursore, il timing delle pressioni di tasti, il comportamento di scorrimento, i rage click, i dead click, le richieste di rete e gli errori JavaScript — e li assembla in registrazioni di sessione che l'analista può scorrere fotogramma per fotogramma. Questa copertura è il prodotto. È anche il motivo per cui FullStory si trova all'intersezione delle regole di consenso più rigide in ogni moderno regime di privacy. Le linee guida dell'EDPB sulla session replay del 2023 e le priorità della task force 2026 trattano la session replay come una categoria di consenso distinta e più restrittiva. La CNIL è stata il regolatore più pubblico sull'argomento ma non è sola — il Garante, l'ICO, l'AEPD spagnola e l'AP olandese hanno tutte espresso posizioni allineate. Un deployment FullStory configurato per l'acquisizione consent-first, con il masking corretto, il gating corretto e il corretto audit trail, è uno degli strumenti più potenti che un publisher possa utilizzare; quello non così configurato è uno dei bersagli più facili che un regolatore troverà.
Perché FullStory si trova nella categoria di consenso più restrittiva
Un'inizializzazione FullStory predefinita fa tutto ciò che fa ogni strumento di session replay e di più. Imposta cookie di prima parte nello spazio dei nomi fs_uid e fs_lua contenenti l'identificatore visitatore persistente e il timestamp dell'ultima attività, genera un identificatore di sessione in fs_session e inizia a trasmettere il DOM renderizzato a rs.fullstory.com entro millisecondi dal caricamento della pagina. Lo stream include ogni evento di input, ogni movimento del mouse, ogni posizione di scorrimento, ogni transizione di pagina e — quando il modulo di acquisizione di rete è abilitato — ogni risposta XHR e fetch emessa dalla pagina, con i body di risposta inclusi a meno che l'operatore non abbia configurato la soppressione.
Ognuna di queste acquisizioni attiva un gate di consenso separato. Persistere l'identificatore del visitatore è un'operazione di archiviazione e accesso ai sensi dell'Articolo 5(3) della Direttiva ePrivacy che richiede un consenso preventivo, liberamente dato, specifico, informato e inequivocabile in tutto il SEE, nel Regno Unito e in qualsiasi giurisdizione che abbia recepito lo stesso standard. Registrare il DOM renderizzato è il trattamento di dati personali ai sensi del GDPR perché il record visivo è sufficiente per identificare e rivelare contenuti sostanziali sull'utente. Acquisire lo stream di pressioni di tasti è una sensibilità particolare: tutto ciò che l'utente digita in un campo modulo viene acquisito fotogramma per fotogramma, e se il campo non è mascherato la registrazione include il contenuto digitato. L'EDPB è stato esplicito sul fatto che l'acquisizione session replay è una categoria che richiede un consenso esplicito e granulare distinto dal consenso generico alle analisi — e che il masking è un complemento al consenso, non un sostituto.
Cosa scrive FullStory prima del consenso — e cosa deve essere soppresso
Il quickstart standard di FullStory installa il tracking snippet direttamente nel <head> della pagina. Funziona come documentato ed è la fonte del più comune fallimento di conformità: lo snippet viene eseguito prima che il cookie banner sia renderizzato, i cookie fs_uid e fs_session vengono scritti entro millisecondi, e lo stream di session replay inizia a fluire verso rs.fullstory.com indipendentemente da ciò che l'utente decide in seguito. Ogni regolatore europeo che si è pronunciato su questo schema ha deciso allo stesso modo: i cookie impostati prima del consenso sono illeciti, la registrazione acquisita prima del consenso è un trattamento illecito, e il publisher ne porta la responsabilità.
Un'integrazione conforme deve quindi impedire che lo snippet FullStory si inizializzi finché la categoria di consenso rilevante non è stata concessa. Il pattern che funziona in produzione è l'API FS.consent() combinata con la registrazione differita: lo snippet viene caricato con FullStory({ orgId: 'XXX', recordOnlyThisIFrame: false }) e FS.shutdown() viene chiamato immediatamente, poi FS.restart() e FS.consent(true) vengono chiamati solo dopo che il CMP segnala che la categoria session replay è stata concessa. Il pattern alternativo è l'iniezione condizionale di script — lo snippet FullStory viene aggiunto al DOM solo dopo la concessione del consenso — che è più pulito ma richiede all'operatore di perdere qualsiasi identity stitching pre-consenso che FullStory altrimenti fornirebbe.
I cookie e lo storage che FullStory scrive
Lo snippet FullStory scrive i seguenti identificatori all'inizializzazione, tutti non essenziali e che richiedono consenso: fs_uid con una scadenza pluriennale contenente l'identificatore visitatore persistente, fs_lua con il timestamp dell'ultima attività utente, fs_session con l'identificatore di sessione, e i marcatori di stato registrazione che FullStory utilizza internamente. Revocare il consenso deve quindi sia scadere quei cookie sia chiamare FS.consent(false) seguito da FS.shutdown() per fermare ulteriori acquisizioni, e il publisher deve inviare una richiesta di cancellazione tramite l'endpoint privacy di FullStory per le registrazioni precedenti dell'utente.
Mappatura di FullStory sui framework di consenso
FullStory non implementa nativamente IAB TCF o IAB Global Privacy Platform — è una piattaforma di digital experience di prima parte, non un vendor di ad-tech. Espone un'API di consenso nativa e supporta un modello di masking privato per impostazione predefinita che opera indipendentemente dallo stato del consenso. Il pattern che sopravvive alla revisione di un regolatore tratta ogni modulo FullStory come un gate separato legato a un segnale CMP specifico.
- La session replay e lo stream DOM completo sono legati a una categoria dedicata di session replay o ricerca distinta dalle analisi generiche. Le linee guida dell'EDPB sono esplicite su questo punto — il consenso al replay deve essere separato e granulare, non aggregato con analisi o marketing.
- L'acquisizione di rete si trova dietro un sub-gate più restrittivo all'interno della stessa categoria perché acquisisce i body di risposta HTTP che possono contenere dati personali non correlati all'interfaccia visibile. L'acquisizione di rete deve essere disabilitata per impostazione predefinita e abilitata solo per specifici percorsi applicativi dove l'operatore ha confermato che i body di risposta non includono dati sensibili.
- L'identity stitching tramite FS.identify() può funzionare con un identificatore di sessione effimero su base di interesse legittimo quando l'utente è anonimo, ma collegare l'identificazione a un identificatore persistente di prima parte tra le sessioni richiede lo stesso consenso della session replay.
- Le heatmap e le conversion analytics derivate dallo stream di session replay ereditano il gate dallo stream a monte — non sono superfici di consenso separate, sono prodotti a valle degli stessi dati acquisiti.
Il pattern di integrazione che funziona
Il deployment di riferimento ha quattro parti: un CMP che espone un evento di modifica del consenso in tempo reale, un bootstrap differito che inizializza FullStory con l'acquisizione soppressa tramite FS.shutdown(), un listener del consenso che chiama FS.consent(true) e FS.restart() quando si apre il gate di session replay, e una configurazione di masking privato per impostazione predefinita che sopprime rigidamente ogni campo di input a meno che non sia esplicitamente attivato.
Masking privato per impostazione predefinita
Il livello di masking di FullStory opera indipendentemente dal consenso e deve essere configurato in modo aggressivo anche quando il consenso è stato concesso. La classe CSS fs-mask su qualsiasi elemento sopprime il contenuto di quell'elemento dalla registrazione; la classe CSS fs-exclude esclude completamente l'elemento dallo stream DOM; la classe fs-block blocca sia il contenuto sia la struttura. In base alle regole sulle categorie speciali del GDPR e alla definizione di informazioni personali sensibili della CCPA, qualsiasi campo che potrebbe acquisire informazioni sanitarie, dettagli finanziari, identificatori governativi, dati biometrici, geolocalizzazione precisa o contenuto di comunicazioni private deve usare gli attributi di masking indipendentemente dallo stato del consenso dell'utente. La posizione raccomandata è applicare fs-mask a livello di modulo piuttosto che di campo — uno sviluppatore che aggiunge un nuovo campo a un modulo esistente è molto meno probabile che ricordi di mascherarlo singolarmente che non operando all'interno di un wrapper di masking a livello di modulo che lo acquisisce automaticamente.
Selezione della regione e residenza dei dati
FullStory opera endpoint di ingestione separati per USA e UE. Per il traffico SEE e Regno Unito, l'endpoint UE è il corretto default — mantiene ingestione, elaborazione e archiviazione all'interno del SEE e riduce l'esposizione a Schrems II che qualsiasi deployment di session replay in regione USA porterebbe. L'endpoint è configurato per ogni organizzazione FullStory e non può essere modificato retroattivamente, quindi la scelta della regione deve essere effettuata prima del scaling e documentata nell'informativa sulla privacy affinché la catena della base giuridica sia pulita dalla raccolta all'archiviazione.
Validazione dell'integrazione e dell'audit trail
Il passaggio di validazione è ciò che verificano i regolatori e che i publisher più spesso saltano negli strumenti di session replay. Un deployment FullStory correttamente integrato deve superare quattro test in sequenza. Primo, una sessione browser pulita con il banner mostrato ma senza scelta effettuata deve produrre zero richieste a rs.fullstory.com oltre al fetch del file SDK e zero cookie fs_ in document.cookie. Secondo, rifiutare il consenso alla session replay deve mantenere quello stato — nessuna acquisizione, nessun identificatore, nessuna registrazione. Terzo, accettare il consenso alla session replay deve produrre il cookie fs_uid atteso, un singolo evento FS.consent(true) e lo stream DOM che fluisce verso l'endpoint regionale configurato, con i campi mascherati confermati nell'acquisire solo il segnaposto della maschera. Quarto, revocare il consenso deve immediatamente fermare ulteriori acquisizioni, far scadere i cookie fs_ e attivare una richiesta di cancellazione tramite l'endpoint privacy di FullStory per le registrazioni precedenti dell'utente.
L'aspettativa dell'audit trail è dove gli strumenti di session replay affrontano il controllo più rigoroso. Le linee guida dell'EDPB sui cookie banner del 2023 e le priorità rinnovate della task force 2026 sono esplicite sul fatto che il publisher deve essere in grado di dimostrare, per qualsiasi specifica registrazione di sessione nel progetto FullStory, che l'utente che l'ha generata aveva fornito un valido consenso alla session replay al momento dell'acquisizione. Il pattern standard è impostare la versione del consenso e il timestamp come variabili utente sull'identificatore FullStory tramite FS.setUserVars({ consent_version: 'v3', consent_ts: ts }) in modo che ogni singola registrazione sia tracciabile fino a una specifica voce del log di consenso. Un deployment correttamente gatato, abbinato ad attributi di masking predefiniti come privati e a un percorso di cancellazione che si attiva alla revoca, è ciò che trasforma la copertura di FullStory da un rischio di concentrazione normativa in una parte difendibile dello stack di digital experience di un publisher.