Guida all'integrazione del consenso cookie per l'analisi prodotto Heap Auto-Capture: Manuale 2026 per i Publisher

Heap è insolito nell'ecosistema dell'analisi di prodotto per ciò che fa per impostazione predefinita. Dove Mixpanel, Amplitude e PostHog chiedono al publisher di strumentare gli eventi rilevanti, Heap cattura tutto automaticamente e lascia all'analista la definizione degli eventi in modo retroattivo dallo stream catturato. Quel modello di auto-cattura è la caratteristica distintiva del prodotto e il motivo per cui i team lo scelgono; è anche il motivo per cui un'implementazione Heap predefinita porta una delle più ampie superfici di dati comportamentali di qualsiasi strumento che un publisher è probabile installare. Ogni clic, tocco, scorrimento, interazione con i moduli, transizione di pagina e rage-click viene catturato contro un identificatore persistente entro millisecondi dal caricamento della pagina — il che significa che ognuna di queste operazioni attiva un obbligo di consenso. La buona notizia è che Heap, dalla sua acquisizione da parte di Contentsquare, viene fornito con una delle API di consenso più granulari nello spazio dell'analisi di prodotto; il lavoro consiste nel cablarlo correttamente attraverso la superficie di auto-cattura, il livello di identità e il modulo di session replay che l'integrazione con Contentsquare aggiunge.

Perché Heap richiede il consenso — e perché la risposta è più ampia della tipica analisi

Un'inizializzazione Heap predefinita esegue diverse operazioni al primo rendering della pagina. Imposta un cookie di prima parte sotto _hp2_id.{envId} contenente l'identificatore utente persistente, un cookie di sessione sotto _hp2_ses_id.{envId} con l'identificatore di sessione, un cookie di frequenza di campionamento sotto _hp2_props.{envId}, e un marcatore _hp2_loaded che indica che l'SDK si è inizializzato. Genera l'identificatore distinto se non esiste già, cattura la pageview iniziale con referrer, parametri UTM e identificatori di clic, e inizia immediatamente a registrare ogni successiva interazione contro quell'identificatore — clic, tocchi, modifiche ai moduli, cambi di percorso, eventi personalizzati e, quando l'integrazione Contentsquare è abilitata, il diff DOM renderizzato completo per il session replay.

Ognuna di queste attività attiva un gate di consenso separato. La conservazione dell'identificatore utente è un'operazione di archiviazione e accesso ai sensi dell'articolo 5(3) della Direttiva ePrivacy e richiede un consenso preventivo, liberamente dato, specifico, informato e inequivocabile in tutto il SEE, nel Regno Unito e in qualsiasi giurisdizione che abbia adottato lo stesso standard. La cattura dello stream di eventi di auto-cattura è un trattamento di dati personali ai sensi del GDPR perché la combinazione di identificatore, indirizzo IP e traccia comportamentale è sufficiente a isolare un individuo. Il session replay si colloca in una categoria separata e più restrittiva in base alle linee guida EDPB sul session replay — il replay cattura il DOM renderizzato e qualsiasi campo di input non mascherato e richiede un consenso esplicito e granulare distinto dal consenso generico all'analisi. CCPA e CPRA trattano lo stesso trattamento come una vendita o condivisione a meno che il publisher non abbia il relativo contratto da fornitore di servizi con Heap — che Heap offre, ma il contratto entra in vigore solo quando l'integrazione è configurata in modalità fornitore di servizi.

Cosa Heap scrive prima del consenso — e cosa deve essere soppresso

Il quickstart standard fornito con la dashboard Heap installa lo snippet di tracciamento direttamente nel <head> della pagina. Funziona come documentato ed è la fonte del più comune fallimento di conformità nelle implementazioni Heap: lo snippet viene eseguito prima che il banner dei cookie sia stato renderizzato, i cookie _hp2_ vengono scritti in millisecondi e lo stream di auto-cattura inizia a fluire verso heapanalytics.com indipendentemente da cosa decida l'utente in seguito. Ogni autorità di regolamentazione europea che si è pronunciata su questo schema ha deciso allo stesso modo: i cookie impostati prima del consenso sono illeciti e il publisher ne porta la responsabilità.

Un'integrazione conforme deve quindi impedire che lo snippet Heap venga caricato finché la categoria di consenso pertinente non sia stata concessa. I due pattern che funzionano in produzione sono l'iniezione di script condizionale — lo snippet viene aggiunto al DOM solo dopo che il CMP segnala il consenso — e il pre-caricamento dello snippet con heap.load(appId, { disableTextCapture: true, secureCookie: true, autocapture: false }) come bootstrap differito e quindi la chiamata a heap.startAutoCapture() una volta registrato il consenso. Il pattern di iniezione condizionale è più pulito e quello che la documentazione Heap ora raccomanda. Il pattern di bootstrap differito è la scelta giusta quando il publisher ha bisogno di un riferimento globale stabile per il collegamento delle identità ma non può consentire che l'auto-cattura scatti prima del consenso.

I cookie e lo storage che Heap scrive

Lo snippet Heap scrive i seguenti identificatori all'inizializzazione, tutti non essenziali e che richiedono il consenso: _hp2_id.{envId} con scadenza a 14 mesi contenente l'identificatore utente, _hp2_ses_id.{envId} con scadenza di sessione a 30 minuti, _hp2_props.{envId} per la propagazione di frequenza di campionamento e proprietà, e _hp2_loaded come marcatore di caricamento. Il modulo di session replay integrato con Contentsquare aggiunge un buffer di registrazione in memoria che si svuota all'endpoint Heap ogni pochi secondi e può conservare separatamente un piccolo identificatore di sessione di replay. Il ritiro del consenso deve quindi sia scadere i cookie _hp2_ sia segnalare una richiesta di cancellazione attraverso l'API GDPR di Heap per le registrazioni e lo stream di eventi precedenti dell'utente.

