Tableau RegEx simple pour Google Tag Manager

Lorsque nos bons amis de l’équipe de développeurs de Google Tag Manager ont présenté pour la première fois la macro Lookup Table, nous étions ravis. Pour beaucoup d’entre nous, il est rapidement devenu l’arme de prédilection, notamment lorsqu’il est utilisé comme outil de gestion et d’optimisation du conteneur lui-même.

Cependant, la macro n’était pas considérée comme parfaite. En fait, la demande la plus fréquemment entendue concernait la fonctionnalité de base de la fonctionnalité elle-même : la macro doit prendre en charge opérationsC’est, prédis la logique. Il ne suffit pas d’avoir des recherches de correspondance égales ; les gens voulaient un support pour des opérations telles que “x est-il plus grand que y” ou “y contient-il x”.

Le fait est que je ne suis pas d’accord avec la modification de la macro de table de consultation pour prendre en charge ces types d’opérations. Bien sûr, une table dont vous pouvez interroger les valeurs avec des opérations plus complexes que de simples recherches serait géniale, mais ce ne serait pas un table de recherche plus. Nous aurions besoin d’un type de variable différent pour ces cas d’utilisation.

Dans cet article, je vais jeter un œil à ce qui fait d’une table de recherche une table de recherche, et je vais également vous donner une astucieuse variable JavaScript personnalisée qui vous permet de créer vous-même une table d’expressions régulières. Cette table vous permet d’interroger une variable d’entrée (par exemple {{Page Path}}) par rapport à un certain nombre d’expressions régulières (lignes). Si une correspondance est établie, une valeur est renvoyée. Il s’agit donc essentiellement d’une variante de la table de consultation, mais avec des expressions régulières au lieu de correspondances exactes.

Cherchez-le!

Même si je suis un produit du système éducatif finlandais inégalé, je suis nul en ornithologie. Alors vous m’excuserez pour la métaphore maladroite suivante.

Considérez le pigeon voyageur. Il a une connaissance intime d’un endroit, et il vole jusqu’à cet endroit. S’il n’y a rien, il devient confus et caca. S’il trouve un destinataire ou un message, il fait son travail et roucoule joyeusement.

Eh bien, quand vous avez une table de recherche, c’est la même chose. Vous utilisez une référence de variable pour localiser une cellule spécifique dans un tableau. Si cette cellule existe, toute valeur stockée à l’intérieur est renvoyée. Si la cellule n’existe pas, le script devient confus et fait caca un indéfini ou une erreur.

C’est ce qui rend les tables de recherche si incroyablement efficaces. Tout est basé sur la logique binaire.

Il n’y a pas d’opérations complexes, pas de prédicats à évaluer. C’est juste une question de “le tableau X a-t-il une valeur sous l’étiquette Y”.

En JavaScript, une table de recherche peut être un objet brut (le plus courant), un tableau ou même une chaîne. Fondamentalement, il peut s’agir de n’importe quelle structure de type Array.

Si vous utilisez un objet simple comme table de recherche, il est courant de l’appeler un tableau associatif ou un table de hachagemais nous les appellerons tables de recherche ici pour plus de clarté.

Ainsi, vous pouvez effectuer des recherches sur toutes les structures de type Array. Les trois exemples répertoriés ci-dessus peuvent être utilisés pour des recherches comme celle-ci :

// Plain object var newValue = objectTable['key']; // Array var anotherValue = arrayTable[3]; // String var newestValue = 'String'[5]; 

Avec l’objet ordinaire, vous pouvez également utiliser la notation par points dans certains cas.

Comme vous pouvez le voir, vous demandez directement une valeur spécifiquement étiquetée dans la table, et si elle existe, elle vous est renvoyée sans aucune autre opération.

Maintenant, si vous deviez introduire une logique de prédicat dans le mélange, avec quelque chose comme table['[Kk]ey'] (exemple fictif), cela signifierait que la recherche devrait vérifier chaque cellule jusqu’à ce qu’une correspondance soit établie dans le tableau pour voir s’ils ont ‘Key’ ou ‘key’ comme étiquette.

En effet, avec les structures de données JavaScript, une étiquette ne peut jamais être qu’une chose. Avec les tables de recherche, vous demandez une étiquette donnée sans aucune variation, par exemple “Clé”, et seul cette étiquette est donc interrogée dans la table. En effet, la logique de programmation dicte qu’une seule cellule peut exister dans le tableau avec cette étiquette.

Dès que vous ajoutez une logique de prédicat au mélange, vous forcez la recherche à vérifier chaque cellule jusqu’à ce qu’une correspondance soit établie, car vous ne pouvez pas étiqueter les cellules avec des expressions régulières ou des valeurs dynamiques (par exemple, “Clé/clé”).

La différence entre la vérification binaire de la recherche et la traversée d’une opération plus complexe devient plus claire lorsque l’on pense en termes de performances.

On dit que les requêtes sur une table de recherche fonctionnent dans temps constant. Étant donné que vous recherchez une étiquette spécifique dans une table de taille arbitraire, la complexité de l’opération sera toujours la même. Soit l’étiquette existe, soit elle n’existe pas. La table peut être immense ou minuscule, les performances sont toujours les mêmes.

