Bfcache Google Tag Manager : le retour arrière compte en page vue

Dans quelques semaines, quelqu’un va vous montrer une courbe de pages vues GA4 qui monte sans raison et vous demander quelle campagne a si bien marché. Ce ne sera peut-être pas une campagne. Le 9 novembre 2026, Google Tag Manager a annoncé que ses tags qui comptent les pages vues sur changement d’historique enregistreront aussi les pages restaurées depuis le bfcache, le cache « précédent/suivant » des navigateurs. Concrètement, côté bfcache Google Tag Manager, le bouton Retour, qui passait souvent sous les radars, va désormais produire des page_view.

Bonne nouvelle sur le fond, puisque c’est un sous-comptage qui se corrige. Mauvaise nouvelle pour qui compare novembre à octobre sans le savoir, et vraie source de doublons pour les sites qui avaient déjà bricolé leur propre rattrapage. Voici ce qui change, qui est concerné, et comment mesurer l’effet sur vos données avant la clôture de fin d’année.

Ce que Google Tag Manager change le 9 novembre 2026

La note de version de Google Tag Manager du 9 novembre 2026 s’intitule « Back/forward cache support for page view on history change events ». Elle dit en substance que les tags de mesure web abonnés aux pages vues sur changement d’historique vont enregistrer une page vue quand une page est restaurée depuis le bfcache, comme ils le font déjà lors d’un retour arrière sans cache (notes de version GTM).

Deux détails comptent. D’abord, la note parle au futur (« will be updated ») : c’est un déploiement annoncé, pas une bascule datée à la minute pour tous les conteneurs. Ensuite, elle ne donne aucun chiffre d’impact. C’est à vous de le mesurer, et c’est l’objet de la suite.

Le bfcache en deux minutes

Quand vous quittez une page, le navigateur la détruit normalement. Avec le bfcache, il la met plutôt en pause, JavaScript compris, et garde une photo complète en mémoire. Si vous revenez en arrière, il ressort la photo : la page réapparaît instantanément, sans requête réseau et sans rechargement. Chrome le fait depuis la version 96, Firefox et Safari aussi (web.dev).

Pour l’internaute, c’est magique. Pour un outil de mesure, c’est un angle mort : pas de rechargement, donc pas de chargement de page, donc pas de page_view. Le seul signal disponible est l’événement pageshow, dont la propriété event.persisted vaut true quand la page sort du cache. Web.dev le dit sans détour : beaucoup de bibliothèques analytics ne comptent pas ces restaurations, donc vous sous-comptez probablement déjà dans les navigateurs qui utilisent le bfcache.

Avant et après : le même parcours, deux comptages

Prenons un parcours banal : une page catégorie, une fiche produit, puis le bouton Retour.

La dernière ligne explique la logique de Google : selon que le navigateur avait ou non gardé la page en cache, le même geste produisait ou non une page vue. Le changement aligne les deux cas. Votre mesure devient plus cohérente, mais elle change de base : c’est tout l’enjeu du bfcache Google Tag Manager pour vos séries historiques.

Bfcache Google Tag Manager : qui est concerné ?

Tout le monde n’est pas logé à la même enseigne. Le critère, c’est la présence d’une page vue déclenchée par l’historique du navigateur.

Les sites avec la mesure améliorée par défaut

Dans un flux web GA4, la mesure améliorée envoie un page_view à chaque chargement et à chaque changement de l’historique du navigateur (pushState, replaceState, popstate). L’option « Changements de page basés sur l’historique de navigation » est cochée par défaut (aide GA4). Si vous n’y avez jamais touché, vous faites très probablement partie des concernés, y compris sur un site classique qui n’a rien d’une application monopage.

Les applications monopage et leurs déclencheurs d’historique

Sur une application monopage (React, Vue, Next.js en navigation client), deux montages coexistent souvent : la mesure améliorée, ou un déclencheur « Changement d’historique » dans GTM qui pousse un page_view virtuel, comme le recommande le guide officiel. La note de version vise les tags abonnés aux pages vues sur historique ; elle ne précise pas si un déclencheur Historique personnalisé reçoit lui aussi un nouvel événement lors d’une restauration. Je ne vais pas inventer la réponse : testez en mode Aperçu (méthode plus bas) avant de conclure.

Les montages maison sur pageshow : le vrai risque

C’est le cas qui m’inquiète le plus. Des équipes qui avaient lu web.dev ont ajouté un écouteur pageshow pour rattraper les restaurations, à peu près comme ceci :

window.addEventListener('pageshow', function (event) {
  if (event.persisted) {
    window.dataLayer.push({ event: 'bfcache_restore' });
  }
});

Et derrière, une balise GA4 page_view déclenchée sur bfcache_restore. Après le déploiement de Google, ce montage et le tag natif risquent de compter la même restauration. Résultat : deux page_view pour un seul retour arrière, et des pages vues par session gonflées sans que personne ne comprenne pourquoi. Si ce code existe chez vous, c’est la première chose à vérifier, typiquement dans le dataLayer, comme on le voit dans les erreurs de dataLayer qui faussent GA4.

