Por que Amplitude require consentimento

O SDK do navegador Amplitude por defecto e os SDK móbiles de Amplitude fan moito máis que rexistrar visitas a páxinas. Na inicialización establecen un identificador de dispositivo no almacenamento de primeira parte, xeran un identificador de sesión, capturan o referente, analizan os identificadores UTM e de clic da URL e comezan a pór en cola eventos capturados automaticamente: visitas a páxinas, clics en elementos, interaccións con formularios, descargas de ficheiros e — nas últimas versións — reproducións de sesión. Tamén enriquecen eses eventos con xeolocalización derivada do IP, datos de dispositivo derivados do user-agent e, se está configurado, enriquecemento de terceiros a partir de socios de datos.

Cada un deses pasos implica unha base xurídica de consentimento separada. O almacenamento dun identificador de dispositivo é unha operación de almacenamento e acceso segundo o artigo 5(3) da Directiva ePrivacy, que require un consentimento previo, libremente dado, específico, informado e inequívoco no Espazo Económico Europeo, no Reino Unido e en calquera xurisdicción que importase o mesmo estándar. A captura de eventos de comportamento vinculados a ese identificador é o procesamento de datos persoais conforme o RGPD. O enriquecemento con datos de terceiros introduce unha segunda relación de responsable do tratamento. O CCPA e o CPRA clasifican o mesmo procesamento como unha venda ou compartición a menos que o editor teña un contrato de provedor de servizos axeitadamente delimitado con Amplitude — que está dispoñible, pero só se a integración está configurada para desactivar as funcionalidades publicitarias.

O que Amplitude recolle antes do consentimento — e o que debes suprimir

O erro de implementación máis común é tratar Amplitude como unha ferramenta de análise lixeira que pode executarse xunto á banner de cookies. Non pode. Nunha chamada amplitude.init() por defecto, o SDK, no primeiro pintado da páxina, escribirá polo menos unha cookie ou entrada de almacenamento local, enviará unha chamada identify e comezará a poñer eventos en buffer. Nada diso é permisible antes de que un usuario aceptase afirmativamente a categoría de consentimento relevante.

Unha integración conforme debe polo tanto atrasar amplitude.init() ata que a CMP sinalice que se concedeu a categoría de consentimento de análise. O SDK non debe cargarse en absoluto desde unha etiqueta <script> limitada por consentimento que dependa do sinal de propósito 8 (análise) ou propósito 1 (almacenamento e acceso) da CMP, dependendo de que marco expoña a CMP. Se o SDK debe cargarse antes — por exemplo porque está empaquetado no código da aplicación e non se pode obter de xeito perezoso — a chamada de inicialización debe pasar defaultTracking: false e optOut: true para que non se emita ningún evento ata que se rexistre o consentimento, e despois un evento de opt-in deferido debe cambiar eses indicadores.

As cookies e o almacenamento que Amplitude escribe

O SDK Browser 2.x escribe por defecto unha única cookie de primeira parte chamada AMP_{apiKey} cun prazo de caducidade dun ano, que contén o identificador de dispositivo e os metadatos de sesión. As versións máis antigas tamén escribían amplitude_id_{apiKey}. Os SDK móbiles persisten o mesmo identificador dentro do almacenamento en sandbox da aplicación. A reprodución de sesión engade unha segunda cookie, AMP_MKTG_{apiKey}, e os socios de enriquecemento de Amplitude poden establecer cookies de terceiros adicionais se os módulos de orientación de experimentos ou de audiencias están activados. Todos estes son non esenciais e requiren consentimento.

Mapeamento de Amplitude nos marcos de consentimento

Amplitude non implementa de xeito nativo Google Consent Mode v2, IAB TCF nin a IAB Global Privacy Platform. Isto non é un defecto — Amplitude é unha plataforma de análise de primeira parte, non un provedor de tecnoloxía publicitaria — pero significa que a responsabilidade de integración recae no editor. O patrón que funciona na práctica é tratar cada módulo de Amplitude como unha porta de consentimento separada e vinculalo a un sinal específico que a CMP xa expón.

• Os eventos de análise principal vincúlanse ao propósito de análise. En termos de TCF, isto é máis comunmente o propósito 8 (medir o rendemento do contido) combinado co propósito 1 (almacenar e/ou acceder a información). Para Google Consent Mode isto mapea a analytics_storage.
• A reprodución de sesión debe estar detrás dun sinal máis estrito. A reprodución captura o DOM renderizado, incluíndo valores de formulario a menos que se enmascare explicitamente, polo que un opt-in separado de preferencias ou funcional é apropiado, e a reprodución debe estar desactivada por defecto mesmo cando se concede a análise.
• Audiencias, cohortes e enriquecemento de terceiros vincúlanse ao propósito de marketing. En termos de TCF, isto é o propósito 7 (medir o rendemento dos anuncios) ou o propósito 9 (aplicar investigación de mercado). Para Google Consent Mode isto mapea a ad_storage e ad_user_data.
• Experimentación — Amplitude Experiment pode executarse con asignación anónima e efémera baixo unha base de interese lexítimo, pero a asignación persistente vinculada a un identificador de usuario require o mesmo consentimento que a análise principal.

O patrón de integración que funciona

