Perché PostHog richiede il consenso — e perché la risposta non è la stessa per ogni modulo

Il web SDK di PostHog non è un tag di pagina passivo. Con un'inizializzazione predefinita, l'SDK imposta una o più voci di persistenza di prima parte — per impostazione predefinita uno schema combinato di cookie e localStorage codificato sotto ph_{projectKey}_posthog — genera un identificatore distinto stabile, acquisisce il pageview iniziale con referrer, parametri UTM e identificatori di clic, e apre un canale eventi di lunga durata all'host di ingestione configurato. Se il replay della sessione è abilitato a livello di progetto, l'SDK inizia inoltre a trasmettere in streaming una registrazione continua del DOM renderizzato, delle coordinate del mouse e degli eventi di input. Se i feature flag sono configurati, l'SDK li valuta rispetto all'identificatore distinto, persiste le decisioni per la sessione e emette un evento $feature_flag_called per ogni valutazione.

Ciascuna di queste attività si associa a un diverso cancello di consenso. Persistere un identificatore distinto è 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 lo SEE, nel Regno Unito e in qualsiasi giurisdizione che abbia importato lo stesso standard. Acquisire eventi comportamentali è un trattamento di dati personali ai sensi del GDPR perché la combinazione di identificatore, indirizzo IP e traccia comportamentale è sufficiente a individuare una persona. Il replay della sessione rientra in una categoria separata e più rigorosa ai sensi delle linee guida sul replay delle sessioni dell'EDPB — il replay acquisisce il DOM renderizzato e qualsiasi campo di input non mascherato e richiede un consenso esplicito e granulare che sia distinto dal consenso analitico generico. La valutazione dei feature flag è quella più sottile: un controllo di flag che restituisce un valore booleano non richiede di per sé il consenso, ma persistere l'assegnazione del flag dell'utente a un identificatore stabile tra le sessioni lo richiede, perché è così che la sperimentazione basata sui flag crea dati tracciabili a livello utente.

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

Il PostHog Browser SDK predefinito scrive quanto segue all'inizializzazione: una voce combinata di cookie e localStorage sotto ph_{projectKey}_posthog contenente l'identificatore distinto, l'identificatore di sessione e le decisioni sui feature flag, più, quando il replay della sessione è abilitato, un buffer di registrazione in memoria aggiuntivo che viene scaricato sull'endpoint di ingestione ogni pochi secondi. L'SDK invia anche un evento $pageview immediato e, se l'acquisizione automatica è attiva, ogni successivo clic, interazione con i moduli e rage-click sulla pagina.

Il pattern raccomandato è quello di inizializzare PostHog con opt_out_capturing_by_default: true e disable_session_recording: true, poi invertire entrambi i flag una volta che il banner di consenso restituisce un segnale positivo. Questa è la postura di integrazione che la documentazione di PostHog ora raccomanda, ed è la postura che sopravvive alla revisione di un regolatore perché inverte il default: nulla viene acquisito finché il consenso non viene registrato, e l'SDK fornisce una transizione pulita anziché un retrofit con stato.

I cookie, le voci localStorage e gli identificatori che PostHog persiste

Il Browser SDK 1.x scrive una voce di persistenza per progetto, codificata sotto ph_{projectKey}_posthog, con una scadenza di 365 giorni per impostazione predefinita. L'opzione di init persistence controlla il meccanismo sottostante: solo cookie, solo localStorage, localStorage+cookie (il default), sessionStorage o memory. Per un deployment con consenso come priorità, la persistenza memory è il default corretto quando il consenso non è ancora stato concesso — garantisce che nessun identificatore sopravviva alla sessione di pagina — con una transizione a localStorage+cookie una volta che il consenso si attiva. L'SDK scrive anche un marker opt-in o opt-out sotto __ph_opt_in_out_{projectKey} per ricordare la scelta dell'utente tra le visite; quel marker stesso è un cookie strettamente necessario perché persiste una decisione di consenso.

Mappare i moduli PostHog ai framework di consenso

PostHog non implementa nativamente l'IAB TCF o l'IAB Global Privacy Platform, e non è costruito come fornitore ad-tech. Tuttavia si integra con Google Consent Mode v2 attraverso il bridging lato publisher, espone un'API nativa di opt-in e opt-out, e rispetta l'header Do Not Track tramite l'opzione di init respect_dnt. Il pattern che funziona in produzione tratta ogni modulo PostHog come un cancello separato legato a un segnale CMP specifico.

• Gli eventi di analisi del prodotto si legano allo scopo analitico. In termini TCF questo è più comunemente lo scopo 8 (misurare le prestazioni dei contenuti) combinato con lo scopo 1 (archiviare e/o accedere a informazioni). Per Consent Mode questo si mappa su analytics_storage.
• Il replay della sessione si trova dietro un cancello più rigoroso. Il replay della sessione di PostHog acquisisce il DOM renderizzato e qualsiasi campo di input non mascherato, quindi un opt-in a livello di preferenze o di ricerca distinto dall'analisi è la postura difendibile ai sensi delle linee guida dell'EDPB.
• I feature flag e la sperimentazione possono essere eseguiti con una valutazione effimera in memoria sotto una base di interesse legittimo quando l'obiettivo è solo variare la pagina renderizzata. L'assegnazione persistente dei flag legata a un identificatore stabile tra le sessioni richiede lo stesso consenso dell'analisi, perché è allora che il flag diventa un punto dati a livello utente tracciabile.
• I sondaggi e il feedback si legano allo stesso cancello del replay della sessione quando raccolgono input in testo libero, o al cancello analitico quando raccolgono solo valutazioni o risposte a selezione singola.

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 PostHog con acquisizione e replay disabilitati, un listener di consenso che inverte opt_in_capturing e il commutatore di registrazione quando i cancelli rilevanti si aprono, e un percorso di revoca che chiama opt_out_capturing, interrompe il buffer di replay e cancella gli identificatori persistenti tramite l'API di reset dell'SDK.

