Google Tag Manager est strictement un système de livraison d’étiquettes, et veille à ne pas collecter de données d’analyse par lui-même. Il s’agit très probablement d’un choix délibéré, car si GTM commençait à collecter des données, cela introduirait des obstacles supplémentaires à l’adoption.

Néanmoins, étant un outil qui consolide la conception, le développement, le déploiement et le test de tous les pixels marketing et analytiques, extraits de code et utilitaires exécutés sur un site Web ou une application mobile, le manque des fonctionnalités nécessaires à l’audit et à la surveillance a toujours semblé être un oubli.

Récemment, Google Tag Manager a introduit une nouvelle API pour les modèles personnalisés : addEventCallback. Cette API vous permet de créer votre propre système de surveillance pour votre conteneur. Grâce aux efforts de la communauté et au soutien de Google, la nouvelle API introduira prochainement un certain nombre de solutions autour de la surveillance et de l’audit des balises.

Dans cet article, Marc Edmondson et je vais vous aider à démarrer. Nous présenterons le fonctionnement de la nouvelle API et comment vous pouvez l’utiliser pour créer les balises et les déclencheurs nécessaires dans GTM à des fins de surveillance. Nous vous montrerons également comment utiliser les fonctionnalités puissantes, bon marché et évolutives de Google Cloud Platform pour créer le backend du système de surveillance, et enfin nous vous donnerons quelques idées sur la façon de visualiser les données dans un Google Data Studio. rapport.

Vous pouvez également consulter cette vidéo, où je passe par (presque) les mêmes étapes en format vidéo.

Auteur invité : Mark Edmondson

Marc Edmondson est un de mes anciens collègues, un collègue Google Developer Expert pour Google Analytics et le propriétaire de l’un des ensembles de compétences les plus polyvalents de notre secteur. Il travaille actuellement comme ingénieur de données chez IIH Nordic (une super entreprise pleine de gens sympas à part entière !).

Mark sait parfaitement relier les mondes du marketing et de l’analyse, et sa portée s’étend bien au-delà, comme en témoignent ses contributions prolifiques à l’espace open source. Il est l’auteur de la célèbre bibliothèque googleAnalyticsR pour R, et son blog regorge d’excellentes procédures pas à pas pour l’ingénierie des données, la science des données, l’analyse Web et le développement de logiciels.

Étant l’une des personnes les plus humbles que j’ai rencontrées, il est probablement royalement gêné par cette introduction. Je vais donc conclure cette introduction en précisant à quel point je suis reconnaissant pour ses contributions non seulement à cet article, mais à l’ensemble de notre industrie.

Ce que nous allons créer : Google Tag Manager Monitor

Les livrable clé de ce petit projet est une vue BigQuery qui collecte les données de votre site Web. Ces données seront envoyées au moyen d’un nouveau modèle personnalisé Google Tag Manager, et elles comprendront des statistiques de toutes les balises qui se sont déclenchées sur votre site pour une période donnée. dataLayer un événement.

Dans cette preuve de concept, les métadonnées collectées à partir de chaque dataLayer l’événement comprend :

• Nom et horodatage de l’événement (pour distinguer de manière unique les événements portant le même nom les uns des autres).

• ID de balise, nom, état de déclenchement et heure d’exécution de chaque balise qui s’est déclenchée pour cet événement (ou null si aucune balise n’a été déclenchée pour l’événement).

Il est extrêmement facile d’étendre cette solution pour inclure des éléments tels que l’ID de conteneur ou les informations de catégorisation des balises – nous les explorerons plus tard dans le guide.

Pourquoi avons-nous besoin d’un moniteur?

Il n’y a pas beaucoup de façons de surveiller la cohérence des balises déclenchées dans vos conteneurs. De toute évidence, vous pouvez exécuter des rapports sur les différents points de terminaison, tels que Google Analytics ou Facebook, et détecter la collecte de données anormales via leurs interfaces de rapport.

Mais cela a quelques problèmes:

• Tous les points finaux n’ont pas de rapports facilement disponibles.

• Les terminaux collectant des données à partir de plusieurs sources différentes, il est difficile d’identifier ceux qui proviennent de GTM et ceux qui n’en proviennent pas.

• Il est difficile de savoir si les problèmes de données dans les terminaux sont dus à la collecte de données ou à autre chose (par exemple, un filtre défectueux dans Google Analytics).

