Google Consent Mode v2 con FlowConsent
Cómo implementa FlowConsent Consent Mode v2: valores denied antes de toda etiqueta, wait_for_update, pings sin cookies gcs=G100 y detección de carrera.
FlowConsent implementa Google Consent Mode v2 de serie: un stub inline registra valores por defecto denied para las cuatro señales de consentimiento antes de que cargue cualquier etiqueta de Google, el banner envía gtag('consent', 'update', …) cuando el visitante elige, y los pings sin cookies de Google (gcs=G100) mantienen viva la modelización de conversiones sin violar un rechazo. Sin plantillas extra, sin plugins de terceros.
El stub: denied por defecto, antes de cada etiqueta
Tu snippet de integración empieza con este script inline — se genera por ti en Builder → Despliegue → Integración:
<script>
window.dataLayer=window.dataLayer||[];
function gtag(){dataLayer.push(arguments);}
gtag('consent','default',{
'ad_storage':'denied',
'analytics_storage':'denied',
'ad_user_data':'denied',
'ad_personalization':'denied',
'wait_for_update':500
});
gtag('set','url_passthrough',true);
gtag('set','ads_data_redaction',true);
</script>Las cuatro señales v2 — ad_storage, analytics_storage, ad_user_data, ad_personalization — arrancan en denied. El bundle del banner registra los mismos valores por defecto, pero se carga de forma asíncrona: una etiqueta de Google añadida por otro canal (ajustes de un site builder, un plugin) podría adelantarlo. El stub se ejecuta durante el parseo del HTML, así que los valores por defecto están en su sitio antes que cualquier etiqueta, la cargue quien la cargue. Por eso el stub debe permanecer antes del cargador en tu snippet.
wait_for_update
wait_for_update: 500 indica a las etiquetas de Google que retengan sus primeros hits hasta 500 ms, dando tiempo al banner a aplicar la elección guardada de una visita anterior. Un visitante recurrente que ya aceptó recupera la medición completa sin que sus primeros hits salgan como rechazados. El retardo se configura en los ajustes de Consent Mode de tu banner.
url_passthrough y ads_data_redaction
Ambos están activados por defecto y pueden desactivarse en la configuración del banner:
url_passthrough— hace pasar la información de clic publicitario (gclid,dclid…) por parámetros de URL mientras el consentimiento está rechazado, para que un consentimiento posterior no pierda la atribución.ads_data_redaction— cuandoad_storageestá rechazado, Google elimina además los identificadores de clic publicitario de sus pings sin cookies.
Cómo se ve un rechazo: gcs=G100
Cuando el visitante rechaza, las etiquetas se quedan en modo sin cookies: no se escribe ninguna cookie y Google recibe pings anónimos con gcs=G100 (señal de «consentimiento rechazado»). Esos pings son conformes con el rechazo — el escaneo de conformidad de FlowConsent los reconoce, los reporta aparte y nunca los cuenta como violaciones. Un sitio que usa Consent Mode correctamente jamás resulta penalizado por ellos.
La carrera que FlowConsent no puede ganar — pero detecta
Los valores por defecto de Consent Mode solo protegen a las etiquetas que entran en el dataLayer después de ellos. Si un gtag('config', 'G-XXXX') se encola antes que los valores por defecto de consentimiento — típicamente la integración analítica nativa de un site builder inyectada por encima de tu custom code, como hacen los ajustes de Webflow — Google lo procesa sin restricciones y coloca sus cookies, haga lo que haga cualquier CMP después.
El banner comprueba exactamente este caso al arrancar y de nuevo tras la carga de la página: si un config precede al consent default en el dataLayer, registra un error de consola con los identificadores de las etiquetas y envía un evento ConsentDefaultRaceLost a la telemetría de FlowConsent. La solución es siempre la misma: quitar la etiqueta del canal que la inyecta demasiado pronto y declarar el servicio en Builder → Servicios para que el banner lo gestione.