Single page application tracking is the setup that makes analytics record page views and events correctly on a site that changes what you see without loading a new page. Sites built with React, Vue, Angular or similar frameworks often work this way, and without extra configuration they can report one page view for an entire visit.
How single page application tracking works
On a traditional site, every click loads a fresh HTML page and the analytics tag fires again, so each page is counted. A single page application (SPA) loads once, then uses JavaScript to swap content in and update the address bar through the browser’s History API. The tag only loaded once, so unless something tells it the view has changed, it records nothing new.
There are three common ways to close the gap:
- GA4 enhanced measurement. The page view setting includes an option to count page changes based on browser history events. It works on many SPAs with no code, but it fires as soon as the URL changes, sometimes before the page title has updated.
- A history change trigger in Google Tag Manager. A history change trigger fires your page view tag on each route change, giving you control over timing and which values are sent.
- Developer-pushed events. The application pushes a virtual page view to the data layer once the new screen has rendered, with the correct path and title. This is the most reliable option because the app knows exactly when a view is complete.
Why it matters
Untracked SPAs produce reports that look plausible but are wrong. Pages per session drops to one, landing page reports credit everything to the home page, and funnels that depend on reaching a confirmation screen show no completions. Ad platforms suffer too: if the Meta Pixel or Google Ads tag cannot see the thank-you view, it cannot record the lead, and automated bidding learns from bad data.
Consent is the other UK angle. Your cookie banner’s choice has to carry across every route change. A common fault is an SPA where the consent state resets or the banner re-renders on each view, which either annoys visitors or lets tags fire without valid consent under PECR.
Common mistakes
- Counting twice. Leaving enhanced measurement’s history option on while also firing a GTM page view on history changes creates double-firing page views.
- Stale titles and referrers. Firing before the new screen renders sends the previous page’s title, so reports show the wrong names against the right URLs.
- Data layer values that never clear. A product value pushed on one screen can still be present on the next, attaching itself to unrelated events.
- Counting every query change. Filters and sort options that only change a URL parameter can trigger page views you do not want, inflating counts. Decide which route changes deserve a page view.
How to act on it
Start by checking whether you have a problem. Open the site with GTM preview or GA4 DebugView, click through four or five screens and watch whether a page_view arrives for each one with the right path and title. If it does not, agree with your developer which of the three methods to use, then switch off the others so nothing double counts.
SPA tracking overlaps with JavaScript SEO, since the same rendering choices affect what search engines see. Getting both right on ad landing pages is part of my performance marketing service, because paid campaigns are only as good as the conversions they can record.