Comment le suivi des SPA compte les pages vues quand la page ne se recharge jamais

Qu'est-ce que le suivi des SPA ?

Dans une application monopage, le suivi des SPA consiste à enregistrer une page vue virtuelle chaque fois que l'application change d'écran en JavaScript, car le navigateur charge le document HTML une seule fois et n'effectue plus de nouveau chargement de page lors des changements de route suivants. Google décrit les SPA comme des "websites that load an HTML document once and fetch any additional content using JavaScript APIs," et fixe l'objectif sans détour : "The key to measuring page views from SPAs correctly is to count page views for each screen a user interacts with and get the page referrer right, so you can correctly trace the user journey."

Une page vue virtuelle est un événement de page vue que votre outil d'analytics envoie sans véritable chargement de page. Le navigateur ne demande jamais de nouveau document, mais le rapport affiche une nouvelle page avec sa propre URL et son propre référent, exactement comme s'il l'avait fait.

Pourquoi une balise d'analytics standard rate-t-elle les pages vues d'une SPA ?

Une balise d'analytics standard rate les pages vues d'une SPA parce qu'elle envoie sa page vue au premier lancement du script, et dans une SPA, le script ne se lance qu'une fois par visite. Un visiteur qui arrive sur /, ouvre /pricing puis /signup via des liens internes a pris des décisions sur trois écrans, alors qu'une balise limitée au chargement enregistre une seule page vue pour /.

Les dégâts dépassent le nombre de pages vues. Google note que sans pages vues virtuelles, "Google Analytics treats the SPA as a single page, leading to skewed metrics," et que "all engagement time is attributed to the initial page load, making it impossible to analyze time spent on individual screens." Les clics et les défilements sont eux aussi rattachés à l'URL d'arrivée. Le guide pages vues, sessions et utilisateurs explique pourquoi un faible nombre de pages vues par session dans une SPA est un signal de tracking avant d'être un signal de comportement.

Comment l'API History signale-t-elle un changement de route ?

L'API History signale un changement de route par des méthodes qu'appelle votre routeur et des événements que déclenche le navigateur, et les deux ne se correspondent pas un pour un. C'est ce décalage qui oblige les trackers à écouter à plusieurs endroits.

