Google Tag Manager : l’écouteur d’historique

Il y a un nouvel auditeur en ville ! Cela fait quelques jours maintenant que l’équipe Google Tag Manager a lancé le Auditeur d’historiqueet le moment est venu pour moi de vous dire ce que ce bébé peut faire.

L’écouteur d’historique est conçu pour être utilisé sur des sites Web où le contenu est chargé dynamiquement. En règle générale, ces sites Web font un usage intensif d’AJAX (UNEsynchrone JavaScript unend XML), qui est conçu pour charger du contenu en arrière-plan et le diffuser dynamiquement sans avoir à recharger la page.

Parce que je ne veux pas approfondir le fonctionnement d’un site Web dynamique, ce tutoriel devrait être assez simple. La clé est de comprendre quels événements déclenchent l’écouteur d’historique et comment vous pouvez suivre vos pages vues sur un site Web sans URL statiques liées au contenu statique.

Arrière plan

Un site qui charge dynamiquement du contenu est généralement incompatible avec certains événements de navigateur par défaut. Par exemple, si vous avez un site qui charge dynamiquement son contenu sans aucun changement dans l’URL de la page (rien ne se passe dans la barre d’adresse), que pensez-vous qu’il se passe lorsqu’un visiteur quitte votre site et clique ensuite sur le navigateur Arrière bouton? Je peux vous donner un indice, ils ne verront pas l’état dynamique de la page juste avant leur départ.

Ceci est, bien sûr, un problème pour les moteurs de recherche également, car ils souhaitent indexer des pages avec des adresses URL uniques, qui renvoient chacune un élément de contenu statique et unique. C’est pourquoi Fragment d’URL (AKA ancres AKA hachages) ont été introduits pour résoudre les problèmes d’historique du navigateur. Si vous avez chargé du contenu en cliquant sur un lien “À propos de nous”, votre URL aurait ressemblé à https://www.simoahava.com/main#aboutus.

Cela a résolu le problème avec l’historique du navigateur, puisque vous pouviez désormais détecter les modifications dans le fragment d’URL et servir à nouveau le contenu approprié, même si l’utilisateur utilisait le bouton Précédent. Cependant, cela n’était pas suffisant pour les moteurs de recherche ou pour Google Analytics, qui ont du mal à gérer les fragments d’URL.

Entrer le coup de hache (le nom le plus cool jamais donné à quoi que ce soit n’importe où). Le hashbang est un hash suivi d’un point d’exclamation : # !. C’est une vieille invention, ayant existé dans les systèmes UNIX pour faciliter le chargement des scripts. Google l’a adopté comme schéma pour signifier un site AJAX avec un contenu crawlable. Lorsque les robots de recherche sont tombés sur la séquence hashbang, ils l’ont traduite en un paramètre de requête d’URL approprié (escaped_fragment=_the-original-fragment). Un paramètre de requête signifiait que la page pouvait être explorée et indexée pour que les utilisateurs des moteurs de recherche la trouvent.

Cependant, le hashbang n’est pas la solution la plus simple à mettre en œuvre, il a l’air absolument horrible, et ce n’est tout simplement pas la façon dont vous devriez traiter vos URL.

Le dernier chapitre de l’histoire, et le plus pertinent pour History Listener, est apporté par la norme HTML5. HTML5 a introduit le window.history API, qui peut être utilisée pour manipuler manuellement l’historique du navigateur lors du chargement dynamique de contenu. Vous pouvez maintenant pousser manuellement un état dans l’historique du navigateur, et lorsque quelqu’un navigue avec le bouton Retour du navigateur sur votre page, vous pouvez rechercher des états stockés et les charger dans l’ordre, tout comme le comportement par défaut d’un site Web statique.

L’écouteur d’historique écoute les changements dans l’historique du navigateur. S’il détecte un tel événement de changement, il vous dira ce qui s’est passé, s’il y a un objet d’état stocké dans l’historique et s’il y a eu un changement de fragment d’URL impliqué. Vous pouvez utiliser ces informations pour envoyer des vues de page virtuelles, empêcher certaines balises de se déclencher à nouveau, servir des balises dynamiques et essentiellement tout ce que vous feriez normalement lorsqu’une page est chargée.

Configurer l’écouteur d’historique

Vous configurez l’écouteur d’historique comme vous le feriez pour n’importe quel autre écouteur.

1. Créer une nouvelle balise

2. Nommez-le judicieusement

3. Définissez le type de balise sur Écouteur d’événement > Écouteur d’historique

4. Définissez la règle de déclenchement sur Toutes les pages ({{url}} correspond à regex .*)

