Le server-side tagging est une méthode technique où un serveur cloud dédié agit comme intermédiaire entre votre site web et des plateformes marketing comme Google et Meta. Au lieu que le navigateur du visiteur envoie des données directement à des scripts tiers, votre site web envoie un flux unique de données vers votre propre conteneur Google Tag Manager (sGTM) côté serveur. Ce serveur traite, filtre et distribue ensuite ces données vers les points de terminaison requis, ce qui améliore considérablement les performances du site et la précision des données à une époque de contrôles stricts de la confidentialité.
Pourquoi le passage au server-side tagging se produit-il maintenant ?
La méthode traditionnelle de suivi, appelée client-side tagging, repose fortement sur le navigateur de l’utilisateur pour exécuter JavaScript et gérer les cookies. Cependant, cette méthode fait face à des défis croissants. L’Intelligent Tracking Prevention (ITP) dans Safari et des fonctionnalités similaires dans d’autres navigateurs limitent souvent la durée de vie des cookies tiers à 24 heures ou les bloquent complètement. Cela rend difficile pour une entreprise d’attribuer une conversion qui se produit deux jours après un clic.
Les bloqueurs de publicités ciblent également des scripts spécifiques de Google ou Meta. Lorsqu’un navigateur bloque ces scripts, les données n’atteignent jamais vos comptes marketing. Dans un compte typique, nous voyons une divergence entre les ventes backend et les rapports de la plateforme publicitaire en raison de ces interruptions au niveau du navigateur. Déplacer la logique vers un serveur que vous contrôlez vous permet d’utiliser des cookies propriétaires (first-party) définis depuis votre propre domaine, comme metrics.example.com. Ces cookies sont plus durables et moins susceptibles d’être restreints par les mises à jour du navigateur.
Comment le server-side tagging améliore-t-il les performances de Google Ads ?
Google Ads s’appuie sur des signaux de haute qualité pour optimiser les stratégies d’enchères. Si l’algorithme ne voit que 70 % de vos conversions réelles, il ne peut pas dépenser votre budget efficacement. En utilisant sGTM, vous pouvez implémenter les conversions améliorées (Enhanced Conversions) de manière plus fiable. Les conversions améliorées envoient des données utilisateur hachées, comme des adresses e-mail ou des numéros de téléphone, à Google, permettant au système de faire correspondre les conversions même lorsqu’un cookie est manquant.
Lorsque vous traitez ces données sur le serveur, vous avez un meilleur contrôle sur la confidentialité. Vous pouvez supprimer les informations sensibles avant qu’elles ne quittent votre environnement. Cette configuration prend également en charge le Consent Mode v2, qui est une exigence pour les annonceurs dans l’Espace économique européen (EEE). Le Consent Mode v2 garantit que votre serveur n’envoie des données à Google que si l’utilisateur a donné son consentement approprié, maintenant la conformité tout en récupérant des données pour les utilisateurs n’ayant pas donné leur consentement via la modélisation.
Quel est l’avantage de la Meta Conversions API (CAPI) ?
La Meta Conversions API, ou CAPI, est l’équivalent côté serveur du Meta Pixel. Elle crée une connexion directe entre votre serveur et les serveurs de Meta. Un avantage majeur ici est le score de qualité de correspondance des événements (EMQ). Lorsque vous envoyez des événements comme ‘Purchase’ ou ‘Lead’ via CAPI, vous pouvez inclure des paramètres supplémentaires côté serveur que le navigateur pourrait manquer, tels que l’adresse IP de l’utilisateur, l’ID du navigateur et les informations de contact hachées.
Un modèle courant consiste à utiliser une configuration redondante où le Pixel et CAPI envoient le même événement. Pour éviter le double comptage, vous devez envoyer un ‘event_id’ unique depuis les deux sources. Meta utilise ensuite cet ID pour dédupliquer les événements. Si l’événement du navigateur est bloqué par un bloqueur de publicités, l’événement du serveur atteint toujours Meta. Cela garantit que vos audiences de retargeting et lookalike restent alimentées avec des données précises.
Composants clés d’une configuration de server-side tagging
La mise en place de cette infrastructure nécessite trois éléments principaux travaillant ensemble. Si l’un d’eux est mal configuré, le flux de données sera interrompu, entraînant des rapports vides dans vos panneaux publicitaires.
- Google Tag Manager Web Container : Il s’agit du conteneur standard qui se trouve sur votre site web et écoute les actions de l’utilisateur telles que les clics ou les soumissions de formulaires.
- Google Tag Manager Server Container : Un type de conteneur distinct dans GTM conçu pour recevoir des données du conteneur web et les envoyer vers des API externes.
- Tagging Server : Un environnement cloud, généralement Google Cloud Platform (GCP), qui héberge le conteneur serveur. Bien que d’autres fournisseurs existent, GCP est la norme pour sGTM.
- Custom Subdomain : Une URL comme gtm.yourdomain.com qui pointe vers votre serveur de marquage, permettant le contexte des cookies propriétaires.
Comparaison du suivi client-side et server-side
Pour comprendre pourquoi l’approche côté serveur gagne du terrain, il est utile de comparer les deux méthodes selon différentes mesures de performance et de confidentialité.
- Data Privacy : Le client-side expose toutes les données au navigateur ; le server-side vous permet de filtrer les données avant de les envoyer à des tiers.
- Page Speed : Le client-side nécessite le chargement de plusieurs scripts lourds ; le server-side réduit la charge du navigateur en envoyant un flux unique vers votre serveur.
- Cookie Lifespan : Les cookies client-side sont souvent limités par l’ITP ; les cookies propriétaires server-side peuvent durer beaucoup plus longtemps.
- Accuracy : Le client-side est vulnérable aux bloqueurs de publicités ; le server-side est beaucoup plus difficile à bloquer car il utilise votre propre domaine.
Comment implémenter le Consent Mode v2 dans l’EEE ?
Pour les entreprises opérant dans l’EEE, le Consent Mode v2 n’est plus facultatif pour Google Ads. Dans un environnement côté serveur, le conteneur web capture le choix de consentement de l’utilisateur via une plateforme de gestion du consentement (CMP). Ce statut est ensuite transmis au conteneur serveur en tant que paramètre (par exemple, ‘ad_user_data=granted’).
Le conteneur serveur doit être configuré pour respecter ces indicateurs. Si un utilisateur refuse le consentement, le serveur peut soit bloquer le déclenchement de la balise, soit envoyer un ‘ping sans cookie’ selon les capacités de la plateforme. Cette architecture garantit que vous ne traitez pas de données personnelles sans base légale, ce qui est une exigence fondamentale du RGPD. Elle fournit une couche technique de protection plus facile à auditer que des dizaines de balises de navigateur distinctes.
Pièges courants dans l’implémentation côté serveur
Une erreur fréquente est d’ignorer le coût de l’infrastructure cloud. Une configuration Google Cloud standard pour sGTM nécessite généralement au moins trois instances pour une haute disponibilité, ce qui peut coûter entre 30 et 50 dollars par mois. Pour une petite boutique Shopify dépensant 500 dollars par mois en publicités, cela peut ne pas être nécessaire, mais pour une boutique dépensant 5 000 dollars, la récupération des données justifie souvent le coût.
Un autre problème est la déduplication incorrecte pour Meta CAPI. Si vous oubliez d’inclure l”event_id’ dans vos balises serveur, Meta comptera chaque achat deux fois : une fois depuis le navigateur et une fois depuis le serveur. Cela gonflera votre ROAS (retour sur les dépenses publicitaires) et conduira à de mauvaises décisions d’allocation budgétaire. Vérifiez toujours le gestionnaire d’événements dans Meta pour vous assurer que les clés de déduplication sont correctement mises en correspondance.
Par où commencer cette semaine
La transition vers le server-side tagging ne doit pas se faire en une seule fois. Vous pouvez commencer par une approche hybride pour minimiser les risques et gérer les coûts tout en validant la qualité des données.
- Auditez votre suivi actuel : Vérifiez la différence entre vos chiffres de vente internes et vos conversions Google Ads.
- Créez un conteneur serveur : Dans Google Tag Manager, cliquez sur ‘Admin’, puis sur ‘Créer un conteneur’ et sélectionnez ‘Serveur’.
- Configurez un environnement de test : Utilisez l’option ‘Serveur de marquage provisionné automatiquement’ dans GTM pour un démarrage rapide sur le niveau gratuit de Google Cloud.
- Configurez un événement à haute valeur : Commencez par l’événement ‘Purchase’ pour Meta CAPI pour voir comment il affecte votre score de qualité de correspondance des événements.
- Vérifiez votre domaine personnalisé : Configurez un enregistrement DNS pour votre sous-domaine afin de vous assurer que vous définissez des cookies propriétaires.
En suivant ces étapes, vous construirez une infrastructure de données plus résiliente, moins dépendante des caprices du navigateur et plus alignée sur les normes modernes de confidentialité. De meilleures données conduisent à de meilleurs résultats d’apprentissage automatique dans Google et Meta, ce qui réduit finalement votre coût par acquisition.
Continuer la lecture : Planification stratégique · Marketing numérique