Google Consent Mode (v1 et v2)

Nicolas Belhamri

03/05/2023

12 min

Définition courte

⚠️ Attention (beaucoup sont confus sur le sujet) le Google Consent Mode n’est pas une CMP (Consent Management Platform) comme Axeptio, Didomi, OneTrust, Cookiebot, etc.

Initialement (dans sa première version bêta – la v1), le Google Consent Mode est une fonctionnalité qui permet d’adapter les données collectées par différentes balises Google (Google Analytics 4, Google Ads, Floodlight, etc) en fonction de l’état du consentement de l’utilisateur vis-à-vis de l’écriture et de la lecture des cookies par ces balises.

Cette fonctionnalité permet de modéliser des données aux seins des produits Google concernés (Google Analytics 4, Google Ads, Search Ads 360, etc) afin de combler les pertes de données enregistrées par les utilisateurs n’ayant pas donné leur consentement quant à l’écriture et à la lecture des cookies par les balises Google associées (Google Analytics 4, Google Ads, Floodlight, etc).

Voici une documentation officielle de Google sur le sujet :

https://support.google.com/analytics/answer/9976101?hl=fr

Pour information, une balise Google est un bout de code JavaScript qui, lorsqu’il est déclenché/exécuté sur un site web, envoie des données à un produit Google par l’intermédiaire d’un hit (une requête HTTPS).

Afin d’envoyer des données “plus précises” à un produit Google (Google Analytics 4, Google Ads, Search Ads 360, etc), la balise Google concernée (Google Analytics 4, Google Ads, Floodlight, etc) doit être en mesure d’écrire et lire des cookies sur le navigateur de l’utilisateur concerné.

Cela permet par exemple à Google Analytics 4 de reconnaître un même utilisateur sur un site web dans le temps (sur une même session comme sur plusieurs sessions).

En effet, si une balise Google Analytics 4 peut écrire et lire des cookies sur le navigateur d’un utilisateur, elle peut intégrer dans chaque hit envoyé à Google Analytics 4 depuis ce navigateur, un identifiant spécifique (client_id, user_id) stocké pour une durée plus ou moins longue, dans les cookies du navigateur de cet utilisateur.

Ainsi, si Google Analytics 4 reçoit plusieurs hits avec le même client_id (ou user_id) dans le temps, il saura que ces hits proviennent d’un même utilisateur.

Reconnaître un même utilisateur dans le temps permet (en partie) à Google Analytics 4 de réaliser des analyses comportementales intéressantes comme :

Des analyses de rétention (cohortes) ;
Des analyses de parcours utilisateurs ;
Etc.

Si vous voulez aller plus loin sur le sujet du Google Consent Mode (v1 et v2), c’est un peu plus bas que ça se passe, nous n’avons pas fait les choses à moitié 👇 🤓

10 ressources data marketing à forte valeur ajoutée

1. Formation sur Google Analytics 4

2. Formation sur Google Tag Manager

3. Formation sur les paramètres UTM

4. Formation sur le plan de taggage

5. Formation sur Looker Studio

6. Formation sur Matomo

7. Formation sur Google Tag Manager Server-Side

8. Formation sur l’attribution marketing

9. Formation sur l’API de conversion Facebook

10. Formation sur Google BigQuery

Pour aller plus loin

Pour faire simple, avec le Google Consent Mode v1 (qui, rappelons-le, est une version bêta), si un utilisateur donne son consentement pour l’utilisation des cookies par une balise Google spécifique, cette balise fonctionne normalement. C’est-à-dire qu’elle envoie des données non anonymisées via des hits classiques aux serveurs de Google en écrivant et lisant des cookies sur le navigateur de l’utilisateur concerné.

À l’inverse, si un utilisateur refuse de donner son consentement pour l’utilisation des cookies par une balise Google spécifique, cette balise envoie des données anonymisées via des pings “allégés” aux serveurs de Google sans écrire ni lire de cookies sur le navigateur de l’utilisateur concerné.

