Balisage côté serveur

Le balisage côté serveur déplace l'exécution de vos balises du navigateur de l'utilisateur vers un serveur que vous contrôlez. Au lieu que la page envoie directement des pixels à Google et Meta, elle envoie une seule requête à votre propre point d'accès de balisage.

Ce serveur décide ensuite quelles données transmettre, à qui et sous quelle forme. Le navigateur ne communique qu'avec votre domaine de première partie.

Dans le modèle classique, chaque pixel d'un fournisseur s'exécute dans le navigateur et envoie sa propre requête à un tiers. Avec le balisage côté serveur, le navigateur envoie un seul événement à un serveur de balisage, qui le distribue à plusieurs destinations.

Vous contrôlez ainsi les données, réduisez les requêtes bloquées et diminuez la quantité de code côté navigateur qui ralentit les pages.

Google Tag Manager côté serveur de Google (sGTM) est l'implémentation la plus courante. Il s'agit d'un conteneur qui s'exécute sur Cloud Run, App Engine ou n'importe quel hôte, reçoit les requêtes et les traite au moyen de composants clients et de balises.

Un « client » analyse les requêtes entrantes pour les transformer en événements ; les balises transmettent ensuite ces événements à leurs destinations. C'est GTM, mais exécuté sur le serveur plutôt que sur la page.

Le principal gain de fiabilité vient de l'association du serveur de balisage à un sous-domaine de votre propre site, comme sgtm.example.com, au moyen d'un enregistrement DNS A ou CNAME.

Les requêtes étant désormais envoyées à votre domaine, les cookies définis dans la réponse sont des cookies de première partie et HttpOnly. Ils échappent aux limitations les plus strictes d'ITP et sont beaucoup moins susceptibles d'être bloqués par les bloqueurs de publicités.

Un achat a lieu sur la page. Le conteneur Web (ou gtag) envoie un événement à sgtm.example.com. Le composant client GA4 qui s'y trouve reconstitue l'appel, l'enrichit, puis une balise GA4 le transmet au point d'accès de collecte de Google.

Le même événement peut simultanément déclencher une balise de l'API Conversions de Meta, une conversion Google Ads côté serveur et bien d'autres actions, le tout à partir d'une seule requête entrante.

L'API Conversions de Meta, les conversions améliorées de Google et l'API Events de TikTok sont toutes des points d'accès de serveur à serveur. Elles acceptent directement les événements provenant de votre serveur et contournent entièrement le pixel du navigateur.

Cela permet de récupérer les conversions perdues à cause des bloqueurs de publicités et d'ITP, et d'envoyer des identifiants de première partie hachés (adresse e-mail, numéro de téléphone) pour améliorer la correspondance, à condition d'avoir obtenu le consentement.

Comme le serveur voit l'événement brut, vous pouvez l'enrichir : ajouter la valeur réelle de la commande provenant de votre base de données, supprimer les PII que vous ne souhaitez pas partager, ajouter des horodatages côté serveur ou dédupliquer les événements par rapport à ceux du navigateur.

Vous devenez le responsable de la sélection de vos propres données et n'envoyez à chaque plateforme que les champs minimaux dont elle a besoin. C'est la minimisation des données en pratique, et pas seulement sur le papier.

Si vous exécutez à la fois un pixel du navigateur et un événement serveur pour la même conversion, les plateformes ne doivent pas la comptabiliser deux fois. La déduplication utilise un identifiant partagé.

Envoyez le même event_id (et le même event_name) depuis le pixel client et l'appel CAPI côté serveur. Meta et les autres plateformes les font correspondre et n'en conservent qu'un seul, ce qui vous apporte une redondance sans gonflement des résultats.

Le serveur de balisage constitue une véritable infrastructure. Sur Google Cloud Run, il adapte automatiquement sa capacité au trafic ; vous payez les ressources de calcul et la sortie de données. Un petit site peut fonctionner avec quelques instances, tandis qu'un grand site peut en nécessiter beaucoup.

Prévoyez le suivi, un serveur de prévisualisation pour le débogage et une bonne disponibilité, car si votre serveur de balisage tombe en panne, la mesure s'arrête également. Il s'agit désormais d'un service de production, et non d'un simple extrait de code.

Le balisage côté serveur ne permet pas de contourner le consentement. Vous avez toujours besoin d'une base légale, et l'envoi de données sans consentement est illégal, quel que soit l'endroit où il est exécuté.

Il ne rétablit pas non plus comme par magie le suivi intersites déterministe. Il améliore la fiabilité et la correspondance pour les données de première partie recueillies avec consentement ; il s'agit d'une couche de résilience, et non d'une faille.

Un déploiement réel suit une séquence : mettre le serveur en place, associer le sous-domaine, y relier le conteneur Web, configurer les composants clients et les balises, puis connecter les destinations CAPI.

Validez le fonctionnement à l'aide de la vue de prévisualisation et de débogage, confirmez que la déduplication fonctionne, vérifiez le filtrage selon le consentement, puis seulement ensuite basculez le trafic. Traitez cette opération comme le déploiement de n'importe quel service dorsal.

Vérifiez votre maîtrise du balisage côté serveur.

Le balisage côté serveur achemine les événements du navigateur vers un serveur de balisage situé sur votre propre sous-domaine. Celui-ci définit des cookies de première partie et transmet les données recueillies avec consentement aux plateformes au moyen d'API de serveur à serveur comme CAPI de Meta.

Avantages : moins de requêtes bloquées, des cookies plus compatibles avec ITP, l'enrichissement et la minimisation des données, ainsi que la déduplication des événements. Il s'agit d'une couche de fiabilité et de contrôle, d'une véritable infrastructure à exploiter, et jamais d'un substitut au consentement.