Dernière mise à jour : 18 octobre 2021. Peview fonctionne maintenant avec le conteneur proxy même si l’ID du conteneur est remplacé.

Bien que le balisage côté serveur dispose déjà d’un merveilleux client intégré pour le proxy du conteneur Google Tag Manager via votre propre domaine propriétaire, ce n’est pas parfait.

Les principaux problèmes sont qu’il ne vous permet pas de délimiter l’accès par origine, de sorte que les demandes d’ID de conteneur sur liste blanche peuvent être envoyées de n’importe où, et qu’il ne vous laisse pas choisir librement le chemin par lequel l’ID de conteneur est chargé.

Pour résoudre ces problèmes, je suis heureux de vous révéler que j’ai écrit un nouveau modèle de client pour les conteneurs de serveur, nommés Chargeur GTM.

Les principales caractéristiques de ce modèle sont :

• Choisissez librement le chemin de requête auquel le client répond. Vous pouvez conserver la valeur par défaut /gtm.jsou vous pouvez opter pour quelque chose de plus imaginatif, comme /green-dragons.
• Chargez toujours un conteneur d’un ID spécifique, quel que soit ce qu’il y a (le cas échéant) dans le ?id= paramètre de la requête.
• Autoriser uniquement les demandes provenant d’origines spécifiques.

Lisez la suite pour plus d’informations!

Obtenir le modèle

Comme la galerie de modèles de la communauté ne distribue pas encore de modèles de clients, vous devrez importer manuellement le fichier de modèle.

Tout d’abord, récupérez le brut template.tpl fichier du référentiel GitHub en suivant ce lien et en enregistrant la page sous template.tpl dans votre ordinateur.

Ensuite, dans votre Serveur conteneur, allez à Modèles et cliquez Nouveau dans la zone Modèles de client.

Dans le menu de débordement dans le coin supérieur droit de l’écran, choisissez Importer.

Localisez le template.tpl fichier de votre conteneur, attendez que l’éditeur s’actualise avec le modèle GTM Loader, puis cliquez sur Sauver pour enregistrer le modèle.

Créer un nouveau client

Dirigez-vous vers Clients dans votre conteneur, et cliquez sur Nouveau pour créer un nouveau Client.

Dans la liste des Clients disponibles, choisissez le Chargeur GTM Client.

Vous devriez être prêt maintenant à personnaliser le nouveau Client !

Configurer le Client

Voici à quoi ressemble le client avec tous les champs disponibles affichés :

Chemin de requête

Définissez ceci sur un chemin (incluez la barre oblique de début). Vous pouvez également conserver la valeur par défaut /gtm.js si vous le souhaitez.

Le client sera à l’écoute des requêtes vers ce chemin, et si un correspondance exacte est faite, le Client réclamera la demande et fera ses merveilles.

Par exemple, si vous définissez le chemin sur /google_tag_manager.js comme dans la capture d’écran ci-dessus, puis une demande à https:///google_tag_manager.js?id=GTM-ABCDEFG chargera le conteneur Google Tag Manager avec ID GTM-ABCDEFG sauf si vous avez aussi le Remplacer l’ID du conteneur paramètre coché (plus d’informations ci-dessous).

Rappelez-vous que c’est correspondance exacte! La demande doit être avec un chemin qui correspond exactement au paramètre que vous configurez dans ce client.

Remplacer l’ID du conteneur

Important! Si vous remplacez l’ID de conteneur, Aperçu conteneurs seront chargés, mais le navigateur doit faire une requête supplémentaire pour www.googletagmanager.com. Donc, si votre site a une politique de sécurité du contenu, https://www.googletagmanager.com doit encore lui être ajouté pour que le mode Aperçu fonctionne correctement.

Si vous cochez ce paramètre, vous pouvez alors ajouter un ID de conteneur Google Tag Manager valide dans le champ correspondant.

