Analytics

Guide des modèles personnalisés pour Google Tag Manager

Dernière mise à jour le 12 août 2020: Ajout de détails sur le balisage côté serveur.

Comme j’ai enfin réussi à ramasser ma mâchoire du sol, il est maintenant temps de vous dire ce qui m’excite tant. Google Tag Manager a récemment publié une nouvelle fonctionnalité appelée Modèles personnalisés. En fait, ce n’est pas juste de l’appeler un caractéristique. C’est un changement de paradigme à part entière dans la façon dont nous utilisons Google Tag Manager. C’est un suite de fonctionnalités conçues pour aider les marques, les entreprises et les utilisateurs à créer et à partager facilement leurs propres configurations JavaScript et HTML personnalisées, tout en veillant à ce que le code soit optimisé pour être diffusé dans le navigateur Web.

modèles personnalisés dans google tag manager

Modèles personnalisésen bref, sont des modèles de balises, de variables et de clients qui vous peut créer et configurer. En d’autres termes, si vous avez une idée intéressante pour une balise (par exemple, une balise de suivi analytique pour un fournisseur non pris en charge nativement par GTM), une variable (par exemple, une variable JavaScript personnalisée qui fait quelque chose avec une chaîne) ou un client (par exemple un point de terminaison côté serveur pour un nouvel outil d’analyse), vous pouvez désormais les transformer en modèles réutilisables qui peuvent, à leur tour, être partagés avec d’autres utilisateurs et conteneurs via l’exportation et l’importation de modèles. Vous pouvez également utiliser la galerie de la communauté pour distribuer vos modèles.

Exemple de modèle

Les modèles utilisent une version personnalisée et en bac à sable de JavaScript, qui a sa propre langue vernaculaire idiosyncrasique que vous devez apprendre (avec l’aide de ce guide, bien sûr). La raison de cette complexité supplémentaire est qu’avec les modèles, vous pouvez vous assurer que le code exécuté est sûr, non intrusif et optimisé.

De plus, les modèles que vous créez définiront certains autorisations qui sont nécessaires pour que le code du modèle puisse s’exécuter. Un niveau de gouvernance supplémentaire est assuré par Stratégies défini sur la page Web elle-même où le code du modèle peut être exécuté. L’interaction entre ces autorisations et ces stratégies est une fonctionnalité essentielle de la sécurité des modèles.

Il y a beaucoup, beaucoup de choses à couvrir dans ce guide, alors commençons.

Table des matières

Table des matières

[+show] [–hide]

Comment lire ce guide

C’est un long guide. Il doit l’être – il y a tellement de modèles personnalisés qui doivent être abordés dans tout document dont le but est de fournir un traitement complet du sujet.

Cependant, n’interprétez pas mon incapacité à écrire de la prose concise comme une indication de la complexité des modèles personnalisés. Je peux vous assurer qu’ils sont absolument gérables par quiconque utilise Google Tag Manager depuis un certain temps.

Ce guide est un référence. Son but est de vous proposer une documentation pour étayer votre travail avec des modèles personnalisés.

Pour cette raison, je veux suggérer différentes façons d’aborder ce guide.

  • Toutes les personnes devriez lire les chapitres Modèles personnalisés en bref et Concepts de base.

  • Je le recommande vraiment toutes les personnes jetez un œil aux deux procédures pas à pas du chapitre Mise en route.

  • Gardez la documentation officielle à portée de main à tout moment, en particulier les références API pour les modèles Web et pour les modèles côté serveur.

  • Lorsque vous travaillez avec des modèles, le chapitre sur l’éditeur de champs (avec une analyse approfondie des configurations de champs) devrait être très utile – le même que celui sur les autorisations.

  • Si vous êtes un administrateur de site, vous voudrez peut-être lire la référence des politiques pour avoir une idée de la façon dont vous pouvez restreindre davantage l’exécution de code personnalisé sur votre site.

  • Si vous souffrez d’insomnie, commencez par le début et ne vous arrêtez pas avant de vous endormir. Cela devrait arriver au bout de 10 000 mots.

Assurez-vous de consulter mon autre guide sur la façon de créer un modèle de pixel Facebook – il devrait vous éclairer davantage sur le fonctionnement des modèles. Vous pouvez également consulter la vidéo correspondante si vous préférez regarder plutôt que lire.

