Basic vs Advanced Consent Mode : le guide complet
Comprendre la difference entre Basic et Advanced Consent Mode de Google, les 4 signaux, le bug des Additional Consent Checks et la solution Trigger Groups.
Le Consent Mode de Google existe en deux variantes dont les implications techniques sont radicalement differentes. Mal configurer le mode choisi revient a perdre soit des donnees, soit la conformite RGPD. Ce guide detaille les differences, les pieges et les bonnes pratiques, en s’appuyant notamment sur les analyses de Simo Ahava.
Advanced Consent Mode : la simplicite apparente
En Advanced Consent Mode, les tags Google (GA4, Google Ads, Floodlight) se declenchent immediatement au chargement de la page, mais s’adaptent automatiquement a l’etat du consentement. Sans consentement, ils envoient des pings sans cookie (cookieless pings) qui permettent a Google de modeliser les conversions. Avec consentement, ils fonctionnent normalement.
L’avantage est la simplicite de mise en oeuvre. Les tags se declenchent normalement, c’est le SDK Google qui gere l’ajustement. L’inconvenient : des donnees (meme anonymisees) sont envoyees avant le consentement, ce que certaines autorites de protection des donnees considerent comme problematique.
Basic Consent Mode : le controle total
En Basic Consent Mode, les tags sont completement bloques tant que l’utilisateur n’a pas donne son consentement. Aucune donnee n’est envoyee, aucun ping, aucune requete reseau. Ce mode offre la conformite la plus stricte mais necessite une implementation manuelle rigoureuse dans GTM.
Les quatre signaux a maitriser
Le Consent Mode repose sur quatre signaux que votre CMP doit gerer :
- ad_storage : autorise le stockage de cookies publicitaires (gclid, conversion linker)
- analytics_storage : autorise le stockage de cookies analytics (GA4 client ID)
- ad_user_data : autorise l’envoi de donnees utilisateur aux plateformes publicitaires
- ad_personalization : autorise le remarketing et les audiences similaires
Le pattern recommande : definir tous les signaux a denied dans le trigger Consent Initialization, puis mettre a jour via un evenement dataLayer lorsque l’utilisateur consent. Pour plus de details sur l’implementation, consultez notre guide pratique du Consent Mode v2.
Le bug critique des Additional Consent Checks
Voici le piege le plus vicieux de GTM en Basic Consent Mode. Vous configurez un tag avec un trigger “Once per page” (comme All Pages) et ajoutez des Additional Consent Checks sur ce tag. Le scenario : l’utilisateur arrive, le consentement est denied, le trigger se declenche mais le tag est bloque. L’utilisateur accepte les cookies. Le consentement passe a granted. Mais le trigger “Once per page” a deja ete consomme. Le tag ne se declenchera plus jamais sur cette page.
Resultat : zero donnee collectee meme apres consentement explicite. Ce bug est silencieux et peut passer inapercu pendant des semaines.
La solution : Trigger Groups
La solution recommandee par Simo Ahava est d’utiliser les Trigger Groups plutot que les Additional Consent Checks. Un Trigger Group attend que toutes les conditions soient remplies simultanement avant de declencher le tag. Creez un groupe combinant le trigger Page View et un trigger sur l’evenement de mise a jour du consentement. Le tag ne se declenchera que lorsque les deux conditions seront reunies.
Cette approche fonctionne aussi bien en Basic qu’en Advanced Consent Mode et elimine le probleme des triggers consommes. Pour aller plus loin sur la conformite, consultez notre FAQ sur le Consent Mode v2.