Tracker des Single Page Applications avec GTM et GA4

Qu’est-ce qu’une Single Page Application (ou SPA) ? #

Une Single Page Application est un type de site web qui charge tout le code nécessaire à la navigation dès la première page. Comme son nom l’indique, c’est une application qui n’est constituée que d’une seule page.

Les SPA sont souvent créées à partir des framework Javascript Angular, React et Vue.js.

Google Analytics 4 offre une fonctionnalité par défaut pour tracker les SPA mais celle-ci peut ne pas fonctionner selon votre cas. C’est pour cette raison qu’on va voir 3 méthodes différentes dans cet article.

Qu’est-ce que l’History API en Javascript ? #

Sans rentrer dans les détails techniques, l’idée ici est de bien comprendre le fonctionnement des SPA.

L’objet history est une variable Javascript globale qui est utilisée par la plupart des SPA pour manipuler l’historique de navigation.

Si vous travaillez sur une SPA assez ancienne, il se peut qu’elle n’utilise pas l’History API de Javascript et dans ce cas-là vous devrez installer Google Analytics 4 via la méthode 3.

Les 3 méthodes pour tracker une SPA avec GTM et GA4 #

Méthode 1 : Laisser GA4 avec les réglages par défaut #

On va maintenant voir ce qu’il se passe si j’installe la balise de configuration d’une nouvelle propriété GA4 sur toutes les pages.

Je reçois maintenant des événements History (gtm.historyChange-v2) et des événements History Change (page_view).

L’événement gtm.historyChange-v2 est déclenché autant de fois que le gtm.historyChange car ils écoutent les mêmes événements (ceux de l’History API).

En revanche, gtm.historyChange-v2 est géré par GA4 alors que gtm.historyChange est géré par GTM.

C’est pour cela que gtm.historyChange-v2 déclenche ensuite un événement page_view (nommé History Change dans GTM).

Cet événement page_view permet ensuite de tracker toutes les pages vues en s’appuyant sur l’history API.

Cette fonctionnalité est activée par défaut dans les mesures améliorées de GA4 et peut être désactivée si vous estimez que c’est nécessaire. Si vous souhaitez transmettre plus d’informations dans l’événement page_view vous serez obligé de passer par la méthode 3.

Méthode 2 : Tracker les pages vues avec le déclencheur Modification de l'historique dans GTM #

Pour utiliser cette méthode, je désactive le suivi des pages lors du changement de l’historique de navigation dans les paramètres des mesures améliorées de GA4.

Je n’ai plus que l’événement gtm.historyChange, l’événement gtm.historyChange-v2 n’est plus présent dans la Data Layer.

Je vais maintenant mettre à jour tous mes événements GA4 pour surcharger les paramètres page_location et page_referrer en utilisant les variables envoyées par le déclencheur de changement d’historique.

Pour cela, je vais créer une variable d’événements de la balise Google (Google tag: Event settings) et je vais renseigner ces 2 paramètres.

A partir de maintenant, j’ai deux options :

1. utiliser les paramètres d’événements partagés (Shared event settings) de la balise Google. Ceci permet d’appliquer les paramètres renseignés à tous les événements GA4 à condition que pour l’ensemble des événements GA4, la balise Google se déclenche avant.

2. ajouter les paramètres à l’ensemble des événements GA4 (ceci permet de s’assurer que tous les événements auront les paramètres)

Dans l’événement page_view

Dans tous les autres événements

Méthode 3 : Tracker les pages vues via la Data Layer #

Pour utiliser cette méthode, je désactive le suivi des pages lors du changement de l’historique de navigation dans les paramètres des mesures améliorées de GA4.

La méthode 3 consiste à demander à un développeur d’envoyer un événement page_view dans la Data Layer lorsque l’utilisateur change de vue dans la SPA.

dataLayer.push(
    {
        event: "page_view",
        virtual_page_title: document.title,
        virtual_page_location: document.location.protocol + '//' +
                    document.location.hostname +
                    document.location.pathname +
                    document.location.search,
        virtual_page_referrer: document.referrer
    }
);

Une fois que la Data Layer a été mise en place par le développeur, je vais mettre à jour tous mes événements GA4 pour surcharger les paramètres page_title, page_location et page_referrer en utilisant les variables envoyées par le déclencheur de changement d’historique.

Pour cela, je vais créer une variable d’événements de la balise Google (Google tag: Event settings) et je vais renseigner ces 3 paramètres.

A partir de maintenant, j’ai deux options :

1. utiliser les paramètres d’événements partagés (Shared event settings) de la balise Google. Ceci permet d’appliquer les paramètres renseignés à tous les événements GA4 à condition que pour l’ensemble des événements GA4, la balise Google se déclenche avant.

2. ajouter les paramètres à l’ensemble des événements GA4 (ceci permet de s’assurer que tous les événements auront les paramètres)

Dans l’événement page_view

Dans tous les autres événements