Vous pouvez également voir tous les modèles personnalisés que j’ai créés et/ou collectés dans ce référentiel GitHub et dans la section Modèles de ce site.

Modèles personnalisés en bref

Les modèles personnalisés de Google Tag Manager offrent un moyen de créer une interface utilisateur autour du code personnalisé que vous souhaiterez peut-être exécuter sur le site à l’aide de Google Tag Manager. L’interface utilisateur est celle à laquelle vous vous êtes habitué lorsque vous utilisez les balises et les variables de GTM. Il comporte champs de saisie de texte, Les paramètres, les tables, Étiquettes, menus déroulantset ainsi de suite.

Modèle de balise avant et après

De toute évidence, l’interface utilisateur elle-même est déjà un énorme atout. Le fait de pouvoir offrir une interface utilisateur au lieu d’un bloc de code compliqué minimisera les problèmes résultant d’erreurs de saisie et aidera à maintenir la stabilité du code.

Cependant, les modèles ont une autre fonction moins apparente (mais non moins percutante). Ils ajoutent des couches de protection et Sécurité au code qu’ils résument. Les modèles utilisent une coutume Cadre JavaScript qui introduit une poignée d’API (interfaces de programmation d’applications) que vous devez utiliser si vous voulez que le code fasse réellement quelque chose.

Cela introduit une courbe d’apprentissage abrupte, car vous ne pouvez plus simplement copier-coller le code de Stack Overflow. Si vous voulez définir un global window propriété, vous devez utiliser une API pour cela. Si vous souhaitez vous connecter à la console, vous devez utiliser une API pour cela. Si vous voulez vérifier la valeur d’un cookie, devinez quoi, vous devez utiliser une API pour cela.

API en cours d'utilisation

Fondamentalement, tout code qui tente d’accéder à l’état global de la page ou d’exécuter des fonctions JavaScript natives définies au niveau global nécessite un appel d’API.

Alors pourquoi cette complexité supplémentaire ? Eh bien, d’une part, ces API garantissent que les modifications potentiellement dangereuses et/ou intrusives de l’état global sont effectuées de manière contrôlée.

Chaque fois que vous souhaitez utiliser une API, vous devez require() dans le code du modèle. Et lorsque vous introduisez une API comme celle-ci, le modèle génère automatiquement un ensemble d’autorisations configurables pour cet appel d’API.

Autorisations API

En un mot, les modèles encapsulent la logique que vous introduiriez autrement avec du code personnalisé. En introduisant des API avec autorisationsles modèles peuvent être configurés pour fonctionner dans un contexte sécurisé et facilement géré.

Un niveau de sécurité supplémentaire est l’introduction de Stratégiesoù vous, en tant que propriétaire du site, pouvez ajouter du code à la page Web elle-même, ce qui peut avoir des niveaux de contrôle supplémentaires sur la façon dont les autorisations de modèle sont résolues.

Par exemple, si j’ai une balise configurée pour envoyer des hits à un point de terminaison, je peux écrire une politique sur la page qui n’autorise les demandes de pixels qu’à l’un des nombreux points de terminaison configurés dans la balise.

window.dataLayer = window.dataLayer || []; function gtag(){dataLayer.push(arguments);}  gtag('policy', 'send_pixel', function(container, policy, data) {   if (data.url !== 'https://snowplow.simoahava.com/i') {     throw('Invalid pixel endpoint!');   } else {     return true;   } }); 

Avec cette stratégie en place, la demande d’image ne sera exécutée que si l’URL du point de terminaison est https://snowplow.simoahava.com/i. Sinon, la balise échouera dans une erreur, et vous pouvez voir le message d’erreur dans le les erreurs onglet du mode Aperçu.

Erreurs de balise

Un avantage supplémentaire de l’utilisation de modèles est que vous n’avez pas à ajouter le méchant unsafe-eval mot-clé à votre politique de sécurité du contenu. Tout code exécuté via un modèle est compilé en JavaScript lorsque le conteneur est écrit, et ne nécessite donc pas l’utilisation de eval().

Inversement, avec les balises HTML personnalisées et les variables JavaScript personnalisées, le code est écrit dans une chaîne qui est ensuite compilée avec eval() lors de l’exécution. Ceci est une mauvaise pratique et nécessite un énorme compromis en matière de sécurité si vous utilisez une politique de sécurité du contenu.

