Certains ne voient que par lui, d’autres clament haut et fort que c’est le futur inévitable avec la multiplication des bouts de code (autrement appelés balises) à rajouter à notre site pour lui greffer de nouvelles fonctionnalités (souvent liées au marketing : suivi de conversion, tests A/B, etc…).

Le problème (enfin, mon problème mais peut être le votre aussi) c’est qu’il est difficile de trouver un tuto facile à comprendre. Du genre clair comme de l’eau de roche, un peu du genre pour les nuls. C’est mon challenge aujourd’hui. Avec des mots simples et des comparaisons imagées, je vais tenter de vous expliquer GTM (V2, puisque c’est la dernière en date).

Cet article est le premier d’une série de 4 articles sur Google Tag Manager. Cette série de 4 articles a l’ambition d’être le guide francophone le plus complet sur Google Tag Manager . Vous pouvez vous rendre directement aux autres articles si vous le souhaitez :

Google Tag Manager V2 : Le concept général

logo-google-tag-managerConcrètement, vous avez votre site web. Il est beau, il marche bien, tout va bien. Par contre, il a une audience limitée. Vous souhaitez donc faire un peu d’Adwords, une campagne sur Facebook et aussi tester quelques pages avec disons AB Tasty (ou un autre!).

Dans ce cas, chacun des protagonistes va vous demander d’ajouter un bout de code sur votre site. Un, c’est chiant. Deux, vous n’êtes peut être pas doté de compétences techniques qui vous permettent de le faire vous-même, vous êtes donc tributaire de votre développeur et du temps libre qu’il a à vous accorder. Et trois, avec du code en dur dans votre site il y a toujours un risque qu’il soit corrompu ou effacé à un moment ou un autre (mise à jour, ajout de module, customisation, etc…).

Google Tag Manager résout ces différents problèmes. On met en place un bout de code (autrement appelé container GTM) une seule fois sur notre site. On insère nos petits bouts de code (on va les appeler balises maintenant) dans l’interface GTM et GTM les insère dans le container dynamiquement sur votre site (dans le container plus exactement).

Plutôt simple non ? En plus de ça, GTM donne deux avantages sympa. D’abord, dans nos bouts de code à insérer (Adwords, Facebook, AB Tasty), il est possible que l’un d’eux (ou plusieurs!) soient bloquants. C’est à dire qu’ils bloquent le chargement de la page tant qu’ils ne sont pas exécutés intégralement. Du coup, ça ralentit votre site… Et ben, s’ils sont exécutés dans un container GTM, ils s’exécutent de manière asynchrone (ils ne sont plus bloquant, ils s’exécutent en arrière plan). Votre site se charge donc plus vite.

Et deuxièmement, GTM nous donne la possibilité de choisir l’ordre dans lequel s’exécute nos balises. On peut donc définir des priorités (ce que l’on ne peut pas forcément faire sans GTM). Ca peut aussi être un gros avantage, notamment sur un gros site avec beaucoup de balises.

Voyons maintenant autre chose. Revenons à notre situation d’exemple. Pour Adwords, le code à rajouter sur votre site (le code de suivi des conversions en l’occurrence) doit l’être sur la page unique qui signifie qu’une conversion a bien eu lieu (la page de remerciement classiquement). Si vous insériez manuellement (à l’ancienne) votre bout de code sur votre site, vous devriez donc trouver le fichier qui correspond à cette page (ou définir une condition si votre site est dynamique exemple WordPress, Prestashop, etc…) et insérer votre bout de code en dur dans votre fichier.

Ce principe s’applique également pour Facebook. Et pour AB Tasty, il y a de fortes chances qu’il vous demande d’ajouter un bout de code sur chaque page, un autre spécifique sur la ou les pages à tester et peut être même encore un autre sur les pages variantes.

On se rend donc bien compte qu’il nous faut un moyen de pouvoir définir des conditions dans GTM qui vous nous permettent d’appliquer les mêmes règles que si on devait mettre à la main nos bouts de code. Je vous propose donc de découvrir les déclencheurs.

