Find duplicate pageviews in a single-page application
Inspect first load and client-side navigation as separate pageview paths, locate overlapping automatic and manual sends, and verify one chosen screen contract.
Find the sender before filtering the result
A single-page application can send one pageview from initial tag configuration, another from browser-history measurement and another from a custom route effect. If those paths overlap, a dashboard filter may hide the symptom while engagement and other downstream measures remain distorted.
Google’s SPA documentation describes history-based or custom-event virtual pageviews and recommends checking page location and referrer during navigation. It also warns about double counting when automatic history tracking overlaps a Tag Manager implementation. [Google Analytics: Measure single-page applications]
Start by defining what counts as a virtual screen in this product. A meaningful route change and a sort parameter update may have different intended behavior. There is no useful duplicate count until the expected screen contract is clear.
A synthetic first-load and navigation trace
| Journey step | Expected page_view count under this contract | Suspicious evidence |
|---|---|---|
| First document load: /tools | 1 | Config send and manual first-route send both appear |
| Internal navigation: /tools to /tools/example | 1 additional | History sender and route handler both fire |
| Change a non-screen filter | 0 additional | A generic URL-change listener records another screen |
| Browser back to /tools | 1 additional | Back navigation is missing or counted twice |
| Reload /tools | 1 in the new document load | Initialization runs twice |
Capture event timestamps, page location, referrer and known sender context in a permitted technical test. Two pageviews close together are suspicious but not sufficient by themselves: the user may have genuinely visited two screens. Compare the event log with the action log.
A framework can invoke a route effect more than once during development, while production behaves differently. Verify the actual production build. Also inspect whether multiple tag containers or an embedded third-party script introduce an additional sender.
Give the pageview path one owner
- Inventory first-load, history and manual pageview mechanisms.
- Write the expected count for each relevant transition.
- Reproduce the overlap with a technical journey.
- Choose which mechanism owns each transition and disable only the redundant path.
- Verify location and referrer as well as event count.
Do not globally suppress every repeated URL. Returning to the same route later can be a real pageview under the chosen contract. A deduplication key based only on URL can remove legitimate navigation. If a local duplicate guard is needed, define its scope and lifecycle around the actual transition.
Consent initialization needs its own case. When analytics becomes permitted after the page is visible, the first eligible event should follow the site’s documented contract. A permission update should not accidentally trigger both a new configuration pageview and an unconditional route pageview. Preserve the denied state rather than sending first and filtering later.
Replay the changed paths, then review the aggregate
- Direct entry to a nested route with permission already granted.
- Entry with permission denied, followed by an authorized grant and a withdrawal.
- Two internal navigations, browser back/forward and a full reload.
- A query update that is not an intended new screen.
- An initialization or routing error that previously caused a fallback.
Save the before/after event log and expected counts. Technical delivery proves that the tested path now follows the contract; it does not establish the size of the historical inflation. Review later complete visitor periods separately, with technical tests excluded.
I would leave a short ownership note beside the pageview code and an acceptance test for the overlapping path. That is more durable than a report filter whose purpose becomes unclear at the next routing change.
Sources
AI-assisted writing and an AI-generated editorial cover. Source links and checked dates are listed below; illustrative examples are labeled in the text.
- Google Analytics: Measure single-page applications — checked 2026-10-18