A implementación de referencia que supera a revisión dun regulador ten catro partes móbiles: unha CMP que expón un evento en tempo real cando o usuario cambia o consentimento, un cargador de SDK diferido que só obtén Amplitude despois de que ese evento se active para a categoría relevante, un garda a nivel de sesión que respecta o opt-out sen perder o identificador de dispositivo anónimo anterior do usuario onde a lei o permite, e unha ponte do lado do servidor para os eventos que realmente requiren recollida independentemente do consentimento — como a telemetría de seguridade ou a detección de fraude — encamiñados a través dun endpoint separado coa súa propia base xurídica.

Implementación web

Na web, o patrón máis limpo é expor o estado de consentimento da CMP a través dun obxecto window.__cmp_consent ou o callback estándar __tcfapi, e despois ter un pequeno script bootstrap que se subscriba aos cambios de consentimento. Cando o consentimento de análise pasa de false a true, o bootstrap obtén o SDK de Amplitude desde o CDN xestionado pola CMP, chama a amplitude.init(apiKey, undefined, { defaultTracking: true }) e reproduce calquera evento que estivese na cola na memoria mentres o consentimento estaba pendente. Cando o consentimento volve a false, o bootstrap chama a amplitude.setOptOut(true), elimina a cookie AMP_ a través da caducidade de document.cookie e elimina calquera estado en memoria. De xeito crítico, o bootstrap nunca debe inicializar Amplitude de xeito perezoso no mesmo fluxo de solicitude que o renderizado do banner — o SDK debe esperar a unha concesión explícita.

Implementación móbil

En iOS o equivalente é manter o marco Amplitude importado pero atrasar Amplitude.instance().initialize(apiKey: apiKey) ata que o fluxo de consentimento na aplicación retorne un sinal de análise positivo. A solicitude ATT é unha preocupación separada: ATT rexe o IDFA, mentres que o identificador de Amplitude é o UUID propio do SDK almacenado no sandbox da aplicación. Ambos requiren consentimento no EEE, pero as bases xurídicas e as solicitudes son distintas. En Android aplícase a mesma lóxica con Amplitude.getInstance().initializeApolloClient() ou o equivalente dependendo da versión do SDK.

Modo do lado do servidor

Amplitude admite a inxestión do lado do servidor a través da API HTTP V2. Os eventos do lado do servidor non están exentos do consentimento — a base xurídica segue os datos, non o transporte — pero a inxestión do lado do servidor dá ao editor un control total sobre que campos se envían, o que facilita o cumprimento do consentimento parcial. Un patrón común é capturar un conxunto mínimo de eventos esenciais unicamente do lado do servidor baixo interese lexítimo, e só enriquecer eses eventos con detalles de comportamento despois de que o usuario concedese o consentimento de análise no cliente.

Validación da integración

O paso de validación é o que os editores omiten con máis frecuencia e os reguladores verifican con máis frecuencia. Un despregamento de Amplitude correctamente integrado debe superar catro comprobacións. Primeiro, un navegador co banner de consentimento mostrado pero sen ningunha elección feita debe producir cero solicitudes a api.amplitude.com ou api.eu.amplitude.com e cero cookies AMP_ en document.cookie. Segundo, rexeitar a categoría de análise debe manter ese estado — sen eventos, sen cookies, sen entradas de almacenamento local cun prefixo AMP_. Terceiro, aceptar a análise debe producir un único identify seguido de tráfico de eventos, e a cookie AMP_ debe aparecer cun atributo SameSite coherente coa política CMP do editor. Cuarto, retirar o consentimento despois de ter dado debe deter inmediatamente outros eventos e limpar os identificadores almacenados — unha limpeza atrasada é un achado.

A pista de auditoría é importante por separado. Segundo as directrices de banner de cookies de 2023 da EDPB e as prioridades renovadas do grupo de traballo de 2026, os reguladores esperan que o editor poida probar, para calquera evento dado no proxecto Amplitude, que o usuario que o xerou dera un consentimento válido no momento da captura. Isto require que o rexistro de consentimento da CMP sexa consultable por identificador de dispositivo ou identificador de sesión, e que a carga útil do evento de Amplitude leve un campo de versión de consentimento que se vincule a ese rexistro. Almacenar a cadena de consentimento como propiedade de usuario personalizada en cada evento é a forma máis sinxela de facer auditable esa ligazón.

Elixir a rexión correcta e a residencia dos datos

Amplitude opera dúas rexións de produción: os EUA (api.amplitude.com) e a UE (api.eu.amplitude.com). Para o tráfico do EEE e do Reino Unido, a rexión da UE é o valor predeterminado correcto — mantén os datos dentro do EEE e reduce a superficie de risco de transferencia que a decisión Schrems II e o Marco de Privacidade de Datos UE-EUA fixeron central en calquera revisión de análise. O cambio de rexións non é retroactivo: os datos existentes permanecen onde foron inxeridos por primeira vez. Para os editores que planifican un despregamento de CMP vale polo tanto a pena confirmar a rexión antes de escalar, e vale a pena documentar a elección no aviso de privacidade para que a cadea de base xurídica sexa limpa desde a recollida ata o almacenamento. Unha rexión correctamente elixida, combinada cun SDK correctamente limitado e un rexistro de consentimento consultable, é o que converte un despregamento de Amplitude dun risco regulatorio nunha parte defendible da pila de análise.