Per què Amplitude requereix consentiment

L'Amplitude Browser SDK predeterminat i els SDK mòbils d'Amplitude fan molt més que registrar pàgines vistes. En la inicialització estableixen un identificador de dispositiu a l'emmagatzematge de primera part, generen un identificador de sessió, capturen el referent, analitzen els identificadors UTM i de clic de l'URL, i comencen a posar en cua els esdeveniments capturats automàticament: vistes de pàgina, clics en elements, interaccions amb formularis, descàrregues de fitxers i — en les darreres versions — repeticions de sessió. També enriquiran aquests esdeveniments amb geolocalització derivada de l'IP, dades de dispositiu derivades de l'agent d'usuari i, si es configura, enriquiment de tercers de socis de dades.

Cadascun d'aquests passos implica una base legal de consentiment diferent. Emmagatzemar un identificador de dispositiu és una operació d'emmagatzematge i accés d'acord amb l'article 5(3) de la Directiva ePrivacy, que requereix un consentiment previ, lliurement donat, específic, informat i inequívoc a l'Espai Econòmic Europeu, el Regne Unit i qualsevol jurisdicció que hagi importat el mateix estàndard. Capturar esdeveniments de comportament vinculats a aquest identificador és un tractament de dades personals en virtut del GDPR. Enriquir amb dades de tercers introdueix una segona relació de responsable del tractament. La CCPA i la CPRA classifiquen el mateix tractament com una venda o compartició, llevat que l'editor tingui un contracte de proveïdor de serveis correctament delimitat amb Amplitude, que existeix però només si la integració es configura per desactivar les funcions publicitàries.

Què recull Amplitude abans del consentiment — i què cal suprimir

L'error d'implementació més comú és tractar Amplitude com una eina d'anàlisi lleugera que pot funcionar al costat del banner de cookies. No pot. En una crida predeterminada a amplitude.init() el SDK escriurà, durant el primer renderitzat de la pàgina, almenys una entrada de cookie o d'emmagatzematge local, enviarà una crida d'identificació i començarà a emmagatzemar esdeveniments en memòria intermèdia. Res d'això és permissible abans que un usuari hagi acceptat afirmativament la categoria de consentiment pertinent.

Una integració conforme ha de retardar per tant amplitude.init() fins que la CMP hagi indicat que s'ha concedit la categoria de consentiment analític. El SDK no s'hauria de carregar en absolut des d'una etiqueta <script> controlada per consentiment que depèn del senyal de propòsit 8 (anàlisi) o propòsit 1 (emmagatzematge i accés) de la CMP, depenent del marc que exposi la CMP. Si el SDK s'ha de carregar abans — per exemple perquè és part del codi de l'aplicació i no es pot recuperar de manera diferida — la crida d'inicialització ha de passar defaultTracking: false i optOut: true perquè no s'emeti cap esdeveniment fins que no es registri el consentiment, i llavors un esdeveniment d'adhesió diferit hauria de canviar aquests indicadors.

Les cookies i l'emmagatzematge que escriu Amplitude

Browser SDK 2.x escriu per defecte una sola cookie de primera part amb el nom AMP_{apiKey}, amb una caducitat d'un any, que conté l'identificador del dispositiu i les metadades de la sessió. Les versions antigues també escrivien amplitude_id_{apiKey}. Els SDK mòbils persisteixen el mateix identificador dins de l'emmagatzematge en sandbox de l'aplicació. La repetició de sessió afegeix una segona cookie, AMP_MKTG_{apiKey}, i els socis d'enriquiment d'Amplitude poden establir cookies de tercers addicionals si els mòduls de segmentació d'experiments o d'audiències estan habilitats. Tots ells no són essencials i requereixen consentiment.

Mapeig d'Amplitude als marcs de consentiment

Amplitude no implementa de manera nativa Google Consent Mode v2, IAB TCF ni IAB Global Privacy Platform. Això no és un defecte — Amplitude és una plataforma d'anàlisi de primera part, no un proveïdor de tecnologia publicitària — però significa que la responsabilitat d'integració recau en l'editor. El patró que funciona a la pràctica és tractar cada mòdul d'Amplitude com una porta de consentiment separada i vincular-lo a un senyal específic que ja exposa la CMP.

• Els esdeveniments d'anàlisi bàsics es vinculen al propòsit d'anàlisi. En termes del TCF, això és més freqüentment el propòsit 8 (mesurar el rendiment del contingut) combinat amb el propòsit 1 (emmagatzemar i/o accedir a informació). Per a Google Consent Mode, això s'associa a analytics_storage.
• La repetició de sessió hauria d'estar darrere d'un senyal més estricte. La repetició captura el DOM renderitzat, inclosos els valors dels formularis, llevat que s'emmascarin explícitament, de manera que és adequada una adhesió separada de preferences o functional, i la repetició hauria d'estar desactivada per defecte fins i tot quan s'hagi concedit l'anàlisi.
• Les audiències, les cohorts i l'enriquiment de tercers es vinculen al propòsit de màrqueting. En termes del TCF, això és el propòsit 7 (mesurar el rendiment dels anuncis) o el propòsit 9 (aplicar investigació de mercat). Per a Google Consent Mode, això s'associa a ad_storage i ad_user_data.
• L'experimentació — Amplitude Experiment pot funcionar amb una assignació anònima i efímera sota una base d'interès legítim, però l'assignació persistent vinculada a un identificador d'usuari requereix el mateix consentiment que l'anàlisi bàsica.

El patró d'integració que funciona

