Technical
Single-page application tracking
Also called SPA tracking.
Single-page application tracking is recording views in an app that swaps screens with JavaScript instead of loading a new document. The tracker has to notice route changes itself, because the browser never fires a load.
How it is measured
In DevTools click through the app. The URL changes but no document request appears, only fetch calls. A correct tracker sends one event per route change by hooking `history.pushState`, `replaceState`, `popstate`, and sometimes `hashchange`. Compare the event count with the route changes you made by hand.
Check that each payload carries the new URL and title, not the ones from first load. Many frameworks update the title a moment after the route changes.
Worked example
A React dashboard has six routes. A visit that opens `/overview`, then clicks through to `/reports/42` and `/settings`, should send three events. The tracker fires only on load and records one, so `/reports/42` shows zero views for two weeks.
Adding a history hook lifts the count from 8,100 to 23,400 events a week. Every title still reads Dashboard because the framework sets it 50 ms after the route change, so the tracker now waits a tick before reading it.
How it differs
SPA tracking is the whole job of recording navigation in such an app. A virtual pageview is the single event you send for one route change. The setup decides when each virtual pageview fires.
Common errors
Tracking only the first load. Firing on both pushState and a framework event. Reading the title before it updates. Sending the old URL as the referrer. Counting query-only changes as new views. Mishandling `replaceState` redirects. Missing back and forward.
In practice
Click every route in staging with the Network tab open and count the events. Hook the history API once in the tracker, wait for the title to settle, and skip changes that only call `replaceState`.