Les deux nouveaux signaux de Google Consent Mode v2

Qu'a changé Google Consent Mode v2 ?

En novembre 2023, Google Consent Mode v2 a ajouté deux paramètres publicitaires, ad_user_data et ad_personalization, à côté des signaux ad_storage et analytics_storage que les balises Google lisaient déjà. La documentation de la plateforme de balises de Google le dit sans détour : "le mode consentement a été mis à jour en novembre 2023 et contient désormais deux paramètres supplémentaires" (Manage consent mode). Les mécaniques sous-jacentes, les commandes default et update et la modélisation que Google applique aux résultats, sont traitées dans un guide pratique du mode consentement. Cette page reste sur ce que la version 2 a posé par-dessus.

Que contrôlent ad_user_data et ad_personalization ?

Les deux paramètres coupent une ancienne question en deux. La référence gtag de Google définit ad_user_data comme ce qui "définit le consentement pour l'envoi de données utilisateur à Google à des fins publicitaires" et ad_personalization comme ce qui "définit le consentement pour la publicité personnalisée" (gtag.js reference). L'un gouverne la transmission, l'autre l'usage. Un visiteur peut accepter que ses données parviennent à Google pour la mesure des conversions et refuser quand même d'être ciblé avec, et la version 2 donne à cette distinction un format de transmission.

Sept types de consentement existent dans l'API. Les descriptions de Google, citées depuis ses propres pages :

Chacun d'eux accepte exactement deux valeurs, granted ou denied. Rien d'autre n'est interprété.

Google Consent Mode v2 est-il exigé par le RGPD ?

Non, et cette confusion est l'erreur la plus répandue dans ce qui s'écrit sur le sujet. Google Consent Mode v2 est une exigence que Google impose aux annonceurs qui veulent continuer à utiliser ses produits, portée par la politique de consentement des utilisateurs de l'UE, qui s'applique aux "utilisateurs finaux de l'Espace économique européen, du Royaume-Uni et de la Suisse" et oblige les annonceurs à obtenir le consentement pour "l'utilisation de cookies ou d'un autre stockage local lorsque la loi l'exige" et pour "la collecte, le partage et l'utilisation de données personnelles à des fins de personnalisation des annonces" (EU user consent policy). Le RGPD et la directive ePrivacy imposent les obligations légales sous-jacentes. Ni l'un ni l'autre ne nomme un paramètre JavaScript.

La conséquence pratique : une implémentation qui envoie granted pour tout satisfait la plomberie de Google et viole quand même la loi si aucun consentement valide n'a été recueilli. Ce qui rend un consentement valide se joue en amont de toute API, et est traité dans ce qui compte comme consentement au tracking et dans les exigences de consentement du RGPD pour le web analytics. Câblez les signaux une fois la question juridique réglée, pas à la place.

Basique ou avancé : quelle implémentation choisir ?

Google documente deux implémentations du mode consentement, et la version 2 hérite des deux. En mode consentement basique, le site va "empêcher les balises Google de se charger tant que l'utilisateur n'a pas interagi avec une bannière de consentement", et "aucune donnée n'est envoyée avant que l'utilisateur consente". En mode consentement avancé, "les balises Google se chargent quand l'utilisateur ouvre le site ou l'application" avec des valeurs par défaut sur denied, et "quand le consentement est refusé, l'état de consentement et des pings sans cookies sont envoyés. Quand le consentement est accordé, des cookies sont écrits" (Google Ads Help).

La différence apparaît dans la modélisation de Google. La même page d'aide décrit le mode basique comme produisant un "modèle général (modélisation moins détaillée)" et le mode avancé comme produisant un "modèle spécifique à l'annonceur (modélisation plus détaillée)". Le mode avancé achète une meilleure modélisation des conversions en transmettant un ping sans cookies depuis les visiteurs qui ont dit non, ce qui est une décision de protection des données à prendre par une équipe juridique plutôt que par une équipe growth. Quel que soit votre choix, la bannière de consentement doit déclencher l'appel update et pas seulement se repeindre.

Qu'est-ce qui casse dans les produits publicitaires de Google quand les signaux sont absents ?

L'absence n'est pas neutre. La documentation Customer Match de Google indique : "si ces consentements manquent, la valeur de consentement est déterminée comme non consentie", et "les données des utilisateurs de l'EEE sans consentement ne seront pas traitées et ne peuvent pas être utilisées pour la personnalisation des annonces avec Customer Match" (About Customer Match and the EU user consent policy). La même page porte l'exigence datée : "à partir de mars 2024, pour que les listes Customer Match puissent être utilisées dans l'EEE, les deux champs de consentement de type ConsentStatus doivent être définis sur 'GRANTED' pour indiquer que vous avez recueilli le consentement utilisateur requis."

Quelles balises lisent réellement les signaux est aussi documenté. Google liste les produits dont les balises "contiennent des vérifications de consentement intégrées" : Google Analytics, Google Ads, Floodlight et Conversion Linker (Consent mode in Google Analytics). Une balise hors de cette liste ne répond pas à un appel gtag('consent', ...), donc c'est à vous de la bloquer.

Comment les commandes default et update portent-elles les nouveaux paramètres ?

La commande default s'exécute avant qu'une balise Google ne se déclenche, et la commande update s'exécute quand le visiteur répond. La forme documentée par Google :

gtag('consent', 'default', {
  'ad_storage': 'denied',
  'ad_user_data': 'denied',
  'ad_personalization': 'denied',
  'analytics_storage': 'denied'
});
 
gtag('consent', 'update', {
  'ad_storage': 'granted',
  'ad_user_data': 'granted',
  'ad_personalization': 'granted',
  'analytics_storage': 'granted'
});

