Le défaut posé après GTM
L'erreur numéro un. Le bloc consent default se charge après le snippet GTM : les premiers tags partent sans statut et Google les ignore.
Comment implémenter Consent Mode v2 pour Google Ads et Google Analytics via un conteneur GTM server-side, sur Shopify ou WooCommerce, et récupérer le signal de conversion perdu depuis mars 2024. Écrit pour les PME suisses qui font de l'acquisition payante et reçoivent du trafic de l'Union européenne.
Guide technique · Google Ads · GA4 · GTM server-side
Depuis mars 2024, Google exige les signaux de consentement v2 pour continuer à alimenter le remarketing, le Customer Match et la modélisation des conversions sur le trafic de l'EEE. Un site resté en v1 voit ses audiences se vider sans message d'erreur.
aucune alerte, aucun mail : ça se vide en silence
Les deux derniers sont les nouveautés de la v2, et ce sont eux qui conditionnent le remarketing. C'est là que la plupart des sites romands décrochent sans s'en apercevoir.
En mode avancé, les tags Google se chargent immédiatement et envoient des pings sans cookie tant que le consentement est refusé. Google modélise alors les conversions manquantes. En mode basique, rien n'est envoyé : pas de modélisation, pas de récupération. Vous perdez sèchement le signal des visiteurs qui refusent.
Un conteneur server-side ne contourne pas le consentement : il le centralise. Un seul point de décision applique le statut à Google Ads, GA4 et la CAPI Meta, au lieu de dépendre de chaque tag navigateur. C'est plus fiable, pas plus permissif. Si vous vous demandez ce que cette infrastructure coûte et à partir de quel budget elle se justifie, c'est le sujet du guide sur le coût du tracking server-side.
La nLPD n'impose pas le consentement préalable comme le RGPD. Mais dès qu'une part de votre trafic vient de l'Union européenne, la règle de Google s'applique à ce trafic. La plupart des sites romands sont concernés sans le savoir.
Dans cet ordre. L'étape 1 conditionne toutes les suivantes : c'est là que se joue l'erreur la plus fréquente.
Avant tout tag Google, le navigateur doit connaître l'état par défaut. Ce bloc se place dans le <head>, au-dessus du snippet GTM. S'il se charge après, Google considère le consentement comme inconnu et les pings partent mal formés.
<!-- À placer AVANT le snippet GTM, dans le <head> -->
<script>
window.dataLayer = window.dataLayer || [];
function gtag(){dataLayer.push(arguments);}
gtag('consent', 'default', {
'ad_storage': 'denied',
'ad_user_data': 'denied',
'ad_personalization': 'denied',
'analytics_storage': 'denied',
'functionality_storage': 'granted',
'security_storage': 'granted',
'wait_for_update': 500
});
gtag('set', 'ads_data_redaction', true);
gtag('set', 'url_passthrough', true);
</script>ads_data_redaction supprime les identifiants publicitaires des pings refusés ; url_passthrough conserve le gclid dans l'URL pour ne pas perdre l'attribution Google Ads.
La CMP (Axeptio, Didomi, Cookiebot, Usercentrics, Complianz) doit émettre une mise à jour dès le choix de l'utilisateur, et pousser un événement dataLayer pour déclencher les tags en attente.
// Appelé par la CMP quand l'utilisateur accepte
gtag('consent', 'update', {
'ad_storage': 'granted',
'ad_user_data': 'granted',
'ad_personalization': 'granted',
'analytics_storage': 'granted'
});
dataLayer.push({ event: 'consent_updated' });Vérifiez que votre CMP est bien certifiée Google : une CMP non certifiée ne suffit pas pour les fonctionnalités de remarketing sur le trafic EEE.
Le conteneur web transmet l'état de consentement dans l'event data envoyé au conteneur server-side. Côté serveur, chaque tag lit ce statut avant d'envoyer quoi que ce soit à Google Ads, GA4 ou la CAPI Meta.
// Variable "Consent state" dans le conteneur server-side
// Lue depuis l'event data transmis par le client
const eventData = require('getAllEventData')();
const adConsent = eventData.consent_state &&
eventData.consent_state.ad_user_data === 'granted';
// Le tag Google Ads / CAPI n'envoie les données utilisateur
// (email, téléphone hashés) que si adConsent === trueRègle pratique : les données utilisateur hashées (Enhanced Conversions, advanced matching) ne partent que si ad_user_data vaut granted. L'événement de conversion lui-même peut partir anonymisé.
Sur Shopify, la Customer Privacy API gère nativement le consentement : les Custom Pixels du Checkout lisent son état, et les apps GTM doivent être configurées en mode avancé, pas en blocage. Sur les thèmes non-Plus, le bloc par défaut se pose dans theme.liquid, tout en haut du <head>.
Sur WooCommerce, le piège classique est l'ordre de chargement des plugins : la CMP doit s'enfiler avant GTM (priorité de hook plus basse), sinon le défaut n'est jamais posé. Les événements e-commerce (add_to_cart, purchase) sont ensuite envoyés au conteneur server-side avec l'état de consentement attaché.
Trois vérifications, dans cet ordre. Tag Assistant : le statut de consentement doit apparaître à chaque déclenchement. Onglet Réseau : les requêtes /g/collect portent gcs=G100 avant consentement et gcs=G111 après. Google Ads : l'écran de diagnostic des balises confirme la réception des pings cookieless et l'activation de la modélisation.
Dans GA4, DebugView permet de suivre événement par événement. Comptez plusieurs jours de volume avant que la modélisation des conversions n'apparaisse dans les rapports.
Quatre défauts reviennent sur la majorité des setups que j'ouvre. Aucun ne déclenche d'alerte : c'est ce qui les rend coûteux.
L'erreur numéro un. Le bloc consent default se charge après le snippet GTM : les premiers tags partent sans statut et Google les ignore.
La CMP envoie ad_storage et analytics_storage, mais pas ad_user_data ni ad_personalization. Résultat : les listes de remarketing se vident silencieusement.
Beaucoup de plugins bloquent purement les tags avant consentement. C'est le mode basique : conforme, mais vous perdez toute la modélisation des conversions.
Le conteneur server-side envoie les données utilisateur hashées quel que soit le consentement. Techniquement invisible, juridiquement indéfendable.
Un tracking propre mesure, encore faut-il un budget bien dimensionné à mesurer. Les fourchettes de CPC par secteur et la méthode de calcul.
Ce que le consentement modélise, l'attribution déplace et le CRM corrige : les six mécanismes d'écart, et la méthode pour réconcilier les trois étages.
Un tracking propre ne sert à rien si les moteurs ne voient pas vos pages. Le simulateur vérifie en 30 secondes le rendu sans JavaScript, les robots IA, le balisage et le llms.txt. Gratuit, rapport par email.
Lancer le test gratuitJe vérifie gratuitement votre implémentation : ordre de chargement, quatre signaux, mode avancé, propagation server-side, modélisation reçue côté Google Ads. Vous repartez avec la liste des correctifs, même si on ne travaille pas ensemble.
Demander mon audit gratuitLa Suisse n'est pas dans l'EEE : le RGPD ne s'applique pas d'office et la nLPD n'impose pas le consentement préalable aux cookies de la même manière. En revanche, Google l'impose contractuellement dès que vous adressez du trafic de l'EEE, et la plupart des sites romands en reçoivent (France voisine, frontaliers, clients UE). Sans Consent Mode v2 pour ces utilisateurs, Google Ads coupe le remarketing et l'audience matching sur ce trafic.
La v1 gérait deux signaux : ad_storage et analytics_storage. La v2 en ajoute deux, ad_user_data (envoi de données utilisateur à Google) et ad_personalization (publicité personnalisée et remarketing). Un site resté en v1 envoie des signaux incomplets : les tags se déclenchent, mais les listes de remarketing et le Customer Match ne se remplissent plus sur le trafic EEE.
Le mode basique bloque le chargement des tags Google tant que l'utilisateur n'a pas consenti : aucun ping, donc aucune modélisation des conversions. Le mode avancé charge les tags dès le départ et envoie des pings sans cookie (cookieless pings) tant que le consentement est refusé, ce qui permet à Google de modéliser les conversions manquantes. Pour un site publicitaire, le mode avancé est presque toujours le bon choix : c'est lui qui récupère du signal.
Oui, et c'est le montage le plus robuste. Le statut de consentement est établi côté navigateur par la CMP, transmis dans le dataLayer, puis propagé au conteneur server-side. Les tags server-side lisent ce statut et décident d'envoyer, d'anonymiser ou de bloquer. Attention : le server-side ne contourne pas le consentement, il l'applique de manière centralisée et vérifiable.
Toute CMP certifiée Google (Axeptio, Didomi, Cookiebot, Usercentrics, Complianz sur WooCommerce) qui pousse nativement les quatre signaux Consent Mode v2 et le mode par défaut avant tout tag Google. Le critère décisif n'est pas la marque mais l'ordre de chargement : la commande gtag consent default doit s'exécuter avant le snippet GTM.
Trois contrôles : la console Google Tag Assistant affiche le statut de consentement à chaque déclenchement de tag ; l'onglet Réseau montre des requêtes /g/collect avec gcs=G100 avant consentement et gcs=G111 après ; enfin, dans Google Ads, le diagnostic de balise et l'écran Consent Mode indiquent si les pings cookieless sont reçus. La modélisation des conversions n'apparaît qu'après un volume suffisant, comptez plusieurs jours.
Sur un Shopify ou un WooCommerce standard avec une CMP déjà en place, comptez 1 à 2 semaines : audit, correction de l'ordre de chargement, mise en place des quatre signaux, propagation au conteneur server-side, recette. Sur un site custom avec un plan de taggage lourd, plutôt 4 à 6 semaines.
Pour le reste du dispositif de mesure (GA4, CAPI Meta, Enhanced Conversions, remontée de marge brute), voir la page Tracking GA4 & server-side.