Si l’on résume simplement, voici comment cela se matérialise :

Si un utilisateur indique sur un bandeau cookie custom ou une CMP tierce qu’il ne souhaite pas qu’une balise publicitaire Google écrive et lise des cookies sur son navigateur, alors le paramètre de consentement “ad_storage” a la valeur “denied” ;
Si un utilisateur indique sur un bandeau cookie custom ou une CMP tierce qu’il est d’accord pour qu’une balise publicitaire Google écrive et lise des cookies sur son navigateur, alors le paramètre de consentement “ad_storage” a la valeur “granted” ;
Si un utilisateur indique sur un bandeau cookie custom ou une CMP tierce qu’il ne souhaite pas qu’une balise analytics Google écrive et lise des cookies sur son navigateur, alors le paramètre de consentement “analytics_storage” a la valeur “denied” ;
Si un utilisateur indique sur un bandeau cookie custom ou une CMP tierce, qu’il est d’accord pour qu’une balise analytics Google écrive et lise des cookies sur son navigateur, alors le paramètre de consentement “analytics_storage” a la valeur “granted”.

Ces paramètres de consentement sont envoyés systématiquement avant qu’une balise Google se déclenche sur le site web concerné pour collecter des données.

Une balise Google utilisera ou n’utilisera pas les cookies lors de son déclenchement en fonction de la valeur des paramètres de consentement envoyés à Google juste avant son déclenchement.

À titre d’information, lorsque le Google Consent Mode v1 est déployé sur un site web, les hits générés par les balises Google concernées intègrent un “code de statut” par l’intermédiaire du paramètre “gsc” présent dans le payload de ces hits. Voici les différents codes de statut possibles :

“gsc” = “G100” quand “ad_storage” = “denied” et “analytics_storage” = “denied” ;
“gsc” = “G101” quand “ad_storage” = “denied” et “analytics_storage” = “granted” ;
“gsc” = “G110” quand “ad_storage” = “granted” et “analytics_storage” = “denied” ;
“gsc” = “G111” quand “ad_storage” = “granted” et “analytics_storage” = “granted”.

Vous trouverez plus d’informations à ce sujet sur ces 2 documentations officielles de Google :

https://support.google.com/analytics/answer/9976101?hl=fr

https://developers.google.com/tag-platform/security/guides/consent?hl=fr

Ainsi, à l’aide des données non anonymisées, des données anonymisées et d’algorithmes de machine learning, un produit Google peut modéliser le comportement des utilisateurs qui refusent les cookies ainsi que les éventuelles conversions “perdues”, en se basant sur le comportement des utilisateurs similaires qui acceptent les cookies.

La modélisation du comportement et des conversions permet à Google :

De vous proposer des rapports “plus précis” sur ses produits en ajoutant des données modélisées afin de combler les données manquantes dues au non-consentement de certains de vos utilisateurs ;
De mieux optimiser vos campagnes publicitaires sur ses produits publicitaires en ajoutant des données modélisées dans ses algorithmes afin de combler les données manquantes dues au non-consentement de certains de vos utilisateurs.

Vous trouverez plus d’informations concernant le fonctionnement de la modélisation du comportement et des conversions sur ces 5 documentations officielles de Google :

https://support.google.com/analytics/answer/11161109?sjid=7539879738310082012-EU&hl=fr

https://support.google.com/analytics/answer/10710245?sjid=7539879738310082012-EU&hl=fr

https://support.google.com/google-ads/answer/10081327?sjid=3672433235500020354-EU&hl=fr

https://support.google.com/google-ads/answer/10548233?sjid=3672433235500020354-EU&hl=fr

https://support.google.com/google-ads/answer/12445061?sjid=9498974950668629432-EU&hl=fr

Le Google Consent Mode v1, c’est donc un peu la mesure hybride de Piano Analytics mais à la sauce Google.

La principale différence entre le Google Consent Mode v1 et la mesure hybride de Piano Analytics est qu’avec cette dernière, si un utilisateur ne donne pas son consentement, un tracking beaucoup moins allégé qu’avec le Google Consent Mode v1 est tout de même activé.