Et c’est tout. Cela configurera votre auditeur sur toutes les pages pour attendre les déclencheurs qui l’activent.

Vous remarquerez également qu’un tas de nouvelles variables d’événement automatique ont été fournies. Vous pouvez les utiliser pour accéder aux propriétés du changement d’événement d’historique après le déclenchement de l’écouteur d’historique. En savoir plus à ce sujet dans mon guide des macros.

Les déclencheurs

L’écouteur d’historique s’active chaque fois que l’un des événements suivants se produit :

• Appel au méthode window.history.pushState()

• Appel au méthode window.history.replaceState()

• UNE état pop l’événement est détecté

• Le fragment d’URL (hachage) change

window.history.pushState() est utilisé pour ajouter un état dans la pile d’historique du navigateur. pushState() prend trois arguments : un objet d’état, un titre et une URL.

L’objet d’état est l’endroit où vous stockez des détails sur le contenu, que vous pouvez utiliser ultérieurement pour servir le même contenu au visiteur qui revient. Le titre n’est qu’un moyen de nommer l’entrée d’historique, bien qu’il puisse être utilisé avec état pop pour définir le titre de la page. L’URL est ce qui apparaîtra dans la barre d’adresse de votre navigateur après le pushState() csll est terminé. Ceci est particulièrement utile, car les visiteurs de votre site peuvent partager cette URL “virtuelle”, qui peut ensuite être utilisée pour proposer le contenu correct aux visiteurs arrivant via ce lien.

window.history.replaceState() est à peu près le même que pushState(), sauf qu’il remplace l’état actuel de l’historique par le nouvel état.

état pop est ce qui se produit chaque fois que l’entrée active de l’historique change. Par exemple, les boutons Précédent et Suivant du navigateur déclenchent état pop. Si l’entrée d’historique qui est activée lors état pop a été créé par pushState() ou alors replaceState()le état pop événement aura l’objet d’état stocké comme propriété. Vous pouvez utiliser cet objet pour diffuser le même contenu aux personnes naviguant dans l’historique du navigateur vers votre site AJAX.

Noter! Il existe certaines différences quant à la manière et au moment où les navigateurs envoient le état pop. Chrome et Safari, par exemple, lancent un état pop à chaque chargement de page (puisque c’est à ce moment que l’entrée d’historique active change), mais pas Firefox. Firefox nécessite une entrée d’historique qui a été créée par un pushState() ou alors replaceState() téléphoner à.

Modifications des fragments d’URL sont des vestiges de l’ère du hashbang, mais les fragments sont encore largement utilisés sur les sites Web. Par exemple, si vous avez des liens d’ancrage internes, vous déclencherez un événement de changement de fragment chaque fois que le visiteur accède à une ancre sur votre page. Dans les sites AJAX, vous pouvez écouter les événements de changement de fragment et les utiliser pour envoyer une vue de page ou déclencher une balise de votre choix.

{{event}} est égal à gtm.historyChange

Lorsque l’écouteur d’historique est en cours d’exécution et que l’un des événements décrits dans le chapitre précédent se produit, un gtm.historyChange est poussé dans la couche de données. La plupart des propriétés de cet événement sont accessibles par les macros d’événement automatique, mais il est bon de savoir à quoi ressemble l’entrée de la couche de données.

Voici à quoi ressemble votre objet dataLayer après un événement pushState(). Ici, l’objet d’état que je pousse est très simple. Il ne contient qu’une seule paire clé-valeur, rubrique : « À propos de nous ».

Voici à quoi ressemble votre dataLayer après un événement replaceState() . Les paramètres sont les mêmes que dans pushState(). Notez que j’ai lancé replaceState() juste après pushState(), vous verrez donc l’objet d’état précédent stocké dans le gtm.oldHistoryState la propriété!

Maintenant, si je quitte la page et que je reviens avec le bouton Précédent du navigateur, un état pop événement se produit avec mon objet d’état soigneusement stocké dans :

Comme vous pouvez le voir, l’ancien état et le nouvel état sont les mêmes, car j’ai quitté la page Contact et suis arrivé sur la même page après avoir cliqué sur Retour dans mon navigateur. Lorsque popstate se produit, je peux consulter l’objet d’état de l’historique et envoyer la vue de page correcte pour le contenu dynamique. Dans ce cas, je constate que le visiteur est revenu sur la page Contact.

Enfin, me voici naviguant d’un fragment d’URL à un autre :

Comme vous pouvez le voir, je suis d’abord allé au bas de la page via un fragment d’URL #fond. Cela déclenche une état pop événement, avec #fond comme gtm.newUrlFragment. Après cela, j’ai cliqué sur “Retour en haut”, ce qui m’a transporté vers l’URL #retour au sommetet cela se reflète dans la capture d’écran ci-dessus.