J’espère que vous pouvez voir l’utilité des modèles personnalisés. Imaginez une bibliothèque de modèles personnalisés, où n’importe qui peut partager son propre travail pour que d’autres puissent le télécharger et l’utiliser dans ses conteneurs. Les petites marques et entreprises pourraient enfin mettre leurs outils et plates-formes à la disposition du grand public à l’aide de Google Tag Manager.

Mise à jour 2 octobre 2019: Vous n’avez plus besoin d’imaginer une telle bibliothèque telle qu’elle existe maintenant. Consultez la galerie de modèles de la communauté ainsi que mon introduction à celle-ci.

Commencer

Avant de vous épuiser avec tous les détails sur les modèles personnalisés (et croyez-moi, il y a un parcelle à digérer dans la fonctionnalité), je veux commencer par vous guider dans la création d’un modèle de balise et un modèle variable. Nous n’utiliserons pas toutes les fonctionnalités les plus complexes pour cela, mais cela devrait servir d’introduction intéressante au fonctionnement des modèles personnalisés dans Google Tag Manager.

Assurez-vous de consulter ce guide pour une présentation de la création d’un modèle de client pour balisage côté serveur.

N’oubliez pas de consulter mon autre article, qui traite de la création d’un modèle de pixel Facebook. Il devrait fournir un aperçu plus complet (et plus accablant) de la façon dont les modèles sont créés.

Présentation du modèle de tag

Dans cette procédure pas à pas, nous verrons comment créer un simple balise d’injection de script. C’est le nombre de fournisseurs tiers qui souhaitent que leurs scripts soient chargés.

Nous utiliserons une merveilleuse entreprise appelée Conductrics comme exemple. Ils ont développé un outil avec lequel vous pouvez effectuer des tests A/B et de la personnalisation, en utilisant une logique de ciblage basée sur ML, des objectifs dynamiques, des options de déploiement côté serveur et côté client, et toute une série d’autres fonctionnalités pour vous aider à répondre à ces questions commerciales difficiles que vous avez avec Les données.

Modèle d'étiquette conductrice

Note! Vous pouvez bien sûr remplacer les éléments spécifiques à Conductrics par une URL source d’un autre fournisseur, si vous le souhaitez. Les étapes que vous suivez dans ce guide seraient toujours identiques.

Le modèle de balise est simple, de par sa conception. Conductrics offre la possibilité d’héberger le JavaScript requis pour vous, il vous suffit donc d’ajouter le <script> tag à la page qui charge la bibliothèque JavaScript à partir du serveur de Conductrics.

Cependant, j’ai ajouté du sucre dans l’interface utilisateur pour rendre la configuration un peu plus intéressante.

Fondamentalement, tous les modèles comprennent quatre composants :

  1. Les détails, qui déterminent le nom, le logo et la description du modèle.

  2. L’interface utilisateur, qui régit les champs et les configurations de champ du modèle.

  3. L’éditeur de code, qui utilise toutes les entrées de l’utilisateur dans les champs pour exécuter le code du modèle réel.

  4. Les autorisations, qui déterminent le type de code pouvant être exécuté par la balise.

Nous allons parcourir chacune de ces étapes ici.

Étape 1 – Créer et définir les détails du modèle de balise

La première chose à faire est de créer un nouveau modèle de tag :

Créer un nouveau modèle de balise

Ensuite, remplissez quelques détails. Pour l’image, j’ai utilisé le logo créé par le designer de la marque Conductrics, Joshua McCowen.

Paramètres conductrices

Vous pouvez Sauver le modèle en cliquant maintenant sur l’icône correspondante dans le coin supérieur droit. Vous devriez voir le logo et le titre du modèle dans la fenêtre d’aperçu.

Aperçu de la balise

Là! Presque fini. Eh bien, pas tout à fait.

Étape 2 – Créer l’interface utilisateur

Nous devons maintenant créer les cloches et les sifflets de l’interface utilisateur réelle de la balise.

Tout d’abord, cliquez sur le Des champs pour ouvrir l’éditeur de champs. Ensuite, cliquez sur le bleu Ajouter le champ bouton.

Bouton Ajouter un champ

Dans la superposition qui s’ouvre, sélectionnez Saisie de texte.

Choisissez la saisie de texte