Ce tracking beaucoup moins allégé permet à Piano Analytics de nourrir ses rapports affichant des données primaires (landing pages, sources, sessions, pages vues, etc) sans modélisation via machine learning.

⚠️ À date (janvier 2024), il y a encore peu de documentations officielles sur le sujet. Dans les prochaines semaines, des documentations officielles devraient voir le jour et nous donner plus de détail concernant l’obligation du Google Consent Mode v2, son déploiement, les CMP compatibles, etc.

Le 28 novembre 2023, Google a assuré un webinaire afin de présenter les améliorations significatives relatives au Google Consent Mode v2. La majeure partie des informations que nous vous donnons ici proviennent de ce webinaire.

Lien du replay : https://www.youtube.com/watch?v=IcNS8ATkGo0&ab_channel=GoogleMarketingPlatform

À partir du 6 mars 2024, Google va imposer aux sites web utilisant des produits publicitaires Google (Google Ads, Search Ads 360, etc) de recueillir le consentement de leurs utilisateurs finaux basés dans l’EEE (Espace Économique Européen) et au Royaume-Uni avec le Google Consent Mode v2.

Après mars le 6 mars 2024, le déploiement du Google Consent Mode v2 sera obligatoire pour activer des publicités performantes aux utilisateurs basés dans l’EEE et au Royaume-Uni sur les produits publicitaires Google.

Autrement dit, après mars le 6 mars 2024, si vous n’avez pas déployé le Google Consent Mode v2 sur votre site web, vous ne pourrez pas utiliser toutes les fonctionnalités (publicités retargeting, publicités personnalisées, création d’audiences, suivi avancé des conversions, etc) des produits publicitaires Google que vous utilisez. Sans parler du fait que vos rapports sur ces produits seront moins “précis” et les algorithmes d’optimisation des publicités moins performant en raison de la perte des données modélisées.

Cette imposition a pour objectif de mettre en conformité Google au DMA (Digital Marketing Act – loi de régulation qui vise à diminuer l’effet de monopole des GAFAM en Europe) d’ici le 6 mars 2024.

Afin de se mettre en conformité aux exigences du DMA, Google a donc introduit 2 principales nouveautés au Google Consent Mode v1 (qui, rappelons-le, est une version bêta), donnant ainsi naissance au Google Consent Mode v2.

Ces deux principales nouveautés sont :

L’introduction de 2 nouveaux paramètres de consentement ;
La proposition de 2 niveaux de déploiement.

2 nouveaux paramètres de consentement

Alors que le Google Consent Mode v1 se concentrait sur la collecte des données consenties, cette nouvelle version du Google Consent Mode a été améliorée pour contrôler l’utilisation de ces données consenties dans les produits publicitaires Google.

Ainsi, la première principale nouveauté est l’introduction de 2 nouveaux paramètres de consentement relatifs à la publicité (en plus du paramètre “ad_storage” initialement présent dans le Google Consent Mode v1) : “ad_user_data” et “ad_personalization”.

Avec cette nouveauté, en plus de spécifier leur consentement vis-à-vis de l’écriture et de la lecture des cookies par les balises publicitaires du site web concerné (paramètre de consentement ”ad_storage”), les utilisateurs ont désormais la possibilité de spécifier :

Leur consentement concernant le partage de leurs données utilisateurs aux produits publicitaires Google (”ad_user_data”) ;
Leur consentement concernant les publicités de retargeting ultérieures par les produits publicitaires Google (”ad_personalization”).

Si l’on résume simplement, voici comment cela se matérialise :

