Depuis l’introduction des modèles personnalisés en mai 2019, la communauté (moi y compris) attend avec impatience une solution officielle pour conserver et distribuer les modèles créés par la communauté.

Maintenant, enfin, nous l’avons. Ça s’appelle le Galerie de modèles de la communauté! Lisez l’annonce de Google dans cet article de blog.

Je ne vais pas revenir sur les bases dans cet article, car la propre documentation de Google se suffit à elle-même. Cependant, je souhaite discuter de certaines des façons dont vous pouvez rationaliser la mise à jour et le partage de ces jolis modèles que vous avez créés.

N’oubliez pas qu’il existe également d’autres sources de modèles, à savoir :

• Modèles GTM – bibliothèque de modèles open source pour les modèles communautaires (voir ici) pour plus d’informations.
• GoogleTagManagerTemplates – Référentiel GitHub pour les modèles de la communauté.

Qu’est-ce que la galerie de modèles de la communauté ?

La galerie de modèles de la communauté est la propre bibliothèque intégrée de Google Tag Manager pour le téléchargement et la distribution de modèles entre les utilisateurs, les comptes et les conteneurs.

N’importe qui membres de la communauté peuvent soumettre un modèle à la galerie et ainsi mettre leur travail à la portée de tous les utilisateurs de Google Tag Manager dans le monde.

REMARQUE! Tous les modèles ne seront pas publiés. Votre modèle doit suivre le guide de style, et s’il existe déjà un modèle avec des fonctionnalités similaires dans la galerie, votre modèle risque de ne pas être publié.

Les modèles peuvent être ajoutés à un conteneur en cliquant sur le Rechercher dans la galerie à côté des listes Modèles de balises et Modèles de variables dans la Modèles partie du conteneur.

Cela ouvre une superposition dans laquelle vous pouvez effectuer des recherches de chaînes pour le modèle que vous souhaitez ajouter à votre conteneur.

La superposition de modèles vous permet ajouter le modèle à l’espace de travail en cliquant sur le bouton correspondant (1). Ici, vous pouvez jeter un dernier coup d’œil aux autorisations avant de choisir d’ajouter le modèle à l’espace de travail actuel.

Les petit lien fléché dans le coin ouvre la page de modèle dans la galerie elle-même (2).

Vous pouvez cliquer sur le nom de l’auteur pour accéder à leur profil GitHub (3). La coche verte indique que cette organisation a été vérifiée dans GitHub.

Les autorisations La vue d’ensemble est importante, car elle vous permettra d’évaluer les types d’autorisations dont le modèle pourrait avoir besoin (4). Les icônes de danger rouge et d’avertissement grise vous avertissent que le modèle chargera du code potentiellement dangereux, et vous ne devez ajouter le modèle que si vous faire confiance à l’auteur.

Il existe des liens directs vers référentiel de modèles dans GitHub, et au problèmes section du dépôt (5).

Vous pouvez également visiter la galerie de modèles de la communauté directement à l’URL https://tagmanager.google.com/gallery/. Il a toutes les mêmes fonctionnalités que la superposition.

GitHub

Comme vous l’avez peut-être remarqué ci-dessus, pour soumettre un modèle, vous devez créer un Référentiel GitHub pour ça.

GitHub est une communauté de gestion et de partage code. Il est utilisé pour gérer et coordonner les projets exécutés sur le système de contrôle de version Git.

GitHub est gratuit, bien qu’il existe également un niveau payant, qui vous offre des avantages tels que la possibilité de créer des référentiels privés.

Pour les besoins de la galerie de modèles de la communauté, chaque modèle nécessite son propre référentiel public dans GitHub. Cela peut entraîner des frais généraux pour les utilisateurs qui soumettent de nombreux modèles, mais cela permet à Google Tag Manager d’analyser plus facilement le bon modèle à chaque fois, de gérer les métadonnées et d’avoir le Problèmes fonctionnalité (essentiellement le suivi des bogues et des fonctionnalités) soit dépourvue d’ambiguïtés, car il n’y a qu’un seul modèle auquel les problèmes se rapportent.

Pour être un modèle valide pour la galerie, le référentiel nécessite les trois fichiers suivants dans le racine:

Ces trois fichiers devoir être à la racine du référentiel ou vous ne pourrez pas télécharger le modèle dans la galerie de modèles de la communauté.