En d’autres termes, si vous souhaitez être alerté des problèmes de collecte de données, la meilleure façon de le faire est de surveiller la collecte de données elle-même.

Pour que cela soit possible, le mécanisme de collecte de données nécessite la possibilité d’introduire un effet secondaire. L’effet secondaire dans ce cas est le addEventCallback API, et son objectif est de collecter des métadonnées sur la collecte de données de préférence vers un point de terminaison qui est séparé des balises surveillées.

Pourquoi avoir un point de terminaison distinct pour la surveillance ? Eh bien, cela n’aurait pas vraiment de sens de collecter des données sur la collecte de données de Google Analytics dans Google Analytics lui-même (une propriété de rapport personnalisée, par exemple), car si la collecte de données d’analyse échoue en raison de l’impossibilité de se connecter au point de terminaison GA , la collecte des données de surveillance échouerait également.

C’est pourquoi cet article utilise un point de terminaison dans Google Cloud Platform pour collecter les données. Ce n’est pas sûr non plus, car si la collecte de données échoue en raison d’une panne de réseau, la collecte vers GCP échouera également. Même s’il existe également des moyens de résoudre ce problème, nous essaierons de maintenir les choses à un niveau MVP (produit minimum viable), et vous pourrez ensuite étendre la solution pour répondre à vos besoins plus élaborés.

Étape 1 : Créer le modèle personnalisé

La douane étiqueter modèle créera un rappeler qui s’appelle à chaque fois qu’un dataLayer l’événement touche à sa fin. C’est fondamentalement la même chose que l’eventCallback de Google Tag Manager, juste enveloppé dans un modèle d’API.

Lorsque le rappel est appelé, un tableau de balises est transmis au rappel dans un objet de données. Chaque balise est signalée avec les métadonnées suivantes :

• id: ID de balise

• status: Statut de tir (par exemple succès, échec)

• executionTime: Temps d’exécution en millisecondes

Nous allons augmenter cet ensemble de données avec ces valeurs :

• eventName et eventTimestamp (pour identifier de manière unique chaque événement)

• name: Nom de balise

C’est plus facile de montrer en faisant.

Dans Google Tag Manager, ouvrez le Modèles vue et créez un nouveau modèle de balise.

Vous pouvez également télécharger le modèle à partir d’ici et l’importer directement dans votre conteneur.

1.1. Des champs

N’hésitez pas à ajouter ce que vous voulez dans le Info onglet du modèle. Nous sommes allés avec ceci:

Dans l’onglet Champs, nous allons avec deux champs par défaut. Un pour le URL du point de terminaisonet un pour laisser l’utilisateur décider s’il souhaite lot les coups ou pas.

Il existe également un troisième champ, qui devient disponible si l’utilisateur décide de regrouper les résultats.

1.1.1. endPoint domaine

Le premier champ est un champ de saisie de texte nommé endPoint.

Il a les configurations de champ suivantes activées :

• Indice de valeur: e.g. https://track.com/collect

• Afficher un nom: GET request endpoint

• Texte d’aide: Provide the URL to which the GET request with tag data is sent.

• Toujours en résumé: vérifié

• Règles de validation

Il existe deux règles de validation :

• Cette valeur ne peut pas être vide

• Cette valeur doit correspondre à une expression régulière: ^https://.+

Si vous le souhaitez, vous pouvez ajouter des messages d’erreur personnalisés à ces règles de validation en ouvrant les paramètres avancés de chaque règle.

1.1.2. batchHits domaine

Le deuxième champ est un champ Bouton radio nommé batchHits.

Il a les configurations de champ suivantes activées :

• Afficher un nom: Batch hits

• Texte d’aide: If you select No, details of all the tags that fired for any given hit are sent in a single GET request. If you select Yes, you can choose the maximum number of tags per request, and the tag will automatically send multiple requests if necessary.

Il y a deux boutons radio.

Les première l’un est nommé Noet a la valeur no.

Les seconde l’un est nommé Yeset a la valeur yes.

Le bouton Oui a un champ imbriqué (trouvé après avoir affiché les paramètres avancés du bouton), qui est un Saisie de texte champ nommé maxTags.

1.1.3. maxTags domaine

Les imbriqué maxTags le champ est un Saisie de texte champ dans lequel l’utilisateur peut définir une limite de balises envoyées par requête.

Ceci est utile si vous avez des balises avec des noms longs ou dataLayer événements qui peuvent déclencher des dizaines de balises à la fois. L’envoi des requêtes par lots devrait réduire l’effort nécessaire au point de terminaison pour analyser les données dans la table BigQuery.