Si un utilisateur indique sur un bandeau cookie custom ou une CMP tierce qu’il ne souhaite pas que ses données utilisateurs soient partagées aux produits publicitaires Google, alors le paramètre de consentement “ad_user_data” a la valeur “denied” ;
Si un utilisateur indique sur un bandeau cookie custom ou une CMP tierce qu’il est d’accord pour que ses données utilisateurs soient partagées aux produits publicitaires Google, alors le paramètre de consentement “ad_user_data” a la valeur “granted” ;
Si un utilisateur indique sur un bandeau cookie custom ou une CMP tierce qu’il ne souhaite pas être ciblé par des publicités personnalisées (retargeting) de la part des produits publicitaires Google, alors le paramètre de consentement “ad_personalization” a la valeur “denied” ;
Si un utilisateur indique sur un bandeau cookie custom ou une CMP tierce qu’il est d’accord pour être ciblé par des publicités personnalisées (retargeting) de la part des produits publicitaires Google, alors le paramètre de consentement “ad_personalization” a la valeur “granted” ;

Ces paramètres de consentement sont envoyés systématiquement avant qu’une balise Google se déclenche sur le site web concerné pour collecter des données.

À titre d’information, lorsque le Google Consent Mode v2 est déployé sur un site web, les hits générés par les balises Google concernées intègrent un nouveau “code de statut” par l’intermédiaire du paramètre “gcd” présent dans le payload de ces hits. Le format de ce “code de statut” est le suivant :

“11{{ad_storage_consent_value}}1{{analytics_storage_consent_value}}1
{{ad_user_data_consent_value}}1{{ad_personalization_consent_value}}5”

Avec :

“11” – préfixe qui ne change jamais ;
“1” – séparateurs pour les valeurs des paramètres de consentement (”ad_storage”, “analytics_storage”, “ad_user_data” et “ad_personalization”) ;
“5” (ou parfois “7”) – suffixe qui ne change jamais.

Les valeurs relatives aux “{{xxx_consent_values}}” peuvent être les suivantes :

“p” – valeur “denied” par défaut ;
“t” – valeur “granted” par défaut ;
“q”, “m” ou “u” – valeur “denied” lors d’un update après une interaction de l’utilisateur avec le bandeau cookie custom ou la CMP tierce ;
“r”, “n” ou “v” – valeur “granted” lors d’un update après une interaction de l’utilisateur avec le bandeau cookie custom ou la CMP tierce ;
“l” – le paramètre de consentement n’est pas défini.

2 niveaux de déploiement

La seconde nouveauté est la proposition de 2 niveaux de déploiement pour le Google Consent Mode v2 :

Google Consent Mode v2 (avancé) ;
Google Consent Mode v2 (basique).

Avant d’examiner de plus près ces deux niveaux de déploiement, voici un schéma illustrant l’intersection des 2 principales nouveautés introduites dans le Google Consent Mode v2.

Avec le Google Consent Mode v2 (avancé), même si un utilisateur n’a pas encore interagi avec le bandeau cookie custom ou la CMP tierce utilisée par le site web concerné, les balises Google concernées envoient des données anonymisées via des pings “allégés” (les mêmes que ceux présentés un peu plus haut) aux serveurs de Google.

Dans ce cas de figure :

Les balises Google concernées ne peuvent ni écrire ni lire de cookies sur le navigateur de l’utilisateur ;
Les données utilisateurs (données first-party hachées, user_id) ne sont pas partagées aux produits publicitaires Google ;
L’utilisateur ne peut pas être ciblé par des publicités personnalisées (retargeting) de la part des produits publicitaires Google.

La collecte de données s’effectue donc dans la même logique qu’avec le Google Consent Mode v1.

En utilisant le Google Consent Mode v2 (avancé), vous envoyez davantage de données aux produits publicitaires Google que vous utilisez. La modélisation des conversions est donc plus précise, ce qui vous permet d’optimiser davantage vos performances publicitaires.

Avec le Google Consent Mode v2 (basique), si un utilisateur n’a pas encore interagi avec le bandeau cookie custom ou la CMP tierce utilisée par le site web concerné, les balises Google concernées sont bloquées et n’envoient aucunes données aux serveurs de Google (même pas de données anonymisées via des pings “allégés”).

