Tagging côté serveur et consentement : pourquoi sGTM a toujours besoin d’un bandeau

Le tagging côté serveur ne supprime pas le besoin de consentement. Avec Google Tag Manager côté serveur, le navigateur du visiteur exécute toujours un script et envoie une requête contenant des informations issues de l’appareil, désormais vers un serveur de tagging sur votre propre sous-domaine au lieu d’aller directement chez Google ou Meta. La règle ePrivacy porte sur cet accès à l’appareil, donc la mesure d’audience et la publicité exigent toujours un consentement dans l’UE et au Royaume-Uni. Ce que change le tagging côté serveur, c’est la destination des données après leur sortie du navigateur, ce qui peut vous aider à en envoyer moins, à condition que le consentement accompagne chaque requête et que chaque balise du conteneur serveur le respecte.

Qu’est-ce que le tagging côté serveur ?

Dans une configuration classique, le conteneur web du navigateur charge la balise de chaque éditeur, et chaque balise envoie ses données directement à son éditeur. Avec le tagging côté serveur, Google décrit un conteneur serveur qui tourne sur un serveur que vous contrôlez, comme votre propre projet Google Cloud, et non dans le navigateur du visiteur. Le site envoie les événements à l’URL du conteneur, que Google recommande de placer sur votre domaine propre (par exemple metrics.example.com). Dans le conteneur, des clients reçoivent les requêtes et les transforment en événements, et des balises serveur transmettent ces événements à Google Analytics, Google Ads ou d’autres éditeurs. L’introduction de Google souligne que vous seul avez accès aux données du serveur tant que vous ne choisissez pas de les envoyer ailleurs.

Pourquoi faut-il toujours un consentement ?

Pour trois raisons.

1. C’est toujours le navigateur qui collecte. Un script de la page lit des informations (page, site référent, identifiants, caractéristiques de l’appareil) et les fait envoyer par le navigateur. L’article 5, paragraphe 3, de la directive ePrivacy couvre le stockage d’informations sur l’appareil ou l’accès à celles-ci, et les lignes directrices 2/2023 du CEPD sur son champ technique l’appliquent à des techniques comme les pixels de suivi et le suivi par URL, pas seulement aux cookies.
2. Les cookies restent des cookies. Un cookie interne déposé par votre serveur de tagging sur votre domaine est stocké sur l’appareil du visiteur comme n’importe quel autre. Le domaine change, la règle non.
3. La finalité ne change pas. Si le serveur transmet l’événement à une plateforme publicitaire, le traitement est publicitaire, et le RGPD exige une base légale, qui pour le suivi est le consentement.

Cacher un traceur derrière un sous-domaine interne pour que les bloqueurs de publicité ou les bandeaux ne le voient pas ne le rend pas licite. Cela rend même la preuve du consentement plus importante, car une autorité demandera comment vous vous êtes assuré que le serveur ne transmettait rien pour les visiteurs qui ont refusé.

Comment le consentement atteint-il le conteneur serveur ?

Par la balise web. Le guide de Google sur le consent mode avec Tag Manager côté serveur indique que le bandeau du site recueille le consentement, que la balise Google ajoute l’état du consentement à chaque requête qu’elle envoie au conteneur serveur, et que vous n’avez besoin de configurer le consent mode que dans le conteneur web. Les conteneurs serveur prennent en charge le consent mode basique comme avancé.

L’ordre des opérations du guide Consent Mode s’applique donc toujours : valeurs par défaut sur refusé avant l’exécution de la balise Google, une mise à jour à chaque choix, et la balise web pointée vers votre serveur de tagging.

Quelles balises serveur respectent le consentement d’elles-mêmes ?

Google indique que ses balises produits dans le conteneur serveur tiennent compte du consentement :

Les balises des autres éditeurs sont une autre affaire. Une balise serveur qui transmet des événements à Meta, TikTok, LinkedIn ou à un entrepôt de données se déclenche chaque fois que son déclencheur se déclenche, sauf si vous ajoutez une condition. Dans le conteneur serveur, construisez cette condition à partir de l’état du consentement porté par la requête, ou n’envoyez les événements destinés à ces éditeurs que depuis des balises web qui attendent déjà le consentement.

Que peut apporter le tagging côté serveur à la vie privée ?

Utilisé avec le consentement, il peut réduire ce que reçoit chaque éditeur :

• retirer ou tronquer les adresses IP et les user agents avant transmission ;
• supprimer les paramètres d’URL, adresses e-mail ou identifiants qui ne doivent jamais parvenir à un éditeur ;
• envoyer moins de requêtes tierces depuis le navigateur, ce qui aide aussi la vitesse des pages ;
• garder un point unique où vous pouvez voir et documenter chaque flux de données.

Ce sont de bonnes raisons de l’adopter. Ce ne sont pas des raisons de se passer du bandeau.

Comment le configurer correctement ?

Les étapes ci-dessous supposent qu’un conteneur web et un conteneur serveur existent déjà. Le guide de la plateforme Google Tag Manager traite du côté conteneur web avec un bandeau de consentement.

Comment le tester ?

Utilisez le mode aperçu de Tag Manager pour les deux conteneurs, et le test dans le navigateur décrit dans vérifier les cookies avant consentement. Avant tout choix, les requêtes vers votre serveur de tagging doivent porter l’état refusé, et l’aperçu du conteneur serveur doit montrer que les balises non Google ne se déclenchent pas. Après « Tout refuser », même chose. Après « Tout accepter », tout se déclenche.

Où se place un bandeau de consentement ?

Exactement là où il était : dans le navigateur, avant la balise Google. Le script de Cookiequiet règle les valeurs par défaut de Consent Mode sur refusé avant l’exécution de toute balise Google et les met à jour à chaque choix, pour que la balise web transmette le bon état à votre conteneur serveur. Il pousse aussi un événement dataLayer cq_consent avec des indicateurs par catégorie que les déclencheurs web peuvent utiliser. L’installation tient en une balise script placée avant vos autres scripts, avec Consent Mode v2 activé dans l’extrait que vous donne le tableau de bord ; l’offre gratuite couvre un site, Starter coûte 3 € par site et par mois (voir les tarifs).