Le champ a les configurations de champ suivantes activées :

• Afficher un nom: Maximum number of tags per request

• Texte d’aide: Enter the maximum number of tags per request that will be dispatched to the endpoint. If necessary, multiple requests will be made.

• Valeur par défaut: 10

• Règles de validation

La seule règle de validation est Cette valeur doit être un entier positif.

1.2. Code

Dans le Code onglet, ajoutez le code suivant :

// Require the necessary APIs const addEventCallback = require('addEventCallback'); const readFromDataLayer = require('copyFromDataLayer'); const sendPixel = require('sendPixel'); const getTimestamp = require('getTimestamp');  // Get the dataLayer event that triggered the tag const event = readFromDataLayer('event');  // Add a timestamp to separate events named the same way from each other const eventTimestamp = getTimestamp();  const endPoint = data.endPoint; const batchHits = data.batchHits === 'yes'; const maxTags = data.maxTags;  // Utility for splitting an array into multiple arrays of given size const splitToBatches = (arr, size) => {   const newArr = [];   for (let i = 0, len = arr.length; i < len; i += size) {     newArr.push(arr.slice(i, i + size));   }   return newArr; };  // The addEventCallback gets two arguments: container ID and a data object with an array of tags that fired addEventCallback((ctid, eventData) => {    // Filter out tags that have the "exclude" metadata set to true   const tags = eventData.tags.filter(t => t.exclude !== 'true');      // If batching is enabled, split the tags into batches of the given size   const batches = batchHits ? splitToBatches(tags, maxTags) : gestionnaire de balises google,modèles personnalisés,surveiller,plate-forme cloud google,grande requête;      // For each batch, build a payload and dispatch to the endpoint as a GET request   batches.forEach(tags => {     let payload = '?eventName=' + event + '&eventTimestamp=' + eventTimestamp;     tags.forEach((tag, idx) => {       const tagPrefix = '&tag' + (idx + 1);       payload +=         tagPrefix + 'id=' + tag.id +         tagPrefix + 'nm=' + tag.name +         tagPrefix + 'st=' + tag.status +         tagPrefix + 'et=' + tag.executionTime;     });     sendPixel(endPoint + payload, null, null);   }); });  // After adding the callback, signal tag completion data.gtmOnSuccess(); 

La partie fonctionnellement la plus importante de ce code est la addEventCallback() méthode. Cela appelle l’API du même nom.

L’API vérifie le dataLayer événement qui a déclenché la balise créée à partir de ce modèle, puis met à jour dataLayer eventCallback avec la fonction définie dans le modèle.

En d’autres termes, lorsque l’événement qui déclenche cette balise de surveillance est entièrement résolu (c’est-à-dire que toutes les balises ont signalé leur achèvement), la fonction de rappel s’exécutera avec des données sur chacune des balises qui se sont déclenchées sur l’événement.

Il existe une disposition en place pour exclure toutes les balises de la surveillance en fonction d’un champ de métadonnées de balise que vous pouvez définir (plus d’informations à ce sujet ci-dessous). Pour certains, il peut être judicieux d’exclure la balise de surveillance elle-même de la surveillance, même s’il peut être utile de mesurer son temps d’exécution avec toutes les autres balises.

De loin, le code le plus important est exécuté lors de la construction de la charge utile :

batches.forEach(tags => {    let payload = '?eventName=' + event + '&eventTimestamp=' + eventTimestamp;    tags.forEach((tag, idx) => {       const tagPrefix = '&tag' + (idx + 1);       payload +=        tagPrefix + 'id=' + tag.id +        tagPrefix + 'nm=' + tag.name +        tagPrefix + 'st=' + tag.status +        tagPrefix + 'et=' + tag.executionTime;    });    sendPixel(endPoint + payload, null, null); }); 

Ici, chaque balise qui s’est déclenchée sur l’événement est analysée et concaténée dans une charge utile de chaîne de requête d’URL. Par exemple, un dataLayer événement nommé gtm.js qui a déclenché deux balises peut avoir la charge utile suivante :

?eventName=gtm.js &eventTimestamp=1562402273899 &tag1id=12 &tag1nm=GA-PageView &tag1st=success &tag1et=124 &tag2id=29 &tag2nm=Facebook &tag2st=failure &tag2et=422 