Le référentiel pouvez ont également d’autres fichiers (comme un README), mais ces trois sont obligatoires.

Le moyen le plus simple de commencer est de créer un référentiel public, puis d’utiliser l’option de téléchargement de fichiers pour ajouter des fichiers au référentiel.

Une fois que vous êtes à l’aise avec GitHub, je vous recommande d’installer les outils de ligne de commande git et de travailler à partir de votre terminal.

template.tpl

Pour que le fichier modèle soit accepté dans la galerie, vous devoir cochez la case intitulée “Accepter les conditions d’utilisation de la galerie de modèles communautaires” disponible dans le Info onglet de l’éditeur de modèles.

Vous devrez également manuellement modifier le template.tpl fichier (je suis sûr que cela sera bientôt remplacé par une fonctionnalité d’interface utilisateur) pour ajouter catégories à elle. Les catégories seront utilisées pour catégoriser (d’oh) les modèles dans l’interface utilisateur de la galerie.

{   "displayName": "My template",   "categories": ["AFFILIATE_MARKETING", "ADVERTISING"],   // etc... }

En savoir plus sur les catégories disponibles ici.

En dehors de cela, il n’y a pas grand-chose à dire sur le fichier de modèle. Vous aurez besoin de exportation le fichier de GTM et assurez-vous qu’il est renommé en template.tpl avant de le télécharger sur votre référentiel GitHub.

metadata.yaml

Le fichier de métadonnées est fourni dans le YAML forme (abréviation de OuiLAM UNpas Markup Llangue). La seule exigence est qu’il ait le versions clé remplie avec les hachages de tous les commits que vous souhaitez inclure en tant que changements de version dans l’entrée de la galerie de modèles.

Voici un échantillon metadata.yaml dossier:

homepage: "https://www.simoahava.com/" documentation: "https://www.simoahava.com/analytics/create-facebook-pixel-custom-tag-template/" versions:   # Latest version   - sha: d7bad4f7a6e39c72dbc72afc7773d7fb8fdc358c     changeNotes: Update template metadata.   # Older versions   - sha: ff7bf31a0777e22a370d6371607022fe2a6d1b7c     changeNotes: |2       Add support for "consent" command.       Add support for using a variable to populate object properties.   - sha: e1206f9c677fe67348c6678c4669952cb0c0b97b     changeNotes: Initial release.

Utilisez le homepage clé pour indiquer l’URL de la page d’accueil du site Web pour le modèle, et utilisez la documentation clé pour indiquer où trouver la documentation.

Les versions la clé est l’endroit où vous imbriquez tous les commits au fichier template.tpl que vous souhaitez considérer comme neuf versions du modèle.

Chaque version comprend deux clés. La première clé, shaest obligatoire et correspond à la valider le hachage pour le commit où vous avez apporté les modifications finales au template.tpl dossier. La deuxième clé, changeNotesest facultatif et est l’endroit où vous ajoutez des détails sur ce qui a été modifié.

Les versions doivent être répertoriées de sorte que la version la plus récente soit la première entrée, et les versions plus anciennes sont répertoriées après celle-ci, de la plus récente à la plus ancienne.

Vous pouvez suivre mon exemple et utiliser le commentaire # Latest version pour séparer visuellement les anciennes versions (répertoriées après le # Older versions commenter).

Alors, comment trouvez-vous cela sha hacher? Eh bien, chaque fois que vous faites un commettre à GitHub, le commit recevra un hachage qui identifiera de manière unique le commit.

Ainsi, chaque fois que vous faites un commit qui inclut les modifications apportées à template.tplet que vous considérez que cette validation est suffisamment importante pour justifier une nouvelle version du modèle, vous devez accéder au engage de votre dépôt GitHub, trouvez le commit en question et copiez son hachage.

Le moyen le plus simple de trouver les commits est de prendre votre URL de dépôt GitHub et d’ajouter /commits/ à la fin, par exemple https://www.github.com/gtm-templates-simo-ahava/user-distributor/commits/.

Ensuite, recherchez le commit dont vous voulez le hachage et cliquez sur le bouton du presse-papiers pour copier le hachage dans le presse-papiers.

Enfin, ajoutez un nouvel élément sous versions dans le metadata.yaml avec le hachage sous le sha clé et toutes les notes de modification sous la changeNotes biens. Vous pouvez spécifier des notes multilignes avec le symbole de tuyau |2 comme dans l’exemple au début de ce chapitre.

Note! Vous n’avez pas besoin d’ajouter chaque commit à template.tpl en tant que nouvelle version. Vous pouvez d’abord effectuer des mises à jour incrémentielles, puis lorsque vous êtes prêt avec une mise à jour de version, vous copiez le hachage du dernier commit, car il inclurait également tous les commits précédents.

A son strict minimum, le metadata.yaml le fichier a juste besoin du sha clés, donc cela fonctionnerait aussi:

versions:   - sha: abcd12345   - sha: bcde23456   - sha: cdef34567

Le but de versionner les modèles comme celui-ci est qu’avec le temps, la galerie introduira des fonctionnalités permettant aux utilisateurs qui ont importé les modèles d’être informés des modifications apportées aux sources des modèles. Pour que cela fonctionne, l’auteur du modèle doit ajouter des informations de version au fichier de métadonnées.

LICENCE

Vous pouvez trouver le texte de la licence Apache 2.0 ici : https://www.apache.org/licenses/LICENSE-2.0.txt. Enregistrez-le sous LICENSE dans votre référentiel et assurez-vous de modifier le texte du copyright à la fin.

Astuce GitHub #1 : Ajouter un nouveau modèle à la galerie

Lorsque vous souhaitez ajouter un nouveau modèle à la galerie, c’est (à peu près) le processus que vous suivrez.

ÉTAPE 1: Créez un nouveau référentiel dans GitHub. Assurez-vous que c’est Public et qu’il a le Apache 2.0 licence ajoutée. Si vous créez des modèles sous un organismeassurez-vous que le référentiel est créé au bon endroit.

ÉTAPE 2: Créez le modèle dans Google Tag Manager. Assurez-vous d’avoir coché la case des conditions d’utilisation de la galerie communautaire dans le Info languette. Exportez le modèle en tant que template.tpl dossier.

ÉTAPE 3: Dans le référentiel GitHub, choisissez Télécharger des fichiers pour télécharger votre fichier de modèle dans GitHub. Validez la modification avec un nom de validation clair, par exemple “Publication initiale de template.tpl”. Engagez-vous directement auprès de master bifurquer.

ÉTAPE 4: Visiter le /s’engage/ page du dépôt et copiez le hash de commit du dernier commit dans le presse-papiers.

ÉTAPE 5: De retour à la racine du référentiel, cliquez sur Créer un nouveau fichier. Nommez le fichier metadata.yaml. Le contenu doit être au moins ce qui suit:

versions:   - sha: paste_commit_hash_here

Vous pourriez tout aussi bien ajouter le homepage et documentation clés pendant que vous y êtes.

Assurez-vous de valider le nouveau fichier directement dans le master bifurquer.

ÉTAPE 6 : Rendez-vous sur le formulaire de soumission de la galerie. Ajoutez l’URL à la racine du dépôt dans le champ URL et appuyez sur Nous faire parvenir. Si tout est OK, vous devriez obtenir une réponse indiquant que le modèle a été soumis. S’il y a eu un problème, un message d’erreur vous indiquera où la validation a échoué.

C’est ça! Votre modèle devrait apparaître dans la galerie après avoir subi une validation supplémentaire.

REMARQUE! Juste un rappel que tous les modèles ne seront pas publiés. Votre modèle doit suivre le guide de style, et s’il existe déjà un modèle avec des fonctionnalités similaires dans la galerie, votre modèle risque de ne pas être publié.

Enfin, il peut être judicieux de cloner le référentiel sur votre ordinateur local uniquement pour pouvoir utiliser le git outils de ligne de commande à la place.

Conseil GitHub n°2 : mettez à jour le modèle

Une fois le modèle soumis à la galerie, vous le mettez à jour en validant les modifications apportées au template.tpl dossier.

Une fois que vous avez un commit du template.tpl fichier fusionné avec master que vous souhaitez soumettre à la galerie de modèles de la communauté en tant que nouvelle version du modèle, vous devez copier son hachage de validation et l’ajouter en tant que nouvelle entrée dans le metadata.yaml dossier. Il doit devenir la nouvelle première entrée sous le versions clé.

Une fois que vous avez mis à jour le metadata.yaml fichier, vous devez vous engager que et assurez-vous que vos modifications sont fusionnées avec le master bifurquer.

Ensuite, il vous suffira d’attendre que la galerie récupère vos dernières modifications, de les valider et de mettre à jour la liste des modèles dans la galerie avec les modifications.

L’essentiel ici est le processus:

1. Apportez des modifications incrémentielles à template.tpl.
2. Une fois satisfait et prêt à créer une nouvelle version du modèle dans la galerie, commettre la version finale de template.tplfusionnez-le avec masteret copiez le hachage de validation.
3. Éditer metadata.yaml et ajoutez ce hachage de validation en tant que version la plus récente du modèle.
4. Commettre les changements à metadata.yaml et assurez-vous qu’il est fusionné avec master.
5. Attendez.

Astuce GitHub n°3 : Configurer une organisation et des sous-modules

Si vous fournissez de nombreux modèles, il peut être judicieux de les ordonner logiquement dans GitHub en tant qu’organisation. Après avoir créé une organisation, tous les modèles publics que vous souhaitez télécharger seront créés en tant que référentiels au sein de cette organisation, vous offrant un point d’origine unique pour la gestion de vos modèles.

Un autre avantage de la création d’une organisation est que vous pouvez vérifier l’organisation (en montrant à GitHub que vous possédez les domaines référencés dans le profil de l’organisation) et, par conséquent, obtenir la coche verte à afficher à côté du nom de votre organisation dans la liste de la galerie.

Voici à quoi ressemble mon modèle d’organisation :

Une autre chose que vous voudrez peut-être faire est de créer un nouveau référentiel “roll-up”, auquel vous ajoutez tous les référentiels de modèles en tant que sous-modules. C’est, encore une fois, un moyen de gérer logiquement vos modèles. Le cas d’utilisation est similaire aux organisations, donc si vous regroupez déjà les modèles avec une organisation, l’utilisation de sous-modules peut ne pas être utile du tout. Néanmoins, voici à quoi ressemble mon référentiel “roll-up”. Voyez comment chaque dépôt de modèle a son propre dossier à l’intérieur ? Ce sont des sous-modules.

Ce ne sont que des éléments de qualité de vie, et il n’est certainement pas nécessaire de s’installer avec la galerie de modèles.

Résumé

La galerie de modèles de la communauté est enfin là ! Nous avons maintenant un moyen de distribuer les modèles sur lesquels nous avons travaillé – c’est excitant.

Ne soyez pas découragé par la manière apparemment complexe de gérer vos modèles personnalisés via GitHub. Tout d’abord, si vous avez réussi à créer un modèle et à ajouter toutes les métadonnées requises, il y a de fortes chances que vous maîtrisiez déjà GitHub et que vous trouviez son fonctionnement trivial (même s’il prend un peu de temps).

Et même si GitHub est une nouveauté pour vous, considérez cela comme une excellente leçon de contrôle de version. Vos fichiers étant directement exploités par Google Tag Manager, il est très important de pouvoir annoter discrètement chaque version.

De même, être en mesure de gérer les problèmes soumis par la communauté modèle par modèle et engagement par engagement est utile non seulement pour la galerie de modèles, mais aussi pour vous.

Je suis sûr que notre communauté se montrera à la hauteur de l’occasion et écrira de petits outils qui faciliteront encore plus la mise à jour des modèles (un outil en ligne de commande pour copier le hachage du dernier commit et l’ajouter en tant que nouvelle entrée dans le metadata.yaml? N’importe quels preneurs? Ping moi – j’ai des idées).

Le temps nous dira à quel point la galerie sera populaire, mais j’ai l’impression que ce sera le principal moyen pour les marques de distribuer leurs extraits de script dans un proche avenir. Je ne vois plus pourquoi un fournisseur devrait proposer un bloc de code personnalisé à copier-coller dans une balise HTML personnalisée, en particulier après l’introduction de la galerie de modèles. Je ne vois pas non plus de raison pour eux de partager leurs modèles uniquement sur leur propre site, alors qu’ils peuvent obtenir une visibilité supplémentaire de la marque en proposant les modèles via la galerie.

Dans tous les cas, les modèles personnalisés restent fermement en tête de ma liste des “fonctionnalités Google Tag Manager les plus importantes et les plus inspirantes de ces dernières années”, et la Community Template Gallery est une excellente fonctionnalité complémentaire pour prendre en charge la suite de fonctionnalités de modèles.

Que pensez-vous de la galerie de modèles de la communauté ? Vous avez des idées d’amélioration ? Faites entendre votre voix dans les commentaires !