Consent Mode v2 dejó de ser opcional el 06-03-2024. Desde esa fecha, el tráfico de la UE y el EEE hacia los productos publicitarios de Google ha tenido que pasar dos nuevas señales — ad_user_data y ad_personalization — junto con las originales ad_storage y analytics_storage. El cambio no fue impulsado por el GDPR, sino por la Ley de Mercados Digitales (Reglamento (UE) 2022/1925), y específicamente por el Art. 5(2) de la DMA, que prohíbe a los guardianes de acceso (gatekeepers) designados combinar o cruzar datos personales entre servicios sin un consentimiento explícito.
Para un acortador de URLs, esto se cruza con el plano de datos de redirección de formas complejas. Un enlace corto es lo que el usuario pulsó; el estado de consentimiento en la página de destino decide si ese clic puede atribuirse. Esos dos eventos ocurren en dominios diferentes, en depósitos de cookies diferentes y, a menudo, en sesiones diferentes. La brecha entre ellos es donde reside ahora la mayor parte de la pérdida de atribución.
Este post es la lectura de un asesor de cumplimiento en ejercicio sobre qué ha cambiado, qué significan realmente las cuatro señales para un servicio de redirección, dónde es legal la recuperación server-side bajo las directrices actuales del EDPB y dónde no lo es. Gran parte del trabajo de ingeniería para el seguimiento server-side de GA4 a través de redirecciones es correcto bajo el GDPR; parte de ello no lo es bajo la DMA.
La DMA, en un párrafo#
La Ley de Mercados Digitales comenzó a aplicarse el 07-03-2024. Designa a los "gatekeepers" — Alphabet, Amazon, Apple, ByteDance, Meta, Microsoft, Booking — e impone obligaciones ex ante sobre ellos. El Art. 5(2) de la DMA es el que importa para el seguimiento: un gatekeeper no procesará datos personales de usuarios finales de servicios de terceros para publicidad online, ni combinará datos personales entre sus servicios, sin consentimiento.
Consent Mode v2 es el mecanismo de cumplimiento de Google para el Art. 5(2). Las dos nuevas señales — ad_user_data y ad_personalization — permiten al gatekeeper observar si el editor ha obtenido un consentimiento de nivel Art. 5(2) antes de que la telemetría de clics se use para publicidad o personalización. Sin esas señales establecidas como granted, los productos publicitarios de Google recurren a conversiones agregadas o modeladas sin atribución por usuario.
La DMA no reemplaza al GDPR. Se sitúa por encima. Un responsable del tratamiento (controller) sigue necesitando una base legal del Art. 6 bajo el GDPR; Consent Mode v2 añade una segunda puerta que se cierra para los datos publicitarios enrutados por gatekeepers incluso cuando la puerta del GDPR está abierta.
Las cuatro señales, en términos sencillos#
Consent Mode v2 envía cuatro señales booleanas. Cada una puede ser granted (concedido) o denied (denegado). Los valores por defecto pueden configurarse por región.
ad_storage — la señal original de la v1. Controla si se escriben cookies u otro almacenamiento para publicidad. Cuando es denied, las etiquetas de Google se activan sin identificadores; la medición de conversiones se degrada a agregados modelados sin cookies. La redirección decide qué UTMs e identificadores de clic aterrizan en la página, y estos se convierten en las claves a las que se adjunta el consentimiento. La documentación de consentimiento de tag-platform es la referencia canónica de lo que hace cada señal aguas abajo.
ad_user_data — nueva en la v2. Controla si los datos del usuario pueden enviarse a Google para publicidad en absoluto. Esta es la señal del Art. 5(2) de la DMA. Cuando es denied, la etiqueta no puede transmitir datos del usuario — incluyendo identificadores hasheados, IP, user-agent — a Google Ads. El etiquetado server-side no evita esto; la señal viaja con el evento.
ad_personalization — también nueva. Controla si los datos transmitidos pueden usarse para publicidad personalizada, incluido el remarketing. Una configuración común es ad_user_data=granted más ad_personalization=denied, lo que permite la atribución pero bloquea el remarketing.
analytics_storage — controla si se escribe almacenamiento para analítica. La etiqueta de GA4 respeta esto; cuando es denied, GA4 funciona sin cookies y utiliza el modelado de consent mode para reconstruir la atribución a nivel agregado. El modelado necesita un volumen mínimo de tráfico y un periodo de aprendizaje de 7 días.
Ninguna de las cuatro señales se decide en el acortador. El acortador emite el clic; la página de destino lee las señales; la etiqueta en la página de destino decide qué hacer con ellas. El trabajo del acortador es entregar un estado limpio — UTMs preservadas, identificador de clic preservado, redirección rápida — para que el banner pueda resolverse antes de que se active la etiqueta.
Lo que falla en el plano de datos de redirección#
Tres modos de fallo aparecen en cada acortador que se toma en serio la ruta de redirección.
El identificador de clic sobrevive pero la señal de consentimiento no. Un clic en un anuncio de Meta llega a s.elido.me/abc123?fbclid=… y redirige a https://cliente.example/destino?fbclid=…. El fbclid se preserva. La página carga, aparece el banner, el usuario deniega. Meta CAPI ya ha recibido un clic vinculado a ese fbclid — pero el usuario ahora ha denegado el uso publicitario. El acortador no hizo nada mal; el responsable del tratamiento tiene un problema de deduplicación de CAPI que resolver en su endpoint.
El acortador añade identificadores que la página de destino no entiende. Algunos acortadores (como bitly_session de Bitly o _branch_match_id de Rebrandly) añaden parámetros específicos del proveedor que necesitan ser eliminados o tratados de forma especial bajo un consentimiento denegado. Elido reenvía únicamente las UTMs y el propio identificador de clic del cliente.
El estado de consentimiento de la página de destino es imposible de conocer desde la perspectiva de la redirección. El acortador no puede ver un banner que aún no ha cargado. Las decisiones de fallback server-side no pueden condicionarse a un estado de consentimiento que aún no existe. El único valor por defecto honesto: no disparar ningún evento server-side con fines publicitarios en el momento de la redirección; dejar que el banner se resuelva y luego permitir que la página o su proxy se disparen con el estado de consentimiento adjunto.
Los proveedores que disparan eventos de Measurement Protocol o CAPI directamente desde el edge están apostando a que el usuario concederá el consentimiento. Bajo el Art. 5(2) de la DMA, esa apuesta no les corresponde a ellos. Las Directrices 02/2023 del EDPB sobre el alcance técnico del Artículo 5(3) de ePrivacy señalaron un punto relacionado sobre la inyección de identificadores previa al consentimiento: es un tratamiento, necesita una base legal, y la ausencia de un banner no es una base.
Mitigaciones server-side que son legales#
Las mitigaciones a continuación son las que se mantienen firmes tanto bajo el GDPR como bajo la DMA. Comparten un hilo común: el estado de consentimiento debe ser observado antes de que cualquier dato sea transmitido a un gatekeeper o usado para publicidad.
Measurement Protocol con el estado de consentimiento adjunto. El Measurement Protocol de GA4 acepta los mismos parámetros de consent que el cliente gtag. El patrón: la página de destino resuelve el banner, envía el estado de consentimiento al servidor de primera parte del cliente, y el servidor de primera parte reenvía una solicitud mp/collect a GA4 con consent.ad_user_data y consent.ad_personalization configurados. Es server-side, pero posterior a la resolución del consentimiento. El reenvío de Elido (cubierto en Seguimiento server-side de GA4 a través de redirecciones) aplica el estado de consentimiento a la carga útil de salida.
Conversion API con cadenas de consentimiento. Meta CAPI acepta data_processing_options y opt_out; la API de conversiones de LinkedIn acepta enlli; la API de eventos de TikTok acepta limited_data_use. Todas ellas comunican el estado de consentimiento a la plataforma. El patrón es idéntico: la página de destino resuelve, envía al servidor de primera parte, y este dispara con el estado de consentimiento adjunto.
Informes server-side agregados. Cuando el estado de consentimiento deniega el uso publicitario o analítico, los informes server-side que son genuinamente agregados y carecen de identificadores por usuario son generalmente correctos bajo el Art. 5(2) de la DMA y bajo el Art. 6 del GDPR sobre una base de interés legítimo. Las Directrices 04/2023 del EDPB sobre anonimización reiteran que los datos seudonimizados no son anónimos y que la k-anonimidad baja sigue permitiendo la reidentificación. La práctica conservadora es publicar recuentos a nivel de espacio de trabajo con un umbral ≥10.
Resolución de identificadores de primera parte (first-party) en la página de destino. El enfoque más resiliente es identificar al usuario mediante una señal del Art. 6(1)(b) del GDPR — iniciaron sesión, completaron un formulario, pulsaron en un enlace de correo confirmado — y atribuir hacia atrás. Esto no depende de ad_storage ni de ad_user_data en absoluto. El post sobre atribución de clics tras Safari ITP cubre este patrón; es la respuesta adecuada también para el mundo post-DMA.
Mitigaciones server-side que no son legales#
Tres patrones suelen aparecer en las propuestas de proveedores de herramientas y no deberían.
Disparar eventos CAPI desde el edge antes de que se resuelva el consentimiento en la página de destino. Este es el modo de fallo descrito anteriormente. No hay un estado de consentimiento que adjuntar; disparar el evento implica que el responsable del tratamiento ha obtenido el consentimiento, lo cual no es cierto. Algunos proveedores describen esto como "atribución determinista"; bajo el Art. 5(2) de la DMA es una operación de combinación de datos que el usuario no ha autorizado.
Hashear la IP y tratar el hash como anónimo. El EDPB ha sido claro desde el Dictamen 4/2007 sobre el concepto de datos personales y reiterado en las Directrices 04/2023 que los identificadores hasheados siguen siendo datos personales cuando el hash es reversible por cualquier persona con acceso a la población. Los hashes de IP son fácilmente reversibles a escala; el hash no cambia el carácter legal del tratamiento.
Sincronización de identificadores server-side con gatekeepers. Reenviar el evento de clic a Google o Meta con un correo o número de teléfono hasheado, y confiar en que el gatekeeper lo empareje con su propio gráfico de identificadores, es la operación que el Art. 5(2) de la DMA restringe específicamente. El emparejamiento es una combinación de datos entre servicios realizada por el gatekeeper. El consentimiento para ello debe ser explícito y a nivel de usuario. La presencia del hash no hace que la operación sea lícita; la ausencia de consentimiento la hace ilícita.
Contexto reciente del TJUE y el EDPB#
Dos movimientos recientes de los reguladores aclaran el panorama.
La sentencia del TJUE en el Asunto C-621/22 (Royal Lichtervelde, 2024) reiteró el análisis de corresponsabilidad de Wirtschaftsakademie (C-210/16) y Fashion ID (C-40/17). Cuando un editor integra una etiqueta de un tercero y esa etiqueta transmite datos de usuario a dicho tercero, el editor y el tercero son corresponsables del tratamiento para ese proceso. El Art. 26 del GDPR exige un acuerdo transparente entre ellos. Para un cliente de Consent Mode v2, el acuerdo del Art. 26 con Google debe estar en vigor y el estado de consentimiento debe fluir con honestidad. Falsear ad_user_data=granted para recuperar la atribución es una responsabilidad de corresponsabilidad para ambas partes.
Las Directrices 03/2024 del EDPB sobre señales de consentimiento en contextos publicitarios (borrador de consulta, final esperado para el Q3 2026) abordan explícitamente Consent Mode v2. El borrador sostiene que la señal ad_user_data está, bajo el Art. 7(4) del GDPR, condicionada a un consentimiento libremente prestado, y que los banners que agrupan ad_storage con ad_user_data sin controles granulares no superan la prueba de consentimiento libre del Art. 7. La mayoría de los banners actuales los agrupan. El rediseño depende del cliente; el acortador ofrece un estado limpio, no diseña el banner.
Para el panorama más amplio del impacto de las transferencias — consentimiento otorgado, pero los datos siguen saliendo de la UE — el post sobre Schrems II y los píxeles de seguimiento cubre el ángulo de la Evaluación de Impacto de la Transferencia (TIA). La DMA no resuelve ese problema; añade otra restricción.
Lo que Elido hace (y no hace) en la capa de redirección#
Elido es el encargado del tratamiento (processor); el responsable (controller) decide la postura de consentimiento y opera el banner. El plano de datos de redirección hace lo mínimo:
- Preserva las UTMs y el propio identificador de clic del cliente. Los identificadores publicitarios específicos de proveedores (
fbclid,gclid,msclkid,ttclid) se reenvían por defecto porque son la superficie de atribución del responsable; hay disponibilidad de exclusión voluntaria (opt-out) por espacio de trabajo. - No dispara ningún evento publicitario server-side en el momento de la redirección. El evento de clic interno escrito en ClickHouse tiene la IP truncada a /24 o /48 y solo campos de dispositivo analizados, según el GDPR y la minimización de datos. No se comparte con ningún tercero.
- Soporta el reenvío de conversiones server-side con conciencia de consentimiento (consent-aware) a GA4, Meta CAPI, LinkedIn, TikTok y Reddit, condicionado por el estado de consentimiento que suministra la página de destino. El reenvío reside en
/features/conversion-tracking; la configuración está en la guía de documentación de seguimiento de conversiones. - Requiere una carga útil de
consentdesde la página de destino cuando el reenvío con conciencia de consentimiento está habilitado; si falta la carga útil, el evento se descarta, no se dispara silenciosamente con valores por defecto.
El panel de analítica en /features/analytics muestra el desglose del estado de consentimiento por campaña — otorgado, denegado, no establecido — para que el equipo de marketing pueda ver cuánta atribución se está perdiendo por las denegaciones.
Lo que Elido no hace: implementar el banner, decidir el consentimiento de antemano u honrar el consentimiento otorgado para usuarios que no lo han otorgado realmente. Esas decisiones pertenecen al responsable del tratamiento, donde tanto el GDPR como la DMA las sitúan.
La cuestión de la contratación#
Para un responsable del tratamiento que evalúa un acortador bajo el Art. 5(2) de la DMA, tres preguntas.
¿Reenvía el acortador datos de clics a algún servicio de publicidad o analítica de terceros en el momento de la redirección, independientemente del estado de consentimiento de la página de destino? Si la respuesta es sí, eso es una exposición al Art. 5(2) de la DMA que debe terminarse.
¿Soporta el acortador el reenvío del estado de consentimiento a sus endpoints de conversión server-side? Si no es así, el responsable necesitará un proxy de etiquetado server-side separado (contenedor de servidor GTM, Stape, Snowplow) entre la página de destino y las APIs de los gatekeepers.
¿Comparte la capa de analítica del acortador datos agregados con algún tercero? Algunos orientados al marketing publican "benchmarks de la industria" que resultan ser datos de clics de clientes con sub-gráficos identificables por la forma del tráfico; ¿cuál es el análisis de corresponsabilidad bajo Wirtschaftsakademie y Fashion ID?
Un acortador que vacila en cualquiera de estos puntos añade una superficie de riesgo de la DMA que el responsable tendrá que defender en una auditoría.
Conclusiones#
Consent Mode v2 no es una iniciativa de marketing. Es un mecanismo de cumplimiento para el Art. 5(2) de la DMA que se distribuye a través de la plataforma de etiquetas de Google. Las cuatro señales son honestas sobre qué consentimiento se ha obtenido; las mitigaciones server-side funcionan cuando el estado de consentimiento viaja con el evento; la pérdida de atribución en un mundo de consentimiento denegado es real pero menor de lo que parece una vez que se implementa la resolución de identificadores de primera parte. El acortador entrega un estado limpio a través de la redirección y expone un reenvío consciente del consentimiento que el responsable conecta a su banner.
Las directrices del EDPB esperadas para el Q3 2026 elevarán el listón. Diseñar solo para el listón actual es miope; diseñar para lo que el Art. 5(2) pretende — un consentimiento explícito, granular y libremente prestado para la combinación de datos entre servicios — es la posición que sobrevive a la siguiente ronda de cumplimiento.
Lectura relacionada#
- GDPR para acortadores de URL: lo que su DPO realmente quiere ver — la piedra angular del clúster de cumplimiento.
- Atribución de clics tras Safari ITP — la historia paralela de la pérdida de atribución en el lado del navegador.
- Atribución sin cookies explicada — patrones de identificadores de primera parte que sobreviven al consentimiento denegado.
- Seguimiento server-side de GA4 a través de redirecciones — la estructura de Measurement Protocol sobre la que se asienta el reenvío de consentimiento.
- Schrems II y los píxeles de seguimiento — qué sucede con los datos consentidos después de que cruzan el Atlántico.
- Superficie de producto:
/features/analyticspara la vista de desglose del estado de consentimiento. - Guía operativa: la guía de documentación de seguimiento de conversiones para la configuración del reenvío consciente del consentimiento.