Celle-ci est ensuite jointe à l’URL du point de terminaison et une requête GET est envoyée.

Il s’agit de la charge utile qui est capturée par le point de terminaison dans Google Cloud, que Mark montrera plus tard comment créer.

Il est facile d’étendre cela avec des métadonnées supplémentaires. Il suffit de mettre à jour le payload += concaténation avec chaque clé de métadonnées supplémentaire à laquelle vous souhaitez accéder à partir des balises.

1.3. Autorisations

Si vous avez ajouté le code dans l’éditeur de code sans erreur, vous devriez voir trois autorisations prédéfinies dans le Autorisations languette.

• Lit la couche de données : ajoutez la clé event dans la zone de texte.

• Lit les métadonnées d’événement : aucune entrée nécessaire.

• Envoie des pixels : ajoutez l’URL du point de terminaison auquel vous enverrez les données (vous pouvez également utiliser des caractères génériques et des correspondances partielles).

Naturellement, vous ne connaîtrez pas le point de terminaison tant que vous ne l’aurez pas créé, donc si vous voulez tester le modèle avant de créer le point de terminaison, vous pouvez simplement un espace réservé dans les autorisations telles que https://placeholder.com/collect.

Vous pouvez Test le modèle si vous le souhaitez, mais cela ne fera vraiment rien, car le rappel nécessite qu’un événement soit poussé dans dataLayer déclencher.

Sauver le modèle une fois que vous avez terminé.

Étape 2 : Balises et déclencheurs

La première chose que nous devrons faire est de créer le surveiller la balise lui-même.

2.1. Créer la balise de moniteur

Dans GTM, accédez à Mots clés et créer une nouvelle balise. Sélectionnez le modèle que vous venez de créer dans le sélecteur de type de balise.

Le champ de point de terminaison de la requête GET prend le point de terminaison que vous allez créer dans la section suivante, vous pouvez donc simplement utiliser la valeur d’espace réservé de https://placeholder.com/collect là pour l’instant, nous y reviendrons sous peu.

Si vous voulez envoyer les hits par lots, choisissez le Oui bouton radio, mais vous voudrez peut-être commencer sans lots et utiliser simplement les paramètres par défaut.

Ensuite, développez Réglages avancés et faites défiler jusqu’à un nouveau paramètre nommé Métadonnées de balise supplémentaires.

Cliquez dessus pour l’ouvrir et cochez la case nommée Inclure le nom de la balise. Met le Clé pour le nom de la balise valeur à name.

Ajoutez une nouvelle métadonnée en cliquant sur le + Ajouter des métadonnées et définissez ces valeurs :

• Clé: exclude

• Évaluer: true

Étant donné que ce moniteur doit surveiller chaque événement qui se déclenche dans votre conteneur, ajoutez un nouveau Déclencheur d’événement personnalisé à la balise qui ressemble à ceci :

Avec cette expression régulière pour le nom de l’événement, la balise de surveillance se déclenchera pour chaque dataLayer un événement.

Enregistrez le déclencheur et la balise lorsque vous êtes prêt.

2.2. Le paramètre Métadonnées de balise supplémentaires

Comme vous pouvez le voir, il y a un nouveau paramètre avancé pour les balises Google Tag Manager.

Cette Métadonnées de balise supplémentaires vous permet d’ajouter des métadonnées à chaque balise du conteneur. Ces métadonnées sont ajoutées aux balises transmises au eventCallback du dataLayer.push() (comme celui ajouté par le addEventCallback API de modèle personnalisé).

Une métadonnée prédéfinie vous est déjà donnée : la nom de la balise. En vérifiant le Inclure le nom de la balise boîte, la eventCallback l’objet de données inclura toujours le name key (ou la touche que vous attribuez), automatiquement définie sur le nom de la balise.

Vous pouvez également ajouter des métadonnées supplémentaires, telles que la catégorie ou le type de balise.

N’oubliez pas que la solution telle qu’établie dans cet article n’utilise que la balise name et exclude clés de métadonnées. Toute autre métadonnée que vous ajoutez nécessitera un changement de code dans le modèle, car les nouvelles métadonnées devront également être concaténées dans la chaîne de charge utile.

2.3. Mettez à jour toutes vos balises

La dernière chose que vous aurez à faire dans GTM (à part mettre à jour l’URL du point de terminaison de la balise de surveillance lorsque vous en avez une), est de mettre à jour chacun de vos balises pour inclure la balise name métadonnées. Le nom de la balise est plus facile à interpréter que l’ID de la balise lors de la création de vos rapports et visualisations.

