Tag Manager now counts back-button returns as page views

If your page views went up on 9 November and your traffic did not, the Tag Manager release notes explain it. Google tags that send page views on history changes now also count a page the browser restores from its back/forward cache. Until now those returns were not counted.

What changed

The back/forward cache (bfcache) keeps a page in memory after the user leaves it. When they press Back, the browser shows the stored page again. It does not load it again, so no page load event fires and no history state changes. Google’s web.dev guide says this plainly: many popular analytics libraries “don’t measure bfcache restores as new pageviews”.

Google’s Tag Manager release notes for 9 November 2026 change that for one group of tags: web measurement tags that subscribe to “page view on history change” events. These tags now record a page view on a bfcache restore, “mirroring the behavior of these tags on non-cached back and forward navigation”. If the browser did not cache the page, Back reloads it, and the tag counted that return already.

Google does not list the tags. The best-known one is the Google tag sending Google Analytics page views. Its enhanced measurement page view option has an advanced setting that sends page_view on browser-history events (pushState, popState, replaceState). That setting is a subscription of this kind, so a Google Analytics property with it on is our working assumption for what is affected.

The read: the old count depended on the browser

Before 9 November, a return with the Back button counted only when the browser did not cache the page. That depends on the browser, on the device’s memory, and on things the page does that block bfcache, such as Cache-Control: no-store or an unload handler. Two visitors with the same journey could give two different view counts. The undercount was largest on the pages people come back to: category pages, search results, comparison tables.

How big is the jump? Google’s own Chrome usage data puts back and forward at 1 in 10 navigations on desktop and 1 in 5 on mobile. That is the upper limit. Only the share of those that land on your pages and are restored from the cache gives new views. So expect a step up in Views on mobile, and on listing pages, from 9 November, with no change in users or sessions. Views per session and any rate that divides by views move with it.

The same change can count one return twice in two setups:

• A pageshow listener added by hand. web.dev’s bfcache guide gives a fix for the undercount: listen for pageshow and send gtag('event', 'page_view') when event.persisted is true. A site that added this and has the history setting on can now send two page views for each bfcache restore.
• A key event built on a thank-you page. Google’s help shows how to create a key event from page_view when the URL is the thank-you page. “Once per event” counting is the default for key events not migrated from Universal Analytics goals. A buyer who leaves the thank-you page and comes back with Back can now add a second conversion, whether the browser cached the page or not. If that key event goes to Google Ads, bidding learns from it.

What to do

• Annotate 9 November in your Google Analytics reports. Read a jump in Views from that date as measurement, not demand, until users and sessions confirm it.
• Search your site code for pageshow. If a listener sends a page_view on event.persisted, test one back-button return in DebugView. Two page_view events for one return means you remove the listener.
• Check key events made from page_view. A purchase or lead counted from a thank-you page view is safer counted from the purchase or generate_lead event the page sends once. Or set it to “Once per session” if the event is a lead you count one per visit.

The jump moves every number that divides by views and leaves every number that divides by sessions or users the same. Which one does your conversion rate use? The answer can move the rate by more than any campaign change, and the denominator decides it.