Lorsque des modèles personnalisés ont été publiés pour Google Tag Manager, j’ai mis à jour mon flux de travail pour travailler avec GTM. Au lieu de me précipiter instinctivement vers la balise HTML personnalisée et la variable JavaScript personnalisée, j’ai commencé à me demander si le script personnalisé qui devait être déployé pouvait d’abord être transformé en un modèle personnalisé.

Tout en publiant de nombreux modèles dans la galerie de la communauté, j’ai toujours passé du temps au cours des 12 derniers mois à bricoler sur une traduction de modèle extrêmement compliquée : le tracker JavaScript Snowplow Analytics.

J’ai déjà écrit sur Snowplow, et j’ai un faible dans mon cœur pour leur merveilleuse approche de bricolage du pipeline d’analyse.

Dans cet article, je présenterai les deux modèles que j’ai créés et je partagerai avec vous une partie de la philosophie de conception. Ce fut une course étrange, et je me suis retrouvé à pousser les capacités des modèles personnalisés à leurs limites.

Cet article est ne pas un manuel pour les modèles. Vous devez vous tourner vers les documentation technique liés dans le tableau ci-dessous.

Merci

Le travail préliminaire de pré-publication sur les modèles a été effectué par moi, mais les modèles ont été publiés pour le développement open-source sous la propre organisation GitHub de Snowplow. Je pense que cela est essentiel pour les maintenir à jour et liés au développement du tracker JavaScript.

Je tiens à remercier d’avance toute personne qui contribue au développement de ces modèles, même si ce n’est que dans des discussions en ligne, des commentaires de blog ou via GitHub Issues.

Un grand merci à Paul Boocock de chasse-neige. Il a parcouru le modèle avec moi pour repérer les incohérences, et il a également aidé à établir la configuration pour le développement open source des modèles.

Le modèle de balise

Les Modèle de balise Snowplow Analytics est une implémentation assez fidèle de la bibliothèque complète de trackers JavaScript Snowplow Analytics.

La bibliothèque elle-même rappelle la bibliothèque Universal Analytics et le SDK JavaScript Matomo (ancien Piwik). Ces similitudes facilitent la traduction en un modèle, car nous pouvons utiliser le modèle de balise Universal Analytics natif pour nous inspirer.

Aperçu général

En général, lorsque la balise est déclenchée, elle effectue les mouvements suivants :

1. Charge le bibliothèque de suivi à partir d’une URL auto-hébergée.
2. Crée le espace de noms global pour le nom de la méthode (similaire à la façon dont Universal Analytics génère le ga objet global).
3. Initialise un nouveau (ou réutilise un existant) objet de suivi.
4. Compile les paramètres de la balise dans un commande qui est ensuite passé à la méthode globale.
5. La bibliothèque prend cette commande de la file d’attente, la construit dans une charge utile et l’envoie au point de terminaison du collecteur.

Dans l’ensemble, le processus est assez similaire au fonctionnement d’Universal Analytics. La plus grande différence sur un superficiel est la nature de bricolage du pipeline. Vous devez auto-héberger la bibliothèque JavaScript et vous devez créer vous-même le collecteur.

Initialisation de la balise

Convertir une bibliothèque en modèle est une tâche compliquée. Il faut consacrer beaucoup de temps à comprendre le fonctionnement de la bibliothèque, puis à examiner les restrictions des modèles personnalisés.

Le chargement de la bibliothèque et l’initialisation de l’espace de noms global étaient faciles – le injectScript L’API a géré le premier, et un copyFromWindow / setInWindow combiner la seconde.

Si l’espace de noms global n’est pas établi, le script le crée à l’aide d’une méthode de file d’attente similaire à celle utilisée par Universal Analytics.

Ensuite, le premier hoquet est affronté : initialisation d’un tracker.

La méthode globale Snowplow n’a pas de fonction pour vérifier l’existence d’un tracker. Il existe des moyens d’explorer l’objet et de rechercher ces informations, mais comme il n’y a pas d’API officielle pour interroger l’état du tracker, je ne voulais pas commencer à analyser l’objet sans garantir qu’il fonctionnera à l’avenir.

Donc, pour conserver les informations sur les trackers qui ont été créés, j’ai utilisé un nouveau tableau global, window._snowplow_trackers. Ce tableau stocke tous les trackers qui ont été initialisés, et lorsque la balise se déclenche, le nom du tracker est comparé à cette liste pour vérifier si un tracker existe déjà.

Mise en garde majeure avec la bibliothèque auto-hébergée

Il y a un gros problème d’utilisation injectScript.

Parce que, en tant qu’auteur du modèle, je n’ai aucune idée des URL à partir desquelles les utilisateurs du modèle pourraient charger le script auto-hébergé, il incombe à l’administrateur du modèle de s’assurer que le les autorisations du modèle sont mises à jour lorsque l’URL de la bibliothèque auto-hébergée est modifiée.

Il y a des instructions pour cela ici.

