Table des matières

Google Consent Mode V2 : ce que c'est, comment ça marche et comment le mettre en place.

What Consent Mode V2 is, how does it work, and how to leverage it with Server-side Tracking

Google a mis à jour son cadre Consent Mode au début de l'année 2024, en ajoutant 2 nouveaux types de consentement et en rendant le tout obligatoire pour toute personne utilisant Google Ads en Europe. La plupart des équipes ont mis à jour leur balise CMP dans GTM et sont passées à autre chose. Ce que beaucoup n'ont pas saisi, c'est que le choix Basique vs Avancé, et la façon dont les signaux de consentement voyagent à travers un conteneur de serveur, a un impact direct sur la quantité de données de conversion qui atteignent tes plateformes publicitaires.

Le cadre, les compromis, les nuances côté serveur et les étapes de configuration sont abordés dans cet article.

Le Consent Mode est un ensemble de signaux que ta bannière de cookies envoie aux balises de Google. Lorsqu'un utilisateur accepte ou refuse les cookies, ces signaux indiquent aux produits de Google ce qu'ils sont autorisés à faire : installer des cookies, collecter des données utilisateur, diffuser des annonces personnalisées ou modéliser des conversions.

Le CMP s'occupe de l'interaction avec l'utilisateur, en amont. Les balises de Google ajustent ensuite leur comportement en fonction de ce que l'utilisateur a choisi. Consent Mode se situe entre les deux et transmet la décision de l'un à l'autre.

V1 utilisait deux types de consentement. La version 2 en a ajouté deux autres :

Type de consentementContrôlesAjouté enDMA requis
ad_storageCookies publicitairesV1Non
analytics_storageCookies analytiquesV1Non
ad_user_dataEnvoi des données des utilisateurs à Google à des fins publicitaires.V2Oui
ad_personalizationAnnonces personnalisées et remarketingV2Oui

Les deux derniers points concernent plus particulièrement la loi européenne sur les marchés numériques. Google a besoin d'un consentement explicite non seulement pour stocker des cookies, mais aussi pour utiliser les données de tes visiteurs dans ses systèmes publicitaires. Sans ad_user_data et ad_personalization correctement configurés, les audiences de remarketing et le suivi des conversions sont incomplets, quoi qu'en dise ton CMP.

Il y a deux façons de mettre en œuvre le Consent Mode, et la différence se voit dans tes performances publicitaires.

Mode Consent Mode de base : Les balises ne se déclenchent qu'après le consentement explicite de l'utilisateur. Les visiteurs non consentants ne génèrent aucune donnée.

