Google Consent Mode v2 avec FlowConsent

FlowConsent implémente Google Consent Mode v2 nativement : un stub inline enregistre des défauts denied pour les quatre signaux de consentement avant le chargement de tout tag Google, la bannière envoie gtag('consent', 'update', …) quand le visiteur choisit, et les pings cookieless de Google (gcs=G100) préservent la modélisation des conversions sans violer un refus. Pas de gabarit supplémentaire, pas de plugin tiers.

Le stub : denied par défaut, avant chaque tag

Votre snippet d'intégration commence par ce script inline — généré pour vous dans Builder → Déploiement → Intégration :

<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>

Les quatre signaux v2 — ad_storage, analytics_storage, ad_user_data, ad_personalization — démarrent denied. Le bundle de la bannière enregistre les mêmes défauts, mais il se charge de façon asynchrone : un tag Google ajouté par un autre canal (réglages d'un site builder, plugin) pourrait le devancer. Le stub, lui, s'exécute au parsing du HTML : les défauts sont en place avant tout tag, qui que ce soit qui le charge. C'est pour ça que le stub doit rester avant le chargeur dans votre snippet.

wait_for_update

wait_for_update: 500 demande aux tags Google de retenir leurs premiers hits jusqu'à 500 ms, le temps que la bannière pousse le choix mémorisé d'une visite précédente. Un visiteur qui a déjà accepté retrouve la mesure complète sans que ses premiers hits partent en refusé. Le délai se règle dans les paramètres Consent Mode de votre bannière.

url_passthrough et ads_data_redaction

Les deux sont activés par défaut et se désactivent dans la configuration de la bannière :

• url_passthrough — fait transiter les informations de clic publicitaire (gclid, dclid…) par les paramètres d'URL tant que le consentement est refusé, pour qu'un consentement ultérieur ne perde pas l'attribution.
• ads_data_redaction — quand ad_storage est refusé, Google expurge en plus les identifiants de clic publicitaire de ses pings cookieless.

À quoi ressemble un refus : gcs=G100

Quand le visiteur refuse, les tags restent en mode cookieless : aucun cookie n'est écrit et Google reçoit des pings anonymes portant gcs=G100 (signal « consentement refusé »). Ces pings sont conformes au refus — le scan de conformité FlowConsent les reconnaît, les rapporte à part et ne les compte jamais comme violations. Un site qui utilise correctement Consent Mode n'est jamais pénalisé pour eux.

La course que FlowConsent ne peut pas gagner — mais détecte

Les défauts Consent Mode ne protègent que les tags entrés dans le dataLayer après eux. Si un gtag('config', 'G-XXXX') est mis en file avant les défauts de consentement — typiquement l'intégration analytics native d'un site builder injectée au-dessus de votre custom code, comme le font les réglages Webflow — Google le traite sans restriction et pose ses cookies, quoi que fasse ensuite n'importe quelle CMP.

La bannière vérifie exactement ce cas au démarrage, puis à nouveau après le chargement de la page : si un config précède le consent default dans le dataLayer, elle affiche une erreur console nommant les identifiants de tags et remonte un événement ConsentDefaultRaceLost à la télémétrie FlowConsent. La correction est toujours la même : retirer le tag du canal qui l'injecte trop tôt, et déclarer le service dans Builder → Services pour que la bannière le gère.