Consent Mode v2 : guide de configuration

Qu'est-ce que Google Consent Mode v2

Google Consent Mode v2 est le protocole de Google qui ajuste le comportement des tags de mesure (Google Analytics 4, Google Ads, Floodlight) en fonction du consentement que l'utilisateur a accorde ou refuse via la banniere de cookies.

La version originale permettait deja d'envoyer des pings sans cookies quand l'utilisateur refusait le consentement. La version 2 introduit deux parametres supplementaires qui changent les regles :

ad_user_data : controle si les donnees utilisateur peuvent etre envoyees a Google a des fins publicitaires.
ad_personalization : controle si la publicite personnalisee est autorisee (remarketing, audiences similaires).

Depuis mars 2024, Google exige le Consent Mode v2 pour tout annonceur souhaitant utiliser les audiences et la mesure de conversion dans l'Espace economique europeen (EEE) et le Royaume-Uni.

Pourquoi c'est important pour le CRO et l'analytics

Sans Consent Mode v2 correctement implemente, vous perdez des donnees de deux facons :

Perte de donnees de conversion

Si un utilisateur refuse les cookies et que vous n'avez pas le Consent Mode, le tag Google Ads ne se declenche tout simplement pas. Cette conversion disparait completement de vos rapports. Avec le Consent Mode actif, Google utilise la modelisation pour estimer les conversions des utilisateurs qui n'ont pas donne leur consentement, recuperant entre 30 % et 70 % des donnees perdues selon le secteur.

Perte de donnees d'audience

Sans le parametre ad_user_data configure, vous ne pouvez pas alimenter les audiences de remarketing ni creer des lookalikes dans Google Ads pour les utilisateurs de l'EEE. Cela impacte directement la performance de vos campagnes et, par consequent, votre cout par acquisition.

Mode Basic vs. Advanced

Le Consent Mode v2 peut etre implemente a deux niveaux :

Mode Basic

Les tags Google ne se chargent que quand l'utilisateur accepte. S'il refuse, aucune donnee n'est envoyee. C'est l'option la plus conservatrice et la plus simple a implementer, mais vous perdez toute information des utilisateurs qui refusent.

Mode Advanced

Les tags se chargent toujours, mais leur comportement change selon le consentement :

Avec consentement : fonctionnement normal avec cookies.
Sans consentement : des pings sans cookies sont envoyes sans identifiants personnels. Google utilise ces pings anonymises pour alimenter ses modeles de conversion.

Le mode Advanced est recommande pour la plupart des entreprises car il maximise la recuperation de donnees sans compromettre la confidentialite.

Comment implementer le Consent Mode v2

Prerequis

Une plateforme de gestion du consentement (CMP) compatible : Cookiebot, OneTrust, Didomi, Usercentrics ou similaire.
Google Tag Manager (recommande) ou gtag.js.
GA4 et/ou Google Ads configure.

Implementation avec GTM

Definir les valeurs par defaut : dans la configuration GTM, etablissez les valeurs de consentement initiales avant le chargement de la banniere :

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

Connecter votre CMP : configurez votre plateforme de consentement pour mettre a jour les etats quand l'utilisateur interagit avec la banniere.
Verifier avec Tag Assistant : utilisez Google Tag Assistant pour confirmer que les etats de consentement sont envoyes correctement avec chaque hit.

Impact sur les donnees : a quoi s'attendre

Apres avoir implemente le Consent Mode v2 en mode Advanced, voici les changements typiques dans les donnees :

Metrique	Sans Consent Mode	Avec Consent Mode v2
Conversions trackees	Uniquement utilisateurs consentants	Toutes (mesurees + modelisees)
Sessions GA4	Uniquement avec consentement	Pings anonymises + sessions completes
Audiences remarketing	Pas de donnees EEE	Donnees avec consentement explicite
Precision attribution	Faible (donnees incompletes)	Amelioree avec modelisation

Dans les marches avec des taux de refus de cookies eleves (Allemagne, France), la difference peut atteindre 40-60 % de conversions rapportees en plus.

Erreurs d'implementation courantes

Ne pas definir wait_for_update

Si vous ne definissez pas un temps d'attente pour le chargement de la CMP, les tags peuvent se declencher avec les valeurs denied par defaut avant que l'utilisateur n'ait eu la possibilite d'accepter. Cela genere des donnees inutilement incompletes.

Oublier ad_user_data et ad_personalization

Beaucoup d'implementations ne mettent a jour que analytics_storage et ad_storage mais oublient les deux nouveaux parametres v2. Sans eux, vous ne remplissez pas les exigences de Google pour l'EEE et perdez des fonctionnalites publicitaires.

Ne pas tester par marche

Les taux d'acceptation des cookies varient enormement par pays. Testez l'implementation dans chaque marche ou vous operez et ajustez le design de la banniere pour maximiser l'acceptation sans etre intrusif.

Consent Mode et tagging server-side

Si vous utilisez le tagging server-side avec GTM, le Consent Mode v2 fonctionne de maniere similaire : les etats de consentement sont envoyes au conteneur serveur, qui decide quelles donnees traiter et transmettre aux endpoints (GA4, Google Ads, Meta CAPI).

L'avantage du server-side est que vous pouvez appliquer une logique de consentement supplementaire avant d'envoyer des donnees a des tiers, vous donnant plus de controle sur les informations qui quittent votre infrastructure.

Chez Boost, nous implementons le Consent Mode v2 dans le cadre de notre configuration analytics pour que nos clients mesurent correctement leurs conversions sans compromettre la confidentialite des utilisateurs. Si vous avez besoin d'aide avec votre implementation, parlez a notre equipe CRO ou analysez votre site gratuitement avec Scan&Boost.

— Adria Vidal, Boost