Vous devriez voir apparaître un champ de saisie de texte dans l’éditeur de champs. Renommez le champ en sourceUrl, et modifiez le paramètre Afficher le nom. Le nom du champ est utilisé sous l’éditeur de code, et le Afficher un nom est ce que l’utilisateur voit au-dessus du champ lors de la modification des paramètres de balise.

Renommer le champ de texte

L’interface utilisateur pourrait être prête maintenant – c’est vraiment le seul champ et la seule configuration dont vous auriez besoin.

Mais rendons-le un peu plus robuste en ajoutant quelques validation.

Clique le roue dentée icône associée au champ pour ouvrir la superposition de configuration du champ. Dans la superposition, assurez-vous Afficher un nom, Texte d’aideet Règles de validation sont tous basculés AU.

Chaque type de champ possède son propre ensemble de configurations que vous pouvez modifier pour rendre le champ plus polyvalent.

Configurations sur le terrain

Fermez la superposition en cliquant sur le X dans le coin, ou n’importe où en dehors de la superposition.

Ensuite, ajoutez un texte d’aide. Le texte d’aide peut être vu en survolant le petit point d’interrogation à côté du nom d’affichage lors de la modification de la balise.

Ajouter un texte d'aide

Vous pouvez Sauver le modèle périodiquement pour actualiser l’aperçu du modèle et voir les modifications qui s’y trouvent.

Ensuite, ajoutons quelques règles de validation. Ceux-ci peuvent être utilisés pour s’assurer que l’utilisateur ajoute des valeurs valides aux champs.

Cliquez sur Ajouter une règle et modifier la règle pour correspondre à une expression régulière où l’expression est ^https://.*. Les expressions régulières de validation recherchent matchs complets uniquementvous devez donc ajouter le début et/ou la fin .* utiliser un modèle ouvert.

Première règle de validation

Ensuite, cliquez sur le petit menu d’action dans le coin supérieur de la boîte de règle de validation, et sélectionnez Afficher les paramètres avancés.

Afficher les paramètres avancés

Les règles de validation ont deux paramètres avancés. Le premier est l’endroit où vous pouvez fournir un message d’erreur personnalisé (que nous utiliserons). La seconde est celle où vous pouvez établir des conditions pour lorsque cette règle de validation est active (ou inactive).

Dans ce cas, ajoutons un message d’erreur descriptif. Met le Message d’erreur champ à The URL must start with "https://"..

Message d'erreur

Vous pouvez maintenant rapidement test comment cela fonctionne. Cliquez sur Sauver dans le coin supérieur droit, puis cliquez sur le modèle de tag en mode aperçu pour passer en mode édition. Ajoutez une chaîne au champ de saisie de texte qui n’a pas commencez par “https://”, puis cliquez sur le Test bouton dans le coin supérieur droit. Vous devriez voir votre message d’erreur.

Message d'erreur affiché

Cool, non ?

Ajoutons deux plus de règles de validation. Faites-les ressembler à ceci :

Dernières règles de validation

La première règle garantit que le script est chargé à partir d’un *.conductrics.com domaine, et la deuxième règle exige que l’URL du script ait le apikey paramètre.

Une dernière chose que nous ajouterons à l’interface utilisateur est un simple déboguer basculer.

Clique le Ajouter le champ bouton et sélectionnez Case à cocher de la superposition.

Case à cocher

Définissez le nom du champ sur débogueret réglez le Texte de la case à cocher champ à Consigner les messages de débogage dans la console. N’hésitez pas à enregistrer le modèle pour voir à quoi ressemble la case à cocher dans la nature.

Case à cocher dans l'aperçu du modèle

Nous en avons fini avec l’interface utilisateur, enfin !

Étape 3 – Ajouter du code

Maintenant, sélectionnez le Code onglet de l’éditeur de modèles. Vous devriez voir un code passe-partout qui vous aidera à démarrer (nous le remplacerons par d’autres éléments assez tôt).

Éditeur de code

Pour étiqueter templates, le code que vous écrivez comporte trois composants dont vous devez être conscient.

  • Les format de code lui-même, qui utilise un JavaScript spécial en bac à sable. Ce JS en bac à sable offre un tas d’API modèles que vous pouvez utiliser pour travailler avec JavaScript en dehors de la portée du code lui-même (accès dataLayerécrire des cookies, etc.).

  • Les data objet, qui comprend le contenu des champs de balise avec lesquels l’utilisateur a pu interagir.

  • Les data.gtmOnSuccess() et data.gtmOnFailure() méthodes, qui indiquent respectivement le succès ou l’échec de l’exécution de la balise.

