Blog
Une bannière de cookies devant le tagging côté serveur : ce qui change, et ce qui ne change pas
Publié · Mis à jour · 3 min de lecture
La bannière demande son choix au visiteur. Consent Mode transmet ce choix aux balises Google. Le blocage des scripts décide si l’extrait SignalHost s’exécute. Ce sont des fonctions distinctes. Afficher une bannière ne suffit pas.
Ce que le tagging côté serveur change au consentement : rien
Un nom d’hôte first-party est une propriété technique d’une requête. Ce n’est pas une permission. Si vous aviez besoin d’un consentement hier pour déposer un cookie d’analyse, vous en avez besoin aujourd’hui, et le fait que le cookie soit désormais déposé par metrics.votresite.com au lieu de google-analytics.com n’y change rien. La question du régulateur est ce que vous collectez et pourquoi, pas quel serveur le paquet a visité en chemin.
Configurer votre bannière de cookies
La bannière demande son choix au visiteur. Consent Mode transmet ce choix aux balises Google. Le blocage des scripts décide si l’extrait SignalHost s’exécute. Ce sont des fonctions distinctes.
Dans les réglages de votre fournisseur, activez l’intégration Google Consent Mode v2. Afficher une bannière ne suffit pas. N’ajoutez ni seconde bannière ni balise Google en double.
Basic ou Advanced : quelle différence ?
Choisissez le mode adapté à la politique de votre organisation. Ne désactivez pas un blocage volontaire uniquement pour faire apparaître des événements.
- **Basic :** bloquez l’extrait de suivi jusqu’au consentement correspondant. Aucun événement de suivi n’est attendu dans SignalHost avant ce consentement.
- **Advanced :** les balises Google chargent avec des valeurs initiales `denied`. Google peut recevoir des mesures sans cookies avant le choix ou après un refus. Une mesure ne vaut pas consentement.
Définissez les valeurs initiales, puis transmettez les choix
Définissez `analytics_storage`, `ad_storage`, `ad_user_data` et `ad_personalization` sur `denied` avant l’exécution de l’extrait SignalHost. La bannière adapte ensuite chaque autorisation au choix du visiteur.
- Accepter uniquement les statistiques ne doit pas autoriser la publicité.
- Mémorisez le choix pour les visites suivantes et transmettez toute modification ou tout retrait.
- Les conversions améliorées Google Ads nécessitent aussi l’autorisation `ad_user_data` et leur configuration dans Ads. `ad_personalization` concerne la publicité personnalisée, pas le comptage ordinaire.
Si votre bannière bloque les scripts
Ajoutez l’URL exacte du chargeur de votre extrait SignalHost aux règles de blocage de la bannière. Votre domaine peut échapper à ses règles Google habituelles. Ne le débloquez qu’après le consentement nécessaire.
Avant d’activer le rapprochement des contacts
Cette option peut lire les e-mails saisis sur votre site. Le hachage ne rend pas ces coordonnées anonymes et elles ne sont pas nécessaires pour compter les événements ordinaires.
En mode Advanced, des coordonnées peuvent atteindre SignalHost avant leur suppression par SignalHost lorsque `ad_storage` est `denied`. Pour éviter tout transfert avant consentement, laissez le rapprochement désactivé ou bloquez l’extrait jusque-là.
Testez l’acceptation et le refus
Ouvrez une nouvelle fenêtre privée pour chaque test. Dans Google Tag Assistant, saisissez l’URL du site et examinez les premiers et derniers événements Consent. Vérifiez ces cas :
- Avant un choix et après Refuser : les autorisations concernées restent sur `denied`.
- Statistiques uniquement : `analytics_storage` peut être accordé ; les autorisations publicitaires restent refusées.
- Publicité acceptée : n’accordez que les finalités réellement acceptées par le visiteur.
- Retrait : les valeurs concernées repassent sur `denied`. Rechargez et vérifiez le choix enregistré.
Un événement visible prouve-t-il que le consentement est correct ? Non. Les événements en direct montrent l’arrivée dans SignalHost, pas les quatre autorisations ni la livraison à une plateforme. Vérifiez le consentement dans Tag Assistant, puis la destination séparément.