Medir desde tu servidor no te salta el consentimiento: la regla sigue al dispositivo, no al dato
Hay una idea que circula por despachos y por foros de marketing desde hace un par de años: que si mueves la medición a un servidor tuyo, el consentimiento deja de ser un problema. Es falsa, y esta semana ha vuelto a quedar por escrito.
El 23 de octubre, la empresa italiana de gestión de consentimiento iubenda publicó una guía y un documento técnico sobre medición del lado del servidor. Su conclusión cabe en una frase:
«La regla sigue al dispositivo, no al dato.»
Dicho en largo: la obligación de pedir permiso se activa cuando algo lee o escribe en el aparato de la persona. Da igual a dónde viajen después esos datos y da igual quién los procese. Mover el procesamiento a tu servidor cambia la fontanería, no el permiso de entrada.
De dónde sale esa regla
De dos sitios que conviene distinguir, porque se mezclan todo el rato:
- El artículo 5(3) de la Directiva ePrivacy. Es el que obliga a pedir consentimiento para almacenar información en el dispositivo o acceder a la que ya hay. Es el artículo de las cookies, pero no habla solo de cookies: habla de almacenamiento y de acceso, con la tecnología que sea.
- El RGPD. Es el que exige una base jurídica para tratar datos personales. Para la mayoría de la medición publicitaria, esa base es el consentimiento.
Las directrices 2/2023 del Comité Europeo de Protección de Datos son las que aclaran el matiz que más cuesta: el requisito se dispara por la lectura o escritura en el dispositivo, sin distinguir si quien recibe los datos es un servidor tuyo o una plataforma publicitaria.
Por eso la frase funciona. La regla mira al teléfono o al ordenador de quien te visita, no al mapa de servidores por el que pasa el dato después.
Los cinco errores que se repiten
1. «Como va por mi servidor, no necesito consentimiento»
El más extendido. El propio documento lo llama el mito más persistente sobre medición de servidor y RGPD, y lo resuelve así:
«El tracking del lado del servidor cambia dónde se procesan tus datos, no si necesitas permiso para procesarlos.»
2. «Reenvío desde el servidor los eventos de quien no aceptó»
Esta es la versión operativa del error anterior, y es la que de verdad genera riesgo. Si el evento se recoge igual y simplemente se manda desde otro sitio, sigue siendo seguimiento sin consentimiento. Cambiar el remitente no cambia la naturaleza de lo enviado.
3. «Si lo hasheo, ya es anónimo»
No. El hash es seudonimización, no anonimización. Un correo electrónico hasheado sigue siendo dato personal: identifica a la misma persona de forma estable y permite cruzarla con otras fuentes. Es justamente para lo que sirve en las conversiones mejoradas.
4. «Al no verse, no hay que contarlo»
Al revés. Cuando el dato sale de tu servidor hacia varios destinos, hace falta más transparencia, no menos: la política de privacidad y el banner tienen que describir ese tratamiento y quién recibe qué. Lo invisible para el usuario es exactamente lo que hay que explicar.
5. «Duplicar la medición no hace daño»
Sí hace daño, pero a tus números. Si tienes el píxel del navegador y la conexión de servidor funcionando a la vez sin deduplicar, cuentas cada compra dos veces. Es la causa más tonta y más frecuente de que un panel diga el doble que la caja.
Si tus conversiones no cuadran entre Google, Meta y tu propia facturación, el problema casi nunca es la herramienta. Es cómo está montada.
Solicitar revisiónEntonces, ¿para qué sirve de verdad?
Para tres cosas que sí valen dinero. Ninguna es saltarse la ley.
Recuperar señal. Alrededor del 29,5% de los usuarios de internet declara usar bloqueador al menos parte del tiempo. Como la petición sale de un subdominio tuyo, se parece a tráfico propio y es menos probable que se bloquee. Menos probable, no imposible: cuando un bloqueador identifica ese subdominio como punto de recogida, lo bloquea igual.
Minimizar antes de enviar. El servidor es el único sitio donde puedes decidir, destino por destino, qué campos salen, cuáles se recortan y cuáles se descartan. Eso es minimización de datos de verdad, no una declaración de intenciones en la política de privacidad.
Auditar. Un punto único por el que pasa todo es un punto único donde mirar. Sin él, saber qué scripts están enviando qué a quién es una excavación.
Lo que no va a arreglar
Conviene bajar las expectativas con dos asuntos:
- Safari. Las cookies que fija el servidor pueden durar más que las que fija el JavaScript, pero Safari las limita a siete días cuando detecta que el subdominio resuelve a una infraestructura de un tercero. El criterio técnico es poco intuitivo: considera el subdominio ajeno cuando las direcciones IP comparten menos de 16 bits iniciales. Es decir, no basta con que el subdominio sea tuyo; tiene que resolver a algo que lo parezca.
- La carrera no se acaba. Las versiones recientes de Safari han empezado a bloquear rastreadores por dirección IP y han dejado de resolver dominios publicitarios concretos. El server-side compra tiempo y calidad de señal; no compra inmunidad.
Y un apunte sobre las cifras que acompañan a estas conversaciones: buena parte del material comercial sobre medición de servidor sigue apoyándose en que Chrome iba a eliminar las cookies de terceros, plan que Google abandonó en abril de 2025. Si alguien te justifica una inversión con ese argumento, el argumento está caducado. Lo contamos en qué son las cookies de terceros y qué ha pasado con ellas.
Cómo se monta esto bien
El orden importa, porque los fallos caros son siempre de orden.
- Primero el consentimiento, luego la fontanería. La decisión de la persona se recoge en el navegador y viaja con cada evento. El servidor decide, para cada destino, si reenvía, recorta o descarta.
- Nada se dispara antes de la decisión. La primera interacción es el agujero clásico: el evento sale antes de que el usuario haya elegido nada. Ahí es donde se cometen la mayoría de los incumplimientos reales.
- Consent Mode v2 para los destinos de Google. El modo de consentimiento no sustituye al banner: declara el estado y permite modelar lo que falta. La obligación de obtener el permiso sigue siendo de quien gestiona la web, y Google lo dice con claridad en su documentación.
- Deduplica desde el primer día. Identificador único de evento compartido entre navegador y servidor. Si se deja para después, nunca se hace.
- Convive dos semanas con los dos sistemas. Navegador y servidor en paralelo, comparando cifras. Es la única forma de saber qué estás ganando y qué estás rompiendo.
- Actualiza banner y política de privacidad. Tienen que describir el procesamiento en servidor y los destinatarios reales. Si el texto no se toca, el montaje está a medias.
- Presupuesta el mantenimiento. Alojamiento o servicio gestionado, alguien técnico disponible y una revisión periódica. Una mala configuración puede pasar semanas sin que nadie se dé cuenta, y cuando se nota ya has perdido el periodo de comparación.
Una nota sobre la fuente
iubenda vende herramientas de consentimiento y tiene en preparación su propio producto de medición de servidor. Su análisis legal es también su argumento comercial, y eso conviene tenerlo presente al leerlo.
Dicho lo cual, la parte jurídica no depende de quién la cuente: el artículo 5(3) y las directrices del Comité Europeo existen igual. Y la conclusión práctica es independiente del vendedor: si mueves la medición al servidor pensando que así te ahorras el banner, has montado un problema, no una solución.
Qué hacer con esto
Si estás pensando en dar el paso, la pregunta previa no es técnica. Es: ¿qué parte de tu medición actual está mal por consentimiento y qué parte está mal por señal? Son dos averías distintas y el server-side solo arregla la segunda.
Es la revisión que hacemos en analítica y tracking: qué se envía, desde dónde, con qué permiso y por qué tus números no cuadran entre plataformas. Y si tu web además recoge formularios, conviene mirarlo junto con lo que ya es exigible en accesibilidad web, que afecta a los mismos formularios por otro motivo.
Lo que entre en tu caso concreto y con qué obligaciones, eso te lo tiene que decir tu asesoría jurídica. Aquí hablamos de cómo se monta, no de qué te obliga.
Fuentes
Preguntas frecuentes
¿Qué es el tracking server-side?
Es mover la recogida de datos del navegador a un servidor que tú controlas, normalmente bajo un subdominio tuyo. El navegador manda el evento a ese servidor, el servidor lo filtra y lo reenvía a Google Analytics, Meta, Google Ads o a quien corresponda. El montaje más habitual es un contenedor de Google Tag Manager del lado del servidor.
¿Me libra de pedir consentimiento?
No. La obligación se activa cuando algo lee o escribe en el dispositivo de la persona, con independencia de a dónde viajen luego los datos. Cambiar el punto de procesamiento no cambia el permiso que necesitas para empezar.
¿Y si hasheo los correos electrónicos?
El hash es seudonimización, no anonimización. Un correo hasheado sigue siendo dato personal y sigue dentro del ámbito del RGPD, porque permite reidentificar a la persona al cruzarlo con otras fuentes. Tratarlo como si fuera anónimo es uno de los errores más comunes.
¿Entonces para qué sirve el server-side?
Para tres cosas reales: recuperar señal que se pierde por bloqueadores y restricciones del navegador, minimizar datos antes de enviarlos a cada plataforma y tener un punto único donde auditar qué sale de tu casa y hacia dónde. Ninguna de las tres tiene que ver con saltarse el consentimiento.
¿Cuánta señal se pierde realmente?
Depende de tu público. Como referencia de contexto, alrededor del 29,5% de los usuarios de internet declara usar bloqueador de anuncios al menos parte del tiempo. En un público técnico o joven la proporción sube; en uno de más edad, baja. Lo sensato es medir tu propia desviación antes de presupuestar nada.
¿Es caro de mantener?
No es un interruptor. Implica coste recurrente de alojamiento o de servicio gestionado, intervención de alguien técnico y disciplina para no acabar enviando más datos de los necesarios. Montarlo y no mantenerlo es la peor de las opciones, porque un error de configuración puede pasar semanas sin que nadie lo note.