Ce paramètre signifie que peu importe ce qu’il y a dans ?id= paramètreun conteneur avec l’ID configuré sera renvoyé.

Lorsque vous avez coché ce paramètre, vous pouvez réellement supprimer le ?id= paramètre de la requête, car le conteneur avec l’ID configuré sera chargé dans tous les cas.

Origines autorisées

Dans ce champ, vous pouvez ajouter une liste séparée par des virgules de origines dont les demandes seront uniquement respectées.

Par exemple, si vous ajoutez https://www.teamsimmer.com,https://www.simoahava.com au champ, seules les requêtes provenant de ces deux origines pourront récupérer le conteneur.

Rappelez-vous que l’origine est le schéma (http ou alors https) plus :// plus nom d’hôte plus port. Donc, fondamentalement, tout jusqu’au chemin de la demande.

Vous pouvez également ajouter * à ce champ, auquel cas le Client réclamera la demande quelle que soit son origine.

Si vous devez fournir manuellement l’origine (par exemple, lorsque vous travaillez avec une ressource intégrée ou lors d’un test), vous pouvez ajouter &origin=<origin> à l’URL de la demande. Par exemple, pour charger le conteneur même quand je ne suis pas sur https://www.simoahava.com et j’ai défini cela dans le champ Origines autorisées, je peux accéder à ceci :

https:///google_tag_manager.js?id=GTM-ABCDEFG&origin=https://www.simoahava.com

Comment ça fonctionne

Un client créé avec le modèle écoute les demandes envoyées au chemin de demande défini dans les paramètres du client.

Valider la demande

Lorsqu’une telle demande est reçue, le Client effectue deux vérifications :

1. Est le Remplacer l’ID du conteneur paramètre coché et un ID de conteneur GTM valide a été configuré, OU existe-t-il un ID de conteneur GTM valide comme valeur de id paramètre de requête dans la requête ?
2. Est-ce que la valeur de Origines autorisées le joker (*) OU la demande provient-elle d’une origine autorisée OU a-t-elle une origine autorisée comme valeur de origin paramètre de requête dans la requête ?

// If the incoming request matches the request configured in the Client if (requestPath === data.requestPath) {      // If the request is for a valid GTM container ID   if (!containerId.match('^GTM-.+$')) return;      // If the request comes from a valid origin   if (!validateOrigin()) return;      ... } 

Si les deux décident de truela requête est revendiquée.

Récupérer le conteneur d’aperçu

Si la demande porte sur un Aperçu conteneur, ce qui signifie qu’il a le gtm_debug, gtm_authet gtm_preview paramètres de requête, le client agit comme un proxy transparent.

Il transmet simplement la demande aux serveurs GTM avec tous les en-têtes et paramètres intacts, et renvoie le résultat à la source de la demande.

const fetchPreviewContainer = () => {   sendHttpGet(     httpEndpoint  +                '&id=' + containerId +                '&gtm_auth=' + gtm_auth +                '&gtm_debug=' + gtm_debug +                '&gtm_preview=' + gtm_preview,      (statusCode, headers, body) => {       sendResponse(body, headers, statusCode);     }, {timeout: 1500}   ); }; 

Il est important de noter que lorsqu’un conteneur d’aperçu est récupéré, le résultat n’est pas mis en cache. Ceci est essentiel pour rendre l’aperçu utile, sinon l’utilisateur devrait attendre que le cache expire avant que le conteneur d’aperçu actualisé ne soit disponible.

Récupérer le conteneur actif

Lorsqu’un habitent conteneur est récupéré, d’autre part, le processus change un peu.

Le modèle utilise templateDataStoragequi est une API conçue pour conserver les informations entre les requêtes dans le conteneur du serveur.

Lorsqu’une demande pour le conteneur en direct arrive, le client vérifie s’il existe déjà une version en cache de la bibliothèque et si la ressource a été mise en cache moins de il y a 7,5 minutes. Dans ce cas, la bibliothèque mise en cache (et tous les en-têtes mis en cache) sont renvoyés à la source de la requête.

