Consent Mode v2 avec GTM server-side.
Le guide d'implémentation pas à pas.

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
  • Snippets prêts à coller, testés en production
  • Cas Shopify et WooCommerce couverts
  • Méthode de recette dans Google Ads et GA4
Baptiste Mauri, consultant tracking et Consent Mode v2 à Genève

Ce que Consent Mode v2 change concrètement pour vos campagnes.

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

obligatoire depuis 03.2024
Les quatre signaux :
ad_storage : cookies publicitairesv1
analytics_storage : cookies GA4v1
ad_user_data : envoi de données utilisateur à Googlenouveau v2
ad_personalization : publicité personnaliséenouveau v2

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.

Mode avancé ou mode basique : la différence coûte cher

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.

Le server-side n'exempte de rien

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.

Et le cas suisse

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.

Cinq étapes pour une implémentation propre.

Dans cet ordre. L'étape 1 conditionne toutes les suivantes : c'est là que se joue l'erreur la plus fréquente.

  1. 1. Poser l'état de consentement par défaut

    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.

  2. 2. Brancher la CMP sur les quatre signaux v2

    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.

  3. 3. Propager le consentement au conteneur server-side

    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 === true

    Rè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é.

  4. 4. Adapter Shopify ou WooCommerce

    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é.

  5. 5. Recette et contrôle dans Google Ads et GA4

    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.

Les erreurs que je retrouve le plus souvent en audit.

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.

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.

Rester sur les deux signaux v1

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.

Mode basique par défaut

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 server-side qui ignore le statut

Le conteneur server-side envoie les données utilisateur hashées quel que soit le consentement. Techniquement invisible, juridiquement indéfendable.

À lire ensuite.

Votre site est-il lisible par les robots d'IA ?

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 gratuit

Votre Consent Mode v2 est-il vraiment en place ?

Je 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 gratuit