Débogage du suivi des événements automatiques dans GTM

(Dernière mise à jour juin 2014 : Lisez le dernier article sur l’extension, GTM Sonar v1.2.)

De nombreux articles de Google Tag Manager sur ce blog pourraient être considérés comme des hacks, en ce sens qu’ils étendent les fonctionnalités prêtes à l’emploi de GTM d’une manière qui ne sera sûrement pas officiellement prise en charge par Google. Le nœud du problème est que beaucoup de gens sont pris par surprise lorsque GTM refuse de fonctionner correctement sur leur site ou lorsqu’ils ont du mal à suivre les éléments clés du modèle de page.

Le suivi automatique des événements est un dénominateur très courant lorsque des problèmes avec GTM surviennent. C’est une fonctionnalité merveilleuse qui vous permet de baliser et de suivre automatiquement les actions sur la page Web à l’aide d’écouteurs d’événements, mais il existe de nombreux problèmes avec JavaScript en conflit et un balisage de mauvaise qualité qui pourraient empêcher le suivi automatique des événements de fonctionner.

Pour vous aider à établir l’état actuel de votre modèle, je vous donne l’extension Chrome GTM Auto-Event Listener Debugger (nom en cours de construction). Ce devrait être un outil bienvenu pour vous si vous souhaitez déboguer votre modèle de page et vos éléments sur la page en gardant à l’esprit le suivi automatique des clics.

Tout d’abord : téléchargez le débogueur d’écouteur d’événements automatiques GTM ici.

Clause de non-responsabilité

Les problèmes de balisage doivent toujours être résolus avec les développeurs de sites en premier et un thérapeute agréé en second. La plupart du temps, il s’agit simplement de savoir si les meilleures pratiques ont été observées, telles que l’identification d’éléments uniques avec des identifiants, le regroupement de styles similaires avec des classes ou la mise en place d’une hiérarchie de mise en page cohérente. Ce sont tous des problèmes qui devraient être résolus dans le CMS (ou le modèle), car ils facilitent également le travail de développement sur le site Web à l’avenir.

Cependant, il existe de nombreuses raisons pour lesquelles un rapport avec les développeurs ne peut pas être établi. Vous pourriez être une main embauchée avec seulement GTM et analyse Web comme domaine. Les développeurs connaissent peut-être le développement Web. L’organisation peut insister sur des processus et une bureaucratie rigides pour faire quoi que ce soit, et cela ne cadrera tout simplement pas avec votre vision de l’analytique agile.

Quoi qu’il en soit, il vous suffit parfois de vous frayer un chemin à travers les lacunes de votre CMS ou de votre modèle de page. Si rien d’autre, vous aurez au moins une preuve de concept entre vos mains à livrer aux développeurs.

Des instructions

Pour utiliser le débogueur, assurez-vous d’abord de l’avoir activé dans Outils -> Extensions de votre navigateur Chrome. S’il est activé, vous devriez voir une icône de cible rouge sur votre volet d’extension.

Les étapes réelles d’utilisation du débogueur sont simples :

1. Accédez à une page Web que vous souhaitez déboguer

2. Cliquez sur la cible rouge (elle doit devenir verte pour signaler que le débogueur est en cours d’exécution)

3. Cliquez n’importe où sur la page

4. Ouvrez la console JavaScript dans Chrome, tapez debugDLet appuyez sur Entrée

Lorsque vous activez le débogueur, il fait deux choses : 1) il arrête l’action par défaut de tous les clics sur la page, 2) lorsque vous cliquez sur un élément, il stocke ses détails dans le debugDL tableau au format identique aux écouteurs GTM.

Pourquoi empêcher l’action par défaut des clics ? Simple, pour des raisons de débogage, il est préférable de rester sur la même page pour tester des éléments. L’arrêt de l’action par défaut empêche les liens de fonctionner. Parce que debugDL est un objet dans le document actuel, il ne persistera que pour la page sur laquelle vous vous trouvez (similaire au fonctionnement de dataLayer).

