How single page application tracking works
A traditional website asks the server for a new document every time you click a link, and the analytics tag runs again on each new document. A single page application loads once and then rewrites the screen in the browser, updating the address bar without ever fetching a new page. Frameworks such as React, Vue, Angular and Next.js work this way, and so do many modern booking engines and dashboards.
The tag, having run only once, sees only the first screen. To measure the rest you have to tell it when a screen change has happened. There are two usual routes. Analytics can watch the browser history for address changes and record a view each time one occurs, which is what the enhanced measurement option for page changes does. Or the application itself can announce each route change by writing an entry into the data layer, and a tag manager listens for that announcement.
Why single page application tracking matters
Without it, your reports describe the entry screen and nothing else. Everything a visitor did afterwards — the product they configured, the step they abandoned, the confirmation they reached — is invisible, so engagement looks poor and the funnel appears to have no middle.
Conversions suffer most. If the thank-you screen never registers as a view, a conversion built on that screen never fires, ad platforms stop receiving the signal they optimise against, and campaigns are judged on outcomes the site failed to report. On checkout and enquiry flows this is the difference between a campaign that looks profitable and one that looks dead.
Where single page application tracking goes wrong
Timing is the classic fault. The address changes before the new screen has finished rendering, so the view is recorded with the previous page title, or with a title the framework has not yet updated. Reports then show real traffic filed under the wrong screen name, which is harder to spot than missing data.
Duplication is the next fault. Automatic history watching and a manual announcement from the application can both fire for the same route change, doubling views. The same happens when a framework rewrites the address for a filter or a modal that is not really a new screen at all.
Then there are the invisible steps: a checkout implemented as stages within one address, where nothing changes for the browser to notice. Those need their own events, defined with the developers, because no automatic setting can detect them.
What to do about it
Decide first what counts as a screen worth recording. Filters, sort orders and opened dialogs usually do not; steps a customer moves through usually do. Write that list down before anyone touches the tag manager, because it is a business decision rather than a technical one.
Prefer an explicit announcement from the application over automatic detection: ask the developers to push an event after the new screen has rendered and its title has settled, and use the history change trigger only where you cannot get developer time. Then test the whole journey in preview mode, watching for missing views, duplicated views and wrong titles, and repeat the test on a phone. Getting this right is normally part of a wider Google Tag Manager implementation rather than a standalone change.