Perché Amplitude richiede il consenso

L'SDK Browser di Amplitude predefinito e gli SDK mobile di Amplitude fanno molto di più che registrare le visualizzazioni di pagina. All'inizializzazione impostano un identificatore di dispositivo nello storage di prima parte, generano un identificatore di sessione, catturano il referrer, analizzano UTM e identificatori di click dall'URL, e iniziano a mettere in coda gli eventi catturati automaticamente: visualizzazioni di pagina, click su elementi, interazioni con form, download di file e — nelle ultime versioni — session replay. Arricchiranno anche questi eventi con geolocalizzazione derivata dall'IP, dati del dispositivo derivati dallo user-agent, e, se configurati, arricchimento di terze parti da partner dei dati.

Ciascuno di questi passaggi coinvolge una base giuridica del consenso separata. Memorizzare un identificatore di dispositivo è 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 nello Spazio Economico Europeo, nel Regno Unito e in qualsiasi giurisdizione che abbia importato lo stesso standard. La cattura di eventi comportamentali legati a tale identificatore è trattamento di dati personali ai sensi del GDPR. L'arricchimento con dati di terze parti introduce una seconda relazione tra titolari. CCPA e CPRA classificano lo stesso trattamento come vendita o condivisione a meno che l'editore non disponga di un contratto con fornitore di servizi adeguatamente delimitato con Amplitude — disponibile, ma solo se l'integrazione è configurata per disabilitare le funzionalità pubblicitarie.

Cosa raccoglie Amplitude prima del consenso — e cosa bisogna sopprimere

L'errore di implementazione più comune è trattare Amplitude come un leggero strumento di analytics che può funzionare accanto al banner cookie. Non può. Su una chiamata amplitude.init() predefinita, l'SDK, al primo paint della pagina, scriverà almeno un'entrata di cookie o local storage, invierà una chiamata identify e inizierà a bufferizzare gli eventi. Niente di tutto ciò è consentito prima che un utente abbia accettato affermativamente la categoria di consenso pertinente.

Un'integrazione conforme deve quindi ritardare amplitude.init() finché la CMP non ha segnalato che la categoria di consenso per l'analytics è stata concessa. L'SDK non deve essere caricato affatto da un tag <script> con gate di consenso che dipende dal segnale di purpose 8 (analytics) o purpose 1 (archiviazione e accesso) della CMP, a seconda del framework esposto dalla CMP. Se l'SDK deve essere caricato prima — ad esempio perché è incluso nel codice dell'applicazione e non può essere recuperato in modo lazy — la chiamata di inizializzazione dovrebbe passare defaultTracking: false e optOut: true in modo che non vengano emessi eventi finché il consenso non viene registrato, e poi un evento di opt-in differito dovrebbe ribaltare quei flag.

I cookie e lo storage che Amplitude scrive

L'SDK Browser 2.x scrive un singolo cookie di prima parte denominato AMP_{apiKey} per impostazione predefinita, con scadenza di un anno, contenente l'identificatore del dispositivo e i metadati di sessione. Le versioni precedenti scrivevano anche amplitude_id_{apiKey}. Gli SDK mobile mantengono lo stesso identificatore all'interno dello storage sandboxed dell'applicazione. Il session replay aggiunge un secondo cookie, AMP_MKTG_{apiKey}, e i partner di arricchimento di Amplitude possono impostare cookie di terze parti aggiuntivi se i moduli di targeting degli esperimenti o di audience sono abilitati. Tutti questi sono non essenziali e richiedono il consenso.

Mappatura di Amplitude ai framework di consenso

Amplitude non implementa nativamente Google Consent Mode v2, lo IAB TCF o lo IAB Global Privacy Platform. Questo non è un difetto — Amplitude è una piattaforma di analytics di prima parte, non un fornitore ad-tech — ma significa che la responsabilità dell'integrazione spetta all'editore. Il pattern che funziona nella pratica è trattare ogni modulo di Amplitude come un gate di consenso separato e vincolarlo a un segnale specifico già esposto dalla CMP.

• Gli eventi di analytics core sono vincolati alla purpose di analytics. In termini TCF si tratta più comunemente della purpose 8 (misurare le performance dei contenuti) combinata con la purpose 1 (memorizzare e/o accedere alle informazioni). Per Google Consent Mode questo si mappa su analytics_storage.
• Il session replay dovrebbe essere dietro un segnale più restrittivo. Il replay cattura il DOM renderizzato, inclusi i valori dei form a meno che non siano esplicitamente mascherati, quindi un opt-in separato di preferences o functional è appropriato, e il replay dovrebbe essere disattivato per impostazione predefinita anche quando l'analytics è concesso.
• Audience, cohort e arricchimento di terze parti sono vincolati alla purpose di marketing. In termini TCF si tratta della purpose 7 (misurare le performance pubblicitarie) o della purpose 9 (applicare ricerche di mercato). Per Google Consent Mode questo si mappa su ad_storage e ad_user_data.
• La sperimentazione — Amplitude Experiment può funzionare con allocazione anonima ed effimera su base di legittimo interesse, ma l'allocazione persistente legata a un identificatore utente richiede lo stesso consenso dell'analytics core.

Il pattern di integrazione che funziona

