Qu’est-ce que le Consent Mode v2 de Google ?
Le Consent Mode v2 est le mécanisme qui transmet aux balises Google (Google Ads, Google Analytics, Floodlight) le choix de consentement exprimé par l’internaute, afin qu’elles adaptent leur comportement : collecte complète si l’internaute accepte, collecte restreinte ou nulle s’il refuse. Il ne collecte pas le consentement lui-même : c’est le rôle du bandeau cookies, ou plateforme de gestion du consentement (CMP).
Google le résume ainsi dans sa présentation du Consent Mode : le Consent Mode permet de communiquer le statut de consentement aux cookies ou aux identifiants d’application, et les balises ajustent leur comportement pour respecter ce choix. La « v2 » désigne l’ajout de deux paramètres, ad_user_data et ad_personalization, présentés par Google dans ses mises à jour pour le trafic de l’EEE.
Pour un annonceur, l’enjeu est double : rester conforme, et conserver assez de signal pour que les campagnes continuent d’apprendre. C’est l’une des briques que nous déployons systématiquement en tant qu’agence tracking publicitaire.
Quels sont les paramètres du Consent Mode ?
Le Consent Mode repose sur sept types de consentement, dont quatre concernent directement la publicité et la mesure : ad_storage, analytics_storage, ad_user_data et ad_personalization. Chacun prend la valeur granted (accordé) ou denied (refusé). Les définitions ci-dessous reprennent la présentation officielle du Consent Mode.
| Paramètre | Ce qu’il contrôle | Nouveau en v2 |
|---|---|---|
| ad_storage | Le stockage (cookies sur le web, identifiants d’appareil dans les apps) lié à la publicité | Non |
| analytics_storage | Le stockage lié à la mesure d’audience | Non |
| ad_user_data | L’envoi à Google de données utilisateur à des fins publicitaires | Oui |
| ad_personalization | La publicité personnalisée (remarketing notamment) | Oui |
| functionality_storage | Le stockage nécessaire au fonctionnement du site, par exemple la langue | Non |
| personalization_storage | Le stockage lié à la personnalisation, par exemple des recommandations | Non |
| security_storage | Le stockage lié à la sécurité : authentification, prévention de la fraude | Non |
La distinction introduite par la v2 est utile en pratique. ad_storage porte sur les cookies ; ad_user_data porte sur l’envoi de données personnelles à Google, par exemple les emails hachés des conversions améliorées Google Ads ; ad_personalization porte sur l’usage de ces données pour cibler. Votre CMP doit donc faire correspondre chaque finalité de son bandeau au bon paramètre.
Mode basique ou mode avancé : quelle différence ?
En mode basique, les balises Google restent bloquées tant que l’internaute n’a pas répondu au bandeau ; en mode avancé, elles se chargent immédiatement avec un consentement refusé par défaut et envoient des signaux sans cookies en cas de refus. La différence a des conséquences directes sur la mesure, que Google détaille dans sa documentation.
| Mode basique | Mode avancé | |
|---|---|---|
| Chargement des balises | Bloquées jusqu’à l’interaction avec le bandeau | Chargées dès l’arrivée, consentement par défaut sur denied |
| Données envoyées avant le choix | Aucune, pas même le statut par défaut | Signaux sans cookies |
| En cas de refus | Aucune donnée transmise à Google | Signaux sans cookies uniquement |
| En cas d’acceptation | Mesure complète | Mesure complète |
| Modélisation des conversions | Modèle général | Modèle propre à l’annonceur, plus détaillé |
Le mode avancé donne à Google davantage de matière pour modéliser les conversions non observées. Il implique aussi que des requêtes partent vers Google avant et malgré un refus, même sans cookies. Le choix entre les deux n’est donc pas seulement technique : il doit être validé au regard de votre analyse juridique et de votre politique de confidentialité, idéalement avec votre DPO ou votre conseil.
Chez Creapreneurs, nous présentons les deux options avec leurs conséquences chiffrées sur vos propres données, puis nous appliquons la décision de l’annonceur. Nous ne choisissons jamais le mode avancé « par défaut » sans que ce point ait été tranché.
Le Consent Mode v2 est-il obligatoire ?
Pour le trafic de l’Espace économique européen, Google exige des annonceurs qui utilisent ses fonctions de personnalisation et de mesure qu’ils recueillent le consentement et transmettent les signaux correspondants ; le Consent Mode v2 est le moyen prévu pour le faire sur un site. Google indique renforcer l’application de sa politique relative au consentement de l’utilisateur dans l’UE (EU user consent policy) et précise que les annonceurs doivent la respecter pour utiliser la personnalisation des annonces et la mesure (Google Ads Help).
Google rattache ces évolutions au Digital Markets Act : sa page Data use in Ad services for the EEA indique qu’en conséquence du DMA, de nouveaux choix sur le partage des données entre services publicitaires Google s’appliquent depuis mars 2024. Pour les listes Customer Match, Google précise qu’à partir de mars 2024 les deux champs de consentement doivent valoir GRANTED pour être utilisés dans l’EEE, un statut non spécifié étant traité comme une absence de consentement (FAQ Customer Match).
Enfin, la page Verify your consent signals for EEA users rappelle que le consentement est requis dans l’EEE, au Royaume-Uni et en Suisse, et demande d’inclure une valeur pour ad_user_data. Sans ces signaux, attendez-vous à perdre l’accès aux fonctions de remarketing et de personnalisation pour ces utilisateurs, ainsi qu’une partie de la mesure.
Consent Mode, CMP et CNIL : qui fait quoi ?
La CMP recueille le consentement dans le respect des règles de la CNIL, le Consent Mode transmet ce choix aux balises Google, et Google Tag Manager orchestre l’ensemble : aucun des trois ne remplace les autres. Le Consent Mode ne rend pas un bandeau conforme ; il ne fait que relayer ce que le bandeau a recueilli.
En France, la CNIL rappelle que le dépôt ou la lecture de traceurs non exemptés exige un consentement préalable (article 82 de la loi Informatique et Libertés), et que l’internaute doit pouvoir accepter ou refuser avec le même degré de simplicité (CNIL, que dit la loi). Certains outils de mesure d’audience peuvent être exemptés sous conditions strictes : finalité limitée à la mesure pour le seul compte de l’éditeur, données statistiques anonymes, pas de recoupement, cookies d’une durée de vie de 13 mois maximum et données conservées 25 mois maximum (CNIL, mesure d’audience).
Les balises publicitaires Google n’entrent pas dans cette exemption. Concrètement, un dispositif sain suit cette logique :
- la CMP affiche des choix clairs, avec un bouton « Tout refuser » aussi accessible que « Tout accepter » ;
- chaque finalité du bandeau est reliée au bon paramètre du Consent Mode ;
- le consentement par défaut est défini avant le chargement de toute balise Google ;
- la mise à jour est envoyée dès que l’internaute fait son choix, puis appliquée sur toutes les pages suivantes.
Google recommande de passer par une CMP certifiée ou, pour un bandeau maison, d’implémenter le Consent Mode vous-même. Sur Shopify, l’aide Shopify précise que les paramètres de confidentialité client fonctionnent avec le Consent Mode v2, mais que les pixels personnalisés nécessitent un ajout manuel.
Quel impact le Consent Mode a-t-il sur la mesure des conversions ?
Le Consent Mode ne récupère pas les conversions des internautes qui refusent : il permet à Google d’en modéliser une partie, avec une précision qui dépend du mode choisi et du volume de données. Google explique utiliser les signaux sans cookies pour modéliser les métriques et combler les écarts de collecte ; en mode basique, la modélisation repose sur un modèle général (Consent mode overview).
Trois conséquences pratiques pour le pilotage :
- Les chiffres bruts baissent après la mise en conformité. Ce n’est pas une perte de performance mais une perte de visibilité ; comparez les périodes avec prudence.
- Les conversions modélisées apparaissent avec un délai et peuvent faire évoluer les rapports des jours précédents. Évitez de juger une campagne sur 48 heures.
- Le back-office reste la référence : chiffre d’affaires Shopify, leads du CRM. Le rapprochement régulier entre les deux évite de couper une campagne rentable. Notre guide sur le calcul du ROAS rentable détaille cette logique.
Deux réglages complémentaires existent dans la documentation de mise en place : url_passthrough, qui fait transiter dans les URL les informations de clic, d’identifiant client et de session lorsque le consentement n’est pas accordé, et ads_data_redaction, qui masque les données publicitaires lorsque ad_storage est refusé. Leur activation mérite le même arbitrage juridique que le choix du mode avancé.
Consent Mode et conversions améliorées : comment les articuler ?
Les conversions améliorées complètent la mesure en envoyant à Google des données first-party hachées, et c’est précisément le paramètre ad_user_data du Consent Mode qui doit encadrer cet envoi. Les deux dispositifs ne sont pas concurrents : l’un récupère du signal, l’autre fixe les limites dans lesquelles ce signal peut être transmis.
D’après l’aide Google Ads sur les conversions améliorées, les données (email notamment) sont normalisées puis hachées avec l’algorithme SHA-256 avant l’envoi. Il en existe deux déclinaisons : pour le web, qui rattache les ventes du site à des comptes Google connectés ayant interagi avec une annonce, et pour les leads, qui rattache des ventes hors ligne issues d’un formulaire.
Notre règle d’implémentation est simple : pas d’envoi de données hachées si ad_user_data vaut denied. Nous vérifions ce comportement en recette, car un conteneur Google Tag Manager mal configuré peut transmettre l’email hashé avant même que le choix de l’internaute soit connu. Les mêmes principes s’appliquent aux paramètres clients envoyés à Meta.
Comment installer et vérifier le Consent Mode v2 ?
L’installation fiable consiste à définir un état de consentement par défaut avant toute balise, à mettre à jour cet état au choix de l’internaute, puis à vérifier le statut dans Google Ads et dans l’outil de prévisualisation de Google Tag Manager. Les commandes sont décrites dans la page Set up consent mode on websites.
- Définir la valeur par défaut de chaque type de consentement utilisé, généralement denied pour les finalités soumises à consentement.
- Utiliser wait_for_update pour laisser à la CMP le temps de charger avant que les balises ne partent.
- Paramétrer region si vous appliquez des valeurs par défaut différentes selon les pays (codes ISO 3166-2).
- Envoyer la mise à jour au clic sur le bandeau, puis la conserver sur les pages suivantes.
- Contrôler le statut dans le diagnostic des conversions de Google Ads, qui indique si le Consent Mode est détecté et actif.
Si vous utilisez aussi Meta, la même lecture du consentement doit piloter le Pixel et l’API de conversion Meta. Et si vous passez par un tracking server side, l’état du consentement doit être transmis au conteneur serveur, qui ne le devine pas.
Quelles erreurs rencontrons-nous le plus souvent ?
La plupart des Consent Mode défaillants sont installés, mais mal branchés : la bannière s’affiche, le code est présent, et pourtant les balises ne respectent pas réellement le choix de l’internaute. Voici les cas que nous corrigeons le plus souvent lors de nos audits.
- Valeurs par défaut définies trop tard : une balise Google part avant que le consentement par défaut ne soit posé.
- Paramètres v2 absents : seuls ad_storage et analytics_storage sont transmis, sans ad_user_data ni ad_personalization.
- Refus mal propagé : le choix est enregistré sur la première page mais pas appliqué aux suivantes, ou pas aux sous-domaines de paiement.
- Balises codées en dur dans le thème, qui échappent au gestionnaire de balises et donc au Consent Mode.
- Doublons de balises : une application native et Google Tag Manager envoient chacun les conversions.
Le test qui tranche est simple : ouvrir le site en navigation privée, refuser, parcourir jusqu’à la commande et observer les requêtes réseau. C’est la première vérification de tout audit que nous menons, et elle se refait après chaque évolution du site.