UTM tracking in RudderStack
RudderStack is an open-source, warehouse-first customer data platform. Its JavaScript SDK automatically parses UTM parameters from the page URL and populates the context.campaign object (source, medium, name, term, content) on events, so campaign attribution flows to every downstream destination and your warehouse.
The context.campaign object
RudderStack's JS SDK reads UTM parameters from the URL and maps them into context.campaign: utm_source to source, utm_medium to medium, utm_campaign to name, utm_term to term, and utm_content to content. This object travels with page and track events.
Because the mapping is built in, you do not write per-destination logic — every connected tool and the warehouse receive the same normalized campaign fields.
- utm_source -> context.campaign.source
- utm_medium -> context.campaign.medium
- utm_campaign -> context.campaign.name
- utm_term -> term, utm_content -> content
Fan-out and consistency
Because the campaign object is standardized at collection, downstream destinations and warehouse tables all see the same source/medium/name values. That makes consistent, lowercase tagging upstream essential — any inconsistency multiplies across destinations.
Validate UTM tags before launch so the context.campaign object stays clean wherever RudderStack routes it.
How it appears in analytics and logs
A populated context.campaign object on RudderStack events confirms UTM parameters were present on the page URL when the SDK fired — the SDK derives campaign fields from the URL, not from a stored profile.
Diagnostic use case
Capture campaign context once in RudderStack and fan it out to analytics and warehouse destinations via the standardized context.campaign object derived from UTM parameters.
What WebmasterID can help detect
WebmasterID pairs with a RudderStack pipeline by independently recording the UTM-tagged landing hit as a campaign touch, giving a server-side source signal alongside the CDP event stream.
Common mistakes
- Assuming RudderStack invents campaign data when no UTM is on the URL.
- Letting inconsistent casing propagate to every connected destination.
- Stripping UTM before the SDK loads, leaving context.campaign empty.
Privacy and accuracy notes
RudderStack is self-hostable and first-party; the campaign object describes the marketing touch, not the visitor. You govern PII and retention, and WebmasterID records the touch without exact location or a shared identity.
Related pages
- UTM tracking in Segment
Segment's analytics.js library automatically parses UTM parameters from the page URL into the standardised context.campaign object on every event, and forwards that context to connected destinations. Understanding this mapping lets you tag links once and have campaign data flow consistently into every tool wired to Segment.
- UTM tracking in Snowplow
Snowplow is an open-source behavioral data platform that collects rich, first-party event data into a warehouse. Its tracker and enrichment process map standard UTM parameters into dedicated campaign fields (mkt_source, mkt_medium, mkt_campaign, mkt_term, mkt_content) on the atomic event, giving you warehouse-native campaign attribution.
- UTM and server-side tracking
Server-side tracking reads the UTM parameters from the incoming HTTP request on your server, rather than relying on a browser tag to capture them. This makes campaign attribution resilient to ad blockers, script failures, and consent-gated client tags. The trade-off is that the server sees the landing request but must be designed to persist the campaign context across the visit. This page covers the mechanics and limits.
- Event explorer
See campaign context carried on first-party events.
Sources and verification notes
- RudderStack Docs — JavaScript SDK / context fieldsDocuments automatic UTM capture into the context.campaign object.
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.