Pour chaque balise, développez la Réglages avancés et vérifier le Inclure le nom de la balise case à cocher sous Métadonnées de balise supplémentaires. N’oubliez pas de définir le nom de la clé sur name aussi.

Espérons que le nom de la balise sera automatiquement inclus en tant que métadonnées à l’avenir – cela semble être une fonctionnalité sensée à avoir toujours activée. Ou, à tout le moins, retournez la case à cocher et exigez qu’elle soit cochée si vous voulez exclure le nom de la balise à partir des métadonnées de la balise.

À ce stade, vous devriez avoir votre balise de surveillance avec presque tous les paramètres en place, et vous devriez maintenant avoir modifié toutes vos balises pour inclure le nom de la balise. La balise de surveillance doit avoir un déclencheur d’événement personnalisé qui le déclenche pour chaque dataLayer un événement.

N’hésitez pas à tester en mode Aperçu pour voir si le point de terminaison est appelé avec une chaîne de requête appropriée. Vous devriez voir quelque chose comme ça dans les journaux réseau de votre navigateur, en supposant que vous avez utilisé l’URL d’espace réservé de https://placeholder.com/collect.

Ensuite, Marquer nous montrera comment faire fonctionner le point de terminaison Google Cloud Platform !

Étape 3 : Créer le point de terminaison Google Cloud Platform

Le point de terminaison GCP doit traiter le Requêtes GET envoyés depuis le site, insérez-les dans un Tableau BigQueryles analyser en colonnes et en lignes, et enfin connecter les données à Studio de données Google.

3.1. Choisir la solution GCP pour le point de terminaison

En résumant les exigences du cas d’utilisation ici, nous cherchons à transformer un appel d’API contenant les données de balise GTM en données utiles pour l’analyse. Il existe de nombreuses façons de résoudre ce cas d’utilisation particulier sur GCP – nous allons passer en revue certaines et montrer pourquoi nous avons finalement opté pour Cloud Functions.

Les exigences générales de la solution étaient :

• Sans serveur: donc nous ne gardons pas un serveur mais sommes capables de gérer un trafic élevé et/ou de réduire à coût zéro lorsqu’aucune donnée n’est collectée.

• Low-code: facile à déployer et à entretenir.

• Configuration basse: maintenance minimale afin qu’il puisse être généralisé et puisse facilement gérer différents schémas de données.

La sortie finale doit être un tableau de bord dans Data Studio. Le choix naturel pour la destination finale a donc été BigQuery en raison de la possibilité de se connecter via son connecteur Data Studio natif.

Petit aparté: Nous craignons que les tableaux de bord ne soient une solution définitive pour les flux de données car ils reposent sur un être humain pour réagir pour vous donner un retour sur investissement. C’est bien pour une preuve de concept, mais pour votre propre projet, considérez votre cas d’utilisation réel – peut-être pourriez-vous plutôt implémenter alertes automatiques si certains seuils de qualité des données étaient dépassés ou quelque chose de similaire.

Compte tenu des exigences ci-dessus, certaines solutions comprenaient :

3.1.1. Suivi des pixels via un équilibreur de charge

Nous avons d’abord pensé à une solution de suivi des pixels, car en théorie, les seules étapes nécessaires consistent à importer un pixel dans Cloud Storage, à le rendre accessible au public, puis à diffuser les journaux d’accès dans BigQuery.

Cependant, le point de terminaison API résultant est une adresse IP HTTP (par exemple http://111.222.333.444) et l’API Google Tag Manager nécessite une communication via HTTPS. Il est tout à fait possible d’attribuer un domaine personnalisé et un certificat SSL à l’équilibreur de charge, mais pour rendre la démo plus accessible à tous, nous voulions trouver une solution qui fournisse son propre domaine et point de terminaison HTTPS.

Toutefois, si vous disposez d’un nom de domaine personnalisé, l’équilibreur de charge est probablement le solution la plus robuste à utiliser, car il ne nécessite pas la surcharge de l’exécution d’une application programmée.

3.1.2. Moteur d’application

Le prochain arrêt était App Engine, qui jusqu’à l’année dernière aurait été celui que nous poursuivions. En fait, voici un code sur la façon de configurer le streaming de GTM vers BigQuery que Mark a écrit il y a trois ans.

Cependant, depuis lors Fonctions cloud avoir…