Borrar un usuario de GA4 no es pulsar un botón y ver desaparecer sus datos al momento: es una solicitud que pasa por la Admin API de Google Analytics y que tarda, según la pieza del sistema que mires, entre 72 horas y dos meses. Para el equipo de marketing que recibe una solicitud de supresión de un cliente, o para quien tenga que tramitarla en el lado técnico, esa diferencia de plazos decide si se cumple el RGPD a tiempo o no.
Esto es lo que hay que saber antes de que llegue la primera solicitud, no después, porque improvisar el procedimiento con el reloj legal ya corriendo es la forma más segura de llegar tarde.
Borrar un usuario de GA4 se pide con el método submitUserDeletion de la Admin API: sus datos salen del informe de actividad del usuario en 72 horas, pero no se eliminan de los servidores de Google hasta el siguiente proceso de borrado, que ocurre aproximadamente cada dos meses.
Borrar un usuario de GA4 exige la Admin API
Hasta hace poco, esto pasaba por la User Deletion API v3, pensada para Universal Analytics y ya retirada. La vía actual es el método submitUserDeletion de la Admin API de Google Analytics, que exige el permiso OAuth analytics.edit, no el antiguo analytics.user.deletion.
Identificadores que acepta la solicitud de borrado
La llamada necesita un identificador para saber a quién borrar. La Admin API acepta cuatro tipos:
- El User ID que tu propia web o app le asigna al usuario registrado.
- El Client ID que genera la cookie o el SDK de Analytics.
- El App Instance ID de Firebase, para apps móviles.
- Un dato aportado por el usuario: su email o su teléfono, normalizados antes de enviarlos.
Sin uno de estos cuatro identificadores la solicitud no se puede tramitar, y en la mayoría de los casos solo el Client ID está disponible porque el usuario nunca llegó a identificarse.
La diferencia con el borrado automático por retención
GA4 ya borra datos solo, por calendario: los eventos caducan a los 2 o 14 meses según la retención configurada, como repasamos en qué borra Google a los 2 meses. Esa caducidad es ciega, no distingue usuarios ni atiende solicitudes. El submitUserDeletion es lo contrario: una orden dirigida a una persona concreta, y la única que sirve para responder a un ejercicio de derechos. Por eso no sirve esperar a que la retención haga el trabajo: si el usuario sigue generando eventos, su rastro se renueva y nunca caduca por sí solo.
Informes y servidores no borran al usuario igual
La respuesta de la API devuelve un deletionRequestTime: el instante a partir del cual se considera que todo dato anterior de ese usuario debe eliminarse. Ese sello marca el inicio del proceso, no el final. En 72 horas, el usuario deja de aparecer en el informe de actividad individual, que es lo primero que comprueba cualquiera que quiera verificar que la solicitud se tramitó.
Lo que tarda más es la limpieza de fondo: los datos no desaparecen de los servidores de Google hasta el siguiente proceso de borrado por lotes, que se ejecuta aproximadamente cada dos meses. Si la solicitud entra justo después de que pase ese proceso, la espera real se acerca a los dos meses completos, no a unos días. Conviene explicarle esto al cliente o al departamento legal antes de que pregunten por qué «ya lo hemos borrado» y el dato sigue en algún backup interno de Google durante semanas.
El plazo lo marca el RGPD, no la API de Google
El derecho de supresión está en el artículo 17 del Reglamento (UE) 2016/679, y el plazo para responder a quien lo ejerce es de un mes desde que llega la solicitud, ampliable a dos meses más si la complejidad o el volumen lo justifica, siempre que se avise al interesado antes de que acabe el primer mes. Ese plazo cuenta desde la recepción, no desde que termines de verificar la identidad de quien pregunta.
Aquí es donde chocan los dos relojes: la API puede tardar hasta dos meses en vaciar el servidor, y el RGPD puede darte solo uno para contestar. La forma de no incumplir es separar las dos cosas: responder dentro del mes confirmando que la solicitud de borrado ya se ha enviado a Google con su deletionRequestTime, en vez de esperar a que el proceso de borrado termine del todo para dar la respuesta por hecha. Esto conecta directamente con lo que ya explicamos sobre por qué procesar GA4 en la UE no basta para cumplir el RGPD: dónde viven los servidores no resuelve el plazo de respuesta.
¿Te ayudamos con esto?
Cuéntanos tu caso
Si esto te afecta, escríbenos en dos líneas y te respondemos por email con una valoración concreta.
Barcelona también borra usuarios de GA4 por RGPD
No es un supuesto teórico. Treinta y dos autoridades europeas de protección de datos, incluida la AEPD, coordinaron una acción conjunta que encuestó a 764 responsables en toda Europa sobre cómo atienden el derecho de supresión; en España respondieron 43 entidades, entre públicas, privadas y del tercer sector. El resultado no fue favorecedor para quien improvisa.
Qué falla más al atender estas solicitudes
La acción europea encontró el mismo patrón una y otra vez: información insuficiente para el ciudadano que quiere ejercer el derecho, procedimientos internos que no llegan a todos los sistemas donde vive el dato, y anonimización mal hecha que deja el registro identificable pese a creerlo borrado. En analítica web esto se traduce en un caso muy concreto: borrar al usuario de GA4 y olvidarse del CRM, del ESP de email marketing o del backup del formulario de contacto, que siguen teniendo su nombre y su teléfono intactos.
Qué debe guardar tu equipo como justificante
Si la AEPD abre expediente porque un usuario reclamó, lo que salva a la empresa no es haber borrado el dato sino poder demostrarlo. Conviene guardar el deletionRequestTime que devuelve la API, una captura de que el usuario desapareció del informe de actividad a las 72 horas y la fecha en la que se avisó al interesado dentro del primer mes. Sin ese rastro documental, la palabra de la empresa vale lo mismo que la del reclamante, y en una inspección eso no basta.
Quién tramita la eliminación de datos en tu equipo
El permiso analytics.edit que exige submitUserDeletion no lo tiene cualquier usuario de la propiedad GA4: hace falta rol de editor o administrador, y normalmente la llamada se hace por API o por consola de desarrollador, no desde un botón del panel de informes. En la práctica, esto cae en quien lleve la parte técnica de la cuenta, no en quien gestiona las campañas.
Las empresas sin perfil técnico propio suelen resolverlo de dos formas: delegar la ejecución en quien les lleva el servicio de analítica web, o pedir una revisión completa de dónde vive cada dato del usuario -GA4, CRM, formularios- antes de que llegue la primera solicitud, que es justo lo que cubre una auditoría web bien planteada. Lo que no funciona es descubrir, con el mes del RGPD ya corriendo, que nadie en la empresa sabe cómo se llama al endpoint.
Preguntas frecuentes sobre la eliminación de datos en GA4
¿Cuánto tarda GA4 en borrar a un usuario?
Entre 72 horas y dos meses. En 72 horas sus datos desaparecen del informe de actividad del usuario; la eliminación completa de los servidores de Google llega en el siguiente proceso de borrado por lotes, que se ejecuta aproximadamente cada dos meses, no al momento de la solicitud.
¿Qué pasa si no respondo a la solicitud en un mes?
El RGPD da un mes para responder, ampliable a dos más si avisas al interesado antes de que acabe el primero. Pasado ese plazo sin respuesta, el interesado puede reclamar directamente ante la AEPD, que abre expediente sin necesidad de un aviso previo a tu empresa.
¿El panel de GA4 tiene un botón para borrar a un usuario?
No. La interfaz de informes no ofrece esa opción directa: el borrado se pide con el método submitUserDeletion de la Admin API, que exige rol de editor en la propiedad y el permiso analytics.edit, así que normalmente lo ejecuta un perfil técnico, no quien gestiona las campañas.
Fuente: Google for Developers