Ensuite, lorsque l’utilisateur interagit avec le bandeau cookie custom ou la CMP tierce utilisée par le site web concerné, les balises Google concernées adaptent leur collecte de données en fonction des paramètres de consentement. Avec ce niveau de déploiement, les balises Google concernées n’enverront jamais de données anonymisées via des pings “allégés” aux serveurs de Google.

La collecte de données avec le Google Consent Mode v2 (basique) est donc plus stricte qu’avec le Google Consent Mode v2 (avancé).

En utilisant le Google Consent Mode v2 (basique), vous envoyez moins de données aux produits publicitaires Google que vous utilisez. La modélisation des conversions est donc moins précise (car uniquement basée sur les données des utilisateurs ayant consenti), ce qui ne vous permet pas d’optimiser davantage vos performances publicitaires.

Voici deux tableaux supplémentaires qui pourraient faciliter votre compréhension des distinctions entre le Google Consent Mode v2 (avancé) et le Google Consent Mode v2 (basique) en ce qui concerne leur impact final :

Pour déployer le Google Consent Mode v2, il est nécessaire d’avoir déjà mis en place un bandeau cookie custom ou une CMP tierce permettant de collecter et gérer les différents paramètres de consentement utilisateur présents dans le Google Consent Mode v2.

Le Google Consent Mode v2 peut être déployé de différentes manières :

Directement dans le code source de votre site web avec la librairie gtag.js ;
Avec un Tag Management System (souvent Google Tag Manager) en utilisant les templates mis à disposition par la communauté ;
Avec une CMP tierce, partenaire à Google pour le Google Consent Mode v2, permettant de le déployer nativement et facilement.

Voici la liste des CMP tierces partenaires à Google pour le Google Consent Mode v2 :

https://cmppartnerprogram.withgoogle.com?hl=fr

Voici plusieurs documentations qui devraient vous aider à déployer le Google Consent Mode v2 :

https://developers.google.com/tag-platform/devguides/consent?hl=fr (documentation Google)

https://support.google.com/analytics/answer/9976101?hl=fr (documentation Google)

https://www.simoahava.com/custom-templates/consent-mode/ (documentation et template de balise Google Tag Manager de Simo Ahava mis à jour)

https://support.axeptio.eu/hc/fr/articles/9263604989457-Google-Consent-Mode-V2 (documentation Axeptio)

https://support.didomi.io/enable-google-consent-mode-with-didomi-new-flow (documentation Didomi)

https://support.cookiebot.com/hc/en-us/articles/360003793854-Google-Tag-Manager-deployment (Cookiebot)

https://support.cookiebot.com/hc/en-us/articles/360016047000-Cookiebot-and-Google-Consent-Mode (Cookiebot)

https://www.cookiebot.com/en/google-consent-mode-v2-integration/ (Cookiebot)

Pour rappel, le tracking server-side (tracking côté serveur) est une approche web analytics où les données collectées depuis un site web (sur le navigateur de l’utilisateur) peuvent être traitées sur un serveur intermédiaire “first-party” (serveur proxy) avant d’être envoyées dans les plateformes tierces concernées (outils analytics, régies publicitaires, CRM, etc). Cela contraste avec le tracking client-side, plus traditionnel, où la majeure partie du traitement a lieu dans le navigateur de l’utilisateur.

Dans le contexte actuel (janvier 2024), le tracking client-side est confronté à plusieurs limitations (RGPD, ePrivacy, ITP/ETP, fin des cookies tiers, etc), principalement conçues pour protéger la vie privée des utilisateurs. Ces limitations ont un impact négatif direct sur les performances du marketing digital des entreprises. Le tracking server-side permet notamment de limiter cet impact négatif direct.

Mais le tracking server-side permet également de mieux maîtriser les données envoyées vers les plateformes tierces (outils analytics, régies publicitaires, CRM, etc). En traitant les données au niveau d’un serveur proxy, il est possible de décider de ce qui est envoyé, quand et comment vers les plateformes tierces. Cela permet un meilleur contrôle sur les sujets de RGPD/ePrivacy, et donc une meilleure gouvernance des données.