Et pourquoi stocker l’objet dans debugDL et pas dataLayer, par exemple? Eh bien, je voulais que ce débogueur ne bousille pas les frameworks existants, afin que vous puissiez jouer librement. Bien sûr, quelqu’un d’autre a peut-être trouvé le nom “debugDL” dans d’autres bibliothèques ou extensions, mais je vais tenter ma chance.

Lorsque vous désactivez le débogueur (en cliquant à nouveau sur la cible), l’action par défaut des événements de clic est renvoyée. Le debugDL tableau n’est pas effacé, cependant, et vous pouvez continuer à afficher son contenu tant que vous êtes sur la page.

La partie de débogage commence lorsque vous commencez à parcourir debugDL. Chaque clic est enregistré dans un format identique à ce que vous obtiendriez si vous aviez un GTM Click Listener actif.

À quoi ça sert?

L’idée est de tester votre modèle de page s’il fonctionne avec les écouteurs GTM.

Ou peut-être souhaitez-vous planifier à l’avance et choisir les propriétés de l’élément cliqué (ou de ses parents ou frères) auxquelles vous souhaitez accéder dans vos macros.

Ou peut-être voulez-vous voir si les événements de clic se propagent aux écouteurs GTM, qui fonctionnent sur le nœud supérieur du document.

Ma raison préférée est la suivante : je fais BEAUCOUP de débogage pour les gens, et je n’ai pas toujours accès à leur conteneur de prévisualisation/débogage. Il n’y a donc en fait aucun écouteur qui se déclenche sur la page, et je dois deviner en regardant le balisage et en rétro-concevant leur JavaScript pour identifier pourquoi les auditeurs de clics pourraient ne pas fonctionner.

Avec cette extension, je peux déboguer le site sans avoir besoin d’un véritable écouteur de clics GTM.

Trucs techniques

Si vous connaissez vos extensions Chrome, vous saurez qu’elles fonctionnent dans un environnement isolé. Cela signifie en pratique que vous ne pouvez pas accéder aux variables créées par la page dans l’extension.

Cela a également des implications pour cet auditeur, car je veux stocker des données dans le window.debugDL déployer.

Pour contourner ce problème, lorsque vous activez le débogueur, il injecte un bloc de script dans votre modèle de page, ce qui crée l’objet. Ce bloc de script amorce également l’écouteur de clic sur le nœud de document. Lorsque vous cliquez ensuite n’importe où sur la page, une autre injection se fait sous la forme d’un push dans debugDL.

Injecter des trucs craint, mais c’est le seul moyen (pour autant que je sache) de modifier les variables dans le window objet à travers l’extension.

Lorsque vous désactivez le débogueur, il supprime l’écouteur d’événement et tous les blocs de script personnalisés créés par l’extension.

Notez également que les actions du débogueur sont uniques à l’onglet dans lequel le débogueur a été activé. Cela signifie que vous pouvez ouvrir plusieurs onglets, chacun avec ses propres instances du débogueur en cours d’exécution ou non. Cool hein?

Et après?

Comme il s’agit de ma première incursion dans les extensions Chrome, il y a beaucoup de réglages à faire. Voici une liste de choses que j’ai pensé à faire dans un futur proche. J’ai également demandé des tests bêta aux merveilleuses personnes de la communauté Google+ GTM, alors j’espère que j’aurai bientôt plus de fonctionnalités sur la planche à dessin !

1. Une bascule pour dissocier tous les gestionnaires de clics jQuery sur le site – pour tester si jQuery interférant est la raison pour laquelle vos clics ne sont pas enregistrés par les écouteurs d’événements automatiques

2. Ajoutez également une fonction Link Click Listener – pour enregistrer uniquement les clics sur les éléments de lien

3. Ajoutez également une fonction Form Submit Listener – puisqu’environ 75% de tous les problèmes d’écoute sont liés à la soumission de formulaires, c’est vraiment une évidence

4. Ajoutez d’autres gestionnaires d’événements, tels que mouseover, keydown, change – pour démontrer la puissance du suivi automatique de toutes les actions basées sur l’utilisateur

5. Rendez-le plus joli et plus flashy

6. Pensez à un meilleur nom pour l’extension