Consent Mode avancé : Les balises se chargent avec des états par défaut (refusés dans l'UE). Lorsqu'un utilisateur qui n'a pas donné son consentement visite le site, la balise continue d'envoyer des cookies à Google, un signal minimal sans données d'identification. Lorsqu'il accepte, toutes les données circulent.

Voici comment les trois États se comparent dans la pratique :

Pas de Consent ModeDe baseAvancé
Utilisateurs non consentantsNon contrôlé (risque de conformité)Aucun signal envoyéEnvoi d'un ping sans cookie
Modélisation de la conversion disponibleNonNonOui (après le seuil)
Seuil de modélisation--700 clics publicitaires / 7 jours / pays
Site de l'UE avec un taux de consentement d'environ 40Risque de non-conformité54% des signaux disparaissent, pas d'alerte54% partiellement récupérable

Google Ads a besoin d'au moins 700 clics publicitaires sur 7 jours par pays avant de commencer à modéliser les conversions. En dessous de ce seuil, même le mode Avancé envoie des pings cookieless d'utilisateurs non consentants, mais la modélisation ne se met jamais en marche.

consent mode v2 for european websites

Selon les statistiques de SearchLab sur la vie privée et le RGPD, pour les sites de l'UE où les taux de consentement se situent généralement autour de 46 %, le mode basique signifie que 54 % de ton signal de conversion disparaît de la vue de Google. Les campagnes continuent de fonctionner, les algorithmes d'enchères s'ajustent à ce qui reste, et il n'y a pas d'avertissement que les données sont minces.

Advanced est le meilleur choix pour la plupart des sites. Il faut que ta balise CMP se déclenche avant toute autre balise, pendant le déclenchement de l'initialisation du consentement, afin que les états par défaut soient définis avant que toute donnée ne soit collectée. S'il y a un retard, tu risques d'envoyer des données avant que le consentement ne soit initialisé.

La plupart des configurations côté serveur présentent ici une lacune : les états de consentement ne sont pas transmis automatiquement au conteneur du serveur. Ce qui se passe à la place dépend entièrement des balises que tu utilises.

Produits Google : traités automatiquement

Pour GA4 et Google Ads, le conteneur Web intègre l'état actuel du consentement dans un paramètre gcs à chaque requête sortante. Cette demande est transmise au conteneur serveur, et les balises Google lisent le paramètre et gèrent elles-mêmes l'application du consentement. Aucune configuration supplémentaire n'est nécessaire dans le conteneur du serveur pour ces balises.

Meta Conversions API, LinkedIn Insight Tag server-side, TikTok Events API, et les plateformes similaires ne lisent pas le paramètre gcs. Elles ont besoin d'états de consentement passés explicitement en tant que paramètres d'événements. Sans cela, la balise n'a aucun moyen de savoir ce que l'utilisateur a accepté.

Configuration pour les balises non Google

  1. Télécharge et importe le modèle d'état de consentement de GitHub dans ton conteneur web GTM.
  2. Créer une variable d'état de consentement pour chaque type pertinent : ad_storage, analytics_storage, ad_user_data, ad_personalization.
  3. Ajoute les quatre variables à une variable de paramètres d'événement Google Tag en tant que paramètres d'événement.
  4. Attache cette variable des paramètres de l'événement à ta balise Google principale.
  5. Dans le conteneur du serveur, crée des variables de données d'événement pour chaque état de consentement, en utilisant le nom du type de consentement comme chemin clé (par exemple, ad_personalization).
  6. Utilise ces variables comme conditions de déclenchement pour bloquer les balises non Google, afin qu'elles ne se déclenchent que lorsque le type de consentement correspondant est accordé.

Sans cela, une balise Meta ou TikTok côté serveur se déclenche à chaque événement, quel que soit le choix de l'utilisateur.

Va dans Admin → Paramètres du conteneur dans ton conteneur web GTM. Sous Paramètres supplémentaires, active l'Aperçu du consentement et enregistre. Cela rend le comportement de consentement visible en mode Aperçu, ce dont tu as besoin pour la vérification.

2. Ajoute ton étiquette CMP

Va dans Tags → Nouveau et trouve ton CMP dans la galerie de modèles de la communauté. Définis le déclencheur sur Initialisation du consentement - Toutes les pages. Cela se déclenche avant tout le reste de la page et définit les états de consentement par défaut.

Les différents CMP utilisent des noms de catégories internes différents. Cartographie standard pour les sites de l'UE :

  1. Marketing → ad_storage, ad_user_data, ad_personalization.
  2. Statistiques → analytics_storage
  3. Préférences → fonctionnalité_stockage, personnalisation_stockage.

Vérifie la documentation de ton CMP pour confirmer les noms exacts des catégories. La mauvaise correspondance est l'un des problèmes les plus courants du Consent Mode et il n'est pas évident de le repérer de l'extérieur.

4. Définir par défaut le refus pour les visiteurs de l'UE

Les quatre types de consentement doivent être réglés par défaut sur "refusé" avant toute interaction avec l'utilisateur. Ta balise CMP devrait s'en charger, mais vérifie-le dans l'aperçu GTM en consultant l'onglet Consentement lors du chargement d'une nouvelle page avant d'interagir avec la bannière.

5. Configure le conteneur du serveur pour les balises non Google.

Suis les étapes de la section précédente : Modèle d'état de consentement, variable des paramètres de l'événement, variables des données de l'événement côté serveur, conditions de déclenchement basées sur le consentement. Pour GA4 et Google Ads dans le conteneur du serveur, rien de supplémentaire n'est nécessaire.

6. Vérifier avec l'assistant de marquage

Ouvre l'aperçu de GTM dans une nouvelle session de navigation. Charge ton site et ouvre l'onglet Consentement. Les quatre types de consentement doivent afficher "refusé". Accepte la bannière et confirme qu'ils sont mis à jour en "accordé". Vérifie ensuite l'onglet Balises pour vérifier que les balises se déclenchent ou se retiennent en fonction de l'état du consentement.

Pour la référence complète de la configuration, la documentation du TAGGRS Consent Mode passe en revue chaque étape en détail.

Notes spécifiques au CMP

Cookieconfirm

Cookieconfirm utilise un tag dédié dans la galerie de modèles de la communauté. Installe-la avec un déclencheur d'initialisation du consentement, et le conteneur du serveur récupère automatiquement le paramètre GCS pour toutes les balises Google. Pour les balises non Google, crée des déclencheurs de blocage personnalisés à l'aide de la variable de données d'événement ED | x-ga-gcs. La valeur gcs=G101 signifie que l'ad_storage est refusé ; gcs=G10 au début indique le refus de l'ad_storage dans le format de la chaîne GCS.

Axeptio

Axeptio fonctionne différemment. Plutôt que le paramètre GCS standard, Axeptio suit le consentement par le biais des noms de fournisseurs stockés dans axeptio_authorized_vendors et pousse un événement axeptio_update vers la dataLayer lorsque le consentement change. Côté serveur, crée une variable Event Data pour axeptio_consent_state et conditionne chaque balise à la présence ou non du nom du fournisseur concerné (par exemple, google_analytics) dans cette variable. Le mappage catégorie-signal pour Consent Mode V2 est configuré à l'intérieur même de la plateforme Axeptio.

Trois méthodes sont utilisées en combinaison.

Ouvre une session de navigation privée, démarre le mode Aperçu et charge ton site. Avant de toucher la bannière, ouvre l'onglet Consentement. Les quatre types de consentement doivent indiquer "refusé". Accepte la bannière et regarde les valeurs se mettre à jour. Si elles ne changent pas, c'est que la balise CMP ne se déclenche pas ou que ses catégories ne sont pas associées aux bons types de consentement.

Onglet Réseau - paramètre gcs

Dans Chrome DevTools, filtre les demandes de réseau pour la collecte. Chaque hit GA4 comprend un paramètre gcs qui encode l'état actuel du consentement. G111 signifie que les quatre types sont accordés. G101 signifie que ad_storage est refusé, analytics_storage est accordé. La valeur du paramètre correspond à ce qui a été réellement envoyé à Google, et non à ce que la bannière prétendait définir.

Tableau de bord TAGGRS

Dans ton conteneur de serveur TAGGRS, les événements entrants portent les paramètres d'état de consentement transmis par le conteneur web. Vérifie un événement d'une session de consentement et confirme que ad_storage, analytics_storage, ad_user_data et ad_personalization apparaissent en tant que paramètres d'événement avec les valeurs attendues. S'ils sont absents, la variable Paramètres de l'événement n'est pas connectée, ou le modèle d'état de consentement n'a pas été importé.

La place de TAGGRS

Le suivi côté serveur et le Consent Mode V2 fonctionnent bien ensemble, mais ils doivent être câblés correctement pour que la combinaison tienne la route. Le traitement automatique des CGV dans les balises de Google couvre GA4 et Google Ads sans travail supplémentaire côté serveur. Pour tout le reste, Meta, LinkedIn, TikTok ou toute intégration server-side personnalisée, le consentement doit être transmis délibérément par le biais de la charge utile de l'événement.

TAGGRS fournit l'infrastructure du conteneur de serveur et publie le modèle d'état de consentement qui gère la façon dont les paramètres de consentement voyagent du conteneur web au serveur. Pour les équipes sur Axeptio ou Cookieconfirm, les guides spécifiques au CMP ci-dessus couvrent les étapes de configuration exactes pour chaque plateforme.

FAQ

La V1 utilisait deux types de consentement : ad_storage et analytics_storage. La V2 a ajouté ad_user_data, qui contrôle si les données des utilisateurs sont envoyées à Google pour la publicité, et ad_personalization, qui contrôle le remarketing et les annonces personnalisées. Ces deux nouveaux types de données sont nécessaires pour assurer la conformité à la DMA. Les sites encore sous V1 verront des audiences de remarketing incomplètes et des lacunes dans le suivi des conversions.

Non. Ils ont des objectifs différents. Le Consent Mode régit les données que Google est autorisé à traiter en fonction des choix de l'utilisateur. Le suivi côté serveur modifie l'endroit où la collecte des données a lieu, en la déplaçant du navigateur vers ton propre serveur. Les deux fonctionnent ensemble : le suivi côté serveur améliore la durée de vie des cookies de première partie et la qualité des données, mais les décisions de consentement doivent toujours voyager avec les données pour rester conformes.

Trois vérifications : l'onglet Consentement de l'aperçu GTM (vérifie que les valeurs par défaut sont " refusées " avant l'interaction et la mise à jour après) ; le paramètre gcs sur les demandes de réseau GA4 (G111 = tous accordés) ; et ton tableau de bord de conteneur de serveur TAGGRS pour confirmer que les paramètres d'état de consentement arrivent sur les événements côté serveur.

Google Ads a besoin de 700 clics publicitaires sur 7 jours par pays et par domaine avant que la modélisation des conversions ne soit activée. En dessous de ce seuil, le mode Consent Mode avancé envoie des pings cookieless de la part des utilisateurs non consentants, mais Google ne peut pas encore modéliser les conversions à partir de ces derniers. Le mode Consent Mode de base n'atteint jamais ce seuil pour les utilisateurs non consentants car aucun signal n'est envoyé.

À propos de l'auteur

Récemment publié

magnifiercrossmenu linkedin facebook pinterest youtube rss twitter instagram facebook-blank rss-blank linkedin-blank pinterest youtube twitter instagram