Le taggage côté serveur est une nouvelle façon d'utiliser Google Tag Manager pour instrumenter votre application sur plusieurs appareils. Les conteneurs serveur utilisent le même modèle de balise, de déclencheur et de variable que celui auquel vous êtes habitué, tout en fournissant de nouveaux outils qui vous permettent de mesurer l'activité des utilisateurs où qu'elle se produise.
Une configuration de taggage typique sans taggage côté serveur s'appuie sur un conteneur sur la page pour envoyer des données de mesure à divers serveurs de collecte. La figure 1 illustre comment un conteneur Web Tag Manager exécuté dans un navigateur Web envoie des données à plusieurs serveurs.
Figure 1: Schéma d'un site instrumenté pour utiliser un conteneur Web Google Tag Manager.
À l'inverse, un conteneur serveur ne s'exécute pas dans le navigateur ou sur le téléphone de l'utilisateur. Il s'exécute sur un serveur que vous contrôlez.
Figure 2: Exemple de configuration de taggage utilisant un conteneur serveur.
Le serveur s'exécute dans votre propre projet Google Cloud Platform (ou dans un environnement différent de votre choix) et vous seul avez accès aux données du serveur jusqu'à ce que vous choisissiez de les envoyer ailleurs. Vous contrôlez entièrement la façon dont ces données sont structurées et vers où elles sont acheminées depuis le serveur. Les balises sont créées à l'aide de la technologie JavaScript en bac à sable. Les autorisations vous permettent de voir ce que la balise peut faire, et les stratégies vous permettent de définir des limites autour du conteneur.
Le serveur reçoit des requêtes Web de l'appareil de l'utilisateur et les transforme en événements. Chaque événement est traité par les balises, les déclencheurs et les variables du conteneur. Les balises, les déclencheurs et les variables d'un conteneur serveur fonctionnent exactement comme dans les autres types de conteneurs: les déclencheurs examinent chaque événement pour rechercher certaines conditions et, le cas échéant, déclenchent des balises qui envoient les données d'événement à traiter.
Ce modèle pose deux questions importantes pour les conteneurs serveur:
- Comment les données de mesure passent-elles de l'appareil de l'utilisateur au conteneur du serveur ?
- Comment les données de mesure envoyées à un conteneur serveur sont-elles transformées en événement ?
La réponse à ces deux questions est un nouveau type d'entité à utiliser dans les conteneurs serveur: un client.
Fonctionnement des clients
Les clients sont des adaptateurs entre le logiciel exécuté sur l'appareil d'un utilisateur et le conteneur de votre serveur. Le client reçoit des données de mesure à partir d'un appareil, les transforme en un ou plusieurs événements, achemine les données à traiter dans le conteneur et empaquette les résultats à renvoyer à l'auteur de la requête.
C'est beaucoup ! Intéressons-nous de plus près à chaque partie. La figure 3 montre les données qui transitent vers le conteneur serveur à partir du navigateur Web de l'utilisateur et de votre serveur Web vers le conteneur serveur.
Figure 3: Un client différent gère chaque flux de données.
Les clients reçoivent des données de mesure à partir d'un appareil. Supposons que vous souhaitiez mesurer l'activité des utilisateurs dans trois endroits: un site Web, une application pour téléphone et une machine à pain connectée. Votre site Web utilise Google Analytics, votre application pour téléphone utilise Firebase Analytics et votre grille-pain utilise un protocole propriétaire appelé "ToastMeasure".
L'instrumentation de ces trois appareils avec Google Tag Manager nécessiterait normalement un conteneur différent pour chaque plate-forme. Étant donné que le conteneur serveur ne s'exécute pas sur l'appareil, le même conteneur peut gérer l'instrumentation d'analyse pour les trois plates-formes d'appareils. Il y a cependant un problème. Ces appareils ne communiquent pas tous de la même manière. Le protocole Google Analytics n'est pas le même que le protocole ToastMeasure. C'est là que les clients entrent en jeu.
À la place de ces trois conteneurs, votre conteneur serveur comporte trois clients. Chaque requête entrante dans le conteneur sera traitée par chaque client dans l'ordre de priorité, le client ayant la priorité la plus élevée en premier. La première chose que chaque client fera est de décider s'il sait traiter ce type de requête. Si c'est le cas, le client "réclame" la requête et passe à l'étape suivante du traitement. L'acte de revendiquer la requête empêche l'exécution des clients suivants. Si le client ne peut pas traiter la requête, il ne fait rien et permet aux autres clients de décider de la traiter ou non.
Les clients transforment les données de requête en un ou plusieurs événements. Une fois que le client ToastMeasure a revendiqué une requête, il doit la transformer en quelque chose que le reste du conteneur comprend. Cet élément est un ensemble d'événements.
Les événements sont des éléments qui se produisent et que vous souhaitez mesurer. Ils peuvent être de n'importe quelle valeur : start_toasting, finish_toasting ou buy_bread. Il existe quelques recommandations concernant la structure des événements générés par un client, mais la seule exigence est que le reste du conteneur les comprenne.
Les clients exécutent le conteneur. Le client a revendiqué la requête et l'a transformée en événements. Il est maintenant temps de passer aux balises, déclencheurs et variables. Le client transmet chaque événement au reste du conteneur pour un traitement ultérieur.
Les clients empaquettent les résultats pour les renvoyer à l'appareil. Une fois le conteneur exécuté, il est temps de répondre au grille-pain. La réponse peut prendre plusieurs formes. Le client peut simplement dire "OK, c'est bon". Il est possible que l'une des balises souhaite rediriger la requête vers un autre serveur de collecte. Ou peut-être que l'une des balises indique aux lumières du grille-pain de changer de couleur. Quel que soit le résultat attendu, c'est au client de regrouper les résultats et de les renvoyer à l'utilisateur à l'origine de la requête.
Heureusement, Tag Manager gère une grande partie de ces tâches. Les conteneurs serveur sont fournis avec deux clients: Google Analytics 4 et le protocole de mesure. Ces clients fournissent les outils dont vous avez besoin pour commencer à instrumenter votre application dès que vous avez créé votre conteneur.
Un bref exemple
Prenons un exemple rapide pour voir comment tous les éléments s'imbriquent. Dans cet exemple, vous allez créer les éléments suivants:
- Site Web simple qui utilise gtag.js pour envoyer un événement
clickà un conteneur serveur. - Client Google Analytics 4 qui reçoit l'événement.
- Déclencheur qui se déclenche sur un événement
click. - Balise Google Analytics 4 qui envoie les données d'événement à Google Analytics pour traitement.
Pour cet exemple, nous partons du principe que vous avez déjà créé et déployé votre conteneur serveur.
Configurer gtag.js
Commencez par configurer gtag.js pour qu'il envoie les données à votre conteneur serveur. Avec gtag.js, l'envoi de données vers votre conteneur serveur fonctionne comme l'envoi de données vers Google Analytics, avec une modification. Comme dans l'exemple de page ci-dessous, définissez l'option de configuration server_container_url pour qu'elle pointe vers le conteneur serveur.
<!-- Google tag (gtag.js) -->
<script async src="https://www.googletagmanager.com/gtag/js?id=TAG_ID"></script>
<script>
window.dataLayer = window.dataLayer || [];
function gtag(){dataLayer.push(arguments);}
gtag('js', new Date());
gtag('config', 'TAG_ID', {
server_container_url: 'https://analytics.example.com',
});
</script>
Remplacez TAG_ID par votre ID de balise.
Remplacez https://analytics.example.com par l'URL de votre conteneur serveur.
Ajoutez ensuite une fonction sendEvent() pour gérer les événements click:
<!-- Google tag (gtag.js) -->
<script async src="https://www.googletagmanager.com/gtag/js?id=TAG_ID"></script>
<script>
window.dataLayer = window.dataLayer || [];
function gtag(){dataLayer.push(arguments);}
gtag('js', new Date());
gtag('config', 'TAG_ID', {
server_container_url: 'https://analytics.example.com',
});
function sendEvent() {
gtag('event', 'click');
}
</script>
<button onclick="javascript:sendEvent()">Send Event</button>
Remplacez TAG_ID par votre ID de balise.
Remplacez https://analytics.example.com par l'URL de votre conteneur serveur.
Avec cette configuration, les gestionnaires d'événements tels que la fonction sendEvent() incluse dans cet exemple enverront un événement click à votre conteneur de serveur.
Client Google Analytics 4
Votre conteneur a besoin d'un client pour recevoir l'événement une fois qu'il a atteint le serveur. Heureusement, les conteneurs serveur sont livrés avec un client Google Analytics 4 préinstallé. Vous n'avez donc pas besoin de suivre cette étape.
Déclencheur de clic
Ensuite, créez un déclencheur qui se déclenche sur l'événement click. Créez un déclencheur personnalisé qui se déclenche lorsque la variable intégrée Nom de l'événement est égale à "clic".
Balise Google Analytics 4
Enfin, associez une balise GA4 au déclencheur. Comme pour les clients, un conteneur de serveur est fourni avec une balise GA4. Il vous suffit de créer la balise, de configurer vos paramètres, et vous avez câblé votre conteneur. Les clients GA4 et les balises GA4 sont conçus pour fonctionner ensemble. Cela signifie que vous n'avez qu'à créer une balise GA4, et sa configuration sera automatiquement extraite des événements provenant du client.
Prévisualiser le conteneur
Maintenant que le conteneur est configuré, cliquez sur Preview (Aperçu). Accédez à votre site Web dans une autre fenêtre de navigateur. Lorsque des requêtes et des événements sont envoyés à votre conteneur serveur, ils s'affichent sur le côté gauche de la page d'aperçu.
Une fois que vous êtes satisfait de vos modifications, publiez le conteneur du serveur.
Configurer votre serveur en mode production avec la diffusion first party
Avant d'envoyer du trafic de production à votre conteneur serveur, nous vous recommandons vivement d'installer le serveur sur votre domaine propriétaire et de le mettre à niveau en mode production.