Ce guide vous explique comment :
- Provisionnez un serveur de taggage sur Google Cloud Platform (GCP) App Engine.
- Mettez à niveau le serveur de taggage pour gérer le trafic en temps réel.
- Augmentez ou diminuez le nombre de serveurs qui exécutent votre conteneur Google Tag Manager.
- Après avoir provisionné le serveur, veillez à ce que la version de votre serveur de taggage soit à jour.
Prérequis
- Vous devez disposer d'un compte GCP. Si vous n'en avez pas, créez un compte GCP.
- Vous devez disposer d'un compte de facturation GCP. Si vous n'en avez pas, créez un compte de facturation GCP (rôle "Créateur de compte de facturation" requis).
- Vous devez disposer des rôles "Créateur de projet" et "Utilisateur de compte de facturation". En savoir plus sur l'ajout de rôles
1. Provisionner un serveur
Pour créer un serveur de taggage sur une instance App Engine, vous devez :
- Créer un conteneur serveur dans Tag Manager
- Créer un projet Google Cloud Platform (GCP)
- Provisionner un serveur de taggage App Engine
- Ajoutez l'URL du nouveau serveur de taggage au conteneur serveur Tag Manager.
Créer un conteneur serveur Google Tag Manager
Ouvrez Google Tag Manager.
Sur la ligne du compte, cliquez sur le menu à développer > Créer un conteneur.
Créez un conteneur serveur.
Cliquez sur le bouton radio "Provisionner manuellement le serveur de taggage". Notez la configuration du conteneur. Vous en aurez besoin pour provisionner votre serveur.
Créer un projet GCP
Pour créer un projet GCP pour votre serveur de taggage :
Ouvrez la console Google Cloud.
Attribuez un nom à votre projet. Nous vous recommandons d'utiliser votre ID de conteneur pour plus de commodité. Ce nom n'est utilisé que dans GCP.
Notez l'ID du projet GCP, car vous en aurez besoin pour créer votre serveur de taggage.
Provisionner un nouveau serveur de taggage
Pour créer votre serveur de taggage :
Ouvrez Cloud Shell.
Définissez le projet GCP dans Cloud Shell. Remplacez
project IDpar l'ID du projet GCP que vous avez noté précédemment :gcloud config set project project IDCréez votre serveur de taggage en suivant le script shell. Définissez le type de déploiement sur
testing.bash -c "$(curl -fsSL https://googletagmanager.com/static/serverjs/setup.sh)"
Ajouter l'URL du serveur de taggage à Tag Manager
Ouvrez Google Tag Manager.
Dans Admin > Paramètres du conteneur, cliquez sur Ajouter une URL. Si vous ne connaissez pas l'URL de votre serveur, exécutez la commande suivante dans Cloud Shell :
gcloud app browseRésultat : Vous avez configuré un serveur de taggage et l'avez provisionné avec une configuration
testing. Vous pouvez désormais tester le taggage côté serveur.
Configuration initiale du serveur (testing)
La configuration de test est appropriée pour explorer le produit en envoyant de petites quantités de trafic de test et en utilisant la fonctionnalité d'aperçu dans Tag Manager. Cette configuration correspond à une classe d'instance F1 App Engine dans l'environnement standard. Dans la plupart des cas, vous n'aurez aucun frais à payer.
2. Utiliser App Engine en production
Dans la configuration production, chaque serveur coûte environ 40 $ par mois (USD). Chaque serveur est une instance App Engine avec 1 processeur virtuel, 0, 5 Go de mémoire et 10 Go de disque dans l'environnement flexible.
Consultez Gérer les coûts App Engine pour comprendre la facturation App Engine et savoir comment configurer des alertes de facturation. Nous vous recommandons vivement de configurer une alerte de facturation.
Paramètres de production recommandés
Nous vous recommandons d'exécuter au moins trois serveurs pour réduire le risque de perte de données en cas de panne de serveur. Toutefois, vous pouvez choisir d'exécuter moins (ou plus) de serveurs. Nous prévoyons que l'autoscaling de trois à six serveurs (valeur par défaut) permettra de traiter entre 50 et 200 requêtes par seconde. Les performances dépendent du nombre de tags et de leur fonction.
Pour configurer votre serveur de taggage :
- Ouvrez Cloud Shell dans Google Cloud Platform.
- Définissez le projet Cloud Platform dans Cloud Shell. Remplacez
project IDpar l'ID du projet GCP que vous avez noté précédemment :gcloud config set project project ID
- Pour reconfigurer le serveur de taggage pour un environnement de production, exécutez le script de configuration ci-dessous. Effectuez les tâches suivantes :
bash -c "$(curl -fsSL https://googletagmanager.com/static/serverjs/setup.sh)"
- Définissez le type de déploiement sur
production. - Configurez des serveurs supplémentaires pour diffuser le trafic de production. Nous vous recommandons d'utiliser au moins trois serveurs.
- Définissez le type de déploiement sur
Facultatif : Désactiver la journalisation
Journalisation des requêtes
Par défaut, App Engine enregistre des informations sur chaque requête reçue (par exemple, le chemin d'accès à la requête, les paramètres de requête, etc.). Si votre serveur de taggage traite un grand nombre de requêtes par mois (plus d'un million, par exemple), ces messages de journalisation peuvent entraîner des frais de journalisation importants. Pour réduire ou éliminer les frais de journalisation, nous vous recommandons de désactiver la journalisation des requêtes App Engine.
Pour désactiver la journalisation des requêtes App Engine :
- Dans la plate-forme Google Cloud, ouvrez le routeur de journaux. Assurez-vous d'être dans le projet qui correspond à votre ID de conteneur :

