Faut-il encore une bannière de cookies avec le marquage côté serveur

Tous les articles

Oui, vous avez toujours besoin d'une bannière de cookies avec le marquage côté serveur. Le marquage côté serveur change l'endroit où vos balises s'exécutent, du navigateur du visiteur vers un conteneur sur un serveur que vous contrôlez. Il ne change pas votre droit de collecter les données au départ. À cette question, c'est le consentement qui répond, et le consentement, c'est ce que la bannière recueille.

Ce que le marquage côté serveur déplace vraiment

La confusion est compréhensible, car le marquage côté serveur déplace vraiment beaucoup de choses. Au lieu d'une douzaine de scripts de fournisseurs qui se déclenchent dans le navigateur, la page envoie une seule requête à un conteneur qui vous appartient, et c'est ce conteneur qui dialogue avec Google, Meta et tous les autres. Vous obtenez des requêtes propriétaires depuis votre propre domaine, des cookies à durée de vie plus longue, et la possibilité de nettoyer ou de supprimer des données avant qu'elles ne sortent.

Rien de tout cela ne touche au moment où un visiteur décide de ce qu'il autorise. Cette décision se prend sur la page, avant que la moindre machinerie côté serveur ne s'exécute. Voici le partage.

La décision de consentement n'a jamais quitté le navigateur

Une bannière existe pour une seule chose : demander à un visiteur si vous pouvez utiliser des cookies et des traceurs non essentiels, et enregistrer la réponse. Le marquage côté serveur porte sur le traitement des données que vous avez le droit de collecter. Il n'a rien à dire sur la question posée.

Le droit se lit de la même façon. La nécessité du consentement dépend de ce que vous collectez et des régions où se trouvent vos visiteurs, pas du serveur sur lequel vos balises s'exécutent. Un visiteur de l'UE ou du Royaume-Uni a toujours droit à l'opt-in. Un Californien a toujours droit à l'opt-out. Déplacez toutes vos balises dans un conteneur hébergé dans votre propre cloud et l'obligation reste exactement là où elle était.

Le trajet que le signal doit parcourir

C'est la partie que les guides des fournisseurs passent sous silence. Ils vous disent que la plateforme de consentement transmet le signal à votre serveur, et s'arrêtent là, comme si c'était automatique. Ça ne l'est pas. La bannière définit l'état Consent Mode v2 dans le navigateur, et cet état doit voyager avec la requête que le navigateur envoie à votre conteneur. Dans une configuration Google, il circule sous la forme du paramètre gcs. Votre conteneur le lit et décide de ce que chaque balise peut faire.

Retenez le sens de circulation. Le choix est capté dans la page puis transmis au serveur. Le serveur peut le respecter, modéliser autour, enrichir ce qui est permis. Ce qu'il ne peut pas faire, c'est inventer un choix qui n'a jamais été exprimé. Pas de bannière, pas de signal, et un conteneur qui ne reçoit rien n'est pas conforme au seul motif qu'il est propriétaire. C'est un traceur qui n'a jamais demandé. Si vous ne savez pas quel mode votre site exécute réellement, nous avons expliqué comment le vérifier dans quel Consent Mode votre site exécute réellement, et le câblage lui-même, étape par étape, se trouve dans comment transmettre le signal de consentement à un conteneur de marquage côté serveur.

Là où ça casse en silence

Comme les requêtes côté serveur viennent de votre propre domaine, elles inspirent une confiance que les requêtes du navigateur n'inspirent pas. C'est exactement pour cela que les défauts sont ici faciles à manquer.

Le cas que nous voyons le plus souvent est un client GA4 dans le conteneur serveur, laissé libre de gérer ses propres cookies. Dans cette configuration, il appose un identifiant propriétaire sur chaque requête entrante, y compris les pings sans cookie envoyés précisément parce qu'un visiteur a refusé. Ces pings refusés cessent d'être anonymes et se mettent à compter comme de vraies sessions. Nous l'avons découvert lors d'une refonte du consentement en production, après des semaines de trafic Unassigned en hausse chez un client sans explication, et la façon dont cela inonde vos rapports fait l'objet d'un article à part : pourquoi votre trafic GA4 apparaît en Unassigned après l'ajout d'une bannière de cookies. Le correctif tenait à un seul réglage. La leçon, c'est que le marquage côté serveur n'a pas rendu le consentement plus sûr ici. Il a rendu la faille plus difficile à repérer.