De cette façon, le client économise des ressources en ne plus avoir à récupérer la ressource sur les serveurs de Google.

Pourquoi une durée de cache de 7,5 minutes ? Eh bien, c’est moitié du temps de cache du navigateur pour la bibliothèque GTM elle-même (15 minutes). De cette façon, le cache du navigateur a toujours le dernier mot sur la durée de mise en cache de la ressource, mais contrairement à un cache de navigateur, tous les utilisateurs bénéficier du cache côté serveur même si l’utilisateur n’a jamais téléchargé la ressource auparavant.

Si la ressource n’est pas mise en cache ou si le cache a expiré, le conteneur est récupéré à partir des serveurs Google.

const fetchLiveContainer = () => {   const now = getTimestampMillis();      // Set timeout to 7.5 minutes   const storageTimeout = now - cacheMaxTimeInMs;      // If the cache has expired fetch library from Google servers and write response to cache   if (!templateDataStorage.getItemCopy(storedJs) ||        templateDataStorage.getItemCopy(storedTimeout) < storageTimeout) {     sendHttpGet(       httpEndpoint + '&id=' + containerId,        (statusCode, headers, body) => {         if (statusCode === 200) {           templateDataStorage.setItemCopy(storedJs, body);           templateDataStorage.setItemCopy(storedHeaders, headers);           templateDataStorage.setItemCopy(storedTimeout, now);         }         sendResponse(body, headers, statusCode);       }, {timeout: 1500}     );   // Otherwise, pull the item from cache and do not make a request to Google servers   } else {     sendResponse(       templateDataStorage.getItemCopy(storedJs),       templateDataStorage.getItemCopy(storedHeaders),       200     );   } }; 

Donc templateDataStorage fonctionne ici comme une couche supplémentaire de mise en cache, réduisant la latence de réponse du serveur et les coûts de sortie du réseau.

Résumé

Pourquoi créer un modèle comme celui-ci alors que le client de conteneur Web intégré fonctionne parfaitement ?

Les cyniques pourraient dire qu’il s’agit d’un moyen amélioré de contourner les bloqueurs de publicités. Et ils auraient raison ! Cette Est-ce que permettent de contourner plus facilement les bloqueurs de publicités, car leurs heuristiques ne ciblent pas seulement googletagmanager.com domaine mais aussi le gtm.js dossier et le GTM-... identifiant du conteneur.

Cependant, j’ai conçu le modèle pour introduire une flexibilité supplémentaire lors du déplacement de Google Tag Manager vers un contexte de première partie. Pouvoir optimiser les chemins de requête et les paramètres de requête semble être une amélioration évidente. Les templateDataStorage la configuration ajoute une couche supplémentaire d’optimisation des coûts.

Mais il y a aussi le fait que les bloqueurs de publicités ciblant Google Tag Manager jettent peut-être le bébé avec l’eau du bain. GTM lui-même n’est pas un outil de suivi, et beaucoup l’utilisent à des fins totalement indépendantes du suivi ou de la collecte de données.

Cela dit, si je devais concevoir un bloqueur de publicités aujourd’hui, je bloquerais probablement GTM également, car il est plus que probable que l’eau du bain soit si sale qu’elle doive être jetée, quels que soient les dommages collatéraux qu’elle cause.

C’est donc un équilibre difficile à trouver. Les seules choses que je peux recommander sont celles-ci :

• Vous devriez aborder le balisage côté serveur avec meilleures intentions à cœur.
• Faites de votre mieux pour améliorer plutôt que d’éroder transparence.
• Être honnête et respectueux aux visiteurs de votre site.
• Assurez-vous que ces mécanismes sont documenté quelque part afin que si quelqu’un devait auditer les flux de données sur le site et le serveur, vos balises n’entravent pas cet important travail.

De cette façon, nous passerons tous un bon moment avec le balisage côté serveur.