¿Puedo pasar un script a Google Tag Manager para condicionarlo al consentimiento?

Todos los artículos

Sí, para la mayoría de los scripts de proveedores, y Google Tag Manager te da una barrera real: la etiqueta solo se ejecuta cuando se dispara su activador y su configuración de consentimiento lo permite. La excepción es cualquier script que tenga que actuar antes de que se renderice la página o ver la primerísima petición, porque un contenedor no puede dispararlo tan pronto.

¿Qué cambia al pasar un script a Google Tag Manager?

Un script escrito directamente en el head se ejecuta en cuanto el parser llega a él. No tiene ninguna barrera delante, y por eso un fragmento de proveedor en el head es el motivo más habitual de que una web instale cookies antes de que el visitante haya aceptado nada.

Pásalo a un contenedor y deja de ser marcado para convertirse en una etiqueta. Ahora se ejecuta cuando lo dispara un activador y cuando su configuración de consentimiento le permite seguir. Eso es justo lo que querías. También es la parte que la gente subestima: no solo has añadido una barrera, has cambiado el momento en que se ejecuta el script. Para la mayoría de los proveedores no pasa nada. Para unos pocos, ese es todo el problema.

¿Qué scripts no se pueden pasar al contenedor?

Hay tres tipos de script que no sobreviven al cambio, y fallan por el mismo motivo de fondo. Un contenedor se carga y se evalúa cuando la página ya ha empezado, y estos scripts necesitan actuar antes.

• Todo lo que tenga que ejecutarse antes del renderizado. Los scripts de personalización y de tests A/B reescriben la página antes de que la vea el visitante. Detrás de un activador llegan después del primer pintado, así que el visitante ve aparecer el contenido original y luego cambiar. Ese parpadeo es exactamente lo que el script tenía que evitar, así que moverlo no lo condiciona: lo rompe.
• Todo lo que tenga que ver la primera petición. Algunas herramientas antibots y antifraude están hechas para observar el primer instante de una visita. Disparadas desde un contenedor, ven una página que ya lleva un rato abierta, y su respuesta cambia en consecuencia.
• La propia capa de consentimiento. No puedes condicionar al consentimiento lo que recoge el consentimiento. El banner tiene que poder ejecutarse antes de que exista ninguna decisión, por eso va en el head, y por eso es uno de los pocos scripts que de verdad son estrictamente necesarios.

Cuando un script no se puede mover, lo honesto es dejarlo donde está y condicionarlo ahí: tu herramienta de consentimiento lo bloquea en la página, por categoría, en lugar de que lo retenga un contenedor. Mismo resultado, otro mecanismo, y la cuestión de la categoría la tratamos en en qué categoría de consentimiento debe ir un script.

¿Cómo se mueve un script sin dejar una copia atrás?

1. Quítalo primero del head

   No al final. Un script que está en los dos sitios se ejecuta dos veces, y la copia del head se ejecuta sin barrera, así que la etiqueta que acabas de montar en el contenedor no demuestra nada. Es la forma más habitual de que una migración parezca terminada sin haber cambiado nada.

2. Vuelve a crearlo como etiqueta

   Una etiqueta de HTML personalizado con el fragmento del proveedor, o la plantilla del propio proveedor si la galería la tiene. Mejor la plantilla: expone los parámetros del proveedor como campos de verdad y suele llegar con su configuración de consentimiento ya declarada.

3. Configura el consentimiento en la etiqueta, no solo en el activador

   En una etiqueta web están en Advanced Settings y, dentro, en Consent Settings. Ahí exiges consentimiento adicional para que la etiqueta se dispare e indicas los tipos de consentimiento de los que depende. Google documenta el panel en su resumen del consentimiento en Tag Manager. El activador es el otro control. Necesitas los dos, por lo que explica la siguiente sección.

4. Publica y prueba en la página real

   El modo de vista previa funciona con el cableado de depuración del contenedor y, muy a menudo, con un estado de consentimiento que tú mismo elegiste un minuto antes. Sirve para confirmar que una etiqueta existe. No demuestra lo que recibe un visitante real.

5. Comprueba los dos casos en la página, no en el contenedor

   Al rechazar, el proveedor no debería aparecer ni en el DOM ni en resource timing, es decir, no se inyectó ni se descargó nada. Al aceptar, debería aparecer en los dos. Resource timing es lo que cuenta: si se descargó algo del host del proveedor, se descargó, diga lo que diga el contenedor.

Hay una excepción al paso tres, y es importante: todo lo anterior es una guía para scripts de proveedores externos. Las etiquetas de la propia Google llevan comprobaciones de consentimiento integradas, así que una comprobación Additional Consent en una etiqueta de GA4 o de Google Ads la bloquea por completo en lugar de modular su comportamiento. Bloquear o no las etiquetas de Google hasta que haya consentimiento explica por qué, y cómo leer lo que hace de verdad tu contenedor.

Si después de todo eso el proveedor sigue apareciendo al rechazar, probablemente el script que moviste no es el que se está disparando. Hay otra cosa en la página que lo carga, y ese es un fallo distinto, con su propio diagnóstico en por qué el píxel de Facebook sigue cargándose aunque tus etiquetas estén bloqueadas.

¿Una comprobación de consentimiento en la etiqueta es lo mismo que un activador que espera?

Esta es la distinción que decide si la barrera aguanta de verdad. Un activador controla cuándo se tiene en cuenta una etiqueta. La configuración de consentimiento controla si puede ejecutarse una vez que se ha tenido en cuenta.

Si la condicionas solo con un activador, has cubierto la primera carga de página y nada más. Una etiqueta cuyo activador es un evento posterior, como un clic, el envío de un formulario o un cambio de ruta en una single page app, se vuelve a evaluar en el momento en que ocurre ese evento. Sin un requisito de consentimiento en la etiqueta, se ejecuta entonces, elija lo que elija el visitante.

Pon también el requisito en la etiqueta y se mantendrá por cualquier vía por la que se llegue a ella. El activador dice cuándo plantearse dispararla; la configuración de consentimiento dice si se permite dispararla. Juntos hacen que la barrera sea una propiedad de la etiqueta y no de una sola vía de entrada.

¿Puede saltarse la barrera un script que consideras estrictamente necesario?

La última limitación no es técnica. A veces se defiende que un proveedor es estrictamente necesario para que pueda ejecutarse antes del consentimiento, y en ocasiones el argumento se sostiene. Lo que importa es que el aviso de consentimiento y la tabla de cookies de la propia web digan lo mismo, palabra por palabra.

Si tu aviso incluye un proveedor en una categoría que el visitante puede rechazar, la etiqueta tiene que respetar ese rechazo. Un script que se ejecuta sin barrera mientras la página le dice al visitante que puede rechazarlo es una contradicción que un regulador puede leer directamente en tu propia web, y es bastante más fácil de encontrar que un contenedor mal configurado.

Velo bloquea por categoría en la página y pasa la misma decisión al contenedor, así que el ‘sí’ o el ‘no’ del visitante llega a la página y al contenedor a la vez.