Google Tag Manager V2 : Le concept des déclencheurs

bouton-declencheurLe déclencheur va donc être l’outil qui nous permet de définir si telle balise (bout de code spécifique) doit être déclenché (comprendre présent) sur telle page. Par exemple, on a dit qu’AB Tasty nécessitait un code spécifique sur chaque page. Et bien on va donner le bout de code à GTM (on crée donc une balise) et on va lui assigner un déclencheur qui insérera ce bout de code dans le container GTM sur chacune des pages de notre site.

Si vous aviez insérer votre bout de code manuellement, vous l’auriez sans doute mis dans votre fichier header pour qu’il apparaissent sur votre page. Et bien la, on définit un déclencheur qui aura pour règle : apparaît pour chaque URL. Ca revient au même. Mission accomplit. Et pour Facebook, on crée une nouvelle balise et on définit un déclencheur qui aura pour règle : apparaît quand l’URL est égale à /merci.php. Ainsi, notre bout de code n’est présent que sur la page merci.php.

Qui a dit que c’était compliqué GTM ????!!!! Ok, alors maintenant, essayons d’être un tout petit peu plus précis par rapport à tout ça. On crée une balise, on paramètre un déclencheur et la balise apparaît sur la ou les pages visées par le déclencheur. Et on a dit que la règle du déclencheur c’est un truc du genre URL est égal(e) à merci.php. Théorisons un tout petit peu (si si c’est nécessaire).

On peut dire qu’un déclencheur est une condition pour laquelle une balise va se déclencher ou non. Dans notre cas, la condition serait : si l’url est égal à merci.php, déclenchement. Si l’url est égale ou quoi que ce soit d’autre, on déclenche pas. L’URL va donc est la variable de déclenchement.

Donc en fait, notre déclencheur pourrait se résumer comme ça : [Variable = URL] est égale à [Valeur = merci.php ]. Et le « est égale à » est finalement un opérateur. La c’est égale à mais ça pourrait être contient, est différent de, est supérieur à, etc… C’est un opérateur. Donc en résumé de chez résumé, un déclencheur c’est [Variable] [Opérateur] [Valeur].

Ca va ? Ok alors on continue. En fait, un déclencheur c’est [Variable] [Opérateur] [Valeur] uniquement dans le cas ou l’on a une seule condition. Mais on peut en avoir plusieurs. Je ne veux pas vous donner d’exemple à ce stade mais il va y avoir des moments ou l’on voudra déclencher si l’on vérifie plusieurs conditions [Variable] [Opérateur] [Valeur] et [Variable] [Opérateur] [Valeur]. Tout ça pour dire que finalement, [Variable] [Opérateur] [Valeur] n’est pas un déclencheur mais plutôt un filtre de déclenchement. Voila, comme ça on a mis les bons mots sur les bonnes choses.

Allez, je résume pour que l’on puisse bien digérer. Nos balises sont déclenchées à condition que quelque chose. Cette condition s’exprime sous forme d’un filtre [Variable] [Opérateur] [Valeur]. Il est possible de cumuler plusieurs filtres pour avoir des déclenchements ultra ciblés.

Google Tag Manager V2 : Les variables

Ok, maintenant, essayons d’en voir encore un peu plus. Pour l’instant on a parler uniquement de la variable URL. On déclenche la balise si URL égale X. Mais on pourrait aussi déclencher la balise si le nom d’hôte de l’URL est égale à X ou que l’URL de provenance contient Y. L’URL est une variable de la famille Page vue. Nom d’hôte de l’URL et URL de provenance sont en quelque sorte des variables sœur de la variable URL au sein de la famille de variable Page vue.

On peut définir des filtres avec l’URL, le nom d’hôte de l’URL ou l’URL de provenance. Et toutes ces variables ont en commun qu’elle sont liées aux pages vues. Et bien une page vue est ce que l’on va appeler un événement.

