URL Parameters Explained: Query Strings, UTM Tags, and GA4
Published:
Last Updated:
Category: Web Analytics
Authors: Shusaku Yosa
URL query parameters carry named values, such as a search filter or campaign identifier. Some affect how a page works; others, including UTM tags, help distinguish traffic. Understanding the structure prevents broken destinations and misleading measurement. This guide uses official references checked on October 11, 2026.
Read a URL: query parameters versus a fragment
In https://example.com/guides?category=analytics&utm_source=newsletter#checklist, /guides is the path, the query begins with ?, and #checklist is a fragment. Each query pair connects a name and value with =; an ampersand separates pairs.
Part | Example | Purpose |
|---|---|---|
Path | /guides | Identifies the page or resource |
Query start | ? | Begins the query |
Name and value | category=analytics | Assigns a value to category |
Another pair | &utm_source=newsletter | Adds a parameter to an existing query |
Fragment | #checklist | Identifies a location or other fragment behavior |
Adding a second ? can produce a different value structure from the one intended. Placing UTM text after # does not make it a normal query parameter. URL syntax and the names accepted by a particular website are separate considerations.
Separate functional parameters from campaign tags
Search terms, categories, sorting, and page numbers may be required by the destination. UTM parameters identify campaigns. Do not remove an unfamiliar parameter simply because it looks like tracking; checkout and authentication links can depend on their existing values.
Conversely, a parameter does not necessarily change page content. Different UTM links can lead to the same article. Establish who owns functional parameters and who maintains campaign naming before changing a destination.
Choose UTM fields and a naming convention
Use Google’s campaign URL guidance to define a consistent sender, method, and campaign. UTM conventions do not mean that source and medium are required for every kind of URL parameter.
Field | Illustrative value | Use |
|---|---|---|
utm_source | newsletter | Identify the sender or traffic source |
utm_medium | Identify the distribution method | |
utm_campaign | october_guide | Name the campaign |
utm_id / utm_source_platform | guide_2026_10 / platform name | Record an ID or platform when needed for the reporting workflow |
utm_content / utm_term | header_link / managed keyword | Distinguish creative, placement, or relevant keyword information |
Prevent variants such as newsletter and Newsletter with a maintained naming dictionary. Check how manual tags interact with the platform’s existing or automatic tagging. Choose names according to the comparisons you need, rather than filling every optional field.
Build links with existing queries and encoded characters
An illustrative destination is https://example.com/guides?category=analytics#checklist. A tagged version is https://example.com/guides?category=analytics&utm_source=newsletter&utm_medium=email&utm_campaign=october_guide#checklist. It preserves the functional category and keeps the fragment after the query. Replace this fictional host with your approved destination and test it.
Spaces, Unicode text, and reserved characters need correct encoding; Unicode values are not inherently invalid. A structured facility such as URLSearchParams can serialize names and values. Watch for double encoding and repeated parameter names.
- Confirm the original page and its functions work.
- Separate the existing query and fragment, preserving necessary values.
- Add approved campaign values with a structured builder.
- Open the result through the actual distribution journey.
Test redirects and check the resulting GA4 data
A generated URL is not proof of correct measurement. Compare the distributed URL with its final destination after shortening, email processing, redirects, or authentication. Test page behavior, tag delivery, and receipt by the intended property separately.
- Look for removed or rewritten parameters at the final landing page.
- Confirm the intended property and production hostname.
- Inspect received events through DebugView where available, recording consent-related visibility limits.
- Review processed reports using the appropriate session or event scope.
Under GA4 campaign processing, new campaign information during an existing session does not itself start another session. Do not apply the old UA behavior or equate tagged clicks, sessions, and users.
Avoid internal UTMs and personal data in tracking URLs
UTMs on internal article links or buttons can distort interpretation of campaign-related event attribution. Explaining this as “every internal UTM starts a new session” would be inaccurate for GA4. Use an appropriate internal-click event design and verify onward success separately.
Follow Google’s PII-prevention guidance: keep names, email addresses, and other prohibited identifying information out of URLs, page titles, and collected parameters. Data redaction is a supplementary control, not a guarantee that all collection routes are free of personal information. Review collection at its origin, including non-web-tag routes.
Maintain a log of destination, sender, date, campaign values, owner, and verification result without embedding personal identifiers. Before reporting registrations, check successful completion, duplicates, consent, production hosts, and authentication or app handoffs. Tagged visits and event totals are not registration headcounts.
Continue with the relevant guide