- Pour la ligne Type : Bucket Cloud Logging, Nom : _Default, sélectionnez le menu de débordement, puis cliquez sur Modifier le récepteur.
- Sous Destination du récepteur, sélectionnez le bucket de journaux _Default.
Sous Sélectionner les journaux à inclure dans le récepteur, ajoutez une ligne. Saisissez la règle suivante dans le filtre d'inclusion existant :
NOT LOG_ID("appengine.googleapis.com/nginx.request") AND NOT LOG_ID("appengine.googleapis.com/request_log")Pour désactiver également la journalisation à partir de l'équilibreur de charge, ajoutez une ligne et saisissez la règle suivante au filtre d'inclusion existant :
NOT LOG_ID("requests")Cliquez sur Mettre à jour le récepteur pour appliquer les modifications. Les requêtes App Engine seront désormais exclues de la journalisation.
Vérifiez qu'aucune nouvelle requête n'apparaît dans les journaux de l'explorateur de journaux.
Journalisation dans la console
Le serveur de taggage, les clients ou les balises d'un conteneur peuvent consigner des messages dans la console, ce qui peut entraîner des frais de journalisation. Pour réduire ou éliminer les frais de journalisation, vous pouvez désactiver les messages de journaux de console indésirables.
Identifiez les journaux de console indésirables :
- Dans GCP, ouvrez l'explorateur de journaux.
Recherchez les messages de journaux indésirables provenant de vos balises. Exemple :
Une balise peut envoyer les journaux suivants :
const logToConsole = require('logToConsole'); logToConsole('Custom message: ' + data.param1); logToConsole('An important message to keep around!'); data.gtmOnSuccess()Recherchez les messages de journal correspondants dans le champ
textPayload:
Pour désactiver le message de journal de la console :
- Dans la plate-forme Google Cloud, ouvrez le routeur de journaux. Assurez-vous d'être dans le projet qui correspond à votre ID de conteneur :

