Un conteneur serveur Google Tag Manager reçoit des requêtes, qu'un client interprète et transforme en événements. Des tags serveur peuvent ensuite filtrer, enrichir ou transmettre ces événements aux destinations autorisées.
Ce que le serveur permet de contrôler
La mise en place d'un conteneur GTM server-side ne justifie pas l'envoi de données supplémentaires. Elle crée un point de contrôle où l'on peut limiter les champs, appliquer des transformations et choisir les destinations.
Pour les conversions améliorées, plusieurs identifiants valides peuvent augmenter les chances de rapprochement. Cette efficacité technique doit rester compatible avec la finalité déclarée, la base juridique retenue et le principe de minimisation.
La bonne question est donc double : quels identifiants améliorent réellement la mesure, et lesquels l'entreprise est-elle autorisée à collecter et à transmettre dans ce contexte ?
Comment normaliser, hacher et transmettre les user data côté serveur ?
Deux circuits sont possibles. Vous pouvez transmettre des données non hachées au Google tag : Google les normalise et les hache avant qu'elles n'atteignent ses serveurs. Vous pouvez aussi les normaliser puis les préhacher en SHA-256 dans votre propre code. Le conteneur serveur traite ensuite l'événement et le transmet selon sa configuration.
Depuis avril 2026, Google Ads accepte simultanément les données fournies par les tags du site, Data Manager et les connexions API. Depuis juin 2026, les conversions améliorées pour le Web et pour les prospects partagent un réglage unifié. Le canal change, mais les exigences de format et de consentement restent.
- Normaliser si vous préhachez. Supprimez les espaces en début et fin, passez le texte en minuscules et formatez le téléphone en E.164. Pour Gmail et Googlemail, retirez aussi les points et le suffixe après
+dans la partie située avant@. - Hacher en SHA-256 hexadécimal. Cette opération est déterministe : la même chaîne normalisée doit produire la même empreinte. Si vous envoyez la donnée non hachée au Google tag, laissez le tag assurer cette étape.
- Transmettre le choix de consentement. Le signal
ad_user_datacontrôle l'autorisation d'envoyer des données utilisateur à Google. Le parcours de refus doit être testé autant que celui d'acceptation.
La normalisation est indispensable lorsque vous préhachez, car Google ne peut plus corriger une chaîne déjà transformée. Une empreinte valide sur le plan cryptographique peut donc rester impossible à rapprocher si l'e-mail ou le téléphone n'a pas été préparé selon les règles attendues.
Brancher les données utilisateur dans GTM server-side
L'implémentation repose sur une variable de données fournies par l'utilisateur dans le conteneur Web et sur le tag Google Ads User-provided Data Event dans le conteneur serveur. Le Google tag ou l'événement GA4 est routé vers l'URL du serveur de tagging, puis le client GA4 du conteneur interprète la requête.
Le point essentiel n'est pas le libellé d'une case dans Google Ads, mais la continuité du flux : collecte au bon moment, présence de la donnée dans l'événement, réception par le client serveur, déclenchement du tag Ads et respect du consentement.
Le branchement se fait en deux temps :
Côté conteneur Web GTM. Créez une variable User-Provided Data avec la méthode automatique, manuelle ou par code. Associez-la à l'événement envoyé vers le conteneur serveur et vérifiez sa présence en mode Preview.
Côté conteneur serveur GTM. Vérifiez que le client GA4 reçoit et transforme la requête, puis configurez le tag Google Ads User-provided Data Event avec le bon identifiant de conversion et le bon déclencheur. La variable peut contenir des données non hachées, que Google traite, ou des données déjà normalisées et hachées correctement.
Après validation, évitez de conserver en parallèle un ancien tag Web qui enverrait le même événement. Pour les fondamentaux, voir les tags, déclencheurs et variables GTM.
Quelle méthode de collecte choisir : automatique, CSS ou dataLayer ?
Avant que le conteneur serveur traite l'événement, les données doivent être disponibles côté Web. Les trois méthodes officielles diffèrent surtout par leur niveau de contrôle et leur maintenance.
| Méthode | Fonctionnement | Sensibilité aux refontes | Recommandation |
|---|---|---|---|
| Automatique | Google détecte les chaînes qui correspondent aux types de données configurés | Dépend de la page et des exclusions configurées | Simple et adaptée à de nombreux sites, à vérifier sur chaque parcours |
| Sélecteurs CSS / variables JS | Sélection manuelle de champs DOM par id ou classe | Élevée si les sélecteurs ou variables changent | Utile pour cibler précisément les champs lorsque le DOM est maîtrisé |
| Configuration par code | Le site fournit un objet structuré, directement ou via le dataLayer |
Faible si le contrat de données est versionné, mais le code peut aussi régresser | Le meilleur contrôle sur le moment, le format et les tests |
Un sélecteur CSS peut cesser de trouver le champ après une refonte. Le mode Preview de GTM et les diagnostics Google Ads permettent de détecter le problème, mais une alerte n'arrive pas nécessairement au moment exact de la régression.
Une configuration par code découple mieux la collecte du DOM, à condition que le schéma soit documenté et testé. Le dataLayer n'est pas une garantie en soi : un renommage de clé, un changement d'ordre ou la suppression du push peut également interrompre le flux.
Quels formats envoyer ?
Format E.164 pour le téléphone
Google attend le signe +, l'indicatif pays et le numéro national sans espace, tiret ni parenthèse. Sa documentation d'implémentation indique une longueur de 11 à 15 chiffres pour ce champ.
Exemples pour un numéro français :
+33612345678: format attendu0612345678: indicatif pays absent06 12 34 56 78: indicatif absent et espaces présents+33 6 12 34 56 78: espaces à retirer
Un numéro français saisi sous la forme 06XXXXXXXX doit être converti en retirant le zéro national et en ajoutant +33. Faites cette conversion avant un éventuel préhachage et testez aussi les numéros déjà saisis avec leur indicatif.
Quand ajouter l'adresse ?
L'adresse constitue une clé de rapprochement supplémentaire. Google recommande d'envoyer les identifiants pertinents disponibles, car plusieurs clés peuvent augmenter la probabilité de correspondance. Cela ne dispense pas de vérifier la finalité, la base juridique et la minimisation : n'ajoutez pas un champ au formulaire uniquement pour la publicité sans validation préalable.
| Champ | Format requis | Statut | Note |
|---|---|---|---|
email |
Minuscules, espaces purgés | Prioritaire | Clé de rapprochement courante |
phone |
E.164 (+33XXXXXXXXX) |
Complémentaire | Voir section ci-dessus |
first_name |
Minuscules, espaces purgés | Conditionnel | Requis si on envoie l'adresse |
last_name |
Minuscules, espaces purgés | Conditionnel | Requis si on envoie l'adresse |
postal_code |
Tel quel (ex. 75001) |
Conditionnel | Requis si on envoie l'adresse |
country |
Code ISO 2 lettres (ex. FR) |
Conditionnel | Requis si on envoie l'adresse |
street |
Minuscules, espaces purgés | Optionnel | À envoyer seulement avec un bloc adresse conforme au schéma |
Pour que l'adresse serve de clé, Google attend au minimum le prénom, le nom, le pays et le code postal. Le nom et la rue sont hachés lorsqu'ils sont transmis via une API, tandis que le pays, la ville, la région et le code postal ne le sont pas. Vérifiez le schéma propre à votre méthode d'envoi.
Si le rapprochement reste faible, commencez par contrôler la couverture, le format et le consentement. Ajoutez ensuite une clé disponible et autorisée si elle apporte une information distincte ; ne collectez pas davantage de données par réflexe.
Comment lire le rapport Diagnostics pour vérifier que vos user data fonctionnent ?
Le rapport Diagnostics distingue les problèmes de collecte, de format et de rapprochement. Son interprétation dépend de la méthode d'envoi et du volume disponible.
Deux métriques à surveiller :
Taux de couverture. Il indique la part des événements éligibles qui contiennent suffisamment de données utilisateur. Une couverture faible invite à vérifier les pages concernées, le déclenchement, la disponibilité des champs et le consentement.
Taux de correspondance. Il indique dans quelle mesure les données transmises correspondent à celles de comptes Google connectés. Un taux faible peut venir d'un format incorrect, mais aussi de clients qui n'ont pas de compte Google ou qui utilisent d'autres coordonnées. Il ne mesure donc pas la normalisation à lui seul, et Google ne publie pas de seuil à partir duquel Smart Bidding « dériverait ».
Alertes de format. Le rapport peut signaler un e-mail incorrect, un téléphone non reconnu ou un bloc adresse incomplet. Remontez alors jusqu'à la valeur source et contrôlez sa transformation. Une alerte absente ne prouve pas que tous les visiteurs sont rapprochables.
Utilisez aussi Preview et Tag Assistant pour vérifier la présence de l'objet de données utilisateur et le déclenchement du tag. Si le format est correct mais que la couverture baisse, examinez le formulaire, le code de collecte et le paramétrage du Consent Mode avant de conclure à un problème de plateforme.
Quand le taux de correspondance reste structurellement faible malgré une normalisation correcte, la question qui suit souvent est celle des écarts entre Ads et GA4, voir Écarts conversions Ads vs GA4 pour le diagnostic structurel.
Pourquoi le hachage seul ne suffit pas : consentement et liste blanche
Le signal ad_user_data indique si des données utilisateur liées à la publicité peuvent être envoyées à Google. Dans les régions et situations concernées, un refus doit empêcher cet envoi. Le conteneur serveur centralise le contrôle, mais ne crée pas la base juridique ; celle-ci doit être validée selon votre contexte.
SHA-256 n'anonymise pas la donnée. Il crée un identifiant pseudonymisé et déterministe, précisément conçu pour être comparé à une autre empreinte. C'est HTTPS qui protège la transmission sur le réseau ; le hachage réduit l'exposition de l'identifiant en clair.
Une donnée non autorisée ne devient pas licite après hachage. Définissez donc les champs et les destinations dans une liste validée, puis contrôlez le comportement en cas de refus.
Les conversions améliorées et la modélisation des conversions sont complémentaires. Une conversion non rapprochée par les données utilisateur n'est pas automatiquement reconstituée : la modélisation dépend de ses propres conditions d'éligibilité et des signaux disponibles.
- Si vous préhachez, normalisez d'abord selon le champ : casse et espaces, E.164 pour le téléphone, règles Gmail spécifiques pour l'e-mail.
- Vous pouvez aussi envoyer la donnée non hachée au Google tag, qui la normalise et la hache avant les serveurs Google.
- HTTPS protège le transport ; SHA-256 pseudonymise l'identifiant sans l'anonymiser.
- Le signal
ad_user_dataet la politique de collecte doivent être vérifiés sur les parcours d'acceptation et de refus.
Le choix à faire
Documentez quatre éléments : les champs et destinations autorisés, la méthode de collecte, les règles de normalisation et le comportement attendu pour chaque état de consentement. Testez ensuite des cas réels dans Preview, Tag Assistant et les diagnostics Google Ads.
Si le rapprochement reste faible, séparez couverture, erreurs de format et capacité réelle de correspondance avec un compte Google. Cette analyse s'inscrit dans l'ensemble du dispositif de mesure Google Ads.
Questions fréquentes
Quelles données utilisent les conversions améliorées ?
Faut-il toujours hacher les données soi-même ?
Le hachage anonymise-t-il les données ?
Que vérifier si le taux de rapprochement reste faible ?
Faut-il transmettre l'adresse en plus de l'e-mail et du téléphone ?
Quel signal de consentement concerne ces données ?
ad_user_data contrôle l'envoi de données utilisateur liées à la publicité à Google. Le parcours de refus doit être testé afin de vérifier que le flux respecte bien ce choix dans les situations concernées.