Comment vérifier que votre installation respecte le consentement

1. Confirmez que la bannière se déclenche toujours en premier

   Côté serveur ou non, la valeur par défaut du Consent Mode doit être fixée sur denied avant l'exécution de la moindre balise Google, sur chaque page, y compris la première d'une visite. Si cette valeur par défaut arrive après la balise, le tout premier hit part dans un état que personne n'a choisi.

2. Refusez, puis observez la requête

   Dans une fenêtre de navigation privée, refusez tout et ouvrez le panneau réseau. Trouvez la requête qui part vers votre conteneur serveur. Le paramètre gcs indique l'état, et G100 signifie que les deux types de stockage sont refusés. C'est le signal sur lequel votre serveur va agir.

3. Vérifiez que le ping refusé reste anonyme

   Sur cette même requête refusée, cherchez un identifiant client. Un ping refusé qui porte un identifiant est le défaut du cookie géré par le serveur, et il va gonfler vos chiffres avec du trafic qu'on vous a demandé de laisser tranquille.

4. Confirmez que les balises publicitaires restent bloquées

   Avec le consentement refusé, les balises publicitaires de votre conteneur ne devraient transmettre aucune donnée identifiable. Si elles se déclenchent quand même, le conteneur lit la requête mais n'en fait pas une condition.

5. Testez en visiteur de retour

   Rechargez le site avec un refus déjà enregistré. Une installation qui respecte le premier choix lors d'une visite répétée, sans le remplacer en silence, c'est celle que vous voulez.

Ce que le passage côté serveur rapporte vraiment

Rien de tout cela n'est une raison d'éviter le marquage côté serveur. Bien fait, c'est l'un des leviers qui récupèrent la mesure qu'une bannière vous coûterait autrement. Sur les implémentations clients d'Amplio Data, nous constatons généralement environ 34% des sessions derrière la bannière, et 20 à 40% des conversions perdues récupérables une fois Consent Mode v2 et le marquage côté serveur câblés comme Google l'attend. Ces chiffres sont des fourchettes mesurées sur les implémentations clients d'Amplio Data, pas une garantie. La récupération dépend de votre mix de trafic, de vos régions et de la configuration de vos balises.

Disons-le clairement, parce que c'est là que le sujet s'embrouille : cette récupération vient de la modélisation et d'un signal plus propre, pas d'une collecte supérieure à ce que le visiteur a autorisé. Le marquage côté serveur gagne sa place en respectant mieux le choix, pas en le contournant. Pour le tableau d'ensemble de ce qui survit vraiment à un refus, nous l'avons traité dans ce qu'il advient de vos données GA4 quand les utilisateurs refusent les cookies.

La version courte

Le marquage côté serveur déplace vos balises du navigateur du visiteur vers un serveur que vous contrôlez. Il ne déplace pas le moment du consentement, qui reste sur la page, et il ne supprime pas l'obligation de demander, qui dépend de vos régions et de vos données. Vous avez toujours besoin de la bannière. Ce qui change, c'est qu'un serveur bien câblé offre à cette bannière un endroit plus propre pour être respectée, et qu'un serveur mal câblé lui offre un endroit plus propre pour être ignorée.

Velo capte le choix dans le navigateur et l'envoie dans la forme attendue par Google, pour que la partie serveur de votre stack agisse sur un signal réel plutôt que sur un signal absent. Le mécanisme est détaillé sur la page produit.

Vous découvrez le côté serveur ? L'équipe derrière Velo a écrit une réponse claire à ce qu'est le marquage côté serveur et si vous en avez vraiment besoin sur le blog d'Amplio Data.