- Pour la ligne Type : Bucket Cloud Logging, Nom : _Default, sélectionnez le menu de débordement, puis cliquez sur Modifier le récepteur.
- Sous Destination du récepteur, sélectionnez le bucket de journaux _Default.
Sous Sélectionner les journaux à inclure dans le récepteur, ajoutez une ligne. Saisissez la règle suivante dans le filtre d'inclusion existant :
NOT textPayload:"Custom message:"Pour vos journaux de console, remplacez le texte Custom message: par une sous-chaîne du journal de console que vous souhaitez désactiver. Pour des filtres plus élaborés, utilisez le langage de requête Logging.
Cliquez sur Mettre à jour le récepteur pour appliquer les modifications. Le message
logToConsolecorrespondant doit être exclu de la journalisation.Vérifiez qu'aucun nouveau message de journal de la console n'apparaît dans l'explorateur de journaux.
3. Mapper le déploiement à votre domaine personnalisé
Le déploiement par défaut du taggage côté serveur est hébergé sur un domaine App Engine. Nous vous recommandons de modifier le déploiement pour utiliser un sous-domaine de votre site Web.
Mappez le sous-domaine de votre site Web à votre serveur de taggage.
4. Ajouter l'URL du serveur à Google Tag Manager
Maintenant que vous disposez d'un serveur, vous devez vous assurer que Google Tag Manager sait qu'il doit l'utiliser.
Ouvrez Google Tag Manager.
Cliquez sur le conteneur serveur que vous souhaitez rediriger vers votre serveur de taggage.
Ouvrez les paramètres de votre conteneur serveur dans l'onglet Admin > Paramètres du conteneur.
Cliquez sur Ajouter une URL, puis collez l'URL de votre serveur.
Enregistrez et revenez à votre espace de travail.
5. Validation
Maintenant que vous avez configuré votre serveur de taggage, assurez-vous qu'il fonctionne comme prévu.
Validation de l'UI
Dans votre espace de travail Tag Manager, cliquez sur le bouton Prévisualiser. Si la page d'aperçu se charge, cela signifie que tout est correctement configuré.
Validation de l'API
Vous pouvez également vérifier que le serveur répond aux vérifications de l'état à l'aide de son API :
- Copiez l'URL de votre conteneur serveur depuis Admin > Paramètres du conteneur.
- Ouvrez un nouvel onglet du navigateur.
- Collez l'URL et ajoutez
/healthyau chemin. Exemple :https://www.example.com/metrics/healthy. - Si votre service fonctionne, le texte
okdevrait s'afficher sur la page.
Si des demandes pour un produit spécifique sont manquantes, vérifiez qu'un événement est déclenché. La commande config initialise le produit, mais les données ne sont généralement transmises que lorsqu'un event est appelé.
Pour en savoir plus sur les bonnes pratiques concernant la validation du taggage côté serveur, consultez Configuration d'un domaine personnalisé.
Prévisualiser plusieurs URL
Si vous avez mappé plusieurs domaines sur un même serveur de taggage, assurez-vous que chaque URL est ajoutée aux paramètres du conteneur.
Si vous avez fourni plusieurs URL, tous les chemins (la chaîne de caractères après le nom de domaine) doivent correspondre.
| Œuvres | Ne fonctionne pas |
|---|---|
URL 1 : example.com/abcURL 2 : example2.com/abc |
URL 1 : example.com/abcURL 2 : example2.com/def |
Si plusieurs URL sont ajoutées, une icône s'affiche à côté du bouton Prévisualiser. Elle vous permet de sélectionner l'URL à prévisualiser.
Mettre à jour la version du serveur de taggage
Les nouvelles mises à jour du serveur de taggage contiennent des correctifs pour les failles de sécurité et de nouvelles fonctionnalités. Nous vous recommandons de mettre à jour votre serveur de taggage au moins pour chaque version majeure (par exemple, passer de la version 1.x.x à la version 2.x.x) lorsque Tag Manager vous invite à le faire.
Pour mettre à jour votre serveur de taggage, exécutez de nouveau le script de configuration en utilisant les mêmes paramètres que précédemment. Les paramètres existants sont définis par défaut.
Pour mettre à jour votre serveur de taggage :
- Ouvrez Cloud Shell dans Google Cloud Platform.
- Définissez le projet Cloud Platform dans Cloud Shell. Remplacez
project IDpar l'ID du projet GCP que vous avez noté précédemment :gcloud config set project project ID
- Exécutez le script de configuration en utilisant les mêmes paramètres que précédemment. Les paramètres existants sont définis par défaut.
bash -c "$(curl -fsSL https://googletagmanager.com/static/serverjs/setup.sh)"
Pour vérifier que la mise à jour a bien été effectuée :
- Dans votre conteneur serveur, cliquez sur le bouton Prévisualiser pour démarrer une nouvelle session de débogage et envoyer une requête dans un onglet distinct.
- Dans le récapitulatif, sélectionnez l'onglet Console et assurez-vous qu'aucun message ne vous demande de mettre à jour le serveur de taggage.
Tag Manager peut afficher des messages vous demandant de mettre à jour votre serveur de taggage jusqu'à 24 heures après la mise à jour réussie du serveur. Toutefois, la page d'aperçu affichera un message à jour sur la version du serveur de taggage.
Résoudre les problèmes de délai d'expiration des déploiements en production
Lorsque vous exécutez le script de configuration pour créer ou reconfigurer le serveur de taggage, le script peut expirer. Plusieurs raisons peuvent expliquer cela. Voici les deux plus courantes :
Les comptes de service ne disposent pas des autorisations appropriées : les comptes de service Compute Engine et App Engine sont responsables du déploiement et de la maintenance du déploiement en production. Par défaut, ils sont préconfigurés avec les autorisations appropriées. Toutefois, il arrive que la règle d'une organisation les rende incorrects.
- Accédez à la page IAM et administration dans la barre de navigation de gauche de la console Google Cloud.
- Recherchez le compte de service Compute Engine
<project_number>-compute@developer.gserviceaccount.comet le compte de service App Engine<project_name>@appspot.gserviceaccount.com. - Les deux comptes de service doivent disposer du rôle
Editor. Si l'un des comptes ne dispose pas du rôleEditor, mettez-le à jour en cliquant sur l'icône en forme de crayon à droite du compte, puis sur le menu déroulant du rôle existant. Faites défiler la page vers le haut et cliquez sur Projet, puis sur Éditeur.
Quota insuffisant : le déploiement en production consomme du quota Compute Engine. Si le projet ne dispose pas d'un quota suffisant, le déploiement peut expirer lors de la tentative de provisionnement des ressources.
- Accédez à la page IAM et administration dans la barre de navigation de gauche de la console Google Cloud, puis cliquez sur l'onglet Quotas dans la barre de navigation de gauche.
- En haut de la page, cliquez sur la zone de texte Filtrer le tableau et saisissez
Compute Engine API. Cliquez sur le seul résultat. - Vérifiez que tous les états de quota sont dans les limites ou comportent une coche verte.
- Recherchez Processeurs et cliquez dessus. Vérifiez que l'utilisation actuelle plus le nombre d'instances déployées resteront en dessous de la limite pour la région de déploiement.