Changement	Ce qui le déclenche	Événement navigateur déclenché
history.pushState()	Votre routeur, sur un lien interne	Aucun
history.replaceState()	Votre routeur, quand il réécrit l'URL courante	Aucun
Bouton Précédent ou Suivant	Le visiteur	popstate
history.back(), forward(), go()	Votre code	popstate
Changement de hash (#section)	Un lien ou du code qui modifie le fragment	hashchange

MDN est explicite sur les deux premières lignes : "just calling history.pushState() or history.replaceState() won't trigger a popstate event." Un tracker qui n'écoute que popstate voit les clics sur Précédent et Suivant et rate chaque navigation vers l'avant via vos propres liens. Les trackers règlent ce problème en encapsulant ou en observant directement pushState et replaceState.

Comment GA4 suit-il les applications monopages ?

GA4 suit les applications monopages via un réglage de la mesure améliorée qui envoie un page_view quand l'historique du navigateur change. Le centre d'aide de Google décrit le déclencheur page_view comme "each time the page loads or the browser history state is changed by the active site," et indique que le réglage avancé "listens for pushState, popState, and replaceState." Google recommande cette voie "If your SPA uses the History API, specifically the pushState() and replaceState() method to update screens."

Pour l'activer :

1. Dans Google Analytics, ouvrez Admin.
2. Sous Data collection and modification, cliquez sur Data streams, puis sur votre flux web.
3. Sous Enhanced measurement, activez l'interrupteur.
4. Cliquez sur l'icône des paramètres, puis sous Page views, cliquez sur Show advanced settings.
5. Activez à la fois Page loads et Page changes based on browser history events.
6. Enregistrez.

L'autre voie est manuelle. Google liste les "Custom events" pour les sites où les écrans s'affichent sans changement d'URL, comme une application qui utilise des objets DocumentFragment. Dans ce cas, vous envoyez vous-même gtag('event', 'page_view', { page_title: '...', page_location: '...' }) depuis votre routeur.

Quelle méthode de suivi convient à votre SPA

Le routeur utilise pushState ou replaceStateActivez Page changes based on browser history events dans GA4

Les balises passent par Google Tag ManagerUtilisez le déclencheur History Change et laissez le suivi automatique de l'historique désactivé

Les écrans changent sans changement d'URLEnvoyez vous-même page_view comme événement personnalisé

Qu'est-ce qui cause le double comptage dans le suivi des SPA ?

Le double comptage dans le suivi des SPA se produit quand deux mécanismes envoient chacun une page vue pour le même changement de route. Les configurations courantes qui le provoquent :

• Google Tag Manager plus les événements d'historique de GA4. L'avertissement de Google : "If you configure your tags using Google Tag Manager, don't enable automatic history tracking in Google Analytics, as this can lead to double-counting page views." Un déclencheur History Change de GTM se déclenche déjà "when the URL fragment changes or when a site uses the HTML5 pushstate API."
• Des appels page_view manuels plus le réglage d'historique. send_page_view: false n'arrête pas les pages vues basées sur l'historique. Google l'indique : "If Enhanced Measurement is enabled, Google Analytics will send page_view events based on browser history changes even if you set send_page_view: false." Désactivez Page changes based on browser history events quand votre routeur envoie ses propres pages vues.
• replaceState utilisé pour des filtres ou des onglets. GA4 compte replaceState parmi les changements d'historique qu'il écoute, donc une liste de produits qui écrit ?sort=price dans l'URL avec replaceState peut produire une page vue à chaque changement de filtre. Testez-le dans DebugView avant de vous fier au nombre de pages sur des écrans chargés en filtres.
• Deux balises Google avec le même ID. Un extrait gtag codé en dur et une balise Google GTM qui pointent vers le même ID de mesure envoient chacun leurs propres événements.

Qu'est-ce qui cause des pages vues manquantes dans le suivi des SPA ?

Les pages vues manquantes dans le suivi des SPA viennent de changements de route qui n'atteignent jamais l'API History, et de pages vues envoyées au mauvais moment.

• Des routeurs qui ne changent jamais l'URL. Une application qui remplace des composants en mémoire ne donne rien à entendre à un écouteur d'historique. Utilisez la voie des événements personnalisés.
• Un routage par hash avec un tracker limité à l'historique. Changer #/pricing déclenche hashchange. Vérifiez si votre outil compte les changements de fragment, et configurez-le s'il ne le fait pas.
• Des pages vues envoyées avant la mise à jour de l'URL. Un page_view qui part avant pushState enregistre l'ancien page_location. Dans DebugView, Google conseille de comparer chaque page_view "with the preceding page_view event to check if the page referrer and page location have been updated correctly."
• Des référents périmés. L'exemple d'événement personnalisé de Google conserve l'ancienne URL et la passe en page_referrer, car le document.referrer du navigateur reste figé sur le référent d'arrivée pendant toute la visite.

Un piège voisin se trouve hors du routeur. web.dev note que le back/forward cache "doesn't work for 'soft navigations' within a single-page app," donc un clic sur Précédent à l'intérieur de votre application est un événement d'historique, alors qu'un clic sur Précédent qui ramène vers votre application depuis un autre site peut restaurer toute la page depuis la mémoire sans déclencher le moindre événement d'historique.

Comment vérifier que le suivi des SPA fonctionne ?

Vous vérifiez le suivi des SPA en parcourant l'application avec le mode débogage activé et en contrôlant que chaque nouvel écran produit exactement une page vue avec la bonne localisation et le bon référent. Le contrôle proposé par Google consiste à activer le mode débogage, "click through your single-page application," et à confirmer "a new page_view event in DebugView" pour chaque écran virtuel. Recommencez ensuite avec les boutons Précédent et Suivant, un changement de filtre et un lien avec hash, car ce sont les cas qui doublent ou perdent des pages vues. La checklist de vérification de l'analytics applique la même idée à n'importe quel tracker, et le guide sur la durée moyenne de session montre ce qu'un suivi de SPA cassé fait aux chiffres de temps passé sur le site.

Deux petites corrections aident les chiffres à tenir. Réinitialisez la position de défilement à chaque changement de route avec window.scrollTo(0, 0) pour que la profondeur de défilement s'applique au nouvel écran et non à l'ancien, et n'envoyez la page vue qu'une fois que le routeur a mis à jour l'URL et le titre.

Comment Flowsery gère-t-il la navigation dans une SPA ?

Flowsery suit automatiquement la navigation dans une SPA, donc un changement de route React Router ou Next.js apparaît comme une page vue à part entière sans code supplémentaire. La documentation du SDK npm de Flowsery liste "pageviews, including SPA navigation" dans le tracking automatique, et sa FAQ tarifaire indique que Flowsery "counts a pageview each time a visitor loads a page on your site, including single-page app navigations." Pour les applications qui routent avec des fragments d'URL, le SDK npm propose une option hashMode, et la documentation du script décrit une version du tracker pour les SPA à routage par hash. Si votre application change d'écran sans changer d'URL, le SDK expose trackPageview() pour que vous en envoyiez une depuis votre propre code. La page analytics pour React explique comment Flowsery mesure les routes côté client, les événements personnalisés, les entonnoirs et le chiffre d'affaires dans les applications React.

Questions fréquentes

Qu'est-ce qu'une page vue virtuelle ?

Une page vue virtuelle est un événement de page vue envoyé sans véritable chargement de page, utilisé quand une SPA change d'écran en JavaScript. Elle porte sa propre localisation de page et son propre référent, donc les rapports traitent chaque écran comme une page distincte. Sans elle, une visite de SPA apparaît comme une longue consultation de la page d'arrivée.

GA4 suit-il automatiquement les changements de route d'une SPA ?

Oui, si la mesure améliorée est activée et que Page changes based on browser history events est coché dans les paramètres avancés des Page views. Ce réglage écoute pushState, popState et replaceState. Il n'aide pas les applications qui changent d'écran sans changer d'URL.

Pourquoi GA4 compte-t-il chaque page vue de ma SPA deux fois ?

Deux mécanismes envoient des pages vues pour le même changement. Les paires habituelles sont les déclencheurs d'historique GTM avec les événements d'historique de GA4, ou des appels page_view manuels avec les événements d'historique de GA4. Désactivez l'un des deux ; Google précise que send_page_view: false n'arrête pas les pages vues basées sur l'historique.

pushState déclenche-t-il popstate ?

Non. MDN indique qu'appeler history.pushState() ou history.replaceState() ne déclenche pas d'événement popstate. Seules les actions du navigateur, comme les boutons Précédent et Suivant, ou des appels comme history.back(), le déclenchent.

Comment page_referrer doit-il fonctionner dans une SPA ?

Chaque page vue virtuelle doit porter l'URL de l'écran précédent comme référent. Conservez l'ancienne URL avant le changement de route et passez-la en page_referrer avec le nouveau page_location. Sinon, chaque écran remonte le référent d'arrivée d'origine.

Le back/forward cache affecte-t-il le suivi des SPA ?

Pas pour les navigations à l'intérieur de l'application. web.dev indique que le bfcache ne fonctionne pas pour les soft navigations au sein d'une SPA. Il s'applique quand un visiteur quitte votre application et y revient avec le bouton Précédent, ce qui peut restaurer toute la page depuis la mémoire sans nouveau chargement si la page y est éligible.

Comment activer le suivi des SPA dans GA4 ?

Ouvrez Admin, cliquez sur Data streams, choisissez votre flux web et activez Enhanced measurement. Cliquez ensuite sur l'icône des paramètres, ouvrez Show advanced settings sous Page views et activez à la fois Page loads et Page changes based on browser history events. Enregistrez. Cette méthode fonctionne quand votre routeur utilise pushState et replaceState.

Faut-il activer le suivi de l'historique de GA4 si j'utilise Google Tag Manager ?

Laissez-le désactivé. Google prévient que cumuler les deux peut entraîner un double comptage des pages vues. Un déclencheur History Change de GTM se déclenche déjà quand le fragment d'URL change ou quand le site utilise l'API pushstate HTML5.

Comment suivre des routes à hash comme #/pricing dans une SPA ?

Modifier le fragment déclenche hashchange, donc un outil qui n'observe que l'API History peut le manquer. Vérifiez si votre outil compte les changements de fragment et configurez-le si ce n'est pas le cas. Le SDK npm de Flowsery propose une option hashMode, et la documentation du script décrit une version du traceur pour le routage par hash.

Comment vérifier que ma SPA envoie une page vue par écran ?

Activez le mode debug, parcourez l'application et cherchez dans DebugView un nouvel événement page_view pour chaque écran. Comparez chacun au page_view précédent pour confirmer que l'emplacement de la page et le référent ont été mis à jour. Recommencez avec les boutons précédent et suivant, un changement de filtre et un lien à hash.