Page location (full URL) dimension
Page location is the complete URL of a page — scheme, host, path, and query string — captured by GA4 as page_location. It is more granular than page path and is the raw input from which path, hostname, and query dimensions are derived. This page explains its composition and why high cardinality demands normalization.
What this means
In GA4 the page_location parameter holds the full URL of the page when an event fired — for example https://example.com/blog/post?utm_source=x. From it GA4 derives the page path (the path portion), the hostname, and query-based dimensions.
Because it includes the query string, page_location is the highest-cardinality page dimension: every distinct parameter combination produces a distinct value, even when they all point to the same underlying page.
- page_location = scheme + host + path + query
- Source of derived path, hostname, and query dimensions
- Highest cardinality of the page dimensions
Why normalization matters
Tracking parameters (utm_*, gclid, fbclid, session tokens) make one page appear as dozens of URLs. Left unmanaged, page_location reports scatter a single article's traffic across many rows and inflate cardinality limits, which can push values into '(other)'.
The fix is normalization: strip or allowlist query parameters before storage, or analyse on page path instead when the query is irrelevant. Keep the full location only where the query genuinely changes the content, such as filtered search results.
- Tracking params fragment a page into many URLs
- High cardinality can spill values into '(other)'
- Normalize or analyse on page path where query is noise
How it appears in analytics and logs
A page location value is the whole URL as recorded. A flood of near-duplicate URLs that differ only by tracking parameters signals you need to strip or normalize query strings.
Diagnostic use case
Inspect the exact URL visitors landed on, including query parameters, when path-level reporting hides differences you care about.
What WebmasterID can help detect
WebmasterID captures the full request URL first-party and can normalize tracking parameters out, so reporting groups real pages instead of fragmenting on query noise.
Common mistakes
- Reporting on raw page_location without stripping tracking params.
- Letting query noise push values into the '(other)' bucket.
- Storing full URLs that embed personal data in the query.
Privacy and accuracy notes
Full URLs can carry sensitive query parameters (search terms, IDs). Strip personal data from page_location before it is stored. This is educational, not legal advice.
Related pages
- Page path dimension
The page path dimension is the path portion of a viewed URL — /blog/post — excluding the hostname and, by configuration, the query string. GA4 derives it from the page_location of each page_view. It is hit-scoped, so it counts every view of a page, and the most common pitfall is query strings (utm_*, session IDs) fragmenting one logical page into many distinct paths.
- Query string dimension
The query string is the part of a URL after the '?': key-value parameters such as ?q=shoes&page=2. Analytics tools can surface it as a dimension, but it is double-edged — useful for understanding filters and search, dangerous for cardinality and privacy. This page explains how it is derived and how to handle it safely.
- Hostname dimension
The hostname dimension records the domain that served each page_view — example.com, staging.example.com, or a domain you do not own. It comes from the host portion of the page_location URL. It is one of the most useful data-quality filters: unexpected hostnames reveal staging traffic, mis-deployed tags, or hits faked by referrer/measurement spam against your property.
- Web analytics
Normalize URLs so pages group cleanly.
Sources and verification notes
- Google Analytics Help — [GA4] Automatically collected events (page_location)Documents page_location as the full URL on page_view.
- MDN — URL: properties (href, pathname, search)Defines URL components used to derive path and query.
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.