Pages Per Session

Pages per session is a Universal Analytics metric that divided total pageviews by total sessions to show the average number of pages a visitor viewed before leaving. GA4 does not show pages per session as a default column — the metric was retired with the rest of UA in July 2023. To get the same signal in GA4 you either calculate views per session manually in Explorations, derive it from a BigQuery export, or switch to richer engagement metrics like engagement rate and engagement time. This guide covers the formula, the UA-to-GA4 migration story, the manual calculation, industry benchmarks, and when high pages per session actually means low engagement.

What Is Pages per Session (formula and meaning)

In Universal Analytics, pages per session was defined as:

Pages/Session = Total Pageviews / Total Sessions

If a site recorded 10,000 sessions and 23,500 pageviews in a month, the average pages per session was 2.35. The metric answered a simple question: on average, how deep does a visitor go before leaving? It was a default column in every UA session-scoped report — Audience, Acquisition, Behavior — and a staple of stakeholder dashboards from 2007 through 2023.

The number sounds simple but conflates two very different behaviors. A pages-per-session of 3.0 might mean visitors are reading the site deeply, or it might mean the site has a confusing navigation that forces visitors to click around hunting for what they need. The metric does not distinguish high engagement from high friction. That ambiguity is one reason GA4 retired it.

Universal Analytics vs GA4: The Metric is Gone

When Google released Google Analytics 4 in October 2020 and forced the migration in 2023, dozens of UA staples were redefined or removed. Pages per session was removed entirely. There is no checkbox to turn it on, no metric called pagesPerSession in the GA4 Data API, and no automatic translation from the UA value.

The reasoning, summarized from Google’s UA-to-GA4 mapping documentation:

• GA4 uses an event-based data model, not a session-based one. Sessions are derived from session_start events, and pageviews are now page_view events. Both are still tracked, but the ratio is no longer pre-calculated.
• Engagement rate and engagement time give a more honest signal of visit quality. A 4-pages-per-session visitor who stays 8 seconds is less valuable than a 1-pageview visitor who reads for 4 minutes.
• Modern apps and SPAs (single-page applications) inflate or deflate pages per session unpredictably depending on how page changes are tracked. The metric was already unreliable on JavaScript-heavy sites.

You can still see your historical UA pages-per-session in the UA archive (read-only access through July 1, 2024 was the last reprieve), but going forward the metric is dead. Stakeholders asking “what’s our pages per session?” need a translation to the GA4 equivalent or a re-education on which metric actually answers their question.

How to Calculate Pages per Session in GA4 (custom calc: views / sessions)

Although GA4 does not show pages per session directly, both inputs to the formula are available. Views (which counts both page_view events on web and screen_view events on app) is a default GA4 metric. Sessions is also a default. Divide the two and you get a usable equivalent.

The simplest way is in standard reports. Open Reports → Engagement → Pages and screens, click the pencil icon to customize the report, and add both Views and Sessions as columns. The ratio between them is your pages per session for each page. For a portfolio number, repeat for the Reports → Acquisition → Traffic acquisition view to see the ratio per channel.

You can also export to Google Sheets via the GA4 Data API and compute the column there. The required dimensions are typically pagePath or sessionDefaultChannelGroup; the metrics are screenPageViews and sessions. Divide the two columns and you have your equivalent of pages per session, refreshable on demand.

Views per Session: GA4’s Closest Equivalent

GA4’s views per session calculation is the closest equivalent to UA pages per session, but the inputs are different in two ways worth understanding:

1. Views ≠ Pageviews. The GA4 Views metric combines page_view events (web) and screen_view events (mobile app). On a web-only property it is functionally identical to UA pageviews; on a property with both web and app data streams, it is broader.
2. Sessions are counted differently. A UA session ended after 30 minutes of inactivity OR at midnight OR on a campaign source change. A GA4 session ends only after 30 minutes of inactivity (configurable). The midnight rollover and source-change resets are gone, so a single GA4 session can span multiple UA sessions.

Net result: on most sites GA4 views per session runs 5-15% higher than the same site’s UA pages per session for the equivalent time window. Don’t compare the two values in a year-over-year report without footnoting the methodology change.

Pages per Session vs Engagement Rate vs Session Duration (table)

Three metrics that look related but answer different questions:

If your stakeholder asks for pages per session, ask what decision they want to make. Most of the time the underlying question is “are visitors engaging with our content?” — which engagement rate answers more directly. Pages per session only answers “how many clicks deep do they go?” — useful for navigation diagnostics, almost useless as a satisfaction proxy.

What’s a “Good” Pages per Session: Industry Benchmarks

Typical pages per session ranges, based on aggregated GA4 views/session data and historical UA benchmarks reported by Backlinko and other industry sources:

The Backlinko 2023 GA4 benchmark dataset (data drawn from 6 industries) reported a portfolio-wide average of 1.7 views per session across all sites. Use that as a sanity floor — sites running below 1.3 likely have either a navigation problem or are intentionally single-answer destinations. Anything above 4.0 outside ecommerce usually signals a navigation issue, not an engagement win.