Mappare Heap ai framework di consenso

Heap non implementa nativamente IAB TCF o la IAB Global Privacy Platform — è una piattaforma di analisi di prodotto di prima parte, non un fornitore ad-tech — ma si integra con Google Consent Mode v2 tramite bridging lato publisher, espone un'API nativa di opt-in e opt-out, e supporta un livello di redazione delle proprietà sensibili che opera indipendentemente dallo stato del consenso. Il pattern che supera la revisione di un'autorità di regolamentazione tratta ogni modulo Heap come un gate separato vincolato a uno specifico segnale CMP.

Il pattern di integrazione che funziona

L'implementazione di riferimento ha quattro parti: un CMP che espone un evento di cambio consenso in tempo reale, un bootstrap differito che carica Heap con l'auto-cattura disabilitata, un listener di consenso che attiva l'auto-cattura e avvia il buffer di session replay quando i gate pertinenti si aprono, e un percorso di ritiro che chiama heap.resetIdentity(), interrompe l'auto-cattura, scade i cookie _hp2_, e invia una richiesta di cancellazione tramite l'endpoint GDPR di Heap.

Implementazione web

Sul web il pattern più pulito è caricare lo snippet Heap in modo condizionale — il tag <script> viene iniettato solo dopo che la categoria di analisi è stata concessa. Iscriversi all'evento di cambio consenso del CMP. Quando la categoria di analisi passa a true, iniettare lo snippet Heap con secureCookie: true, disableTextCapture: false per l'auto-cattura completa, e qualsiasi configurazione specifica dell'ambiente. Quando il consenso al session replay passa a true e l'integrazione Contentsquare è abilitata, il buffer di replay si attiva automaticamente. Quando uno dei gate viene revocato, chiamare heap.resetIdentity() seguito dalla rimozione dell'elemento script Heap, scadere i cookie _hp2_ tramite document.cookie, e invocare l'API di cancellazione GDPR per l'identificatore dell'utente.

Redazione delle proprietà sensibili

Heap è dotato di un livello di redazione che opera indipendentemente dallo stato del consenso e che i publisher dovrebbero utilizzare anche quando il consenso è stato concesso. L'attributo data-heap-redact-text su un campo modulo sopprime il contenuto testuale catturato; l'attributo data-heap-redact-attributes sopprime gli attributi dell'elemento. In base alle regole sulle categorie speciali del GDPR e alla definizione CCPA di informazioni personali sensibili, qualsiasi campo che potrebbe catturare informazioni sanitarie, dettagli finanziari, identificatori governativi, dati biometrici, geolocalizzazione precisa o contenuti di comunicazioni private deve utilizzare gli attributi di redazione indipendentemente dallo stato del consenso dell'utente. Impostare gli attributi a livello di modulo è il pattern più sicuro — sopprime l'intero modulo anche quando uno sviluppatore aggiunge un nuovo campo che dimentica di contrassegnare individualmente.

Selezione della regione: residenza dei dati UE vs. USA

Heap gestisce endpoint di acquisizione UE e USA separati. Per il traffico SEE e UK l'endpoint UE è il default corretto; mantiene acquisizione, elaborazione e archiviazione all'interno del SEE e riduce l'esposizione a Schrems II che qualsiasi implementazione di analisi in regione USA porta. L'endpoint viene impostato tramite la configurazione dello snippet e non può essere modificato retroattivamente — i dati esistenti rimangono dove sono stati acquisiti per la prima volta. Per i publisher che pianificano un'implementazione Heap vale quindi la pena confermare la regione prima di scalare, e vale la pena documentare la scelta nell'informativa sulla privacy in modo che la catena della base legittima sia pulita dalla raccolta all'archiviazione.

Validare l'integrazione e la traccia di audit

Il passaggio di validazione è quello che i regolatori controllano e che i publisher più spesso saltano. Un'implementazione Heap correttamente integrata deve superare quattro test in sequenza. In primo luogo, una sessione browser pulita con il banner mostrato ma nessuna scelta effettuata deve produrre zero richieste verso heapanalytics.com oltre al fetch del file SDK e zero cookie _hp2_ in document.cookie. In secondo luogo, il rifiuto dell'analisi deve mantenere quello stato — nessuna auto-cattura, nessun identificatore, nessuna registrazione. In terzo luogo, l'accettazione dell'analisi deve produrre il cookie _hp2_id atteso con attributi SameSite corretti e traffico di eventi che fluisce all'endpoint della regione configurata. In quarto luogo, il ritiro del consenso deve interrompere immediatamente ulteriore auto-cattura e replay, scadere i cookie _hp2_, e attivare una richiesta di cancellazione tramite l'API GDPR di Heap.

L'aspettativa della traccia di audit ai sensi delle linee guida EDPB del 2023 sui banner dei cookie e delle rinnovate priorità 2026 della task force è che il publisher possa dimostrare, per qualsiasi evento nel progetto Heap, che l'utente che lo ha generato aveva fornito un consenso valido al momento della cattura. Il pattern standard è impostare la versione del consenso e il timestamp come proprietà utente sull'ID distinto tramite heap.addUserProperties({ consent_version: 'v3', consent_ts: ts }) in modo che qualsiasi evento individuale sia tracciabile fino a una voce del registro del consenso specifica. Un'implementazione correttamente gated, abbinata ad attributi di redazione che sopprimono i campi sensibili per impostazione predefinita e a un percorso di cancellazione che si attiva al ritiro, è ciò che trasforma il modello di auto-cattura di Heap da un rischio di concentrazione normativa in una delle parti più potenti e difendibili dello stack di analisi di prodotto di un publisher.

← Blog Leggi tutto →