On va donc dire que pour qu’une balise soit déclenchée, elle doit être rattachée au minimum à un événement. Par exemple, notre balise Facebook est déclenchée ou non en fonction d’une page vue. A chaque nouvelle page vue, GTM va évaluer la condition (elle-même basée sur un ou plusieurs filtres contenant des variables de type page vue). URL est égale à index.php, on déclenche pas. URL est égale à merci.php, on déclenche.

Et bien dans GTM, on peut s’appuyer sur 6 types d’événements. Chaque événements aura plusieurs variables (de la même manière que l’événement Page vue a les variables URL, nom d’hôte de l’URL et URL de provenance). Et si jamais malgré ces 6 types d’événements vous n’avez pas encore assez de finesse pour faire ce que vous souhaitez, vous pouvez créer des variables personnalisées que vous pourrez utiliser dans vos conditions. C’est génial non ?

Ok, voyons les un tout petit peu plus en détail. Mais avant cela, je voudrai vous prévenir. A partir de la il est fortement recommandé d’avoir des notions de javascript et de DOM. Etre développeur n’est pas nécessaire, personnellement je ne le suis pas. Mais savoir ce qu’est le DOM et avoir les bases de Javascript me paraissent être des pré-requis minimum. Si vous ne les avez pas, utiliser correctement GTM risque d’être compliqué. Des sites avec des tutos sur le sujet ce n’est pas ce qui manque. Ceci étant dit, la suite !

Pour tout savoir des différents types d’événements et les variables pré-définies associées, je vous conseille la lecture de cette page : https://support.google.com/tagmanager/answer/6106965?hl=fr . En effet, tout y est, je ne vois pas l’intérêt de faire du copier coller. Lisez la et on se retrouve ici ensuite. Si certaines choses bloquent par rapport à cette page, posez moi des questions en commentaires.

Google Tag Manager V2 : Résumé de cette première partie

Il est l’heure de faire un premier bilan de ce que l’on a appris.

GTM c’est un container (un code javascript à insérer sur toutes les pages) dans lequel vont venir s’insérer des balises (des bouts de code de tierce parties) dynamiquement en fonctions de règles (déclencheurs) que l’on aura défini.

Ces déclencheurs s’appuient sur des événements eux même constitués de plusieurs variables pré-définies. Ces variables vont nous permettre de créer des filtres qui serviront de condition pour déclencher ou non nos balises. A chaque événement, GTM parcourra toutes les conditions et comparera ce que l’on a configuré à la situation en cours.

Tout ceci est effectué de manière asynchrone.

La partie 1 s’achève ici. C’était très théorique et imagé. Je vous propose la même approche pour la partie 2. Cette fois on parlera des types d’événements plus en détail. Idem pour les variables. On fera également le tour de la couche de donnée (autrement appelé data layer). Le but du jeu est que vous ayez une compréhension théorique globale complète de GTM V2 avant que l’on passe à la troisième et dernière partie, le concret, la mise en place, les exemples d’utilisation.

La deuxième partie du guide est ici : Partie 2 : Tout sur la couche de données (autrement appelée datalayer) dans Google Tag Manager V2

Nos compétences

Chablais Web, agence spécialiste des solutions Google en Haute Savoie vous accompagne dans la mise en place de Google Tag Manager V2 sur votre site.

Nous réalisons pour vous la création du compte (ou sa migration depuis la version 1), le paramétrage des différentes balises et si vous le souhaitez la formation de vos collaborateurs.

N’hésitez pas à nous contacter.

A propos de l’auteur

Responsable E-commerce pendant 6 ans. Gérant de mon agence Chablais Web pendant 3 ans. Désormais à la tête du Marketing Digital chez FirstPoint Sàrl en Suisse et top contributeur de la communauté Google pour les annonceurs.

Spécialiste multi-certifié des solutions Google et Facebook, j’aide les entreprises à faire d’internet leur meilleur atout. Envie d’aller plus haut ? Contactez-moi.