Avec ces trois éléments à l’esprit, nous devons faire ce qui suit.

  1. Nous avons besoin de la balise pour charger le JavaScript de Conductrics à partir de son réseau, ce qui signifie que nous utiliserons le injectScript API pour le faire.

  2. Nous prendrons l’URL du injectScript API à partir du champ de texte dans la balise, et si l’utilisateur a choisi d’écrire des messages de débogage sur la console, nous respecterons ce choix.

  3. Si le script se charge correctement, nous le signalerons avec data.gtmOnSuccess()mais en cas d’échec (tel qu’un 404 erreur), nous appellerons le data.gtmOnFailure() méthode.

Succès et échec sont pertinents pour la sortie en mode Aperçu et également pour le séquençage des balises.

Sans plus tarder, voici le code complet par lequel vous devez remplacer le contenu de l’éditeur de code :

// Require the necessary APIs const logToConsole = require('logToConsole'); const injectScript = require('injectScript'); const queryPermission = require('queryPermission');  // Get the URL the user input into the text field const url = data.sourceUrl;  // If the user chose to log debug output, initialize the logging method const log = data.debug ? logToConsole : (() => {});  log('Conductrics: Loading script from ' + url);  // If the script loaded successfully, log a message and signal success const onSuccess = () => {   log('Conductrics: Script loaded successfully.');   data.gtmOnSuccess(); };  // If the script fails to load, log a message and signal failure const onFailure = () => {   log('Conductrics: Script load failed.');   data.gtmOnFailure(); };  // If the URL input by the user matches the permissions set for the template, // inject the script with the onSuccess and onFailure methods as callbacks. if (queryPermission('inject_script', url)) {   injectScript(url, onSuccess, onFailure); } else {   log('Conductrics: Script load failed due to permissions mismatch.');   data.gtmOnFailure(); } 

Les commentaires de code devraient vous aider à comprendre comment le code fonctionne. Voici quelques éléments clés sur le code :

  • Les Apis sont chargés de require() méthode. Vous devez utiliser ces API – leurs équivalents dans le JavaScript du navigateur ont été supprimés. Par example, console.log() ne fonctionnerait pas, ni document.createElement().

  • Les data l’objet a des clés correspondant à noms de champs vous avez modifié dans l’éditeur de champ. Toute valeur de ces champs sera les valeurs stockées dans le data chose. Ainsi, si l’utilisateur tape hello dans le sourceUrl champ, cette valeur serait disponible via data.sourceUrl.

  • En utilisant queryPermission() est un bon moyen de s’assurer que l’entrée de l’utilisateur correspond aux autorisations définies dans le modèle. Les autorisations sont mises à jour automatiquement lorsque vous require() une API spécifique dans l’éditeur de code (nous reviendrons sur les permissions au chapitre suivant).

L’essentiel à noter est que cet éditeur est un Éditeur JavaScript. Ainsi, contrairement aux balises HTML personnalisées, vous ne devrait pas envelopper le code avec <script> et </script>.

Une fois que vous avez terminé, cliquez sur Sauver et passez au chapitre suivant.

Étape 4 – Modifier les autorisations

La dernière chose à éditer sont les autorisations. Lorsque vous require() API, vous activerez également automatiquement leurs configurations d’autorisation dans le Autorisations languette. Voir le chapitre sur les permissions pour plus de détails sur leur fonctionnement.

Quoi qu’il en soit, puisque vous utilisez le logToConsole et injectScript API, leurs autorisations sont désormais disponibles pour modification. Les queryPermission et require Les API ne sont associées à aucune autorisation.

Cliquez sur le Autorisations onglet et développez les deux autorisations que vous trouvez.

Autorisations étendues

La permission Injects Scripts est, surprise surprise, pour le injectScript API. Il attend des modèles de correspondance d’URL auxquels la valeur saisie par l’utilisateur dans le champ de texte doit correspondre.

Ajouter la valeur https://*.conductrics.com/ dans le champ de texte.

Cette valeur signifie essentiellement que l’URL du script…

Source : www.simoahava.com

Articles similaires

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Bouton retour en haut de la page
Index