Dans Introduction au taggage côté serveur, vous avez découvert le taggage côté serveur dans Tag Manager. Vous avez appris ce que sont les clients et ce qu'ils font : ils reçoivent les données d'événement des appareils de vos utilisateurs et les adaptent pour qu'elles puissent être utilisées par le reste du conteneur. Cet article explique comment traiter ces données dans les balises côté serveur.
Dans un conteneur serveur, les balises reçoivent les données d'événement entrantes de vos clients, les transforment et les renvoient pour collecte et analyse. Les balises peuvent envoyer les données où vous le souhaitez. Tant que la destination accepte les requêtes HTTP, elle peut également accepter les données d'un conteneur serveur.
Les conteneurs serveur comportent trois balises intégrées, prêtes à être utilisées sans configuration personnalisée :
- Google Analytics
- Requête HTTP
Si vous souhaitez envoyer des données ailleurs que dans Google Analytics ou si vous avez besoin de plus de fonctionnalités que celles fournies par la balise "Requête HTTP", vous devez utiliser une autre balise. Vous pouvez trouver d'autres balises dans la galerie de modèles de la communauté ou créer les vôtres. Ce tutoriel vous apprendra les bases de la création de vos propres balises pour un conteneur serveur.
Objectifs
- Découvrez les API à utiliser pour lire les données d'événement, envoyer des requêtes HTTP et définir des cookies dans le navigateur.
- Découvrez les bonnes pratiques pour concevoir les options de configuration de votre balise.
- Découvrez la différence entre les données spécifiées par l'utilisateur et les données collectées automatiquement, et pourquoi cette distinction est importante.
- Découvrez le rôle d'une balise dans un conteneur serveur. Comprenez ce qu'une balise doit faire et ne doit pas faire.
- Découvrez quand envisager d'envoyer un modèle de balise à la galerie de modèles de la communauté.
Prérequis
- Un conteneur serveur déployé
- Vous connaissez Tag Manager, les conteneurs serveur et leurs concepts de base tels que les clients, les balises, les déclencheurs et les variables.
- Vous connaissez les bases de la création de modèles pour les balises et les variables.
La balise Baz Analytics
Dans ce tutoriel, vous allez créer une balise qui envoie des données de mesure à un service appelé Baz Analytics.
Baz Analytics est un service d'analyse simple et hypothétique qui ingère des données via des requêtes HTTP GET à l'adresse https://example.com/baz_analytics. Il comporte les paramètres suivants :
| Paramètre | Exemple | Description |
|---|---|---|
| id | BA-1234 | ID de votre compte Baz Analytics. |
| en | clic | Nom de l'événement |
| l | https://www.google.com/search?q=sgtm
|
URL de la page où l'événement s'est produit. |
| u | 2384294892 | ID de l'utilisateur effectuant l'action. Permet de lier plusieurs actions à un seul utilisateur. |
Configuration de la balise
La première chose à faire est de créer le modèle de balise. Accédez à la section Modèles de votre conteneur, puis cliquez sur Nouveau dans la section Modèles de balises. Ajoutez un nom et une description à votre balise.
Ensuite, accédez à la section Champs de l'éditeur de modèles pour ajouter les différentes options de configuration de votre balise. La question suivante est évidente : de quelles options avez-vous besoin ? Vous pouvez choisir de créer la balise de trois manières :
- Configuration totale : ajoutez un champ de configuration pour chaque paramètre. Demandez à l'utilisateur de tout définir explicitement.
- Aucune configuration : n'incluez aucune option pour configurer la balise. Toutes les données sont extraites directement de l'événement.
- Configuration partielle : incluez des champs pour certains paramètres, mais pas pour d'autres.
Le fait d'avoir des champs pour chaque paramètre est très flexible et permet à l'utilisateur de contrôler totalement la configuration de sa balise. En pratique, cela entraîne généralement beaucoup de travail en double. En particulier, des éléments tels que le paramètre l de Baz Analytics, qui contient l'URL de la page, sont sans ambiguïté et universels.
Il est préférable de laisser l'ordinateur saisir la même donnée immuable chaque fois que la balise est configurée.
La solution consiste peut-être à utiliser une balise qui ne prend que les données d'un événement. Il s'agit de la balise la plus simple à configurer pour un utilisateur, car il n'a rien à faire. En revanche, c'est aussi l'option la plus restrictive et la plus fragile. Les utilisateurs ne peuvent pas modifier le comportement de la balise, même s'ils en ont besoin.
Par exemple, ils peuvent appeler un événement purchase sur leur site Web et dans Google Analytics, mais Baz Analytics l'appelle buy. Ou peut-être que les hypothèses que la balise fait sur la structure des données d'événement entrantes ne correspondent pas à la réalité. Dans les deux cas, l'utilisateur est bloqué.
Comme pour beaucoup de choses, la réponse se situe entre les deux extrêmes. Il est logique de toujours extraire certaines données de l'événement. D'autres données doivent être configurées par l'utilisateur. Comment décider lesquelles ? Pour répondre à cette question, nous devons examiner de plus près les données qui arrivent dans le conteneur.
D'où proviennent les données ?
Les données qui arrivent dans un conteneur serveur à partir de la balise Google Analytics peuvent être divisées en deux catégories : les données spécifiées par l'utilisateur et les données collectées automatiquement.
Les données spécifiées par l'utilisateur sont tout ce qu'un utilisateur place dans une commande event gtag.js. Par exemple, une commande comme celle-ci :
gtag('event', 'search', {
search_term: 'beets',
});
entraîne les paramètres suivants dans le conteneur serveur :
{
event_name: 'search',
search_term: 'beets',
}
C'est assez simple, mais du point de vue de la balise, il est très difficile de travailler avec. Étant donné que ces données sont saisies par l'utilisateur, elles peuvent être n'importe quoi.
Comme ci-dessus, l'utilisateur n'envoie peut-être que les événements
recommandés et paramètres, mais il n'est pas
obligé de le faire. À l'exception importante de l'emplacement (mais
pas de la valeur !) du event_name paramètre, il n'existe aucune garantie quant à la
forme ou à la structure des données de l'utilisateur.
Heureusement, les données saisies par l'utilisateur ne sont pas les seules que le conteneur recevra. Il recevra également un ensemble de données collectées automatiquement par la balise Google Analytics dans le navigateur. Cela inclut :
ip_overridelanguagepage_locationpage_referrerpage_titlescreen_resolutionuser_agent
De plus, si la requête du serveur provient d'un navigateur Web, des données de cookies de navigateur peuvent également être disponibles via l'API getCookieValue.
Ensemble, ces éléments constituent les données collectées automatiquement que nous avons mentionnées ci-dessus. En général, il s'agit de données universelles et sémantiquement non ambiguës. Lorsqu'une requête provient d'une balise Google Analytics dans le navigateur, ces données sont toujours disponibles et ont toujours le même format. Pour en savoir plus sur ces paramètres, consultez la documentation de référence sur les événements.
Cette classification nous fournit un outil utile pour décider quelles données doivent être configurées par l'utilisateur et lesquelles doivent être spécifiées dans la balise. Les données collectées automatiquement peuvent être lues directement à partir de l'événement. Tout le reste doit être configuré par l'utilisateur.
Dans cette optique, examinez à nouveau les paramètres de la balise Baz Analytics.
- ID de mesure,
id: comme il n'est pas collecté automatiquement, il s'agit d'un exemple clair de valeur qui doit être saisie par l'utilisateur lors de la configuration de la balise. - Nom de l'événement,
en: comme mentionné ci-dessus, le nom de l'événement peut toujours être extrait directement du paramètreevent_name. Toutefois, comme sa valeur est définie par l'utilisateur, il est judicieux de proposer la possibilité de remplacer le nom si nécessaire. - URL de la page,
l: Cette valeur peut être extraite dupage_locationparamètre, qui est collecté automatiquement par la balise de navigateur Google Analytics pour chaque événement. Par conséquent, vous ne devez pas demander à l'utilisateur de saisir une valeur manuellement. - User ID,
u: dans la balise de serveur Baz Analytics, le paramètreun'est ni spécifié par l'utilisateur ni collecté automatiquement par la balise sur la page. Il est stocké dans un cookie de navigateur afin que les utilisateurs puissent être identifiés lors de plusieurs visites sur le site Web. Comme vous le verrez dans l'implémentation ci-dessous, c'est la balise de serveur Baz Analytics qui utilise l'setCookieAPI pour définir le cookie. Cela signifie que la balise Baz Analytics est la seule à savoir où et comment le cookie est stocké. Commel, leuparamètre doit être collecté automatiquement.
Une fois la configuration de la balise terminée, elle devrait se présenter comme suit :
Implémentation des balises
Maintenant que la configuration de la balise est terminée, vous pouvez passer à l'implémentation de son comportement en JavaScript en bac à sable.
La balise doit effectuer quatre opérations :
- Obtenir le nom de l'événement à partir de la configuration de la balise.
- Obtenir l'URL de la page à partir de la propriété
page_locationde l'événement. - Calculer un User ID. La balise recherchera le User ID dans un cookie appelé
_bauid. Si ce cookie n'est pas présent, la balise calculera une nouvelle valeur et la stockera pour les requêtes ultérieures. - Créer une URL et envoyer une requête au serveur de collecte Baz Analytics.
Il est également utile de réfléchir à la façon dont la balise s'intègre dans le conteneur dans son ensemble. Les différents composants du conteneur jouent des rôles différents. Par conséquent, il existe également des éléments que la balise ne fait pas ou ne devrait pas faire. Votre balise :
- ne doit pas examiner l'événement pour déterminer s'il doit s'exécuter. C'est le rôle d'un déclencheur.
- ne doit pas exécuter le conteneur avec l'API
runContainer. C'est le rôle du client. - À l'exception importante des cookies, elle ne doit pas essayer d'interagir directement avec la requête ou la réponse. C'est également le rôle du client.
L'écriture d'un modèle de balise qui effectue l'une de ces opérations entraînerait un comportement déroutant pour les utilisateurs de votre balise. Par exemple, une balise qui envoie une réponse à la requête entrante empêcherait le client de faire de même. Cela ne répondrait pas aux attentes des utilisateurs concernant le comportement du conteneur.
Dans cette optique, vous trouverez ci-dessous une implémentation annotée de la balise en JS en bac à sable.
const encodeUriComponent = require('encodeUriComponent');
const generateRandom = require('generateRandom');
const getCookieValues = require('getCookieValues');
const getEventData = require('getEventData');
const logToConsole = require('logToConsole');
const makeString = require('makeString');
const sendHttpGet = require('sendHttpGet');
const setCookie = require('setCookie');
const USER_ID_COOKIE = '_bauid';
const MAX_USER_ID = 1000000000;
// The event name is taken from either the tag's configuration or from the
// event. Configuration data comes into the sandboxed code as a predefined
// variable called 'data'.
const eventName = data.eventName || getEventData('event_name');
// page_location is automatically collected by the Google Analytics tag.
// Therefore, it's safe to take it directly from event data rather than require
// the user to specify it. Use the getEventData API to retrieve a single data
// point from the event. There's also a getAllEventData API that returns the
// entire event.
const pageLocation = getEventData('page_location');
const userId = getUserId();
const url = 'https://www.example.com/baz_analytics?' +
'id=' + encodeUriComponent(data.measurementId) +
'en=' + encodeUriComponent(eventName) +
(pageLocation ? 'l=' + encodeUriComponent(pageLocation) : '') +
'u=' + userId;
// The sendHttpGet API takes a URL and returns a promise that resolves with the
// result once the request completes. You must call data.gtmOnSuccess() or
// data.gtmOnFailure() so that the container knows when the tag has finished
// executing.
sendHttpGet(url).then((result) => {
if (result.statusCode >= 200 && result.statusCode < 300) {
data.gtmOnSuccess();
} else {
data.gtmOnFailure();
}
});
// The user ID is taken from a cookie, if present. If it's not present, a new ID
// is randomly generated and stored for later use.
//
// Generally speaking, tags should not interact directly with the request or
// response. This prevents different tags from conflicting with each other.
// Cookies, however, are an exception. Tags are the only container entities that
// know which cookies they need to read or write. Therefore, it's okay for tags
// to interact with them directly.
function getUserId() {
const userId = getCookieValues(USER_ID_COOKIE)[0] || generateRandom(0, MAX_USER_ID);
// The setCookie API adds a value to the 'cookie' header on the response.
setCookie(USER_ID_COOKIE, makeString(userId), {
'max-age': 3600 * 24 * 365 * 2,
domain: 'auto',
path: '/',
httpOnly: true,
secure: true,
});
return userId;
}
La balise est ainsi implémentée. Avant de pouvoir utiliser la balise, vous devez définir correctement ses autorisations d'API. Accédez à l'onglet Autorisations de l'éditeur de modèles et spécifiez les autorisations suivantes :
- Lire les valeurs des cookies :
_bauid - Lire les données d'événement :
event_nameetpage_location - Envoyer des requêtes HTTP :
https://www.example.com/* - Définir un cookie :
_bauid
Vous devez également écrire des tests pour votre balise. Pour en savoir plus sur les tests de modèles, consultez la section Tests du guide du développeur de modèles.
Enfin, n'oubliez pas d'essayer d'exécuter votre balise au moins une fois à l'aide du bouton Exécuter le code. Cela évitera que de nombreuses erreurs simples ne se retrouvent sur votre serveur.
Envoyer votre balise à la galerie de modèles de la communauté
Étant donné que vous avez effectué tout le travail de création, de test et de déploiement d'une nouvelle balise, il n'y a aucune raison de la garder pour vous. Si vous pensez que votre nouvelle balise pourrait être utile à d'autres personnes, envisagez de l'envoyer à la galerie de modèles de la communauté.
Conclusion
Dans ce tutoriel, vous avez découvert les bases de la création d'une balise pour un conteneur serveur. Les points suivants ne devraient maintenant plus avoir de secrets pour vous :
- Les API à utiliser pour lire les données d'événement, envoyer des requêtes HTTP et définir des cookies dans le navigateur.
- Les bonnes pratiques pour concevoir les options de configuration d'une balise.
- La différence entre les données spécifiées par l'utilisateur et les données collectées automatiquement, et pourquoi cette distinction est importante.
- Le rôle d'une balise dans le conteneur, ce qu'elle doit faire et ne doit pas faire.
- Quand et comment envoyer des modèles de balises à la galerie de modèles de la communauté.