Por qué Amplitude requiere consentimiento

El Amplitude Browser SDK predeterminado y los SDK móviles de Amplitude hacen mucho más que registrar visitas a páginas. En la inicialización establecen un identificador de dispositivo en el almacenamiento de primera parte, generan un identificador de sesión, capturan el referente, analizan los identificadores UTM y de clic de la URL y empiezan a poner en cola los eventos capturados automáticamente: vistas de página, clics en elementos, interacciones con formularios, descargas de archivos y — en las últimas versiones — reproducciones de sesión. También enriquecerán esos eventos con geolocalización derivada de la IP, datos de dispositivo derivados del agente de usuario y, si se configura, enriquecimiento de terceros de socios de datos.

Cada uno de esos pasos involucra una base legal de consentimiento diferente. Almacenar un identificador de dispositivo es una operación de almacenamiento y acceso conforme al artículo 5(3) de la Directiva ePrivacy, que exige un consentimiento previo, libremente otorgado, específico, informado e inequívoco en el Espacio Económico Europeo, el Reino Unido y cualquier jurisdicción que haya adoptado el mismo estándar. Capturar eventos de comportamiento vinculados a ese identificador es un tratamiento de datos personales en virtud del GDPR. El enriquecimiento con datos de terceros introduce una segunda relación de responsable del tratamiento. La CCPA y la CPRA clasifican el mismo tratamiento como una venta o compartición, a menos que el editor tenga con Amplitude un contrato de proveedor de servicios correctamente delimitado — que existe, pero solo si la integración se configura para deshabilitar las funciones publicitarias.

Qué recopila Amplitude antes del consentimiento — y qué debe suprimir

El error de implementación más común es tratar Amplitude como una herramienta de análisis ligera que puede ejecutarse junto al banner de cookies. No puede. En una llamada predeterminada a amplitude.init() el SDK escribirá, durante el primer renderizado de la página, al menos una entrada de cookie o de almacenamiento local, enviará una llamada de identificación y comenzará a almacenar eventos en el búfer. Nada de eso está permitido antes de que un usuario haya aceptado afirmativamente la categoría de consentimiento relevante.

Una integración conforme debe por tanto retrasar amplitude.init() hasta que la CMP haya señalado que se ha concedido la categoría de consentimiento analítico. El SDK no debería cargarse en absoluto desde una etiqueta <script> controlada por consentimiento que dependa de la señal de propósito 8 (análisis) o propósito 1 (almacenamiento y acceso) de la CMP, según el marco que exponga la CMP. Si el SDK debe cargarse antes — por ejemplo porque está incluido en el código de la aplicación y no se puede recuperar de forma diferida — la llamada de inicialización debe pasar defaultTracking: false y optOut: true para que no se emita ningún evento hasta que se registre el consentimiento, y luego un evento de adhesión diferido debe invertir esos indicadores.

Las cookies y el almacenamiento que escribe Amplitude

Browser SDK 2.x escribe de forma predeterminada una única cookie de primera parte con el nombre AMP_{apiKey}, con una caducidad de un año, que contiene el identificador del dispositivo y los metadatos de la sesión. Las versiones antiguas también escribían amplitude_id_{apiKey}. Los SDK móviles persisten el mismo identificador dentro del almacenamiento en sandbox de la aplicación. La reproducción de sesión añade una segunda cookie, AMP_MKTG_{apiKey}, y los socios de enriquecimiento de Amplitude pueden establecer cookies de terceros adicionales si los módulos de segmentación de experimentos o de audiencias están habilitados. Todos estos son no esenciales y requieren consentimiento.

Mapeo de Amplitude a los marcos de consentimiento

Amplitude no implementa de forma nativa Google Consent Mode v2, IAB TCF ni IAB Global Privacy Platform. Eso no es un defecto — Amplitude es una plataforma de análisis de primera parte, no un proveedor de tecnología publicitaria — pero significa que la responsabilidad de la integración recae en el editor. El patrón que funciona en la práctica es tratar cada módulo de Amplitude como una puerta de consentimiento separada y vincularlo a una señal específica que la CMP ya expone.

• Los eventos de análisis principales se vinculan al propósito de análisis. En términos del TCF esto es con mayor frecuencia el propósito 8 (medir el rendimiento del contenido) combinado con el propósito 1 (almacenar y/o acceder a información). Para Google Consent Mode esto se corresponde con analytics_storage.
• La reproducción de sesión debe estar detrás de una señal más estricta. La reproducción captura el DOM renderizado, incluidos los valores de los formularios a menos que se enmascaren explícitamente, por lo que es apropiada una adhesión separada a preferences o functional, y la reproducción debe estar desactivada de forma predeterminada incluso cuando se haya concedido el análisis.
• Las audiencias, cohortes y el enriquecimiento de terceros se vinculan al propósito de marketing. En términos del TCF esto es el propósito 7 (medir el rendimiento de los anuncios) o el propósito 9 (aplicar investigación de mercado). Para Google Consent Mode esto se corresponde con ad_storage y ad_user_data.
• La experimentación — Amplitude Experiment puede ejecutarse con una asignación anónima y efímera bajo una base de interés legítimo, pero la asignación persistente vinculada a un identificador de usuario requiere el mismo consentimiento que el análisis principal.

El patrón de integración que funciona