Implementazione web

Il pattern più pulito è caricare il PostHog SDK su ogni pagina ma chiamare posthog.init(apiKey, { api_host: 'https://eu.posthog.com', opt_out_capturing_by_default: true, disable_session_recording: true, persistence: 'memory', respect_dnt: true }) come bootstrap iniziale. Iscriversi all'evento di modifica del consenso del CMP. Quando la categoria analytics passa a true, chiamare posthog.set_config({ persistence: 'localStorage+cookie' }) seguito da posthog.opt_in_capturing(); questo riabilita l'acquisizione degli eventi e la transizione della persistenza inizia a scrivere l'identificatore distinto. Quando la categoria replay della sessione passa a true, chiamare posthog.startSessionRecording(). Quando uno dei cancelli viene revocato, chiamare posthog.opt_out_capturing() per il cancello analytics o posthog.stopSessionRecording() per il cancello replay, far scadere le voci di persistenza rilevanti tramite posthog.reset(), e inviare una richiesta di cancellazione tramite l'API GDPR di PostHog se l'utente ha invocato il proprio diritto alla cancellazione.

Selezione della regione: PostHog Cloud US vs EU vs self-hosted

PostHog gestisce due regioni cloud — USA (us.posthog.com) e EU (eu.posthog.com) — e supporta le installazioni self-hosted sull'infrastruttura del cliente. Per il traffico SEE e Regno Unito, il cloud EU è il default corretto; mantiene ingestione, elaborazione e archiviazione all'interno dello SEE e riduce l'esposizione a Schrems II che qualsiasi deployment analitico nella regione USA comporta. L'opzione di init api_host fissa la regione. PostHog self-hosted sposta l'intero stack sull'infrastruttura del publisher stesso, che è la postura di residenza dei dati più solida ma non rimuove le obbligazioni di consenso — la base giuridica segue i dati, non l'operatore. Qualsiasi opzione scelta deve essere riflessa nell'informativa sulla privacy e nel registro del trattamento del titolare.

Acquisizione lato server

PostHog supporta l'ingestione di eventi lato server tramite gli SDK Python, Node, Go, Ruby e PHP. Gli eventi lato server non sono esenti dal consenso — la base giuridica segue i dati — ma l'ingestione lato server dà al publisher il pieno controllo su quali campi vengono emessi e quando. Un pattern comune è acquisire un insieme minimo di eventi essenziali lato server sotto interesse legittimo, poi arricchire quegli eventi con dettagli comportamentali dal client solo dopo che l'utente ha concesso il consenso analitico. Gli eventi lato server e lato client si uniscono sullo stesso identificatore distinto quando il consenso si è attivato; prima del consenso, gli eventi lato server vengono emessi con un identificatore anonimo ed effimero che viene reimpostato ad ogni sessione.

Validazione dell'integrazione e della traccia di audit

Il passo di validazione è quello che i regolatori controllano e che i publisher più spesso saltano. Un deployment PostHog correttamente integrato deve superare quattro test in sequenza. Primo, una sessione browser pulita con il banner mostrato ma nessuna scelta fatta deve produrre zero richieste all'api_host configurato oltre il fetch del file SDK, zero cookie ph_ in document.cookie e zero voci ph_ in localStorage. Secondo, rifiutare l'analisi deve mantenere quello stato — nessuna acquisizione, nessuna registrazione, nessun identificatore persistente. Terzo, accettare l'analisi deve produrre un evento $opt_in immediato, la voce di persistenza attesa ph_{projectKey}_posthog con gli attributi SameSite corretti e il traffico degli eventi che fluisce verso l'host configurato. Quarto, revocare il consenso in seguito deve interrompere immediatamente ulteriori acquisizioni e replay, far scadere gli identificatori persistenti e attivare una richiesta di cancellazione tramite l'API GDPR di PostHog se l'utente ha invocato la cancellazione.

L'aspettativa sulla traccia di audit ai sensi delle linee guida sui banner cookie del 2023 dell'EDPB e delle priorità della task force 2026 rinnovate è che il publisher possa dimostrare, per qualsiasi evento nel progetto PostHog, che l'utente che lo ha generato aveva dato un consenso valido al momento dell'acquisizione. Il pattern standard consiste nell'impostare la versione del consenso e il timestamp come proprietà della persona sull'ID distinto tramite posthog.setPersonProperties({ consent_version: 'v3', consent_ts: ts }) in modo che qualsiasi evento individuale sia tracciabile a una specifica voce del log di consenso. Un deployment correttamente gated, abbinato a una selezione della regione che corrisponde al pubblico, a una persistenza che per default usa la memoria e a un percorso di cancellazione che si attiva al momento della revoca, è ciò che trasforma PostHog da un rischio di concentrazione normativa in un centro difendibile dello stack di analisi del prodotto.