Google Consent Mode v2 avec FlowConsent

FlowConsent implémente Google Consent Mode v2 nativement : un petit script en ligne (stub) enregistre des valeurs par défaut 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 sans cookie 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 extrait de code d'intégration commence par ce script en ligne, 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 outil de création de site, plugin) pourrait le devancer. Le stub, lui, s'exécute pendant la lecture du HTML : les valeurs par défaut sont en place avant tout tag, quel que soit ce qui le charge. C'est pourquoi le stub doit rester avant le chargeur dans votre extrait de code.

wait_for_update

wait_for_update: 500 demande aux tags Google de retenir leurs premières requêtes 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 premières requêtes 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 retire en plus les identifiants de clic publicitaire de ses pings sans cookie.

À quoi ressemble un refus : gcs=G100

Quand le visiteur refuse, les tags restent en mode sans cookie : 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 de mesure d'audience native d'un outil de création de site, injectée au-dessus de votre code personnalisé, comme le font les réglages Webflow), Google le traite sans restriction et dé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 dans la console une erreur 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.