Guida all'Integrazione del Consenso Cookie per Heatmap e Registrazione delle Sessioni di Hotjar: Il Manuale 2026 per gli Editori
Hotjar occupa un posto unico nello stack degli strumenti. Non è una piattaforma di web analytics come Google Analytics, non è una piattaforma di product analytics come Amplitude o Mixpanel e non è un tag manager. È uno strumento di ricerca sull'esperienza utente che esiste specificamente per registrare cosa fanno i singoli utenti su una pagina — dove muovono il mouse, su cosa fanno clic, dove scorrono, dove esitano e, nel caso della registrazione delle sessioni, esattamente cosa hanno digitato e visto renderizzato sullo schermo. Quella granularità è il prodotto. È anche il motivo per cui i regolatori hanno individuato la riproduzione delle sessioni come una delle categorie ad alto rischio di elaborazione comportamentale, e per cui un'implementazione di Hotjar non attenta è uno dei modi più semplici per un sito web altrimenti conforme di uscire dalla conformità. Il CNIL, il Garante e l'EDPB hanno tutti pubblicato linee guida che prendono di mira specificamente il comportamento di riproduzione delle sessioni, e la task force EDPB sui banner dei cookie del 2026 la tratta come categoria prioritaria. La buona notizia è che Hotjar è uno degli strumenti meglio progettati in questa categoria per il deployment consent-first — a condizione che l'editore utilizzi effettivamente i controlli esistenti.
Perché Hotjar richiede il consenso esplicito
Il profilo di raccolta di Hotjar è ciò che attiva gli obblighi di consenso in ogni framework rilevante. In un'inizializzazione predefinita, lo script di tracciamento di Hotjar scrive almeno tre cookie proprietari — _hjSessionUser_{siteId}, _hjSession_{siteId} e una serie di cookie di soppressione e sorgente in entrata — nel browser entro millisecondi dal caricamento della pagina. Lo script inizia poi a trasmettere in streaming una registrazione continua di coordinate del cursore, coordinate dei clic, posizione di scorrimento, dimensioni del viewport e, quando la registrazione delle sessioni è abilitata, il DOM renderizzato completo differenziato rispetto a una baseline.
Ai sensi dell'articolo 5(3) della Direttiva ePrivacy ciascuno di quei cookie è un'operazione di archiviazione e accesso che richiede un consenso preventivo, liberamente dato, specifico, informato e inequivocabile nel SEE, nel Regno Unito, in Svizzera e in qualsiasi giurisdizione che ha adottato lo stesso standard. Ai sensi del GDPR il flusso comportamentale costituisce un trattamento di dati personali perché la combinazione di traccia del cursore, indirizzo IP, impronta digitale del dispositivo e identificatore di sessione è sufficiente a individuare un singolo individuo. Ai sensi del CCPA e del CPRA la stessa raccolta conta come vendita o condivisione a meno che l'editore non abbia il relativo contratto di fornitore di servizi con Hotjar — che Hotjar offre tramite il suo DPA conforme al CCPA, ma che entra in vigore solo quando l'integrazione è configurata correttamente. Ai sensi delle linee guida EDPB sulla riproduzione delle sessioni il livello è ancora più alto: la riproduzione deve essere collegata a uno scopo specifico e legittimo di ricerca UX, il periodo di conservazione deve essere il minimo necessario e l'interessato deve essere informato non solo che le registrazioni esistono ma che la propria sessione potrebbe essere riprodotta da un analista.
Cosa raccoglie Hotjar prima del consenso — e cosa deve essere soppresso
L'errore di implementazione più comune è quello incluso nella guida rapida di Hotjar: incollare lo script di tracciamento direttamente nell'<head> della pagina. Questo funziona, ma carica Hotjar prima che il banner dei cookie sia stato nemmeno renderizzato, il che significa che i cookie vengono impostati e la registrazione comportamentale inizia alla prima visualizzazione di pagina — indipendentemente da cosa decida successivamente l'utente. Ogni regolatore UE che si è pronunciato su questo schema ha deciso allo stesso modo: i cookie impostati prima del consenso sono illegali e l'editore ne è responsabile.
Un'integrazione conforme deve quindi impedire che lo script di Hotjar venga caricato del tutto finché la categoria di consenso pertinente non è stata concessa. Il modo più pulito per farlo è avvolgere lo snippet di Hotjar all'interno di un tag <script> condizionato al consenso che il CMP inietta solo dopo che l'utente ha scelto la categoria analytics o product-research. Se lo script viene caricato tramite un tag manager, l'equivalente è impostare il trigger su un evento di consenso concesso piuttosto che su Tutte le pagine. La documentazione stessa di Hotjar ora raccomanda questo schema esplicitamente, e la piattaforma espone un'API hj('consent', 'grant') per i casi in cui lo script deve essere presente ma deve rimanere inattivo fino a quando il consenso è registrato.
Cookie e storage che Hotjar scrive
Il Hotjar Tracking Code 6.x scrive i seguenti identificatori, tutti non essenziali e che richiedono il consenso: _hjSessionUser_{siteId} con scadenza a 365 giorni contenente l'identificatore utente, _hjSession_{siteId} con scadenza a 30 minuti contenente l'identificatore di sessione, _hjFirstSeen, _hjIncludedInSessionSample_{siteId}, _hjAbsoluteSessionInProgress e una serie di cookie di attribuzione delle campagne quando sondaggi o widget di feedback sono attivi. Le registrazioni delle sessioni stesse sono archiviate sui server di Hotjar e collegate all'identificatore di sessione — revocare il consenso deve quindi anche inviare una richiesta di cancellazione tramite l'API di Hotjar o il flusso di cancellazione utente nel prodotto.
Mappare Hotjar ai framework di consenso
Hotjar non si integra nativamente con IAB TCF o IAB Global Privacy Platform. Non è un fornitore ad-tech e non è mai stato concepito per esserlo. Si integra però con Google Consent Mode v2 tramite il segnale analytics_storage ed espone la propria API di consenso nativa a cui qualsiasi CMP può collegarsi. Lo schema che supera la revisione di un regolatore tratta ciascuna funzionalità di Hotjar come un gate di consenso separato.
- Heatmap e mappe dei clic si legano allo scopo analytics o product-research. In termini TCF questo è più comunemente lo scopo 8 (misurare le prestazioni dei contenuti) combinato con lo scopo 1 (memorizzare e/o accedere alle informazioni). Per Consent Mode questo è analytics_storage.
- La registrazione delle sessioni dovrebbe essere dietro un segnale più rigido e separato. La registrazione cattura il DOM renderizzato e qualsiasi campo non mascherato, e un opt-in a livello di preferenze esplicito — non un consenso analytics generico — è la postura difendibile ai sensi delle linee guida EDPB sulla riproduzione delle sessioni.
- Sondaggi e widget di feedback possono funzionare sotto lo stesso gate di consenso della registrazione delle sessioni quando raccolgono input di testo libero, o sotto il gate analytics quando raccolgono solo dati di valutazione.
- Funnel e tracciamento delle conversioni si legano al gate analytics; se un identificatore utente viene propagato a un CRM o a una piattaforma pubblicitaria si applica anche il gate marketing.
Lo schema 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 caricatore di script differito che inietta lo snippet di Hotjar solo dopo che il consenso analytics si attiva, uno strato di soppressione della registrazione delle sessioni che imposta la registrazione su off per default finché un gate separato non si apre, e una configurazione di mascheramento dell'input che sopprime duramente qualsiasi campo che un regolatore considererebbe sensibile anche quando il consenso è stato concesso. Il quarto punto è spesso trascurato: il mascheramento dell'input non è un sostituto del consenso, ma è un sostituto della catastrofe quando il consenso viene concesso per ricerche legittime e un utente incolla dati sensibili in un campo di testo libero.
Implementazione web
Sul web lo schema più pulito è sottoscrivere l'evento di modifica del consenso del CMP, quindi iniettare condizionalmente lo snippet di Hotjar quando lo scopo analytics passa da false a true. Usare document.createElement('script') per iniettare il codice di tracciamento con l'attributo async impostato e allegare un gestore onload che chiama hj('identify', userId, properties) solo se esiste un identificatore utente validato dal server. Quando il consenso viene revocato, chiamare hj('consent', 'revoke'), far scadere tutti i cookie _hj tramite document.cookie e inviare una richiesta di cancellazione tramite la Hotjar Data API per le registrazioni di sessione precedenti dell'utente. Non inizializzare Hotjar pigramente nello stesso render pass del banner — lo script deve attendere una concessione esplicita, e la concessione deve essere registrata con un timestamp e una stringa di consenso prima che lo script venga mai eseguito.
Mascheramento dell'input e soppressione dei dati sensibili
Il registratore di sessioni di Hotjar viene fornito con tre modalità di mascheramento: Suppress mode, che è l'impostazione predefinita per i campi password e qualsiasi elemento contrassegnato con l'attributo data-hj-suppress; Whitelist mode, dove vengono registrati solo gli input esplicitamente inclusi; e Mask mode, dove le sequenze di tasti vengono registrate come asterischi. Ai sensi delle regole sulle categorie speciali del GDPR e della definizione di informazioni personali sensibili del CCPA, qualsiasi campo che potrebbe acquisire informazioni sanitarie, dettagli finanziari, identificatori governativi, dati biometrici, geolocalizzazione precisa o contenuti di comunicazioni private deve utilizzare la Suppress mode indipendentemente dallo stato del consenso dell'utente. Impostare data-hj-suppress a livello di form piuttosto che a livello di campo è lo schema più sicuro — sopprime l'intero form anche se uno sviluppatore aggiunge successivamente un nuovo campo che dimentica di contrassegnare individualmente.
Applicazioni single-page e cambi di route
Per le SPA (React, Vue, Angular, Svelte) lo snippet di Hotjar si lega per impostazione predefinita solo al caricamento iniziale della pagina. Per tracciare le transizioni di pagina virtuale il bootstrap deve chiamare hj('stateChange', newPath) ad ogni cambio di route. Questa chiamata rispetta qualsiasi stato di consenso che Hotjar mantiene in quel momento, quindi la logica di gating del CMP non deve essere duplicata — ma il cambio di route non deve di per sé innescare un nuovo caricamento dello script se il consenso è stato revocato tra le visualizzazioni di pagina.
Validare l'integrazione
Il passaggio di validazione è ciò che i regolatori controllano e ciò che gli editori saltano più spesso. Un'implementazione di Hotjar correttamente integrata deve superare quattro test nell'ordine. In primo luogo, una nuova sessione del browser con il banner mostrato ma nessuna scelta fatta dovrebbe produrre zero richieste a static.hotjar.com, script.hotjar.com o vars.hotjar.com e zero cookie _hj in document.cookie. In secondo luogo, rifiutare gli analytics dovrebbe mantenere quello stato — nessun caricamento di script, nessuna registrazione, nessun cookie. In terzo luogo, accettare gli analytics dovrebbe produrre un caricamento dello script e i cookie attesi _hjSessionUser e _hjSession con attributi SameSite corretti, e una registrazione heatmap dovrebbe apparire nel dashboard di Hotjar entro cinque minuti. In quarto luogo, revocare il consenso dopo il fatto dovrebbe interrompere immediatamente ulteriori registrazioni, far scadere i cookie e attivare una richiesta di cancellazione — una pulizia ritardata è una violazione.
La traccia di audit è importante separatamente. I regolatori si aspettano che l'editore sia in grado di provare, per qualsiasi registrazione nell'account Hotjar, che l'utente che l'ha generata aveva fornito un consenso valido al momento dell'acquisizione. Lo schema standard è incorporare la versione del consenso e il timestamp come attributo personalizzato nel record utente di Hotjar tramite hj('identify', userId, { consent_version: 'v3', consent_ts: ts }). Ciò rende qualsiasi registrazione specifica tracciabile a una specifica voce del registro del consenso, che è lo standard che l'EDPB ha stabilito e lo standard che gli editori dovrebbero adottare indipendentemente da dove operano. Un'implementazione correttamente bloccata, abbinata a un mascheramento dell'input che sopprime per default e a un percorso di cancellazione che si attiva alla revoca, è ciò che rende Hotjar una parte difendibile di uno stack di ricerca piuttosto che una responsabilità di conformità.