La performance est généralement indiquée avec la notation Big O. La notation pour le temps constant (c’est-à-dire la recherche) serait O(1).

Lorsque vous utilisez la logique de prédicat, vous obtenez O(1) uniquement si vous faites correspondre la requête à la première cellule cochée. Chaque cellule suivante qui est vérifiée pour une correspondance entraîne une diminution linéaire des performances. Ainsi, on dit que la logique de comparaison fonctionne dans temps linéaire.

Décrire les opérations en temps linéaire avec O(1) serait assez optimiste. Pour cette raison, la notation Big O a tendance à décrire le pire scénario. Le pire scénario de temps linéaire serait que la valeur se trouve dans la toute dernière cellule interrogée. Ainsi, la notation serait Au)où n est le nombre de cellules du tableau.

Cela signifie également que plus la table est grande, plus l’opération devient coûteuse en termes de performances.

Avec de petites tables, cette différence est assez insignifiante, mais avec de grandes tables et une multitude de variables chaînées, l’impact sur les performances peut être significatif, surtout s’il faut du temps pour faire la correspondance, et les étiquettes sont suffisamment arbitraires pour que vous ne puissiez pas utiliser de données facilitantes. structures ou algorithmes de recherche.

Donc, si vous êtes préoccupé par les performances, et vous devriez l’être s’il s’agit d’une page Web, utilisez toujours la variable Lookup Table.

Table de recherche RegEx avec JavaScript personnalisé

Eh bien, je sais que vous n’êtes pas satisfait de mon explication et que vous recherchez toujours un moyen plus flexible de récupérer les valeurs d’une table.

J’espère que les développeurs de GTM introduiront, à un moment donné, un autre type de variable qui est essentiellement une table de recherche, mais où vous pouvez spécifier la logique de prédicat utilisée ligne par ligne.

Jusque-là, vous pouvez vous contenter de solutions de contournement telles que le script ci-dessous.

Copiez le code suivant dans une nouvelle variable JavaScript personnalisée :

function() {     // Set inputVariable to the input you want to assess     var inputVariable = {{Page URL}};      // Set defaultVal to what you want to return if no match is made     var defaultVal = undefined;          // Add rows as two-cell Arrays within the Array 'table'.     // The first cell contains the RegExp you want to match     // the inputVariable with, the second cell contains the     // return value if a match is made. The third cell (optional),     // contains any RegEx flags you want to use.      //     // The return value can be another GTM variable or any      // supported JavaScript type.     //     // Remember, no comma after the last row in the table Array,     // and remember to double escape reserved characters: \\?     var table = [         ['/home/?$', 'Home Page'], // Row 1         ['\\?location=', 'Contact Us Page'], // Row 2         ['/products/[123][0-9]', 'Products 10-39', 'i'] // Row n (last)     ];          // Go through all the rows in the table, do the tests,     // and return the return value of the FIRST successful     // match.     for (var i = 0, len = table.length; i < len; i += 1) {         var regex = new RegExp(table[i][0], table[i][2]);         if (regex.test(inputVariable)) {             return table[i][1];         }     }     return defaultVal; } 

Voici comment fonctionne la variable :

1. Tout d’abord, vous lui donnez l’entrée : une variable ou une valeur que vous souhaitez évaluer dans les lignes du tableau

2. Ensuite, vous insérez les lignes

3. Les lignes sont en fait des tableaux dans le table Déployer

1. The first cell contains the regular expression you want to evaluate against the input (note, you will need to _double_ escape reserved characters!)  2. The second cell contains the value that is returned if a match is made  3. The third cell is optional, and can contain any regular expression flags (e.g. 'g', 'i') you might want to use 

4. Enfin, il y a une petite boucle for qui parcourt chaque ligne du table Array, vérifiant l’expression régulière par rapport à la variable d’entrée. Si et quand une correspondance est établie, la valeur de retour spécifiée est renvoyée par la fonction

5. Si aucune correspondance n’est établie, la valeur par défaut spécifiée est renvoyée

N’oubliez pas de modifier les lignes pour qu’elles correspondent à votre tableau. Puisqu’il s’agit de JavaScript en texte brut, vous pouvez également créer le tableau dans Excel (en le formatant avec les crochets et tout), puis simplement le copier-coller en texte brut dans le corps de la macro JavaScript.

Résumé

Comme toujours, cette solution est d’abord éducative, une preuve de concept ensuite et une solution de contournement utilisable et prête à l’emploi en dernier. N’hésitez donc pas à le modifier à vos propres fins, ou simplement à l’abandonner complètement.

La clé à retenir de cet article devrait être une compréhension du fonctionnement des tables de consultation et de la complexité qu’elles obtiendraient si une logique opérationnelle était également introduite. Pour cette raison, ma demande de fonctionnalité reste que la table de consultation serait conservée telle quelle, mais un nouveau type de variable serait introduit, où vous pouvez spécifier l’opération ligne par ligne. De cette façon, tout le monde est gagnant.

Au fait, si vous êtes intéressé par les performances, JavaScript et d’autres structures de données et algorithmes de recherche, jetez un œil à ce livre :

Michael McMillan : Structures de données et algorithmes avec JavaScript

Le livre résume très bien les bases. La prochaine étape serait de prendre un livre sur les modèles de conception et les structures de données plus complexes. Tout est très pédagogique.