Consent Mode v2 : impacts réels sur mesure et acquisition

Consent Mode v2 n’est pas un simple ajustement technique dans l’écosystème Google. Depuis la mise à jour de novembre 2023, Google a ajouté deux signaux de consentement supplémentaires, ad_user_data et ad_personalization, en plus de ad_storage et analytics_storage. Google précise que cette évolution vise les flux de trafic provenant de l’Espace économique européen, du Royaume-Uni et de la Suisse, et qu’elle conditionne la continuité de certains usages publicitaires, de mesure et de remarketing. ([developers.google.com](https://developers.google.com/tag-platform/security/guides/consent?utm_source=openai))

Le point important pour les équipes acquisition est le suivant : Consent Mode v2 ne sert pas seulement à “cocher une case” liée au consentement. Il change la manière dont Google Analytics 4, Google Ads, la modélisation des conversions et les audiences peuvent fonctionner lorsque tout le monde n’accepte pas les mêmes traitements. Autrement dit, ce sujet touche directement la qualité de la mesure, le pilotage des enchères, la taille des listes et la lisibilité réelle des performances. ([developers.google.com](https://developers.google.com/tag-platform/security/concepts/consent-mode?utm_source=openai))

Il faut aussi éviter un contresens fréquent : Consent Mode n’est ni une bannière de consentement, ni une CMP en soi. Google indique clairement que le mode Consentement interagit avec votre bannière ou votre solution de gestion du consentement pour recevoir les choix des utilisateurs et adapter le comportement des balises. La mécanique dépend donc autant du paramétrage technique que de la qualité de la collecte des choix. ([support.google.com](https://support.google.com/google-ads/answer/10000067?hl=en&utm_source=openai))

Ce que Consent Mode v2 change, concrètement

La différence structurante entre la première version et la v2 tient à la granularité. Avec la v2, Google attend désormais des signaux distincts pour l’envoi de données utilisateur liées à la publicité et pour la personnalisation publicitaire. Dans la documentation Google Ads, ad_user_data correspond au consentement pour envoyer à Google des données utilisateur liées à la publicité, et Google précise que ce signal est requis pour des usages de mesure comme le suivi avancé des conversions ou le suivi des conversions via balise. ad_personalization, lui, pilote le consentement pour la publicité personnalisée. ([support.google.com](https://support.google.com/google-ads/answer/13802165?hl=fr&utm_source=openai))

Cette granularité a une conséquence opérationnelle majeure : vous pouvez continuer à mesurer certains signaux sans pour autant disposer du droit de les exploiter pour la personnalisation. À l’inverse, si les signaux sont mal câblés, vous pouvez perdre des usages publicitaires alors même que vos tags continuent de s’exécuter. C’est précisément ce qui rend le sujet plus complexe qu’un simple binaire “accepté/refusé”. ([developers.google.com](https://developers.google.com/tag-platform/security/concepts/consent-mode?utm_source=openai))

Google rappelle aussi que, pour activer la publicité personnalisée dans ses plateformes, ad_user_data et ad_personalization doivent tous les deux être accordés. Si ad_user_data est refusé, l’utilisation de données à caractère personnel pour la publicité en ligne est désactivée et l’export de certaines données de conversion liées à un identifiant de clic vers la plateforme Ads est limité. Cela peut affecter des cas comme l’optimisation des enchères dans Google Ads à partir de conversions Google Analytics. ([support.google.com](https://support.google.com/google-ads/answer/13802165?hl=fr&utm_source=openai))

Autre point concret : Google distingue deux modes d’implémentation. Le basic consent mode bloque les tags tant que l’utilisateur n’a pas donné son choix. Le advanced consent mode charge les tags avec des états de consentement par défaut, puis les ajuste après interaction avec la bannière. Google indique explicitement que l’implémentation avancée permet une modélisation des conversions plus détaillée. C’est un point décisif pour les annonceurs orientés performance. ([developers.google.com](https://developers.google.com/tag-platform/security/concepts/consent-mode?utm_source=openai))

GA4 : ce qui change dans les données visibles et dans les données reconstruites

Dans GA4, l’effet le plus visible de Consent Mode concerne le trou de données créé par les refus sur analytics_storage. Google explique que, lorsque les utilisateurs refusent les cookies analytiques, Analytics ne dispose pas des mêmes informations observées que pour les utilisateurs consentants. Pour compenser partiellement cette perte, GA4 peut recourir à la modélisation comportementale, qui estime le comportement des utilisateurs ayant refusé les cookies analytiques à partir du comportement d’utilisateurs similaires ayant accepté. ([support.google.com](https://support.google.com/analytics/answer/11161109?hl=fr&utm_source=openai))

Ce point est essentiel pour la lecture des rapports. Dans une propriété où Consent Mode est bien implémenté et où le volume de données observées est suffisant, les rapports GA4 peuvent donc intégrer une part modélisée. Google précise toutefois que cette modélisation n’est incluse que lorsque la qualité du modèle est jugée fiable. Si le trafic consenti est insuffisant, les événements des utilisateurs non consentants peuvent ne pas être modélisés. En clair, le modèle ne “magique” pas les données absentes : il réduit une partie de la perte, à condition d’avoir assez de signal de référence. ([support.google.com](https://support.google.com/analytics/answer/11161109?hl=fr&utm_source=openai))

Pour les responsables acquisition, cela change la bonne manière d’interpréter une baisse apparente. Une chute des utilisateurs, des sessions ou des conversions dans GA4 après déploiement d’une CMP ne signifie pas automatiquement une baisse business. Elle peut provenir d’une rupture de collecte, d’un défaut de mise à jour des signaux de consentement, d’un paramétrage régional mal appliqué ou d’un niveau de consentement plus faible que prévu. La bonne lecture consiste à distinguer données observées, données modélisées et zones sans signal exploitable. Cette interprétation est une inférence opérationnelle à partir de la documentation Google sur les limites de modélisation. ([support.google.com](https://support.google.com/analytics/answer/11161109?hl=fr&utm_source=openai))

Google indique aussi que les événements clés modélisés peuvent mettre du temps à se stabiliser. Dans l’aide GA4, il est précisé que les données de conversion attribuées par canal peuvent être actualisées jusqu’à 12 jours après l’enregistrement de la conversion, le temps que les données soient traitées et utilisées pour entraîner les modèles. Pour les équipes média, cela a une conséquence immédiate : juger trop vite la contribution d’un canal ou d’une campagne peut conduire à des arbitrages prématurés. ([support.google.com](https://support.google.com/analytics/answer/10710245?hl=fr&utm_source=openai))

Autre élément important : Google précise que toutes les conversions Google Ads créées à partir d’événements clés Google Analytics incluent la modélisation. Cela signifie que le lien entre GA4 et Google Ads reste exploitable, mais avec une couche de reconstruction statistique qui doit être comprise avant d’interpréter les chiffres au premier degré. ([support.google.com](https://support.google.com/analytics/answer/10710245?hl=fr&utm_source=openai))

Google Ads : mesure, enchères et signaux exploitables

Dans Google Ads, Consent Mode v2 joue un rôle direct sur la continuité de la mesure publicitaire. Google explique que le mode Consentement permet d’envoyer l’état de consentement de l’utilisateur à Google afin que les tags adaptent leur comportement. Quand le consentement réduit la quantité de données disponibles dans Google Ads ou GA4, Google peut ajuster le suivi des performances grâce à la modélisation du parcours clic-vers-conversion. ([support.google.com](https://support.google.com/google-ads/answer/10000067?hl=en&utm_source=openai))

La nuance la plus importante est que tout n’est pas récupérable de la même manière. Si un utilisateur refuse certains stockages ou certains usages publicitaires, Google peut modéliser une partie des conversions agrégées, mais il ne reconstitue pas des audiences nominatives ou des capacités de personnalisation qui nécessitent des consentements explicites. En pratique, la modélisation aide davantage à préserver le pilotage macro de la performance qu’à maintenir intact l’ensemble des leviers d’activation. Cette lecture découle des restrictions documentées sur ad_user_data et ad_personalization. ([support.google.com](https://support.google.com/google-ads/answer/13802165?hl=fr&utm_source=openai))

Google précise en outre que ad_user_data est requis dans les régions où le consentement utilisateur s’applique, notamment l’EEE, le Royaume-Uni et la Suisse. Une page de vérification des signaux de consentement indique explicitement que ce paramètre est requis pour ces régions. Autrement dit, l’enjeu n’est pas seulement qualitatif ; il conditionne aussi l’éligibilité correcte de certains flux de données. ([support.google.com](https://support.google.com/google-ads/answer/16147066?hl=en&utm_source=openai))

Pour les annonceurs qui optimisent leurs campagnes avec des conversions importées depuis GA4, le point de vigilance est clair : Google documente qu’en cas de ad_user_data='denied', l’export de données de conversion liées à un click ID vers Ads est limité, y compris pour des usages d’optimisation d’enchères. Une implémentation imprécise peut donc dégrader la qualité du signal utilisé par les stratégies d’enchères automatiques, même si le volume brut de conversions affichées semble encore correct à première vue. ([support.google.com](https://support.google.com/google-ads/answer/13802165?hl=fr&utm_source=openai))

De ce fait, Consent Mode v2 déplace la question de la performance : on ne parle plus uniquement de volume de conversions remontées, mais de qualité d’activation du signal. Un compte peut afficher des conversions, tout en fournissant à Google Ads un signal moins utile pour l’apprentissage et l’optimisation si certaines dimensions de consentement sont absentes ou refusées. C’est là que se joue une part très concrète de l’impact business. Cette conclusion est une inférence raisonnable à partir des restrictions Google sur le partage de données et sur les conversions liées aux identifiants de clic. ([support.google.com](https://support.google.com/google-ads/answer/13802165?hl=fr&utm_source=openai))

Modélisation des conversions : utile, mais ni totale ni immédiate

La promesse la plus souvent associée à Consent Mode est la modélisation des conversions. Elle est réelle, mais il faut la cadrer. Google décrit un mécanisme où, en cas de manque de données causé par les choix de consentement, les systèmes publicitaires peuvent modéliser des conversions manquantes à partir de signaux agrégés et d’observations disponibles. Avec l’implémentation avancée, cette modélisation est plus riche qu’avec une implémentation basique où les tags restent entièrement bloqués jusqu’au consentement. ([developers.google.com](https://developers.google.com/tag-platform/security/concepts/consent-mode?utm_source=openai))

En pratique, cela signifie que deux annonceurs avec le même taux de consentement peuvent obtenir des résultats de mesure différents selon leur architecture. Celui qui a mis en place un advanced consent mode propre, avec états par défaut, mise à jour rapide après interaction et balises bien ordonnées, offre à Google plus de matière pour modéliser que celui qui bloque tout puis déclenche des tags tardifs ou incomplets. ([developers.google.com](https://developers.google.com/tag-platform/security/guides/consent?utm_source=openai))

Il faut aussi rappeler que Google présente la modélisation comme une estimation, pas comme une restitution parfaite de la réalité individuelle. Dans GA4, la modélisation comportementale repose sur le machine learning, des données observées dans la propriété et des mécanismes de validation interne. Google indique également qu’elle n’apparaît que lorsque le modèle est jugé suffisamment fiable. Cela protège la rigueur statistique, mais impose d’accepter une réalité moins exhaustive qu’avant l’ère du consentement granulaire. ([support.google.com](https://support.google.com/analytics/answer/11161109?hl=fr&utm_source=openai))

Pour une équipe performance, la bonne posture consiste donc à considérer la modélisation comme un amortisseur de perte de signal, pas comme un remplaçant intégral de la donnée observée. Elle améliore la continuité de lecture des conversions et de l’attribution, mais elle ne compense pas totalement des taux de refus élevés, une CMP mal intégrée ou un paramétrage erroné des consent states. ([support.google.com](https://support.google.com/google-ads/answer/10000067?hl=en&utm_source=openai))

Qualité des audiences : le sujet le plus sous-estimé

Beaucoup d’équipes abordent Consent Mode v2 d’abord sous l’angle reporting. Pourtant, l’impact le plus dur à corriger concerne souvent les audiences. Google indique que si ad_personalization et ad_user_data ne sont pas tous deux accordés, la publicité personnalisée n’est pas activée dans ses plateformes. Cela affecte directement le remarketing et les usages de personnalisation publicitaire. ([support.google.com](https://support.google.com/google-ads/answer/13802165?hl=fr&utm_source=openai))

Concrètement, une audience peut devenir plus petite, moins fraîche ou moins activable selon les marchés et selon la part de trafic concernée. Vous pouvez continuer à observer des conversions modélisées au niveau agrégé tout en perdant de la précision dans la constitution et l’exploitation des listes. C’est une asymétrie importante : la mesure peut être partiellement sauvée, alors que l’activation audience se dégrade plus nettement. Cette différence est cohérente avec la documentation Google qui distingue les usages de mesure des usages de personnalisation. ([support.google.com](https://support.google.com/google-ads/answer/13802165?hl=fr&utm_source=openai))

Le sujet dépasse le seul remarketing de site. Pour le Customer Match en EEE, Google Ads précise que, depuis mars 2024, les champs de consentement appropriés doivent être transmis pour que les listes soient utilisables, et que les deux champs de type ConsentStatus doivent être définis sur GRANTED pour l’usage dans l’EEE. Google indique également qu’un consentement refusé sur ad_user_data ou ad_personalization entraîne une erreur et empêche l’utilisation des données concernées pour la personnalisation des annonces. ([support.google.com](https://support.google.com/google-ads/answer/14546648?hl=en&utm_source=openai))

Pour les directions acquisition, cela impose un changement de discipline : la santé d’une audience ne se juge plus uniquement à sa taille affichée, mais à la chaîne complète collecte du consentement, transmission correcte des signaux, éligibilité à l’usage publicitaire et fraîcheur de mise à jour. Sans cette lecture, on risque d’attribuer à la créativité ou au ciblage une baisse de performance qui vient en réalité d’un problème de consentement mal instrumenté. ([support.google.com](https://support.google.com/google-ads/answer/13802165?hl=fr&utm_source=openai))

Basic ou advanced : le vrai arbitrage performance

Sur le terrain, le choix entre implémentation basique et avancée a un impact direct sur la performance mesurable. Google décrit le basic consent mode comme une approche où les tags restent bloqués jusqu’au consentement, tandis que l’advanced consent mode charge les tags avec des paramètres par défaut et adapte ensuite le comportement selon le choix utilisateur. Google précise que cette approche avancée permet une modélisation des conversions plus détaillée. ([developers.google.com](https://developers.google.com/tag-platform/security/concepts/consent-mode?utm_source=openai))

Pour un annonceur orienté acquisition, le compromis est donc assez clair : si l’objectif est de maximiser la qualité de mesure agrégée malgré les refus, l’advanced consent mode est généralement plus favorable. En revanche, il demande une mise en œuvre plus rigoureuse, notamment sur l’ordre de chargement, la définition des états par défaut et la rapidité de la mise à jour après interaction. Google recommande par exemple de définir les commandes consent default avant les commandes de mesure, et documente l’usage de wait_for_update pour laisser à la CMP un court délai afin d’actualiser le statut avant l’envoi de données. ([developers.google.com](https://developers.google.com/tag-platform/security/guides/consent?utm_source=openai))

Il faut aussi noter une subtilité importante pour Google Tag Manager : Google déconseille de remplacer les API spécifiques de gestion du consentement par de simples commandes gtag, car le traitement des messages dans la data layer peut introduire des décalages. Les API recommandées sont setDefaultConsentState et updateConsentState. Ce détail purement technique peut avoir des effets très concrets sur la cohérence des signaux réellement envoyés. ([developers.google.com](https://developers.google.com/tag-platform/security/guides/consent?utm_source=openai))

Checklist de mise en œuvre et de contrôle

Cartographier les marchés concernés. Google vise explicitement l’EEE, le Royaume-Uni et la Suisse pour les exigences de signaux de consentement utilisateur et pour certains paramètres requis comme ad_user_data. ([support.google.com](https://support.google.com/google-ads/answer/16147066?hl=en&utm_source=openai))
Passer à la v2 si ce n’est pas déjà fait. Google indique que la mise à jour de novembre 2023 a ajouté ad_user_data et ad_personalization, et recommande de migrer les implémentations existantes. ([developers.google.com](https://developers.google.com/tag-platform/security/guides/consent?utm_source=openai))
Définir clairement les quatre signaux. Les états par défaut et les mises à jour doivent couvrir ad_storage, analytics_storage, ad_user_data et ad_personalization. ([support.google.com](https://support.google.com/google-ads/answer/13802165?hl=fr&utm_source=openai))
Choisir consciemment basic ou advanced. Si l’enjeu premier est la qualité de modélisation des conversions, Google indique que l’advanced consent mode est plus favorable. ([developers.google.com](https://developers.google.com/tag-platform/security/concepts/consent-mode?utm_source=openai))
Placer le consent default avant toute mesure. Google demande que la commande de consentement par défaut soit appelée avant les commandes qui envoient des données, comme config ou event. ([developers.google.com](https://developers.google.com/tag-platform/security/guides/consent?utm_source=openai))
Prévoir un délai court avec wait_for_update si la CMP est asynchrone. Google documente cette option pour éviter que les tags n’envoient des données avant la mise à jour des choix utilisateurs. ([developers.google.com](https://developers.google.com/tag-platform/security/guides/consent?utm_source=openai))
Dans GTM, utiliser les API dédiées. Google recommande setDefaultConsentState et updateConsentState pour éviter des incohérences liées au traitement de la data layer. ([developers.google.com](https://developers.google.com/tag-platform/security/guides/consent?utm_source=openai))
Vérifier les signaux envoyés pour les régions concernées. Google fournit une aide dédiée qui rappelle que ad_user_data est requis pour l’EEE, le Royaume-Uni et la Suisse. ([support.google.com](https://support.google.com/google-ads/answer/16147066?hl=en&utm_source=openai))
Surveiller la part de conversions modélisées et leur latence. Dans GA4, Google indique que certaines données de conversion attribuées peuvent être ajustées jusqu’à 12 jours après la conversion. ([support.google.com](https://support.google.com/analytics/answer/10710245?hl=fr&utm_source=openai))
Auditer l’impact sur les audiences. Vérifier la taille, la fraîcheur et l’éligibilité des listes de remarketing et de Customer Match, surtout en EEE. ([support.google.com](https://support.google.com/google-ads/answer/13802165?hl=fr&utm_source=openai))
Contrôler le lien GA4 vers Google Ads. Si ad_user_data est refusé, Google documente des limites sur l’export de données de conversion liées à un click ID et sur certains usages d’optimisation. ([support.google.com](https://support.google.com/google-ads/answer/13802165?hl=fr&utm_source=openai))
Ne pas confondre conformité et performance. Une implémentation “fonctionnelle” sur le papier peut rester mauvaise pour la mesure si les signaux arrivent trop tard, mal segmentés ou non exploitables par les plateformes. Cette conclusion est une synthèse opérationnelle fondée sur les contraintes techniques documentées par Google. ([developers.google.com](https://developers.google.com/tag-platform/security/guides/consent?utm_source=openai))

Ce qu’il faut retenir pour piloter l’acquisition

Consent Mode v2 change vraiment trois choses. D’abord, il segmente plus finement les usages possibles de la donnée grâce à ad_user_data et ad_personalization. Ensuite, il rend la qualité de l’implémentation beaucoup plus décisive pour la mesure, notamment si l’on veut bénéficier de la modélisation. Enfin, il fragilise davantage les audiences activables que la lecture agrégée des conversions, ce qui en fait un sujet de performance, pas seulement de conformité. ([support.google.com](https://support.google.com/google-ads/answer/13802165?hl=fr&utm_source=openai))

Pour les marques et les agences, le bon réflexe n’est donc pas de demander si Consent Mode v2 “fait perdre des conversions”, mais où se perd le signal, quelle part est récupérée par modélisation, et quels usages publicitaires restent réellement activables. Les comptes les plus solides seront ceux qui traitent ce sujet comme un chantier de qualité de données, avec instrumentation, QA, lecture régionale et suivi continu des impacts sur GA4, Google Ads et les audiences. ([support.google.com](https://support.google.com/analytics/answer/11161109?hl=fr&utm_source=openai))

Le vrai enjeu de Consent Mode v2 n’est pas de “sauver le tracking” comme avant. C’est d’obtenir le meilleur signal mesurable possible, dans un cadre où tous les usages de la donnée ne sont plus équivalents.