UTM Parameters: The Complete Guide for Marketers (2026)

UTM parameters are the five short tags you add to a URL — utm_source, utm_medium, utm_campaign, utm_content, utm_term — that tell your analytics tool where a visitor came from. They are simple to add, free to use, and quietly the difference between a marketing report you can act on and one that credits everything to "Direct" or "Unknown."

Across TrackRev workspaces, teams that ship clean UTM-tagged links recover attribution on 30–40% of revenue that untagged setups silently misclassify — a finding broadly consistent with HubSpot's State of Marketing report, which finds attribution is one of the top measurement challenges for marketing teams. The catch is that UTMs only pay off if they're spelled the same way every time and captured before the browser strips them. This guide covers what each parameter does, how to build links that survive real-world conditions (Safari ITP, iOS 17 link tracking protection, email confirmation hops), and the naming rules that keep your reports comparable across quarters.

What UTM parameters are

UTM parameters are five standard querystring tags appended to a URL that identify the source, medium, campaign, content, and search term that drove a click.

The format hasn't changed since Google added it to Urchin in 2005 — which is why every analytics tool on earth, from GA4 to Mixpanel to HubSpot to TrackRev, reads them by default. The whole stack agreed on the names so marketers wouldn't have to.

All five parameters are optional. A link with just utm_source still gets attributed; a link with all five gives you the precision to compare two banners inside the same campaign. The tradeoff isn't "more parameters = better" — it's "only as many as you'll actually use in reports." Adding utm_term to organic links you'll never filter by is noise.

Anatomy of a UTM-tagged URL

Everything after the ? is the querystring. Each utm_* parameter is a key/value pair separated by =, and multiple parameters are joined with &. A full example:

1https://example.com/pricing2  ?utm_source=newsletter3  &utm_medium=owned-email4  &utm_campaign=product-launch-jun265  &utm_content=header-cta6  &utm_term=

The destination page (/pricing) is what the visitor sees. The querystring is read by your analytics on landing, then can be stripped from the URL bar for a cleaner UX without losing the data — most tools snapshot the values into a session or cookie before the URL ever changes.

The five UTM parameters explained

Each parameter answers a different question. Confusing them is the most common cause of unreadable reports — and it happens silently, because every tool will accept whatever you put in any field. The discipline is on you.

utm_source: the specific platform

utm_source names the exact origin of the click — not the channel category. newsletter, youtube, partner-acme, twitter, google. Be precise. email is wrong here because two months from now you won't remember if it was the onboarding sequence, the weekly newsletter, or a one-off broadcast — and the report can't tell you either.

If you sponsor two podcasts, give each one its own source: podcast-acme, podcast-beta. Aggregation across them is what utm_medium is for.

utm_medium: the channel type

utm_medium groups sources into channel categories so you can ask "how is paid social doing?" without summing twelve different utm_source rows by hand. Use a fixed, internal vocabulary: cpc, owned-email, affiliate, organic-social, paid-social, sponsorship, referral.

The single biggest mistake is letting utm_medium drift into duplicating utm_source. utm_source=newsletter&utm_medium=email is fine. utm_source=email&utm_medium=email is a destroyed report — you've answered the same question twice and lost the ability to group.

utm_campaign: the initiative

utm_campaign names the push — the launch, the sale, the seasonal push, the webinar series. The trick is versioning. summer-sale looks fine the first time you run it, then collides with itself a year later and you can't compare 2026 to 2025 without a spreadsheet hack. Bake the month-year (or quarter) into the name from day one: summer-sale-jun26, product-launch-jun26, q3-webinar-series. Future-you will thank present-you.

utm_content: the variant

utm_content distinguishes link placements or creative variants within the same campaign — the header CTA versus the footer link, banner A versus banner B, the in-line link versus the button. This is what makes A/B-style decisions possible: same campaign, different content values, compare the conversion rates.

Common patterns: header-cta, footer-link, inline-text-1, banner-blue, banner-orange. Keep the values short and self-describing — they show up in dashboards, and "banner-blue" reads at a glance where "v3_b_blue_2026Q2" doesn't.