Deux options comptent pour la justesse. Google documente wait_for_update avec "une valeur en millisecondes pour contrôler combien de temps attendre avant l'envoi des données", pour les plateformes de consentement qui répondent de façon asynchrone, et une clé region définie "conformément à la norme ISO 3166-2" dans la commande default, où "celle qui porte la région la plus spécifique s'applique". Faire tourner default après que gtag.js a déjà envoyé une page vue est la panne qui annule silencieusement toute l'installation, et le même piège d'ordonnancement est disséqué dans le guide de conformité du consentement aux cookies Google Analytics.

Qu'est-ce que Google n'a pas documenté ?

Google n'a publié aucun barème de sanctions pour le mode consentement, aucune amende et aucune politique de suspension de compte liée aux deux paramètres. La seule date ferme dans les pages de Google pour cette mise à jour est l'exigence Customer Match de mars 2024 citée plus haut ; traitez toute autre date d'application qui circule dans les articles de blog comme non sourcée tant que Google ne l'a pas publiée. La conséquence documentée est fonctionnelle et non punitive : les données EEE sans consentement ne sont pas traitées pour la personnalisation, et la fonctionnalité d'audience ou de mesure qui en dépendait se dégrade.

Il existe une sortie de tout cet appareillage, qui consiste à ne pas envoyer de signaux publicitaires à Google du tout. L'analytics sans cookies retire les paramètres de la question, et l'analytics respectueux de la vie privée de Flowsery fonctionne sans cookies et est hébergé dans l'UE, donc il n'y a aucune décision ad_storage à modéliser. Les équipes qui font tourner Google Ads ont quand même besoin du mode consentement pour la partie publicitaire, puisqu'un outil de mesure ne peut pas répondre pour les balises d'un autre éditeur.

Questions fréquentes

Google Consent Mode v2 est-il obligatoire ?

Il est obligatoire pour les annonceurs qui veulent que les fonctionnalités publicitaires et de mesure de Google continuent de fonctionner avec le trafic de l'EEE, du Royaume-Uni et de la Suisse, au titre de la politique de consentement des utilisateurs de l'UE de Google. Il n'est pas obligatoire au titre du RGPD, qui encadre le consentement lui-même plutôt que la façon dont vous le transmettez à un fournisseur. Un site qui ne fait tourner aucune balise publicitaire Google n'a aucune obligation de mode consentement envers Google.

Que se passe-t-il si je n'envoie que ad_storage et analytics_storage ?

La documentation Customer Match de Google indique que lorsque les champs de consentement manquent, "la valeur de consentement est déterminée comme non consentie". Les paramètres v1 ne remplacent pas ceux de la v2. Les fonctionnalités de personnalisation qui dépendent de ad_user_data et ad_personalization traitent ce trafic comme un refus.

ad_user_data peut-il être granted pendant que ad_personalization est denied ?

Oui, et cette combinaison est tout l'intérêt de les avoir séparés. Elle signifie que les données peuvent parvenir à Google à des fins publicitaires alors que la publicité personnalisée est refusée. Une bannière de consentement avec des interrupteurs de finalité séparés devrait correspondre à cette paire plutôt que de tout ramener à une seule case.

Le mode consentement basique compte-t-il quand même comme Consent Mode v2 ?

Oui. Basique et avancé sont des choix d'implémentation, et les deux portent les quatre paramètres publicitaires et analytics. Le mode basique bloque les balises Google jusqu'à ce que le visiteur interagisse avec la bannière, donc les paramètres n'arrivent que dans l'appel update.

Quelles régions l'exigence de Google couvre-t-elle ?

La politique de consentement des utilisateurs de l'UE de Google nomme les "utilisateurs finaux de l'Espace économique européen, du Royaume-Uni et de la Suisse". L'exigence de consentement Customer Match citée par Google fait référence à l'EEE. La documentation de Google n'étend l'exigence à aucune autre région.

Le mode consentement restaure-t-il les données que les visiteurs ont refusées ?

Non. Le mode consentement alimente la modélisation des conversions de Google, qui produit des estimations plutôt que des observations, et Google étiquette les deux implémentations comme alimentant un modèle général ou un modèle spécifique à l'annonceur. Les réserves sur la modélisation, et la façon dont elles apparaissent dans les rapports, sont traitées dans le guide du mode consentement.

Quelle est la différence entre les signaux v1 et v2 du consent mode ?

Les signaux v1 sont ad_storage et analytics_storage. La version 2 a conservé les deux et ajouté ad_user_data et ad_personalization en novembre 2023, divisant l'ancienne décision de consentement unique en signaux distincts pour l'envoi de données à Google et pour leur usage en publicité personnalisée.

Quelles balises Google vérifient réellement les signaux du consent mode ?

Google cite Google Analytics, Google Ads, Floodlight et Conversion Linker comme les produits dont les balises intègrent des vérifications de consentement. Une balise en dehors de cette liste ignore un appel gtag('consent', ...) et continue de se déclencher tant que rien d'autre ne la bloque.

À quoi sert wait_for_update dans le consent mode ?

C'est un paramètre que Google documente pour la commande default, réglé sur une valeur en millisecondes qui indique à gtag.js combien de temps retenir les requêtes avant de les envoyer. Il existe pour les plateformes de gestion du consentement qui se résolvent de façon asynchrone, afin que les balises ne se déclenchent pas dès le chargement initial avant que la plateforme ait signalé une décision.

Le paramètre region peut-il fixer des valeurs par défaut différentes selon les pays ?

La commande default accepte une clé region utilisant les codes ISO 3166-2, et Google applique la région correspondante la plus spécifique. Un site peut ainsi fixer une valeur par défaut pour l'EEE et une autre pour le reste du monde dans le même appel default.