Tracker une Single Page Application :
quelle méthode choisir ?

Si vous suivez une application React, Vue, Angular ou Next.js avec un outil analytics et que vos rapports affichent une seule page vue par session, vous avez un problème de tracking SPA. C'est probablement le bug le plus courant — et le plus invisible — des implémentations analytics modernes.

Le diagnostic est simple : votre site change de route sans recharger la page, et votre outil analytics ne sait pas que l'utilisateur a navigué. Résultat : un funnel cassé, des taux de rebond artificiellement élevés et des décisions marketing prises sur des données fausses.

Trois méthodes permettent de corriger ça. Le principe est le même quel que soit votre outil — GA4, Piano Analytics, Matomo, Piwik PRO, Adobe Analytics, Plausible — mais chacune a un cas d'usage, des limites et un niveau de contrôle différent. Cet article les compare, avec les pièges que je rencontre régulièrement en mission de consulting tracking.

Pourquoi les outils analytics perdent la trace dans une SPA

Une Single Page Application charge une fois la page initiale, puis met à jour le contenu via JavaScript sans appel serveur. Les frameworks modernes utilisent l'History API du navigateur (pushState, replaceState) pour changer l'URL sans déclencher de rechargement.

Le tracking analytics traditionnel, lui, repose sur l'événement page_load du navigateur pour envoyer une vue de page. Sur une SPA, cet événement ne se produit qu'une seule fois : à l'arrivée de l'utilisateur. Toutes les navigations internes deviennent invisibles, quel que soit l'outil de mesure utilisé.

Méthode 1 : la détection automatique fournie par l'outil

Méthode 2 : le déclencheur "History Change" du TMS

Méthode 3 : pousser un événement custom dans le dataLayer

import { useEffect } from 'react';
import { useLocation } from 'react-router-dom';

export const usePageViewTracking = () => {
  const location = useLocation();
  useEffect(() => {
    requestAnimationFrame(() => {
      window.dataLayer = window.dataLayer || [];
      window.dataLayer.push({
        event: 'virtual_page_view',
        page_path: location.pathname + location.search,
        page_title: document.title,
        page_location: window.location.href,
      });
    });
  }, [location]);
};

router.afterEach((to) => {
  setTimeout(() => {
    window.dataLayer.push({
      event: 'virtual_page_view',
      page_path: to.fullPath,
      page_title: document.title,
      page_location: window.location.href,
    });
  }, 0);
});

Comparatif des 3 méthodes

Les pièges récurrents

Au-delà du choix de la méthode, certains problèmes reviennent dans presque toutes les implémentations SPA.

Comment valider votre tracking SPA

Aucune des méthodes ne se déploie sans validation. Le minimum avant production : mode prévisualisation du TMS, mode debug de l'outil analytics (DebugView GA4, Real-Time Matomo, console Adobe…), comparaison du nombre de vues envoyées vs attendues sur un échantillon de 10 navigations réelles. Si vous obtenez 9 ou 11 vues au lieu de 10, le tracking est cassé.

Testez aussi les cas limites : bouton retour navigateur, ouverture en nouvel onglet, refresh sur une page interne, deep link partagé. Tous ces parcours doivent émettre exactement une vue.

Quelle méthode pour quel projet

Trois questions suffisent à trancher.

Conclusion

Tracker une Single Page Application n'est pas un problème technique difficile. C'est un problème de choix d'architecture, et il se pose de la même façon quel que soit l'outil analytics utilisé. La détection automatique répond à 80 % des cas avec un effort nul, le déclencheur History Change du TMS à 95 % avec un peu de configuration, le push dataLayer custom à 100 % avec un peu de code.

Le piège classique : empiler les méthodes au lieu d'en choisir une. Si vous prenez une seule décision après cet article, vérifiez que vous n'avez pas la détection automatique de votre outil activée en même temps qu'une balise TMS de vue de page. C'est le bug le plus fréquent et le plus simple à corriger.