utm_term: paid-search keywords only

utm_term was built for one job: capturing the keyword that triggered a paid-search ad. Google Ads can auto-populate it via {keyword}, as documented in Google's URL parameters reference; most other channels don't need it. Leave it blank everywhere except paid search and stop debating what to put in it — there's no scenario where utm_term=newsletter-link earns its keep in a report.

How to build UTM-tagged links

There are three honest options: build them by hand, use a builder, or have your link-tracking tool generate them. All three produce the same URL — the choice is purely about how much discipline you trust your team to hold.

By hand

For a single one-off link, hand-typing is fine. Append ? to the destination, then the parameters joined by &. Lowercase, hyphens for spaces, double-check every separator.

https://example.com/pricing?utm_source=newsletter&utm_medium=owned-email&utm_campaign=product-launch-jun26&utm_content=header-cta

With a UTM builder

Google's Campaign URL Builder fills in the parameters via a form and outputs the URL. Useful for occasional tagging; not enforceable. Any team member can ignore the builder, type a link from memory, and re-introduce inconsistency. The reports won't tell you who broke them — they'll just stop aggregating cleanly.

For most marketing teams, the bottleneck isn't typing UTMs; it's making sure everyone uses the same spelling. A builder helps the user who opens it. It does nothing for the user who doesn't.

With a link-tracking tool

Tools like TrackRev bake the UTMs into every branded short link at creation time. The creator picks the source/medium/campaign from dropdowns populated by your internal vocabulary, the short link is generated, and the long URL with the correct UTMs is what visitors land on. Misspellings become impossible because the values come from a list, not a textbox.

This is also the point at which UTM data starts feeding revenue attribution rather than just click counts — see UTM parameters and Stripe for the technical hand-off from click to charge.

UTM naming conventions that survive reality

The whole point of UTMs is aggregation: "how much revenue did the newsletter drive this quarter?" The aggregation only works if every link wrote utm_source=newsletter the same way. The four rules below come from watching reports collapse under inconsistency.

• Lowercase only. Facebook, facebook, and FaceBook are three different sources in most tools — and your dashboards will silently split them into three rows.
• Hyphens, never spaces. A space becomes %20 on the URL and shows up as summer%20sale in reports. Pick one separator (hyphens are friendlier to read than underscores) and never deviate.
• Version your campaigns by date. product-launch-jun26, not launch. Six months from now you will have a second launch and zero way to compare.
• Keep a shared list of allowed values. A single source of truth — a spreadsheet, a Notion page, or a tool's dropdown — so the canonical spelling isn't decided by whoever needs a link first.

A naming template you can copy

Lock in a template once and the team stops debating it. A pattern that holds up across SaaS, e-commerce, and creator businesses:

Common UTM mistakes — and how to fix them

Four mistakes cause the majority of broken UTM data. The first two are formatting; the second two are architectural and quietly cost you the most.

Mixed case and encoded spaces

Most analytics tools treat parameter values as case-sensitive: utm_source=Newsletter and utm_source=newsletter are two separate buckets. A single inconsistent link can split a year of newsletter clicks into two rows that nobody re-merges. Same for spaces — they get URL-encoded to %20 and read as garbage. Lowercase everywhere, hyphens for spaces, no exceptions.

UTM overwrite on second visit

If a visitor arrives via the newsletter, leaves, and comes back via a paid ad — and your pixel writes UTMs into the same cookie on both visits — the second click silently overwrites the first. Last-touch dashboards now credit the ad; first-touch dashboards lose the newsletter entirely. Fix: implement "first-touch wins" (only write if the cookie is empty), or capture both touches as separate events and let your attribution model apportion credit at reporting time.

Email confirmation strips the chain

Classic failure mode: visitor clicks a UTM-tagged link, signs up, and is sent an email confirmation. The confirmation link lands on your site without UTMs and overwrites whatever cookie value you had. Result: a buyer who was clearly newsletter-driven gets attributed to "direct." Fix: write the UTM values onto the user record at signup itself, before the confirmation round-trip ever happens. The durable identity is in the database; the cookie is just a relay.