L'implementazione di riferimento che supera la revisione di un regolatore ha quattro parti in movimento: una CMP che espone un evento in tempo reale quando l'utente cambia il consenso, un loader SDK differito che recupera Amplitude solo dopo che quell'evento si attiva per la categoria pertinente, un guardia a livello di sessione che rispetta l'opt-out senza perdere il precedente identificatore di dispositivo anonimo dell'utente dove la legge lo consente, e un bridge lato server per gli eventi che richiedono genuinamente la raccolta indipendentemente dal consenso — come la telemetria di sicurezza o il rilevamento delle frodi — instradati attraverso un endpoint separato con la propria base giuridica.

Implementazione web

Sul web, il pattern più pulito è esporre lo stato del consenso della CMP tramite un oggetto window.__cmp_consent o il callback standard __tcfapi, quindi avere un piccolo script bootstrap che si iscrive ai cambiamenti di consenso. Quando il consenso per l'analytics passa da false a true, il bootstrap recupera l'SDK di Amplitude dalla CDN gestita dalla CMP, chiama amplitude.init(apiKey, undefined, { defaultTracking: true }), e riproduce tutti gli eventi che erano stati messi in coda in memoria mentre il consenso era in sospeso. Quando il consenso torna a false, il bootstrap chiama amplitude.setOptOut(true), cancella il cookie AMP_ tramite la scadenza di document.cookie, e rimuove qualsiasi stato in memoria. Criticamente, il bootstrap non deve mai inizializzare Amplitude in modo lazy nello stesso flusso di richiesta del render del banner — l'SDK deve aspettare una concessione esplicita.

Implementazione mobile

Su iOS l'equivalente è mantenere il framework Amplitude importato ma differire Amplitude.instance().initialize(apiKey: apiKey) fino a quando il flusso di consenso in-app ha restituito un segnale positivo di analytics. Il prompt ATT è una questione separata: ATT governa l'IDFA, mentre l'identificatore di Amplitude è l'UUID proprio dell'SDK memorizzato nella sandbox dell'app. Entrambi richiedono il consenso nell'EEA, ma le basi giuridiche e i prompt sono distinti. Su Android si applica la stessa logica con Amplitude.getInstance().initializeApolloClient() o l'equivalente a seconda della versione dell'SDK.

Modalità lato server

Amplitude supporta l'ingestione lato server tramite l'HTTP V2 API. Gli eventi lato server non sono esenti dal consenso — la base giuridica segue i dati, non il trasporto — ma l'ingestione lato server dà all'editore il pieno controllo su quali campi vengono inviati, il che rende più facile rispettare il consenso parziale. Un pattern comune è catturare un set minimo di eventi essenziali lato server sotto legittimo interesse, e arricchire quegli eventi con dettagli comportamentali solo dopo che l'utente ha concesso il consenso per l'analytics sul client.

Validare l'integrazione

La fase di validazione è quella che gli editori saltano più spesso e che i regolatori verificano più spesso. Un deployment di Amplitude correttamente integrato dovrebbe superare quattro controlli. Primo, un browser con il banner di consenso mostrato ma nessuna scelta effettuata dovrebbe produrre zero richieste a api.amplitude.com o api.eu.amplitude.com e zero cookie AMP_ in document.cookie. Secondo, rifiutare la categoria analytics dovrebbe mantenere quello stato — nessun evento, nessun cookie, nessuna voce di local storage con prefisso AMP_. Terzo, accettare l'analytics dovrebbe produrre un singolo identify seguito dal traffico di eventi, e il cookie AMP_ dovrebbe apparire con un attributo SameSite coerente con la policy CMP dell'editore. Quarto, ritirare il consenso dopo il fatto dovrebbe immediatamente fermare ulteriori eventi e cancellare gli identificatori memorizzati — una pulizia ritardata è un rilievo.

Il registro di audit è importante separatamente. In base alle linee guida sui banner cookie dell'EDPB del 2023 e alle priorità rinnovate della task force del 2026, i regolatori si aspettano che l'editore sia in grado di dimostrare, per qualsiasi evento nel progetto Amplitude, che l'utente che lo ha generato aveva dato un consenso valido al momento della cattura. Ciò richiede che il registro di consenso della CMP sia interrogabile per identificatore di dispositivo o identificatore di sessione, e che il payload dell'evento Amplitude porti un campo della versione del consenso che si ricollega a quel registro. Memorizzare la stringa di consenso come proprietà utente personalizzata su ogni evento è il modo più semplice per rendere quel collegamento verificabile.

Scegliere la regione giusta e la residenza dei dati

Amplitude opera due regioni di produzione: gli USA (api.amplitude.com) e l'UE (api.eu.amplitude.com). Per il traffico EEA e UK la regione UE è il default corretto — mantiene i dati all'interno dell'EEA e riduce la superficie di rischio di trasferimento che la sentenza Schrems II e l'EU-US Data Privacy Framework hanno reso centrale a qualsiasi revisione di analytics. Cambiare regione non è retroattivo: i dati esistenti rimangono dove sono stati ingeriti per la prima volta. Per gli editori che pianificano un rollout della CMP 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 giuridica sia pulita dalla raccolta allo storage. Una regione correttamente scelta, abbinata a un SDK correttamente limitato e a un registro di consenso interrogabile, è ciò che trasforma un deployment di Amplitude da rischio normativo in parte difendibile dello stack di analytics.