Google Consent Mode fonctionne-t-il vraiment ?
Ce vérificateur Google Consent Mode observe les appels gtag dans l’ordre où la page les effectue, lit le signal de consentement sur les requêtes qui partent et vous dit laquelle des quatre exigences v2 échoue.
Ce que Consent Mode v2 demande vraiment.
Quatre points, dans l’ordre. La plupart des implémentations réussissent les deux premiers et ratent discrètement les deux derniers.
État par défaut défini avant les balises
La valeur par défaut doit être déclarée avant l’exécution de gtag.js ou du conteneur GTM. Si elle arrive plus tard, Google enregistre les premiers hits comme entièrement consentis. Un conteneur qui définit son propre défaut via un déclencheur Consent Initialization convient : l’essentiel est que rien n’ait été mesuré avant.
gtag("consent", "default", {
ad_storage: "denied", analytics_storage: "denied",
ad_user_data: "denied", ad_personalization: "denied",
wait_for_update: 500
});Paramètres v2 présents
Consent Mode v2 a ajouté deux paramètres en mars 2024. Sans eux, Google Ads cesse de constituer des audiences dans l’EEE et de modéliser les conversions, et l’implémentation n’est pas acceptée au titre des règles de Google relatives au consentement de l’utilisateur dans l’UE.
ad_user_data: "denied", ad_personalization: "denied"
Mise à jour au changement de consentement
La bannière doit transmettre le choix du visiteur à Google dès qu’il change, sinon les balises continuent de fonctionner sur la valeur par défaut. Nous ne cliquons pas sur votre bannière : une mise à jour que nous ne voyons pas est donc signalée comme non confirmée plutôt que comme un échec. Acceptez vous-même une catégorie et regardez la console.
gtag("consent", "update", {
analytics_storage: "granted"
});Region et wait_for_update
Un tableau region laisse le trafic hors EEE sans restriction, et wait_for_update empêche les premiers pings de partir avec le mauvais état. Tout refuser globalement sans region ne pose pas de problème : c’est simplement plus strict que nécessaire.
region: ["EEA", "GB", "CH"], wait_for_update: 500
Le paramètre gcs fait foi
Lire votre code source vous dit ce qu’une page voulait faire. La valeur gcs des requêtes sortantes vers Google vous dit ce qui leur est réellement parvenu : G1 suivi de ad_storage et analytics_storage, donc G100 signifie tous deux refusés et G111 tous deux accordés. Une page peut contenir un bloc de consentement parfait et n’envoyer aucun gcs.
Arrêtez de maintenir vos appels gtag à la main.
La bannière de Katla déclare les quatre signaux refusés avant tout chargement, puis les met à jour selon le choix réel du visiteur. Envie de voir ce que la page stocke malgré tout ? Lancez le vérificateur de cookies.