Safari ITP and iOS 17 link tracking protection

iOS 17's link tracking protection strips known tracking parameters from URLs in Safari, Messages, and Mail. UTM parameters are explicitly on that list when the link is shared through those surfaces. The mitigation is server-side capture: when your tracking domain receives the request, read the UTMs off the URL before the browser ever does, store them on the server, and redirect to a clean URL. TrackRev's tracking domains do this by default; raw client-side pixels do not.

How to read UTM data in your reports

Once UTMs are flowing in, the natural next question is where you actually look at them. There are three common surfaces, each with a different trade-off.

GA4: clicks and goals, no revenue by default

GA4 reads UTM parameters automatically and surfaces them under Acquisition → Traffic Acquisition, broken down by session_source, session_medium, and session_campaign. You'll see sessions, engagement rate, and event counts (including conversions, if you've configured them). What you won't see — without custom webhook plumbing — is Stripe revenue. GA4 doesn't talk to Stripe; closing that loop takes either a homegrown bridge or a tool that does it for you.

Stripe metadata: revenue, but only if you wire it

Per Stripe's metadata documentation, you can attach up to 50 key/value pairs as metadata on every Checkout Session, PaymentIntent, and Customer (keys up to 40 characters, values up to 500). If you write utm_source, utm_medium, and utm_campaign into the metadata at checkout time, every payment becomes attributable. The full hand-off is in UTM parameters and Stripe; the broader revenue picture is in how to attribute Stripe revenue to marketing channels.

A unified attribution tool

The third option is a tool that captures UTMs at the click, persists them to the user, hands them to Stripe, and shows revenue-by-UTM in one report — without the team writing webhook handlers. TrackRev does this end-to-end; the click-side capture is server-side (immune to iOS 17 stripping) and the revenue side reads directly from Stripe. The point isn't that you can't build it yourself — it's whether "another two days of webhook plumbing" is the best use of your engineering time.

What the data looks like once it's clean

Across TrackRev workspaces, the ordering by click volume is rarely the ordering by revenue. The shape below is typical for SaaS:

Two patterns repeat: owned channels (newsletter, affiliate partners) over-index on per-visit revenue, and paid social over-indexes on click volume but under-indexes on LTV. The decision "keep funding what looks busy" inverts once you can read revenue by UTM. For the rationale on which model to apply to that data, see attribution models for SaaS; for the benchmark numbers, marketing attribution benchmarks 2026.

When you don't need UTMs

UTMs are the right tool when you have multiple sources sharing a destination and need to tell them apart. They're overkill — and add visual noise to your URLs — when:

• The destination is only reachable via one channel (e.g. an in-app deep link). The source is implied.
• You're tracking on-site clicks between pages of your own site. Use page-path analytics, not UTMs.
• The link is a permanent navigation link in your header or footer. Tagging it pollutes "direct" traffic with a single repeated source.

If in doubt, ask: "would I ever want to filter a report by this source?" If the answer is no, you don't need the UTM.

TrackRev and UTM tracking

TrackRev makes the UTM discipline structural rather than aspirational. The link tracker bakes the parameters into every short link from a vocabulary you control — no more Newsletter vs newsletter splits. The first-party pixel captures the values server-side, immune to iOS 17 link tracking protection. The Stripe sync pushes them into metadata and reads them back on the webhook, so revenue lands attributed without a separate engineering project.

Related reading: UTM parameters and Stripe covers the click-to-charge hand-off in detail; how to attribute Stripe revenue to marketing channels covers the broader setup; channel LTV is the metric you should be ranking your UTM sources by once revenue is wired in. TrackRev's free tier covers 1,000 events; the paid tier removes the cap. For tool comparisons, see Bitly's revenue tracking gap.

External references: Google's official UTM parameter guide on the Analytics Help Center; Stripe metadata documentation; Apple's developer note on iOS 17 link tracking protection.