Ce qui bouge, résumé

Mesurer l’effet dans GA4 et BigQuery

La recette en Debug View et Tag Assistant

Le test prend cinq minutes, sur Chrome :

1. Ouvrez le mode Aperçu de GTM et la Debug View de GA4.
2. Chargez une page A, cliquez vers une page B, puis faites Retour.
3. Vérifiez dans les outils de développement de Chrome, onglet Application, section « Back/forward cache », que la page a bien été restaurée depuis le cache (documentation Chrome). Si elle ne l’a pas été, le test ne prouve rien : un unload ou un Cache-Control: no-store suffit à exclure une page du bfcache.
4. Comptez les page_view de la page A dans la Debug View : un seul au retour, c’est sain ; deux, vous avez un doublon à chasser.

La requête BigQuery : repérer la marche

Dans l’interface, la hausse se noiera dans le bruit saisonnier de novembre. Dans l’export BigQuery, un motif la trahit : la séquence A, B, A dans une même session. Avant le changement, le retour arrière restauré du cache ne laissait pas de trace ; après, il produit ce troisième page_view. Suivre la part de ces séquences jour par jour fait apparaître une marche à la date du déploiement sur votre propriété.

WITH pv AS (
  SELECT
    event_date,
    user_pseudo_id,
    (SELECT value.int_value FROM UNNEST(event_params) WHERE key = 'ga_session_id') AS session_id,
    event_timestamp,
    (SELECT value.string_value FROM UNNEST(event_params) WHERE key = 'page_location') AS page_location
  FROM `mon-projet.analytics_123456789.events_*`
  WHERE _TABLE_SUFFIX BETWEEN '20261019' AND '20261130'
    AND event_name = 'page_view'
),
seq AS (
  SELECT
    *,
    LAG(page_location, 2) OVER (
      PARTITION BY user_pseudo_id, session_id
      ORDER BY event_timestamp
    ) AS page_deux_avant
  FROM pv
)
SELECT
  event_date,
  COUNT(*) AS page_views,
  COUNTIF(page_location = page_deux_avant) AS retours_a_b_a,
  ROUND(100 * SAFE_DIVIDE(COUNTIF(page_location = page_deux_avant), COUNT(*)), 2) AS pct_retours
FROM seq
GROUP BY event_date
ORDER BY event_date;

Le motif n’est pas propre au bfcache : un internaute qui reclique sur le lien de la catégorie produit la même séquence. C’est pour cela qu’on regarde l’évolution du pourcentage, pas sa valeur. Si pct_retours saute de quelques points d’un jour à l’autre sans changement de site, vous tenez votre déploiement. Pour adapter la requête à vos tables, la base est la même que dans les requêtes BigQuery GA4 essentielles.

Pour aller plus loin, vous pouvez marquer les restaurations vous-même, comme le suggère web.dev, avec un paramètre de type de navigation envoyé en dimension personnalisée. Utile pour un audit ponctuel, mais à condition de ne pas envoyer un deuxième page_view au passage.

Les indicateurs qui vont bouger

Plus de pages vues, mais pas plus de sessions ni d’utilisateurs : mécaniquement, les pages vues par session montent. Les explorations de chemin vont afficher des allers-retours qui existaient déjà mais restaient invisibles. Et si d’autres tags (remarketing Google Ads, pixel Meta) se déclenchent sur les mêmes pages vues, leur volume suit. Si un indicateur bouge sans explication, croisez avec la méthode de diagnostic des données manquantes ou anormales dans GA4 : la différence entre bug Google et problème de tracking se joue souvent sur la date exacte de la rupture.

Que faire : garder, filtrer ou retirer le doublon

Garder le comportement natif

Mon avis : n’essayez pas de neutraliser le changement. Un retour arrière est une vraie consultation de page, et vos chiffres étaient jusqu’ici légèrement sous-estimés sur Chrome, Firefox et Safari. Couper l’option historique dans le flux GA4 pour retrouver les anciens volumes vous ferait perdre bien plus, notamment sur une application monopage.

Retirer l’écouteur pageshow maison

Si vous aviez votre propre rattrapage, retirez-le, ou au minimum suspendez la balise qu’il déclenche le temps de vérifier que le tag natif prend bien le relais. Garder les deux, c’est s’assurer un double comptage. C’est la même famille de nettoyage que celle imposée par le changement de gtag config dans GTM en octobre 2026 : Google reprend la main sur des comportements que l’on bricolait à côté.

Annoter et prévenir

Ajoutez une annotation dans GA4 à la date où vous constatez la marche, et prévenez ceux qui lisent les tableaux de bord : marketing, direction, équipe produit. Une hausse de quelques pourcents des pages vues avant le Black Friday, attribuée à tort à une campagne, coûte plus cher qu’une ligne d’explication envoyée à temps.

Checklist de recette

Le changement du 9 novembre est petit, technique et plutôt sain. Le seul vrai danger, c’est de le découvrir dans un comité de pilotage. Faites le test du bouton Retour aujourd’hui : il prend cinq minutes, et il vous évitera de commenter une croissance qui n’existe pas.