Page Views vs Events
Date: 2026-08-16
The older model counted page loads and inferred everything else from URLs. Single-page apps broke the counting, and the inference was always weak — but the pageview didn’t disappear, it became one event among many.
What it is
The pageview model treats a page load as the unit of measurement. Behaviour is inferred from which URLs were loaded, in what order, and how long between them.
The event model treats any meaningful action as the unit, with a pageview as one kind of event among many.
PAGEVIEW MODEL EVENT MODEL
/collections/socks page_view {path: /collections/socks}
/products/wool-socks filter_applied {facet: colour, value: navy}
/cart product_viewed {id: 4471}
/checkout add_to_cart {id: 4471, qty: 2}
/thank-you checkout_started
purchase {value_pence: 4800}
behaviour inferred behaviour recorded
Why the older model broke
Single-page apps. A framework router changes the URL without a page load, so nothing fires. Everything after the first navigation became invisible unless you manually instrumented the router — see The History API.
Interactions aren’t navigations. Opening a size guide, applying a filter, expanding a description — all meaningful, none of them a page load. The pageview model can only see them if you create a fake URL for each, which is what the era’s workarounds did and why old implementations are full of /virtual/size-guide-opened.
Inference is weak. “Time on page” was computed as the gap between two pageviews, which meant the last page of every visit had no duration at all — the origin of bounce rate being defined as a single-pageview session with no measurable time. That definition was an artefact of the measurement model rather than a fact about users.
What survived
The pageview didn’t go away, and treating it as obsolete is a mistake:
- It’s still the best proxy for “what were they looking at”, and page path remains the most-used dimension in any tool
- Content and SEO analysis needs it — traffic by landing page, entrance and exit, by template
- It’s free. Automatically collected by every tool, requiring no instrumentation decisions
The modern position is that a pageview is an event with a path property, which makes it queryable alongside everything else rather than living in a separate reporting universe.
What this changes in practice
- You must instrument route changes yourself in a single-page app. Nothing fires automatically, and the framework’s router is the hook — The Data Layer
- Page path is a property, not a table. Grouping by template rather than by URL is a query, which is why URL Structure affects analytics as well as SEO
- Engagement needs its own events. Scroll depth, visibility and interaction have to be deliberately fired, and firing them changes your session count — Sessionisation, Engagement Metrics
- Bounce rate needed redefining. Most tools now use an engagement threshold rather than a single-pageview rule, which makes it a different metric with the same name — Metric Drift
The failure mode that persists
Instrumenting events while still thinking in pages. The signature is an event set that mirrors the sitemap — homepage_viewed, category_viewed, product_viewed — with no events for anything the user actually does.
That produces a dataset where you can see where people went and never why they left, which is the exact weakness the event model existed to fix. The test: can you answer “how many people applied a filter and then bought”? If every event is a page, you can’t.
See Event Taxonomy Design for designing the set properly, and Ecommerce Event Schema for the conventions you inherit rather than choose.