Skip to content

Pageview & Screenview

Pageviews and screenviews are the navigation primitives of web and mobile-app analytics respectively. Both count how often users move between places inside a product, but the implementations differ, and that difference matters when comparing reports across tools.

Understanding Pageviews

A pageview fires when a user loads or reloads a web page. The metric has been the cornerstone of web analytics since the early web. Each pageview represents a visit to a URL, captured via server logs or, more commonly, a JavaScript snippet that fires on page load.

Pageviews track:

  • Full page loads and refreshes
  • Browser back/forward navigation
  • Direct URL entries
  • Link clicks leading to new pages
  • In single-page apps, every client-side route change via history.pushState / replaceState, and hash navigations

Example: e-commerce navigation

A shopping journey produces multiple pageviews:

  • Homepage load: 1 pageview
  • Category page: 1 pageview
  • Product detail page: 1 pageview
  • Cart page: 1 pageview
  • Checkout: 1 pageview

Total session: 5 pageviews

Understanding Screenviews

Screenviews are the mobile-app equivalent, tracking when users navigate between screens inside an installed app. App screens load from local resources. There is no HTTP request to a server, no URL, so screenview tracking depends entirely on instrumentation in the app code.

Screenviews capture:

  • Screen transitions inside the app
  • Tab switches in multi-tab interfaces
  • Modal or popup displays
  • View changes in single-Activity Android or single-Scene iOS apps

Best practice: consistent naming

Use descriptive, consistent screen names across iOS and Android:

  • Instead of: MainActivity, ViewController2
  • Use: Home Screen, Product Details, Shopping Cart

This keeps cross-platform reports coherent.

Key Differences

The fundamental gap is technical. Pageviews involve full document loads with URL changes; screenviews track state changes inside a persistent app environment. Single-page apps blur this line, behaving more like a native app than a traditional website with no real document loads after initial render.

SPA tracking caveats

Single-page applications sit between the two models:

  • Traditional multi-page site: each navigation is a new pageview
  • SPA: route changes need to be wired to the analytics SDK so they get counted
  • Mobile app: each screen change is a screenview, fired manually from app code

Statable and screenviews

Statable is a web-only analytics tool. It tracks pageviews, including SPA route changes via history.pushState interception, but ships no mobile SDK and records no screenviews. If your product is an iOS or Android app, Statable will not capture in-app navigation. For a hybrid (mobile web plus native app), the dashboard reflects only the web side.

For a typical web project, this is exactly what you want: a small script, no fingerprinting, every pageview counted including SPA transitions. See Pageviews for how Statable computes and reports the pageview metric.

Ready to take control of your web analytics? Try Statable free for 30 days — no credit card required, full feature access, GDPR-compliant by default. Start your free trial or view a live demo.