How to Improve Pages per Session: Internal Linking, UX, Content

If you’ve decided pages per session is genuinely the metric you want to lift (rather than engagement rate or revenue per session), the highest-leverage moves are:

1. Strong internal linking inside content. Three to seven contextual links per long-form article, anchored to specific terms — like the engaged sessions link in this paragraph. Tail-of-article “related posts” rails work but contextual in-body links convert better.
2. Above-the-fold navigation that matches intent. If a visitor lands on a product page, surface comparable products in the first viewport, not buried in the footer. Surface “see also” callouts at the end of every section break.
3. Clear next-step CTAs on every page. “Read the implementation guide”, “see the comparison”, “view the live demo” — give the visitor a reason to click rather than a request to subscribe.
4. Reduce friction in the second click. Slow-loading internal links, broken links, or interstitial popups all kill the second pageview. Audit second-page LCP the same way you audit landing-page LCP.

Avoid gaming the metric with pagination tricks (splitting one article across 5 pages) or autoplay video that triggers fake page transitions. Both raise pages per session while damaging the underlying experience and the metrics that actually matter — engagement rate, conversion rate, and revenue.

Tracking in GA4 Explorations: Step-by-Step

To build a custom views-per-session report in GA4 Explorations:

1. Open GA4 → Explore → Free Form
2. In the Variables panel, add the Page path and screen class dimension
3. Add the Views metric and the Sessions metric
4. Drop the dimension into the Rows shelf, both metrics into the Values shelf
5. Go to the Tab Settings → Show rows → set to a high number (250+)
6. Export to Google Sheets — Explorations does not natively show calculated metric columns, so the division happens in the spreadsheet
7. In the sheet, add a column =B2/C2 for views/session — that is your pages per session GA4 equivalent

For a recurring view, schedule a Looker Studio report on top of the GA4 connector. Looker Studio supports calculated fields, so you can define views_per_session = views / sessions as a direct column without going through Sheets.

BigQuery Calculation (page_view events / sessions)

If you have the GA4 BigQuery export enabled, the most precise pages-per-session calculation is at the event level. The BigQuery export gives you raw page_view and session_start events with full session attribution.

SELECT
  COUNT(CASE WHEN event_name = 'page_view' THEN 1 END) AS page_views,
  COUNT(DISTINCT CONCAT(user_pseudo_id,
    (SELECT value.int_value
     FROM UNNEST(event_params)
     WHERE key = 'ga_session_id'))) AS sessions,
  COUNT(CASE WHEN event_name = 'page_view' THEN 1 END) /
  COUNT(DISTINCT CONCAT(user_pseudo_id,
    (SELECT value.int_value
     FROM UNNEST(event_params)
     WHERE key = 'ga_session_id'))) AS pages_per_session
FROM `your-project.analytics_NNNNNNNNN.events_*`
WHERE _TABLE_SUFFIX BETWEEN '20260101' AND '20260131'

This SQL gives you the cleanest possible pages per session — counting only true page_view events (not screen views) and using the GA4 session boundary directly. Group by page_location or traffic_source for per-page or per-channel breakouts. For a primer on the export schema, see Google’s BigQuery basic-queries documentation.

When the Metric Misleads (high p/s ≠ engagement)

High pages per session sometimes means the opposite of what stakeholders assume. Three scenarios where the metric is actively misleading:

• Confusing navigation forcing extra clicks. A documentation site that hides the search box, requires three clicks to drill into a topic, or splits short reference articles into 4 pages will show high pages per session and low satisfaction. The visitor is not deeply engaged — they are lost.
• Pagination of single articles. Some publishers split one 2,000-word article across 5 pages with “next page →” buttons to inflate ad impressions. Pages per session looks great. Engagement time per page collapses to 12 seconds, and bounce-back-to-search rates climb.
• SPAs with route changes that fire spurious page_view events. A poorly-implemented React or Vue app might fire a page_view on every router change, including filter clicks and sort actions. Pages per session balloons to 8-15. Real engagement is unchanged. The fix is to gate page_view firing to actual content navigations, not UI state changes.

The honest diagnostic stack: combine pages per session with engagement time per page, exit rate per page, and conversion rate. If pages-per-session is climbing while engagement time per page is falling, the deeper navigation is hurting, not helping. The single number is never enough.

Frequently Asked Questions

Related Terms

• Session — the GA4 session boundary definition
• Pageview — the underlying view event counted in the numerator
• Engagement Rate — a more honest GA4 engagement signal
• Engaged Sessions — absolute count of sessions meeting engagement criteria
• Engagement Time — total foreground time on the site
• Bounce Rate — the GA4 inverse of engagement rate
• Event — the GA4 data model unit (page_view is an event)
• Screen View — the app-side counterpart counted in GA4 Views
• BigQuery — for raw event-level calculation
• Cohort Analysis — paired with pages per session for retention diagnostics
• Conversion Rate — what pages per session is supposed to predict