La collecte de données avec le Google Consent Mode v2 (avancé) étant moins stricte qu’avec le Google Consent Mode v2 (basique), elle confère une modélisation plus précise dans les produits publicitaires Google concernés et donc une meilleure optimisation des performances marketing.

Le choix entre ces deux niveaux de déploiement se fait généralement par l’équipe DPO qui préférera le Google Consent Mode v2 (basique) là où l’équipe marketing préférera le Google Consent Mode v2 (avancé) pour optimiser davantage ses performances.

Le tracking server-side peut être une solution pour trouver un entre-deux, en déployant le Google Consent Mode v2 (avancé) et en supprimant certaines données (par exemple les derniers octets de l’adresse IP) au niveau du serveur proxy, avant de les envoyer aux serveurs de Google. Cela permet d’ajouter un cran de sécurité.

Attention tout de même à ne pas trop alléger les hits, cela pourrait affecter (très) négativement la modélisation dans les produits publicitaires Google concernés…

Premièrement, le Google Consent Mode v2 (comme l’ancienne version bêta – la v1) permet à Google de vous proposer des rapports “plus précis” sur ses produits en ajoutant des données modélisées afin de combler les données manquantes dues au non-consentement de certains de vos utilisateurs. Ces rapports “plus précis” devraient améliorer vos prises de décision et vos performances. Il faut cependant que les algorithmes de modélisation soient correctement entraînés.

Plus vous collectez de données qualitatives dans un produit Google, mieux les algorithmes de modélisation dans ce dernier sont entraînés. Voici 2 documentations relatives aux prérequis pour activer une modélisation “qualitative” dans les produits Google :

https://support.google.com/google-ads/answer/10548233?sjid=9498974950668629432-EU&hl=fr

https://support.google.com/analytics/answer/11161109?hl=fr

N’étant pas uniquement basée sur les données des utilisateurs ayant consenti, la modélisation avec le Google Consent Mode v2 (avancé) est plus précise qu’avec le Google Consent Mode v2 (basique).

Deuxièmement, le Google Consent Mode v2 (comme l’ancienne version bêta – la v1) permet à Google de mieux optimiser vos campagnes publicitaires sur ses produits publicitaires en ajoutant des données modélisées dans ses algorithmes afin de combler les données manquantes dues au non-consentement de certains de vos utilisateurs. Ces données modélisées additionnelles dans les algorithmes devraient optimiser davantage vos performances publicitaires. Il faut cependant que les algorithmes de modélisation soient correctement entraînés.

Troisièmement, contrairement au Google Consent Mode v1, le Google Consent Mode v2 vous laisse la possibilité (avec son niveau de déploiement “basique”) de mieux respecter la vie privée des utilisateurs de votre site web. Cela vous permet un meilleur contrôle sur les sujets RGPD/ePrivacy, et donc une meilleure gouvernance des données : Ce qui devrait plaire à votre équipe DPO !

Premièrement, avec le Google Consent Mode v2 (comme avec la version bêta – la v1), si votre site web génère un faible volume de données, les algorithmes de modélisation peuvent manquer de précision, ce qui pourrait avoir un impact négatif sur la fiabilité de vos rapports et la performance de vos publicités sur les produits Google que vous employez.

Deuxièmement, le manque de documentation approfondie de la part de Google sur le Google Consent Mode v2, combiné à l’application du machine learning, engendre une incertitude significative quant au fonctionnement réel de ce système (effet de boîte noire).

Troisièmement, le Google Consent Mode v2 confirme l’abandon de l’idée d’un Google Analytics 4 hybride, capable de remonter l’intégralité des données, comme d’autres solutions, exemptées de consentement par la CNIL telle que Piano Analyics, peuvent garantir. Dans l’ensemble, les produits Google semblent évoluer d’un paradigme axé sur la précision vers un environnement orienté vers la prédiction.