Introduction au taggage côté serveur

Le taggage côté serveur est une nouvelle façon d'utiliser Google Tag Manager pour instrumenter votre application sur tous les 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 repose sur un conteneur dans la page pour envoyer des données de mesure à différents serveurs de collecte. La figure 1 illustre un exemple de la façon dont 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

En revanche, un conteneur serveur ne s'exécute pas dans le navigateur de l'utilisateur ni sur son téléphone. Il s'exécute sur un serveur que vous contrôlez.

Figure 2 : Exemple de configuration de taggage qui utilise un conteneur serveur

Le serveur s'exécute dans votre propre projet Google Cloud Platform (ou dans un autre environnement de votre choix), et vous seul avez accès aux données du serveur tant que vous ne choisissez pas de les envoyer ailleurs. Vous contrôlez entièrement la façon dont ces données sont mises en forme et l'endroit où elles sont routées à partir du serveur. Les balises sont créées à l'aide de la technologie JavaScript en bac à sable. Les autorisations vous donnent une visibilité sur ce que la balise peut faire, et les règles 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 transforme ces requêtes 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 d'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 soulève deux questions importantes pour les conteneurs serveur :

• Comment les données de mesure passent-elles de l'appareil de l'utilisateur au conteneur 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 serveur. Le client reçoit des données de mesure d'un appareil, les transforme en un ou plusieurs événements, les achemine pour qu'elles soient traitées dans le conteneur et regroupe les résultats pour les renvoyer au demandeur.

C'est beaucoup de choses ! Examinons chaque partie individuellement. La figure 3 montre les données qui arrivent dans le conteneur serveur depuis le navigateur Web de l'utilisateur et depuis 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 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 un grille-pain intelligent. 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 Analytics pour les trois plates-formes d'appareils. Cependant, il y a 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à qu'interviennent les clients.

Au lieu de ces trois conteneurs, votre conteneur serveur comporte trois clients. Chaque requête qui arrive dans le conteneur est traitée par chaque client par ordre de priorité, en commençant par le client ayant la priorité la plus élevée. La première chose que chaque client fait est de déterminer s'il sait comment traiter ce type de requête. Si c'est le cas, le client "revendique" la requête et passe à l'étape suivante du traitement. Le fait de revendiquer la requête empêche les clients suivants de s'exécuter. Si le client ne peut pas traiter la requête, il ne fait rien et permet aux autres clients de décider s'ils doivent la gérer 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. Ce quelque chose est un ensemble d'événements.

Les événements sont des éléments qui se produisent et que vous souhaitez mesurer. Il peut s'agir de n'importe quoi : 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, aux déclencheurs et aux variables. Le client transmet chaque événement au reste du conteneur pour un traitement ultérieur.

Les clients regroupent 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 de nombreuses formes. Le client peut simplement dire "OK, c'est fait". L'une des balises peut vouloir rediriger la requête vers un autre serveur de collecte. Ou l'une des balises peut indiquer aux lumières du grille-pain de changer de couleur. Quoi qu'il arrive, il incombe au client de regrouper les résultats et de les renvoyer au demandeur.

Heureusement, Tag Manager gère une grande partie de ce processus pour vous. Les conteneurs serveur sont fournis avec deux clients : Google Analytics 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'assemblent. Dans cet exemple, vous allez créer les éléments suivants :

1. Un site Web simple qui utilise gtag.js pour envoyer un événement click à un conteneur serveur.
2. Un client Google Analytics qui reçoit l'événement.
3. Un déclencheur qui se déclenche sur un événement click.
4. Une balise Google Analytics 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

Tout d'abord, configurez gtag.js pour envoyer les données à votre conteneur serveur. Avec gtag.js, l'envoi de données à votre conteneur serveur fonctionne comme l'envoi de données à Google Analytics, à une exception près. 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 balise ID. Remplacez https://analytics.example.com par l'URL de votre conteneur serveur.

Ensuite, ajoutez 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 balise ID. 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 serveur.

Client Google Analytics

Votre conteneur a besoin d'un client pour recevoir l'événement une fois qu'il atteint le serveur. Heureusement, les conteneurs serveur sont fournis avec un client Google Analytics préinstallé. Vous avez donc déjà terminé 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 à "click".

Balise Google Analytics

Enfin, associez une balise Google Analytics au déclencheur. Comme pour les clients, un conteneur serveur est fourni avec une balise Google Analytics. Il vous suffit de créer la balise, de configurer vos paramètres et de connecter votre conteneur. Les clients Google Analytics et les balises Google Analytics sont conçus pour fonctionner ensemble. Cela signifie que tout ce que vous avez à faire est de créer une balise Google Analytics, et sa configuration sera extraite automatiquement 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 serveur.

Configurer votre serveur pour le mode production avec la diffusion propriétaire

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 passer en mode production.