Une bonne intégration des balises est un élément essentiel pour maintenir des données propres et collecter des informations utiles au business. Actuellement , la plupart du tracking se fait côté client en déployant des balises sur le site Web lui-même (via Google Tag Manager (GTM) ou la mise en œuvre manuelle de la balise globale de site de Google), mais une nouvelle option s’impose : le balisage côté serveur (sGTM). sGTM reprend les concepts de Google Tag Manager du côté client et les applique directement au serveur, permettant aux clients d’exécuter un conteneur Tag Manager dans le nuage. Bien que l’utilisation de sGTM présente de nombreux avantages, de nombreuses exigences et considérations doivent être prises en compte avant de passer à une configuration sGTM adequate. Cet article est fortement inspiré de l’excellent Blog sur la web analyse d’adswerve.com qui édite d’ailleurs un non moins bonne extension de navigateur pour débuguer en mode local un GTM. Merci à son auteur https://adswerve.com/blog/making-the-move-to-server-side-tagging-part-1/
Qu’est-ce que le balisage côté serveur ?
Le gestionnaire de balises Google côté serveur est un serveur intermédiaire entre les données collectées par le navigateur (ou tout autre appareil connecté en ligne) et le point de terminaison (dit endpoint) du fournisseur (Google Analytics, Google Ads, Facebook, etc.). Lorsque vous utilisez un conteneur sGTM, les données qui auraient normalement été envoyées directement au point de terminaison du fournisseur via une balise ou un pixel sont désormais acheminées vers votre propre infrastructure cloud. Vous pouvez ensuite les modifier selon vos besoins et utiliser des balises dans votre conteneur sGTM pour envoyer ces données aux fournisseurs spécifiques qui en ont besoin. Il y a plusieurs avantages à disposer d’un intermédiaire pour la collecte des données. Il y a également de nombreuses considérations à prendre en compte avant de décider d’utiliser le balisage côté serveur.
gtm cote client version classique
Avantages du tracking côté serveur
Confidentialité Et Sécurité Des Données
principe d’un serveur proxy
L’utilisation d’un proxy côté serveur vous permet de modifier les requêtes sortantes adressées aux fournisseurs afin que seules les données que vous souhaitez réellement leur envoyer parviennent à des plateformes telles que Google Analytics et Facebook. Par exemple, en utilisant le balisage côté serveur, vous pouvez hacher les courriels, expurger les adresses IP et supprimer la chaîne de l’agent utilisateur du résultat, si nécessaire. Le balisage côté serveur minimise également les fuites de données, en particulier celles provenant de pixels qui peuvent traverser des réseaux non sécurisés en direction des plateformes des fournisseurs.
Le transfert de vos données dans le nuage réduit la distance que les pixels doivent parcourir et vous permet de mieux contrôler les données que vous envoyez. En outre, le transfert des bibliothèques javascript vers un CDN propre ajoute un niveau de sécurité important. En raison de cette sécurité accrue, la prévention intelligente du suivi (ITP) accorde des privilèges supplémentaires aux cookies provenant d’un CDN propriétaire.
Enfin, si vous avez correctement mappé un sous-domaine de votre site Web sur votre serveur GTM, vous pouvez configurer vos balises Google Analytics pour qu’elles fonctionnent à l’aide d’un cookie de première partie, HttpOnly (alias “serveur uniquement”) qui persiste au-delà de la limite de sept jours imposée aux cookies javascript par la dernière mise à jour ITP.
GTM server-side-tagging-Server-side-container
Données propriétaires
Lorsque vous acheminez des données par l’intermédiaire de vos propres serveurs, vous êtes entièrement propriétaire de ces données. Vous pouvez les utiliser comme bon vous semble au sein de la plateforme Google Cloud (GCP) ou de tout autre fournisseur de cloud computing que vous utilisez.
Efficacité de la collecte des données
L’envoi de requêtes réseau redondantes de votre site Web à plusieurs fournisseurs peut mettre votre site à rude épreuve et avoir un impact négatif sur ses performances. Si vous avez dix fournisseurs qui ont tous besoin des mêmes données détaillées, ces nombreuses requêtes volumineuses peuvent s’accumuler et entraîner un ralentissement des temps de chargement. Avec sGTM, vous pouvez prendre un objet de données d’événement créé par un client et configurer une balise sGTM pour envoyer ces données à plusieurs fournisseurs qui ont besoin des mêmes données. Cela signifie qu’une seule, voire une poignée de requêtes sont nécessaires dans le navigateur, le serveur se chargeant ensuite du reste du travail.
Des performances optimales du navigateur peuvent présenter plusieurs avantages. Tout d’abord, des temps de chargement rapides se traduisent par une meilleure expérience pour l’utilisateur final, et donc probablement par un meilleur engagement. De plus, Google a récemment annoncé que l’expérience de la page deviendra un facteur de classement organique à partir de la mi-juin de cette année, et ce jusqu’en août. Cela signifie que l’amélioration de la vitesse du site et l’accent mis sur les signaux web essentiels seront également une partie importante du Seo à l’avenir.
Enjeux du tracking côté serveur
Coût d’utiliser un serveur
Lorsque l’on parle sGTM doit commencer par parler ressources. Puisque les résultats sont collectés dans votre propre serveur dans le nuage, le processus de collecte des données lui-même entraîne un coût. Ce coût est essentiellement une taxe pour déplacer vos données hors du nuage chaque fois que le client que vous avez configuré répond à une demande et chaque fois qu’une balise ou un client envoie une demande au serveur d’un fournisseur.
L’optimisation du nombre de requêtes envoyées par votre serveur peut contribuer à réduire considérablement les coûts. Il existe également un processus appelé journalisation (qui sera abordé plus en détail ultérieurement) qui engendre également un coût. La journalisation est un outil utile pour le débogage, mais si l’on n’y prend garde, elle peut être une source de dépenses importantes.
google-cloud-services
Il est également important de prendre en compte le coût de la gestion de votre infrastructure dans le cloud . sGTM n’est pas une implémentation “à mettre en place et à oublier”. La surveillance continue de la sortie du réseau et des journaux, la consolidation de vos flux de données afin de ne pas envoyer les mêmes données à votre serveur de manière redondante, et la surveillance de votre utilisation des instances pour vous assurer que votre configuration peut gérer le trafic envoyé à tout moment sont autant d’éléments essentiels à la gestion d’une configuration côté serveur.
Adoption par les fournisseurs (Google analytics, At internet etc..)
Google a mis au point une méthode permettant d’acheminer les données que nous envoyons normalement aux serveurs de Google Analytics directement vers notre propre point d’extrémité de serveur, via un paramètre appelé “URL de transport” (nous y reviendrons plus tard dans notre série de blogs). Facebook a développé son API de conversion qui permet le même processus. Bien que ces géants des médias aient une longueur d’avance, tous les partenaires médias n’ont pas adopté la compatibilité avec un point de terminaison côté serveur. Si vous êtes impatient de migrer entièrement vers une mise en œuvre côté serveur, le coût du temps deviendra un facteur. Vous devrez peut-être attendre que certains fournisseurs publient leurs propres modèles ou investir plus de temps et d’argent dans des services techniques pour vous aider à développer, mettre à jour et maintenir des solutions de modèles personnalisées.
Comment savoir si c’est le bon moment pour passer à la sGTM ?
Voici quelques critères fondamentaux à prendre en compte.
- Vous devez disposer d’une solide configuration de balisage côté client (pensez au conteneur web GTM que nous connaissons et apprécions tous) soutenue par une solide mise en œuvre de la couche de données. Ces données sont toujours collectées et envoyées depuis votre site Web. La seule différence pour le balisage côté serveur est l’endroit où vous envoyez ces données et comment.
- Vous devez disposer des ressources nécessaires pour payer les coûts de la technologie du cloud associés à votre instance côté serveur, ainsi que des ressources pour prendre en charge la gestion de l’infrastructure du cloud requise pour le coût, la collecte des données et l’optimisation de l’instance du serveur.
- Il est important que vous ayez réfléchi aux raisons de passer à sGTM. S’agit-il des performances du site ? Des questions de confidentialité ? Voulez-vous plus de propriété et de contrôle sur vos données ? Parce que le passage à sGTM requiert beaucoup plus d’intention que la mise en œuvre d’un site Web
- Vous avez communiqué avec votre utilisateur final sur la confidentialité et la transparence de ses données et vous êtes clair sur le fait que si vous pouvez collecter ses données et les transmettre à des fournisseurs sans son autorisation, vous vous engagez à respecter son consentement.
Une des voies pour alléger la demande de consentement ?
Étant donné que vos données sont envoyées à votre propre serveur qui se trouve sur votre propre sous-domaine – ce qui fait que cette collecte de données se fait dans un contexte de première partie – il peut être tentant d’utiliser le balisage côté serveur comme moyen de contourner certaines des réglementations légales et des politiques de navigateur les plus restrictives. Il est important de se rappeler que vous devez toujours suivre les lois pertinentes et respecter le consentement de l’utilisateur pour la collecte de données. sGTM n’est pas un moyen de contourner les bloqueurs de publicité ou de collecter des données à l’insu des utilisateurs et sans leur consentement. Enfin, il est important de s’assurer que vous disposez des ressources appropriées coordonnées avant de faire le saut vers sGTM. Une mise en œuvre qui ne bénéficie pas d’un soutien complet peut finir par coûter plus cher à long terme.
Pour conclure comment fonctionne le sgtm ?
Composants D’un Conteneur Sgtm
Dans sGTM, vous verrez tous les composants que vous connaissez et aimez d’un conteneur web. Il y a des balises, des déclencheurs et des variables, qui sont utilisés de la même manière que dans nos conteneurs Web. La nouveauté est une entité appelée “client”. Le client est une entité qui écoute constamment les demandes HTTP entrantes, crée l’objet de données d’événement, exécute le conteneur de serveur et répond à la demande. Ce nouveau composant est essentiel pour sGTM.
client sGtm sur le serveur
Comment fonctionne le sGtm ?
Comme nous l’avons mentionné, les clients du conteneur du serveur jouent un rôle important dans le fonctionnement de sGTM. Ils sont configurés pour accepter, analyser et répondre aux requêtes HTTP dans un format spécifique, mais à quoi cela ressemble-t-il ? Un exemple est la simple tâche d’envoyer vos données à Google Analytics via le nouveau tag Google Analytics (GA4).
Vue navigation et client gtm google
Dans ce cas, le client GA4 accepte les requêtes HTTP provenant des pings envoyés à votre serveur par une balise GA4 résidant dans votre conteneur Web GTM (ou dans le code de votre site Web, si vous utilisez une implémentation de balise codée en dur).
Principes Google tag manager: source Adswerve
Les balises construites à partir d’API modèles sont ensuite configurées à l’aide de déclencheurs et de variables pour prendre les données disponibles dans un objet de données d’événement (créé par le client lorsqu’il a analysé les données de la requête HTTP entrante) et les envoyer au point de terminaison d’un fournisseur dans le format requis par ce fournisseur spécifique.
Les requêtes HTTP entrantes peuvent provenir de n’importe quelle source connectée en ligne, y compris les requêtes de protocole de mesure des systèmes de point de vente en ligne, mais la configuration la plus simple, qui s’alignera probablement fortement sur ce que vous faites déjà dans vos efforts de collecte de données, sera d’envoyer des requêtes HTTP via des balises web qui résident dans votre conteneur web GTM à votre propre point de terminaison côté serveur.
