Analítica conforme con el RGPD sin cookies: qué construimos y por qué no hay banner

La analítica conforme con el RGPD sin cookies solo es posible cuando no se recogen datos personales ni se almacena ningún identificador en el dispositivo del visitante. Acierta en estos dos puntos y la base legal para un banner de cookies desaparece: no hay nada que consentir. Es la vía que seguimos en todos los sitios que lanzamos, incluido este. A continuación explicamos qué significa exactamente, qué se puede y qué no se puede medir, y el tracker first-party que construimos para mantenernos del lado correcto de la línea.

Qué significa realmente "analítica conforme con el RGPD sin cookies"

La expresión se usa a la ligera, así que definámosla. La analítica es verdaderamente sin cookies y exenta de consentimiento cuando supera, a la vez, dos pruebas legales independientes:

• La prueba de la ePrivacy (la ley de cookies). El artículo 5.3 de la Directiva ePrivacy —lo que todos llaman "la ley de cookies"— regula el almacenamiento o la lectura de información en el dispositivo del usuario. No se limita a las cookies. Abarca localStorage, IndexedDB, el fingerprinting del dispositivo y cualquier equivalente. Si no escribes ni lees en el dispositivo nada que no sea estrictamente necesario para entregar la página solicitada, quedas fuera del artículo 5.3 y no necesitas consentimiento.
• La prueba del RGPD (la ley de datos personales). El RGPD regula el tratamiento de datos personales: todo lo que pueda identificar a una persona directa o indirectamente, incluida una dirección IP (el TJUE lo resolvió en la sentencia Breyer, C-582/14). Si no tratas datos personales, todo el mecanismo de consentimiento y base de licitud del RGPD deja, en gran medida, de aplicarse.

Supera ambas y habrás conseguido lo que todo equipo de marketing desea en secreto: sin banner, sin flujo de consentimiento y con una analítica que sigue funcionando para el 100% de los visitantes en lugar del ~60% que pulsa "aceptar". La mayoría de las herramientas "sin cookies" del mercado superan la primera prueba y fallan discretamente la segunda, porque siguen aplicando un hash a una IP y a un user agent para generar un ID de visitante diario. Eso es un identificador derivado del dispositivo y, según el razonamiento de Breyer, muy probablemente un dato personal.

La versión corta

• Sin cookies, sin localStorage, sin fingerprint. No escribimos nada en el dispositivo, así que el artículo 5.3 no aplica.
• Sin datos personales, sin almacenamiento de IP, sin ID entre sitios. No tratamos datos personales, así que la cuestión del consentimiento del RGPD nunca surge.
• Un beacon anónimo por vista de página, guardado first-party en nuestro propio servidor. Ningún tercero ve al visitante.
• Resultado: sin banner de cookies y recuentos que cubren a todos los visitantes, no a un subconjunto que ha consentido.

Qué se puede medir sin cookies (y qué no)

Aquí la honestidad importa más que el argumento de venta, porque la contrapartida es real. La analítica sin cookies y sin identificadores es solo agregada. Cuentas eventos, no sigues a personas.

Lo que sí puedes responder con claridad:

• Cuántas vistas tuvo /work ayer, esta semana, este mes.
• Qué rutas son más populares y la forma aproximada del tráfico a lo largo del tiempo.
• De dónde provienen las visitas a nivel de origen —google.com, linkedin.com, directo— y no la URL de referencia completa con su cadena de consulta.
• Contexto grueso del dispositivo: franja de ancho del viewport, idioma preferido. Lo suficiente para saber si el diseño móvil importa.

Lo que no puedes responder, y no deberías fingir que respondes:

• Visitantes únicos y recurrentes. No hay un ID estable, así que "únicos" no es un número que puedas producir con honestidad. Quien te venda "visitantes únicos" sin cookies está reconstruyendo un identificador en alguna parte.
• Embudos de varios pasos atados a una persona. Puedes contar cuántas sesiones llegaron al paso 1 y al paso 2; no puedes probar que fue el mismo humano recorriendo el camino.
• Recorridos entre dispositivos o entre sitios. Desaparecen por diseño. Ese es justamente el objetivo.

Para un sitio de estudio, un sitio de marketing, un portafolio o la mayoría de los negocios de contenido, la vista agregada basta para decidir. Si tu modelo de negocio realmente necesita atribución por usuario —un embudo de e-commerce de alta velocidad, por ejemplo— entonces necesitas consentimiento, y deberías pedirlo con honestidad mediante un banner real en lugar de disfrazar el tracking de "privacy-first". Eso es exactamente lo que le dijimos a Delicious Diamonds para sus flujos de comercio exclusivos para miembros: el sitio de marketing público funciona sin cookies, y el recorrido de compra autenticado usa datos de sesión first-party que el cliente ya ha aceptado al iniciar sesión.

Cómo lo construimos: un beacon, ninguna identidad

Nuestra stack es deliberadamente aburrida: PHP 8.3 en alojamiento compartido, Cloudflare por delante, sin paso de build, renderizada en el servidor. El tracker sigue esa filosofía. No hay script de terceros, ni SDK, ni dependencia de npm. Son unas líneas de JavaScript puro y un endpoint PHP.

El cliente dispara un único POST unos tres segundos después de la carga (tiempo suficiente para descartar la mayoría de los rebotes y bots) y olvida que ocurrió:

// sin cookies, sin localStorage, sin identidad
navigator.sendBeacon('/api/hit', JSON.stringify({
  path: location.pathname,
  referrer_origin: document.referrer
    ? new URL(document.referrer).origin
    : null,
  lang: navigator.language.slice(0, 2),
  screen_w: window.innerWidth,
  ts: Date.now()
}));

Lee esta carga con atención, porque la garantía de privacidad vive en lo que está ausente. No hay user agent. No hay IP —y, de forma crucial, el servidor está configurado para nunca registrar ni persistir la IP de conexión en estas peticiones—. No hay UUID, ni hash de nada, ni token de sesión. referrer_origin elimina deliberadamente la ruta y la cadena de consulta del referrer, así que sabemos que viniste de LinkedIn pero no de qué publicación ni de qué rastro de UTM. El idioma se trunca a dos caracteres. Ninguno de estos campos, solo o combinado, individualiza a una persona.

En el servidor, el endpoint añade una línea de JSON a un archivo mensual:

// /api/hit -- solo append, sin IP, sin identidad
$line = json_encode([
    'path'     => $clean['path'],
    'ref'      => $clean['referrer_origin'],
    'lang'     => $clean['lang'],
    'w'        => (int) $clean['screen_w'],
    't'        => time(),
]) . "\n";

file_put_contents(
    __DIR__ . '/../storage/hits/' . date('Y-m') . '.jsonl',
    $line,
    FILE_APPEND | LOCK_EX
);

El directorio storage/hits/ está blindado a nivel del servidor web con un .htaccess que lleva Require all denied, así que los logs en bruto nunca son accesibles por HTTP. Un pequeño panel en PHP, protegido con autenticación básica HTTP, lee esos archivos JSON-lines, agrega por día y muestra seis números y un gráfico de barras. Todo se ejecuta en el servidor; ningún dato sale de nuestra infraestructura y ningún tercero —ni Google, ni proveedor de analítica— toca al visitante.

Por qué eso significa que no hay banner de cookies

Volvamos sobre las dos pruebas.

Artículo 5.3: no almacenamos nada en el dispositivo y no leemos nada de vuelta. sendBeacon es una petición HTTP de disparar y olvidar; no fija ninguna cookie ni toca el almacenamiento. No hay "acceso a información almacenada en el equipo terminal", así que el requisito de consentimiento de la ley de cookies no se activa. No hay nada que preguntar.

RGPD: no tratamos datos personales. No se almacena ninguna IP, no se deriva ningún identificador, y ninguno de los campos retenidos —una ruta, un origen de referencia, un idioma de dos letras, un ancho de viewport, una marca temporal— identifica a una persona física, individualmente o en combinación. Sin datos personales en el ámbito, no hay base de licitud del artículo 6 que establecer ni consentimiento que recoger.

Dos pruebas superadas, cero banners necesarios. La conclusión jurídica no es un truco ingenioso; es la consecuencia directa de no tener, genuinamente, nada que declarar. El banner existe para obtener consentimiento para el almacenamiento y para el tratamiento de datos personales. No hagas ninguna de las dos cosas y el banner se queda sin función.

Preguntas frecuentes

¿Puede Google Analytics ser alguna vez conforme con el RGPD sin banner?

No. GA4 fija cookies y trata identificadores y datos derivados de la IP, lo que activa tanto la prueba de la ePrivacy como la del RGPD. Exige consentimiento en la UE, y varias autoridades de protección de datos (Austria, Francia, Italia) han declarado ilegales configuraciones estándar de GA por las transferencias de datos a EE. UU. Si usas GA, necesitas banner y flujo de consentimiento.

¿Y herramientas "sin cookies" como Plausible o Fathom?

Son una gran mejora y evitan las cookies, pero la mayoría genera un hash de visitante diario a partir de la IP y el user agent para estimar únicos. Ese hash es un identificador derivado del dispositivo y, tras Breyer, es discutiblemente un dato personal. Respetan la privacidad y suelen ser defendibles sin banner, pero es una línea jurídica más fina que "no almacenamos ni derivamos nada", que es la línea donde elegimos quedarnos.

¿No se pierden datos importantes?

Se pierden datos por usuario. Se conservan todos los números agregados que realmente informan una decisión de contenido o de diseño, y se conservan para todos los visitantes en lugar de la minoría que acepta un banner, lo que a menudo hace que la foto agregada sea más exacta, no menos.

¿No rompe Cloudflare la promesa de no recoger datos personales?

Cloudflare está por delante como CDN y ve IPs a nivel de red, como cualquier alojamiento. La distinción que importa jurídicamente es que nosotros no registramos, almacenamos ni tratamos esas IPs en nuestra analítica; la carga del beacon no contiene IP y el endpoint nunca registra la dirección de conexión. El tránsito a nivel de red no es lo mismo que recoger datos personales en un conjunto de datos de analítica.

Si quieres esto

El patrón es portable. Cualquier stack renderizada en el servidor puede lanzarlo: un único beacon, una carga que lo despoja todo, un almacenamiento first-party solo de append, sin terceros, sin identificador. La parte difícil no es el código: es la disciplina de no recoger los datos que hacen obligatorio el banner. Construimos los sitios así por defecto porque es más rápido, más ligero y significa que lo primero que ve un visitante es el trabajo, no un cuadro de consentimiento. Si quieres una analítica que puedas defender sin un equipo de privacidad y una revisión legal, esta es su forma.