The page_view event: the base of web analytics
page_view is the event fired when a page loads. It is the base of almost every web-analytics model: sessions, pageviews, and most reports build on it. In classic sites the tracker fires it automatically on load; in single-page apps you fire it on each route change. Its properties (path, title, referrer) drive most downstream reports.
What this means
page_view marks that a page (or virtual route) was shown. Reports for top pages, entrances, exits, and most session logic are built by aggregating page_view events. If it does not fire, the page effectively does not exist in your analytics.
Firing it correctly
Multi-page sites fire page_view automatically on load. Single-page apps must fire it on each client-side navigation — miss that and only the first route is counted; fire it twice and pageviews inflate. Useful properties include the pathname, page title, and referrer; avoid putting personal data in them.
- Auto-fires on load in classic sites
- Fire manually on SPA route changes
- Properties: path, title, referrer — never PII
How it appears in analytics and logs
A missing page_view means a route is invisible to analytics; a duplicated one inflates pageviews. SPA routing is the usual cause of both, so verify firing on navigation.
Diagnostic use case
Ensure page_view fires once per real navigation — including SPA route changes — so pageviews, sessions, and landing-page reports are correct.
What WebmasterID can help detect
WebmasterID's tracker emits page_view events first-party; the ingest API classifies the request and keeps bot page_views out of human analytics.
Common mistakes
- Not firing page_view on SPA route changes.
- Double-firing it and inflating pageviews.
- Putting personal data into event properties.
Privacy and accuracy notes
A page_view needs only the path and a few non-identifying fields. WebmasterID records it first-party with no cookies and never stores raw IPs or full user-agent strings of real visitors.
Related pages
- Custom events: tracking what matters to you
Custom events capture meaningful actions a pageview cannot — a CTA click, a signup, a video play, a form submit. The value is in a consistent naming taxonomy and well-chosen properties. The risk is putting personal data into event names or properties, which turns analytics into surveillance. This page covers both.
- Pageviews: what the metric counts
A pageview is recorded when a page is loaded (or a virtual page is rendered in a single-page app). It is the oldest web-analytics metric and the easiest to misread: pageviews count loads, not people, and modern apps and prefetching can inflate or hide them. This page defines the metric and its caveats.
- Analytics sampling: when reports estimate
Sampling is when an analytics tool computes a report from a fraction of the data and extrapolates. It keeps big queries fast, but it adds estimation error — worst for small segments and rare events, where a few sampled sessions get scaled into a confident-looking number. Knowing when a report is sampled is the first defence.
- Events reference (docs)
What each WebmasterID event contains.
Sources and verification notes
Last reviewed 2026-06-24. Facts are checked against primary/official sources where available; uncertain specifics are marked “Data not yet verified” rather than guessed.