La implementació de referència que supera la revisió d'un regulador té quatre parts mòbils: una CMP que exposa un esdeveniment en temps real quan l'usuari canvia el consentiment, un carregador de SDK diferit que només recupera Amplitude després que s'activi aquest esdeveniment per a la categoria pertinent, un guardià a nivell de sessió que respecta la exclusió voluntària sense perdre l'identificador de dispositiu anònim anterior de l'usuari allà on la llei ho permet, i un pont del costat del servidor per als esdeveniments que realment requereixen recollida independentment del consentiment — com la telemetria de seguretat o la detecció de frau — enrutats a través d'un punt final separat amb la seva pròpia base legal.

Implementació web

Al web, el patró més net és exposar l'estat de consentiment de la CMP mitjançant un objecte window.__cmp_consent o la devolució de trucada estàndard __tcfapi, i després tenir un petit script d'arrencada que se subscrigui als canvis de consentiment. Quan el consentiment analític passa de false a true, l'arrencada recupera el SDK d'Amplitude des del CDN gestionat per la CMP, crida amplitude.init(apiKey, undefined, { defaultTracking: true }) i reprodueix tots els esdeveniments que eren en cua a la memòria mentre el consentiment estava pendent. Quan el consentiment torna a false, l'arrencada crida amplitude.setOptOut(true), esborra la cookie AMP_ mitjançant la caducitat de document.cookie i elimina qualsevol estat en memòria. De manera crítica, l'arrencada mai ha d'inicialitzar Amplitude de manera diferida en el mateix flux de sol·licitud que el renderitzat del banner: el SDK ha d'esperar una concessió explícita.

Implementació mòbil

A iOS, l'equivalent és mantenir el marc d'Amplitude importat però diferir Amplitude.instance().initialize(apiKey: apiKey) fins que el flux de consentiment integrat a l'aplicació hagi retornat un senyal analític positiu. El missatge ATT és una preocupació separada: ATT regula el IDFA, mentre que l'identificador d'Amplitude és el UUID propi del SDK emmagatzemat al sandbox de l'aplicació. Tots dos requereixen consentiment a l'EEE, però les bases legals i els missatges són diferents. A Android, la mateixa lògica s'aplica amb Amplitude.getInstance().initializeApolloClient() o l'equivalent depenent de la versió del SDK.

Mode de servidor

Amplitude admet la ingesta al costat del servidor mitjançant l'API HTTP V2. Els esdeveniments del costat del servidor no estan exempts del consentiment — la base legal segueix les dades, no el transport — però la ingesta al costat del servidor ofereix a l'editor un control total sobre quins camps s'envien, cosa que facilita respectar el consentiment parcial. Un patró comú és capturar un conjunt d'esdeveniments mínims essencials al costat del servidor sota interès legítim, i enriquir aquests esdeveniments amb detalls de comportament només després que l'usuari hagi concedit el consentiment analític al client.

Validació de la integració

El pas de validació és el que els editors ometen amb més freqüència i els reguladors comproven amb més freqüència. Un desplegament d'Amplitude correctament integrat hauria de superar quatre comprovacions. Primer, un navegador amb el banner de consentiment mostrat però sense cap elecció feta hauria de produir zero sol·licituds a api.amplitude.com o api.eu.amplitude.com i zero cookies AMP_ a document.cookie. Segon, rebutjar la categoria d'anàlisi hauria de mantenir aquest estat — cap esdeveniment, cap cookie, cap entrada d'emmagatzematge local amb un prefix AMP_. Tercer, acceptar l'anàlisi hauria de produir un únic identify seguit de trànsit d'esdeveniments, i la cookie AMP_ hauria d'aparèixer amb un atribut SameSite coherent amb la política de CMP de l'editor. Quart, retirar el consentiment a posteriori hauria d'aturar immediatament els esdeveniments posteriors i esborrar els identificadors emmagatzemats — una neteja retardada és una constatació.

El rastre d'auditoria és important per separat. D'acord amb les directrius del banner de cookies de l'EDPB de 2023 i les prioritats renovades del grup de treball de 2026, els reguladors esperen que l'editor pugui demostrar, per a qualsevol esdeveniment donat del projecte Amplitude, que l'usuari que el va generar havia donat un consentiment vàlid en el moment de la captura. Això requereix que el registre de consentiment de la CMP sigui consultable per identificador de dispositiu o identificador de sessió, i que la càrrega útil de l'esdeveniment d'Amplitude porti un camp de versió de consentiment que es vinculi de tornada a aquest registre. Emmagatzemar la cadena de consentiment com a propietat d'usuari personalitzada en cada esdeveniment és la manera més senzilla de fer que aquest vincle sigui auditable.

Elecció de la regió i la residència de dades correctes

Amplitude opera dues regions de producció: els EUA (api.amplitude.com) i la UE (api.eu.amplitude.com). Per al trànsit de l'EEE i el Regne Unit, la regió de la UE és el valor predeterminat correcte: manté les dades dins de l'EEE i redueix la superfície de risc de transferència que la decisió Schrems II i el Marc de Privacitat de Dades UE-EUA han fet central per a qualsevol revisió d'anàlisi. Canviar de regió no és retroactiu: les dades existents es queden on van ser primer ingerides. Per als editors que planegen un desplegament de CMP, per tant, val la pena confirmar la regió abans d'escalar i documentar l'elecció en l'avís de privacitat perquè la cadena de bases legals sigui neta des de la recollida fins a l'emmagatzematge. Una regió triada correctament, combinada amb un SDK correctament controlat i un registre de consentiment consultable, és el que converteix un desplegament d'Amplitude d'un risc regulador en una part defensable de la pila d'anàlisi.