Exemple d’utilisation

Je vais montrer un exemple rapide, élargissant l’idée de naviguer vers la page “Contact”, où les détails de la page sont stockés dans un objet d’état, créé à l’aide de pushState().

Le principe est que lorsque votre visiteur clique sur un lien vers la page “Contact”, le contenu est chargé dynamiquement. Pour tenir compte des modifications de l’historique, le pushState() méthode est appelée avec quelque chose comme :

var page = {page:"Contact"}; history.pushState(page,'Contact','contact.html'); 

Cela pousse une nouvelle entrée dans la pile de l’historique de votre navigateur, avec une seule propriété dans l’objet d’état. Cette propriété est celle à laquelle nous voudrons accéder dans un état pop exemple, c’est-à-dire lorsqu’une personne revient sur la page de contact via un événement d’historique (Retour du navigateur, par exemple).

• Assurez-vous que votre écouteur d’historique est en cours d’exécution

• Créez une nouvelle macro de variable de couche de données pour identifier l’événement d’historique qui s’est produit :

• Créez une nouvelle macro de variable de couche de données pour obtenir le page propriété du nouvel état historique :

• Créez une règle pour votre balise de vue de page :

Et c’est tout. Vous pouvez joindre cette séquence à votre balise de vue de page, par exemple, en vous assurant que la vue de page est envoyée chaque fois que quelqu’un revient à votre contenu de contact via l’historique du navigateur (voir ci-dessous pour savoir comment vous assurer que les propriétés de vue de page sont en ordre).

La règle de tir est importante. Vous cherchez un gtm.historyChange un événement. Ceci est poussé dans la couche de données lorsque l’écouteur d’historique est déclenché. Après cela, vous voudrez vous assurer que l’événement a été état pop (la macro dans (2)), et que le page La propriété du nouvel état de l’historique a la valeur “Contact”.

Désormais, lorsque vous envoyez une vue de page, l’URL sera correctement contact.html (puisque vous le fournissez dans l’appel pushState()). Cependant, le titre de votre document peut être désactivé, à moins que vous ne le définissiez explicitement dans votre logique AJAX. Une bonne façon d’envoyer le titre de la page consiste à utiliser le paramètre Chemin du document dans votre balise de vue de page et à le remplir avec la valeur d’une macro de table de consultation, qui à son tour évalue le page propriété à nouveau. Permettez-moi de démontrer:

C’est votre balise de vue de page. Dans le champ Titre du document, vous récupérez la valeur d’une macro de table de consultation, que j’ai nommée {{ AJAX – Titre de la page }}.

Cela définit le titre de la page en fonction de la page propriété, poussée dans la couche de données lorsque l’écouteur d’historique est déclenché. Vous pouvez définir une valeur par défaut pour la macro Lookup Table, mais d’un autre côté, si elle ne renvoie pas de valeur, la balise enverra simplement tout ce qui se trouve dans la titre du document la propriété.

conclusion

Phew! Cela s’est transformé en un monstre de tutoriel. Mais c’est à prévoir. Travailler avec AJAX et le contenu dynamique n’est pas facile, car il y a tellement de choses à prendre en compte. Non seulement il y a des problèmes d’utilisabilité et de compatibilité du navigateur, mais vous devrez également prendre en compte les moteurs de recherche, et vous devrez comprendre comment fonctionnent les événements historiques.

Comme toujours, je vous recommande fortement de réviser votre JavaScript avant de commencer à travailler avec History Listener. Il n’y a aucun dommage à faire, mais vous ne voulez pas gâcher votre suivi en ne comprenant pas comment fonctionnent les objets d’état, par exemple. De plus, il est très probable que vous deviez revenir à votre configuration AJAX pour vous assurer que les appels pushState() et les appels replaceState() fournissent toutes les données nécessaires à votre utilisation.

Utiliser History Listener sur un site dynamique est tellement mieux que de recourir à Link Click Listeners. Le plus souvent, vous rencontrerez des problèmes de propagation d’événements avec vos auditeurs, car la plupart de la navigation AJAX est conçue pour empêcher le comportement par défaut des liens. Avec l’écouteur d’historique, vous n’écoutez que les événements de l’historique du navigateur, de sorte que les conflits sur la page n’affectent pas les fonctionnalités de base de l’écouteur.

Vous devrez être prudent et précis avec vos règles. Utilisez toutes les propriétés de l’événement gtm.historyChange, car vous aurez envie de faire différentes choses sur pushState() et état poppar exemple.

Et si vous avez des questions, envoyez-moi un mail ou laissez un commentaire ci-dessous !