Dans le dispositif de mesure Google Ads, un conteneur Google Tag Manager (GTM) côté serveur reçoit des requêtes. Un client GTM, composant logiciel et non client commercial, revendique les requêtes compatibles et les transforme en événements. Les balises côté serveur peuvent ensuite filtrer, normaliser ou transmettre uniquement les champs prévus vers les destinations autorisées.
Ce que le serveur permet de contrôler
Le traitement côté serveur facilite le contrôle du flux ; il ne remplace ni le consentement lorsqu'il est requis, ni les politiques Google, ni la minimisation.
La mise en place d'un conteneur GTM côté serveur ne justifie aucune collecte supplémentaire. Cette étape crée un point de contrôle où le comportement des balises peut être vérifié : suppression des champs non autorisés, transformations documentées et choix des destinations. Tout ajout de données doit avoir une finalité définie et rester hors des URL, des journaux ou des outils qui ne sont pas autorisés à les recevoir.
Plusieurs identifiants correctement formatés, disponibles et autorisés peuvent augmenter la probabilité de correspondance des conversions améliorées, sans garantir un rapprochement ni une hausse mesurable des résultats publicitaires. L'efficacité technique reste subordonnée à la minimisation, aux lois applicables, aux politiques Google sur les données client et à l'information des utilisateurs.
Avant de configurer la transmission, vérifiez que les conditions relatives aux données client ont été acceptées dans le compte Google Ads. Faites valider la finalité, les données, la durée, les destinataires et le consentement lorsqu'il est requis par votre délégué à la protection des données ou votre conseil juridique. Le paramètre technique transmis à Google ne constitue pas cette validation.
Comment normaliser, hacher et transmettre les données côté serveur ?
Deux circuits sont admis pour les données de conversion fournies. Le premier transmet la donnée non hachée à la balise Google, qui la normalise puis la hache avant son arrivée sur les serveurs Google. Le second confie à votre code la normalisation et le préhachage en SHA-256 hexadécimal. Ne mélangez pas leurs paramètres : les noms de champs diffèrent selon que la valeur est en clair ou déjà hachée.
Depuis avril 2026, Google Ads peut recevoir simultanément les données issues des balises du site, du Gestionnaire de données et des connexions API. Depuis juin 2026, les conversions améliorées pour le Web et pour les prospects partagent un réglage unifié. Cette évolution ne change ni les formats attendus, ni les obligations de consentement, ni la nécessité d'accepter les conditions relatives aux données client avant traitement.
- Appliquer le consentement avant la mesure. Définissez l'état par défaut du mode de consentement avant toute commande de mesure. Après le choix de l'utilisateur, envoyez la mise à jour sur la même page, avant une éventuelle navigation.
- Normaliser si votre code préhache. Retirez les espaces en début et fin, passez l'e-mail en minuscules et convertissez le téléphone au format E.164. Pour Gmail et Googlemail seulement, retirez aussi les points et le suffixe placé après
+avant@. Ne modifiez pas ainsi les autres domaines. - Produire l'empreinte attendue. Hachez la chaîne normalisée avec SHA-256 et transmettez sa représentation hexadécimale. Si la balise Google reçoit la donnée non hachée, laissez-la assurer elle-même la normalisation et le hachage.
- Limiter puis transmettre. N'envoyez que les types de données de première partie autorisés, au moment de l'événement prévu et vers la destination approuvée. Le signal
ad_user_datadoit refléter le choix obtenu.
Google ne peut pas corriger une chaîne déjà hachée. Une empreinte parfaitement valide peut donc rester sans correspondance si sa valeur source a été mal préparée. À chaque étape, le contrôle doit porter sur la chaîne juste avant le hachage, sur l'objet transmis et sur le nom de champ utilisé.
Configurer les données utilisateur dans GTM côté serveur
Le flux réunit un conteneur Web, un conteneur serveur, le client Google Analytics 4 qui revendique la requête compatible et une balise Google Ads côté serveur. Pour configurer cette transmission, il faut disposer des droits d'administration Google Ads et Google Tag Manager, d'un conteneur Web opérationnel et d'un conteneur serveur déjà relié au site.
- Poser le Conversion Linker côté serveur. Créez une balise Conversion Linker dans le conteneur serveur et déclenchez-la sur les événements concernés, généralement sur toutes les pages. Vérifiez son déclenchement avant de passer à l'étape suivante.
- Créer la balise Google Ads. Ajoutez la balise Google Ads User-provided Data Event, renseignez l'identifiant de conversion et créez un déclencheur d'événement personnalisé. Son nom, visible dans le paramètre
event_name, doit être exactement celui de l'événement Google Analytics 4 envoyé depuis le conteneur Web. - Créer la variable côté Web. Dans le conteneur Web, ajoutez une variable User-Provided Data et choisissez la collecte automatique, la configuration manuelle ou la configuration par code.
- Relier la variable à la balise Google. Dans les paramètres de configuration de la balise Google, ajoutez le paramètre
user_dataet affectez-lui la variable créée. Envoyez l'événement Google Analytics 4 vers l'URL du conteneur serveur. - Valider de bout en bout. Dans l'aperçu du conteneur Web, vérifiez la disponibilité de la variable au bon événement. Dans l'aperçu du conteneur serveur, contrôlez le client qui revendique la requête, la rubrique Tags et les erreurs de la console.
Publiez uniquement lorsque l'événement attendu déclenche une seule fois la bonne balise avec le bon identifiant de conversion, et que le comportement observé en cas de refus bloque les données utilisateur concernées. Contrôlez aussi le Conversion Linker dans l'aperçu serveur. Après validation, retirez l'ancienne balise Web équivalente si elle envoyait le même événement ; la conserver créerait un risque de double envoi.
Quelle méthode choisir : automatique, manuelle ou par code ?
Les trois méthodes officielles produisent la même finalité, mais pas le même niveau de contrôle. Le bon mode dépend du formulaire, de sa stabilité et de la capacité de l'équipe à tester le contrat de données.
| Méthode | Fonctionnement | Risque principal | Quand la retenir |
|---|---|---|---|
| Automatique | La balise détecte dans le navigateur les chaînes correspondant aux types de données activés. | Une page ou un élément non prévu peut être lu si les exclusions sont incomplètes. | Formulaire simple, parcours testés et pages sensibles explicitement exclues. |
| Manuelle | Chaque champ est relié à un sélecteur CSS ou à une variable JavaScript. | Le sélecteur casse après une modification du DOM. | Champs clairement identifiés ; préférez un identifiant stable à une classe de présentation. |
| Par code | Le site fournit un objet structuré, directement ou via le dataLayer. | L'objet arrive trop tard, sous un autre nom d'événement ou avec un champ vide. | Contrat de données versionné, tests automatisés et maîtrise du code du formulaire. |
En configuration manuelle, testez les sélecteurs après chaque refonte. En configuration par code, le push doit précéder l'événement qui lit user_data : le dataLayer ne rend pas asynchrone une donnée arrivée trop tard. Vérifiez le nom de l'événement, les clés attendues et le comportement lorsque chaque champ est vide.
Quelle que soit la méthode, ne placez jamais un e-mail, un téléphone ou une adresse dans une URL du navigateur. Évitez également leur copie dans les journaux, outils de débogage persistants ou destinations qui ne figurent pas dans la liste autorisée.
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. Le téléphone peut être transmis seul, mais Google recommande de l'associer à l'e-mail lorsqu'il est disponible et autorisé.
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
Pour convertir 06XXXXXXXX, retirez le zéro national et ajoutez +33. Faites cette opération avant un éventuel préhachage. Ne réappliquez pas la transformation à un numéro qui possède déjà son indicatif.
Quand ajouter l'adresse ?
L'adresse peut fournir une clé de rapprochement supplémentaire. Elle n'est pertinente que si l'entreprise la recueille déjà directement, si sa finalité publicitaire est autorisée et si son schéma est complet. Ne créez pas un champ de formulaire uniquement pour augmenter un indicateur de correspondance.
| Donnée | Valeur non hachée | Valeur préhachée | Condition |
|---|---|---|---|
email | sha256_email_address | Au moins un e-mail ou un téléphone pour la configuration par code côté serveur. | |
| Téléphone | phone_number | sha256_phone_number | Format E.164 avant préhachage. |
| Prénom | address.first_name | address.sha256_first_name | Requis avec nom, pays et code postal pour utiliser l'adresse. |
| Nom | address.last_name | address.sha256_last_name | Requis pour le bloc adresse. |
| Code postal | address.postal_code | Non haché | Requis pour le bloc adresse. |
| Pays | address.country | Non haché | Code pays à deux lettres, par exemple FR. |
| Rue | address.street | address.sha256_street | Optionnelle, dans un bloc adresse conforme. |
| Ville et région | address.city, address.region | Non hachées | Optionnelles selon les données déjà disponibles. |
Les noms de clés ci-dessus distinguent explicitement la donnée en clair de l'empreinte. Pour que l'adresse soit exploitable, Google Ads demande au minimum le prénom, le nom, le pays et le code postal. Vérifiez toujours le schéma et les paramètres propres à la méthode retenue : une structure valide pour une connexion API ne doit pas être copiée à l'aveugle dans une variable GTM.
N'utilisez que des données de première partie fournies directement dans la relation avec l'entreprise. Les politiques Google interdisent notamment les données dont vous savez qu'elles concernent des personnes de moins de 13 ans ou un service destiné aux enfants, ainsi que les conversions liées à des catégories sensibles. La conformité de la collecte précède toute recherche d'un meilleur taux.
Comment lire le rapport de diagnostic ?
Au 26 juillet 2026, le diagnostic des conversions améliorées combine des alertes techniques et un tableau d'impact. Les alertes utilisent en priorité les données du dernier jour, puis une fenêtre de sept jours si le volume est insuffisant. Google peut ne pas en afficher lorsque l'action totalise moins de 20 conversions sur sept jours : l'absence d'alerte ne vaut donc pas validation.
Couverture. Google Ads divise le nombre d'événements de conversion contenant le paramètre de données utilisateur par le nombre total d'événements de conversion. La vue porte par défaut sur sept jours et peut être étendue à trente jours. Une baisse invite à examiner les pages, le déclencheur, les champs disponibles et le choix des utilisateurs.
Taux de correspondance. Le tableau indique la part des données valides rapprochées de comptes Google. Google Ads actualise cette valeur sous 24 heures et affiche les états Inconnu pour certaines contraintes de confidentialité, Données insuffisantes sous 20 envois valides d'informations personnelles, Aucune correspondance, Faible de 0 à 15 % et Élevé au-delà de 15 %. Cette mesure dépend aussi des coordonnées réellement utilisées par les utilisateurs ; elle ne prouve ni la qualité des annonces, ni la normalisation à elle seule.
Impact sur les conversions. Le tableau peut estimer une hausse liée aux conversions améliorées, mais cette donnée peut demander jusqu'à trente jours d'apprentissage avant d'apparaître. Elle ne garantit ni le volume futur ni la performance des enchères.
Pour une anomalie de format, revenez à la valeur source et à sa transformation. Pour une anomalie de déclenchement, ouvrez le mode Aperçu de Google Tag Manager : contrôlez l'événement côté Web, puis le client, la rubrique Tags et la console côté serveur. Attendez ensuite les délais d'actualisation de Google Ads avant de conclure que la correction n'a pas fonctionné.
Pourquoi le hachage seul ne suffit pas : consentement et liste blanche
ad_user_data transmet un état technique de consentement pour l'envoi de données utilisateur liées à la publicité. Il ne constitue ni la preuve du choix recueilli, ni l'analyse juridique qui justifie le traitement. Lorsque cet état est refusé, le comportement attendu exclut les informations personnelles destinées aux conversions améliorées.
En mode de consentement avancé, un refus de ad_user_data n'implique pas nécessairement l'absence de toute requête : des signaux de mesure sans cookie peuvent encore partir selon les autres états de consentement. Ce flux ne doit pas contenir les données utilisateur traitées dans cette page. Définissez l'état par défaut avant les commandes de mesure, puis envoyez la mise à jour sur la page où le choix intervient.
SHA-256 ne rend pas la donnée anonyme. L'empreinte reste un identifiant pseudonymisé et comparable, donc une donnée personnelle dans ce contexte. HTTPS protège le transport ; le hachage limite l'exposition de la valeur en clair, sans rendre licite une collecte qui ne l'était pas.
La liste blanche doit nommer les champs, leurs sources, la finalité, les destinataires, le responsable et la durée de conservation. Vérifiez l'acceptation des conditions relatives aux données client, l'information des personnes, le consentement lorsqu'il est requis et l'exclusion des catégories sensibles ou des mineurs. Les paramètres publicitaires du compte n'annulent aucune de ces exigences. La modélisation des conversions reste un mécanisme distinct : elle ne transforme pas automatiquement une conversion non rapprochée en conversion observée.
Sources officielles vérifiées le 26 juillet 2026 : Google documente la configuration des données utilisateur dans GTM côté serveur, la normalisation avant hachage, le diagnostic des conversions améliorées, le comportement du mode Consentement, les évolutions du réglage en 2026 et les règles relatives aux données client.
- Choisissez une seule route par champ : donnée non hachée confiée à la balise Google ou valeur normalisée puis préhachée par votre code.
- Reliez la variable à
user_data, faites correspondre exactement le nom de l'événement Web et celui du déclencheur serveur, puis contrôlez Tags et la console. - Les règles Gmail ne s'appliquent pas aux autres domaines ; le téléphone doit être au format E.164 avant préhachage.
- Le consentement, la minimisation et les politiques Google s'appliquent encore après hachage.
La recette avant publication
Figez d'abord le contrat de données : champs autorisés, format en clair ou haché, source, événement, destination et état de consentement requis. Testez ensuite chaque étape avec une acceptation, un refus, un champ vide, un e-mail Gmail, un e-mail d'un autre domaine et un téléphone français dans les deux aperçus GTM.
Publiez lorsque la bonne balise se déclenche une fois, que les données interdites sont absentes et que la console ne remonte plus d'erreur. Contrôlez enfin dans Google Ads la couverture et le taux de correspondance après leur délai d'actualisation, sans ajouter un champ uniquement pour atteindre un seuil.
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 correspondance 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 indique si les données utilisateur liées à la publicité peuvent être envoyées à Google. C'est un état technique, pas une preuve juridique. Testez l'état par défaut, la mise à jour après le choix et l'absence de ces données en cas de refus.