La implementación de referencia que supera la revisión de un regulador tiene cuatro partes móviles: una CMP que expone un evento en tiempo real cuando el usuario cambia el consentimiento, un cargador de SDK diferido que solo recupera Amplitude después de que ese evento se activa para la categoría relevante, un guardián a nivel de sesión que respeta la exclusión voluntaria sin perder el identificador de dispositivo anónimo anterior del usuario donde la ley lo permite, y un puente del lado del servidor para los eventos que genuinamente requieren recopilación independientemente del consentimiento — como la telemetría de seguridad o la detección de fraude — enrutados a través de un punto final separado con su propia base legal.

Implementación web

En la web, el patrón más limpio es exponer el estado de consentimiento de la CMP mediante un objeto window.__cmp_consent o la devolución de llamada estándar __tcfapi, y luego tener un pequeño script de arranque que se suscriba a los cambios de consentimiento. Cuando el consentimiento analítico cambia de false a true, el arranque recupera el SDK de Amplitude desde el CDN gestionado por la CMP, llama a amplitude.init(apiKey, undefined, { defaultTracking: true }) y reproduce cualquier evento que estuviera en cola en memoria mientras el consentimiento estaba pendiente. Cuando el consentimiento vuelve a false, el arranque llama a amplitude.setOptOut(true), borra la cookie AMP_ mediante la caducidad de document.cookie y elimina cualquier estado en memoria. De forma crítica, el arranque nunca debe inicializar Amplitude de forma diferida en el mismo flujo de solicitud que el renderizado del banner — el SDK debe esperar una concesión explícita.

Implementación móvil

En iOS el equivalente es mantener el framework de Amplitude importado pero diferir Amplitude.instance().initialize(apiKey: apiKey) hasta que el flujo de consentimiento dentro de la aplicación haya devuelto una señal analítica positiva. El aviso ATT es una preocupación separada: ATT regula el IDFA, mientras que el identificador de Amplitude es el UUID propio del SDK almacenado en el sandbox de la aplicación. Ambos requieren consentimiento en el EEE, pero las bases legales y los avisos son distintos. En Android la misma lógica se aplica con Amplitude.getInstance().initializeApolloClient() o el equivalente según la versión del SDK.

Modo del lado del servidor

Amplitude admite la ingesta del lado del servidor a través de la HTTP V2 API. Los eventos del lado del servidor no están exentos del consentimiento — la base legal sigue los datos, no el transporte — pero la ingesta del lado del servidor le da al editor control total sobre qué campos se envían, lo que facilita respetar el consentimiento parcial. Un patrón habitual es capturar un conjunto mínimo de eventos solo esenciales del lado del servidor bajo interés legítimo, y enriquecer esos eventos con detalles de comportamiento solo después de que el usuario haya concedido el consentimiento analítico en el cliente.

Validación de la integración

El paso de validación es el que los editores omiten con más frecuencia y el que los reguladores comprueban con más frecuencia. Un despliegue de Amplitude correctamente integrado debe superar cuatro comprobaciones. Primero, un navegador con el banner de consentimiento mostrado pero sin ninguna elección realizada debe producir cero solicitudes a api.amplitude.com o api.eu.amplitude.com y cero cookies AMP_ en document.cookie. Segundo, rechazar la categoría de análisis debe mantener ese estado — ningún evento, ninguna cookie, ninguna entrada de almacenamiento local con un prefijo AMP_. Tercero, aceptar el análisis debe producir un único identify seguido de tráfico de eventos, y la cookie AMP_ debe aparecer con un atributo SameSite coherente con la política CMP del editor. Cuarto, retirar el consentimiento a posteriori debe detener inmediatamente los eventos adicionales y borrar los identificadores almacenados — una limpieza retrasada es un hallazgo.

El rastro de auditoría importa por separado. De acuerdo con las directrices del banner de cookies del EDPB de 2023 y las prioridades renovadas del grupo de trabajo para 2026, los reguladores esperan que el editor pueda demostrar, para cualquier evento dado en el proyecto Amplitude, que el usuario que lo generó había dado un consentimiento válido en el momento de la captura. Esto requiere que el registro de consentimiento de la CMP sea consultable por identificador de dispositivo o identificador de sesión, y que la carga útil del evento de Amplitude lleve un campo de versión de consentimiento que se vincule de vuelta a ese registro. Almacenar la cadena de consentimiento como una propiedad de usuario personalizada en cada evento es la forma más sencilla de hacer que ese vínculo sea auditable.

Elección de la región correcta y la residencia de datos

Amplitude opera dos regiones de producción: EE. UU. (api.amplitude.com) y UE (api.eu.amplitude.com). Para el tráfico del EEE y del Reino Unido la región de la UE es el valor predeterminado correcto — mantiene los datos dentro del EEE y reduce la superficie de riesgo de transferencia que la decisión Schrems II y el Marco de Privacidad de Datos UE-EE. UU. han hecho central para cualquier revisión de análisis. Cambiar de región no es retroactivo: los datos existentes se quedan donde se ingirieron por primera vez. Para los editores que planean un despliegue de CMP vale la pena confirmar la región antes de escalar y documentar la elección en el aviso de privacidad para que la cadena de bases legales sea limpia desde la recopilación hasta el almacenamiento. Una región elegida correctamente, combinada con un SDK correctamente controlado y un registro de consentimiento consultable, es lo que convierte un despliegue de Amplitude de un riesgo regulatorio en una parte defendible del stack de análisis.