MISE À JOUR 18 mai 2020: Le modèle a été mis à jour pour prendre en charge AWS Cloud Front et Stockage en nuage Google destination par défaut (https://*.cloudfront.net/* et https://storage.cloud.google.com/*). Si vous chargez la bibliothèque à partir de l’une ou l’autre des destinations, vous ne pas besoin de mettre à jour les autorisations pour injectScript!

Malheureusement, la modification des autorisations rompt le lien de la galeriece qui signifie que vous ne serez pas informé des mises à jour du modèle.

J’ai soumis une demande de fonctionnalité à Google à ce sujet. Les modifications apportées aux autorisations doivent être dissociées du lien de la galerie.

La configuration du traqueur

Le tracker est créé avec un facultatif carte des arguments des paramètres de configuration.

Au début, j’ai envisagé d’ajouter toutes les options de suivi en tant que champs dans la balise. Cependant, cela a conduit à un sérieux ballonnement, et je voulais garder la balise aussi maigre que possible (tâche très difficile, soit dit en passant).

Alors j’ai pensé à ajouter simplement une table de paramètres où l’utilisateur peut taper les paires clé-valeur qu’il veut.

Bien que cela soit très fonctionnel, il présente quelques inconvénients. C’est très peu intuitif et l’utilisateur doit parcourir la documentation du tracker Snowplow pour construire correctement la carte d’arguments.

La variable Paramètres Snowplow Analytics

Finalement, j’ai décidé de suivre ce que Analytique universelle balise fait avec la variable Paramètres de Google Analytics. La variable de paramètres est un autre modèleoù l’utilisateur peut utiliser une interface utilisateur agréable pour définir des paramètres individuels.

Une fois la variable créée, l’utilisateur peut l’ajouter au tag Snowplow via le menu déroulant.

J’ai également décidé de quitter la table des paramètres. L’utilisateur peut vérifier la Activer les paramètres de remplacement pour cette balise pour ajouter/modifier des champs de paramètres individuels avec le tableau. Tout ce qui est ajouté au tableau remplace le paramètre correspondant dans la variable de paramètres.

Bien qu’il n’existe aucun moyen clair d’utiliser le tableau pour effacer un paramètre de la variable, en définissant un nom de paramètre sur undefined devrait marcher.

Pièces manquantes

Il manque une chose dans le processus de configuration du tracker : la liaison entre domaines. Comme cela repose sur l’analyse Éléments HTML dans le rappel, il n’a pas pu être implémenté dans le modèle personnalisé en raison des restrictions de l’API sandbox.

Vous pouvez toujours introduire des liens entre domaines avec un Balise HTML personnalisée. J’ai également soumis une demande de fonctionnalité à Snowplow où la liaison entre domaines pourrait être effectuée en passant des chaînes de sélecteur CSS ou href modèles via le rappel, plutôt que de lier les éléments eux-mêmes.

Construire la ou les commandes

Une fois la bibliothèque chargée et le tracker initialisé (si nécessaire), il est temps de prendre le reste des paramètres dans la balise et de les regrouper dans une commande.

La construction de la commande est divisée en trois types d’interfaces utilisateur différents :

1. Commandes avec un objet de paramètre générique.
2. Commandes avec des conditions spéciales.
3. Commandes personnalisées.

Objet paramètre

Le tracker JavaScript Snowplow utilise arguments positionnels pour gérer la logique de commande. Cela signifie que les arguments doivent être fournis à la méthode globale dans un ordre spécifique, afin que les valeurs correspondent à leurs équivalents fonctionnels corrects.

Par example, suivi des annonces et impression nécessite que la commande soit compilée comme ceci :

snowplow_name_here('trackAdImpression',     '67965967893',             // impressionId     'cpm',                     // costModel - 'cpa', 'cpc', or 'cpm'      5.5,                      // cost     'http://www.example.com',  // targetUrl     '23',                      // bannerId     '7',                       // zoneId     '201',                     // advertiserId     '12'                       // campaignId ); 

Avoir la configuration de l’architecture comme celle-ci rend la vie difficile pour cet auteur de modèle particulier. Pour cette raison, tous les arguments nommés doivent être mappés en arguments positionnels. Avec les objets basés sur des paramètres, cela signifie que l’utilisateur peut créer une carte de paramètres à l’aide d’une variable Google Tag Manager ou de la table de paramètres, et l’objet ressemblera à ceci :

{   impressionId: '67965967893',   costModel: 'cpm',   cost: 5.5 } 

Mais comme Snowplow utilise des arguments positionnels, je ne peux pas simplement attacher cet objet à l’appel. Cela aurait été magnifiquement élégant et simple, et aurait raccourci la base de code du modèle d’environ la moitié!

Au lieu de cela, le code doit mapper ces paramètres nommés à leurs équivalents positionnels corrects :

// Pseudo-code snowplow_name_here('trackAdImpression',   data.argMap.impressionId,   data.argMap.costModel,   data.argMap.cost ); 

je pouvait ont choisi la solution de facilité et ont obligé l’utilisateur à passer lui-même les positions en retournant un tableau au lieu d’un objet, mais cela aurait rendu l’expérience très maladroite.

Avec des arguments nommés, je peux aussi faire une validation :

if (['cpa', 'cpc', 'cpm'].indexOf(data.argMap.costModel) === -1) return fail('Invalid "costModel" argument provided in trackAdImpression call!'); 

Malheureusement, comme mentionné ci-dessus, le mappage des paramètres nommés à leurs homologues positionnels entraîne beaucoup de code supplémentaire. J’ai soumis une demande de fonctionnalité à Snowplow pour prendre également en charge les arguments d’objet, car cela résoudrait élégamment tout le problème (et convergerait avec le fonctionnement d’Universal Analytics, par exemple).

Commandes spéciales

Pour les commandes avec des fonctionnalités supplémentaires, telles que Affichage des pages et Suivi des liens, j’avais besoin de créer leurs propres groupes de champs. je pouvait sont allés de l’avant avec juste une carte d’arguments, mais avec par exemple le suivi du ping de page et le suivi automatique des liens, les cartes d’arguments ne suffiraient pas, car elles devaient être exécutées en tant que commandes supplémentaires distinctes.

La création de ces groupes spéciaux n’était pas problématique en soi, mais il y avait des cas où je poussais contre les limites du bac à sable de modèle personnalisé. Par example, suivi automatique des liens vous permet d’ajouter des filtres et des contextes basés sur des éléments à l’appel. Étant donné que le bac à sable ne vous permet pas d’interagir avec les éléments HTML, l’utilisation de ces fonctionnalités est impossible.

C’est pourquoi le suivi automatique des liens et le suivi des formulaires ont été réduits au seul liste blanche et liste noire fonctionnalités.

Commandes personnalisées

Enfin, il existe de nombreuses commandes dans la bibliothèque Snowplow qui ne sont pas directement liées à un événement. Ceux-ci sont tous regroupés sous Commandes personnalisées.

Beaucoup d’entre eux ne sont que des commandes simples sans aucun argument. Dans de tels cas, le Argument de commande champ n’est pas affiché.

Dans d’autres cas, il y a un champ où l’utilisateur peut ajouter le ou les arguments.

Il n’y a que très peu de validation pour ces arguments. En règle générale, il s’agit de s’assurer que le paramètre est dans le bon format, et avec par exemple enableGdprContext il transforme une chaîne séparée par des virgules en un tableau.

Cependant, on s’attend à ce que lorsque l’utilisateur du modèle ajoute des commandes personnalisées, soit il sache exactement ce qu’il fait, soit il lit la documentation qui explique comment configurer ces éléments.

En général, je vous recommande d’utiliser les variables de Google Tag Manager au lieu de coder en dur les arguments. Il facilite la commutation à la volée si nécessaire.

Lancer les commandes

Enfin, une fois le tracker créé et les commandes construites, elles sont toutes exécutées dans l’ordre en invoquant la méthode globale.

Par exemple, la création d’un nouveau tracker, la configuration du suivi du ping de page et l’envoi d’une page vue se termineraient avec les éléments suivants ajoutés à la file d’attente globale pour exécution (dans l’ordre) :

Résumé

La construction du modèle a été un voyage très éducatif, et cela a également contribué à générer un certain nombre de demandes de fonctionnalités pour Google Tag Manager et pour le tracker JavaScript de Snowplow, dont chacune, j’en suis sûr, rendra les deux solutions encore plus solides.

Au début, j’ai eu l’idée de créer une interface utilisateur super fluide, où chaque paramètre, événement et option était confiné à son propre champ avec une validation complète, des conseils de valeur, des textes d’aide, etc.

C’était une mauvaise idée.

Tout d’abord, il y a une limitation de quelque chose comme 100 champs dans n’importe quel modèle donné. Avant de crier d’indignation, c’est parfaitement logique. Avoir un mastodonte de modèle forcé sur l’interface utilisateur à chaque fois qu’une nouvelle balise ou variable est créée n’est pas favorable aux performances de Google Tag Manager.

De plus, si vous avez un modèle qui nécessite 100 champs, il est possible que vous devriez envisager de le modulariser.

Le modèle Snowplow est gros. C’est proche de la limite de 100 champs. Je le sais parce que j’ai rencontré la limite plusieurs fois et que j’ai dû refactoriser. S’il s’avère être un porc de performance, je chercherai à le diviser en parties plus petites (par exemple, un modèle pour les événements les plus utilisés, un autre pour le reste).

Séparer la configuration du tracker dans son propre modèle de variable était un pas vers la modularité, et en fonction des retours, nous (Snowplow et moi) verrons s’il doit y en avoir plus.

J’espère que cet article a été utile. Je suis toujours un grand fan des modèles personnalisés et je crois fermement qu’ils sont l’avenir de la gestion des balises de Google. J’espère que de nouvelles API sont constamment ajoutées au bac à sable, car certaines des limitations sont assez discordantes, en particulier lorsque les méthodes que vous attendez de la plupart des bibliothèques JavaScript sont bloquées (je vous regarde, JSON.parse).

Si vous avez des commentaires sur les modèles, assurez-vous de les signaler au fur et à mesure problèmes dans les référentiels respectifs : modèle de balise Snowplow Analytics et modèle de variable Paramètres Snowplow Analytics.