UTM parameters

The five parameters

• utm_source — where the traffic came from: newsletter, github, google.
• utm_medium — the kind of channel: email, cpc, social, referral.
• utm_campaign — which campaign: spring-launch, q3-webinar.
• utm_term — the paid keyword, for search ads.
• utm_content — which creative or link variant, for A/B testing two links to the same place.

https://example.com/pricing?utm_source=newsletter&utm_medium=email&utm_campaign=spring-launch

Source, medium and campaign carry almost all the reporting value. Term and content are detail you add when you have a specific question about keywords or creative.

Why they exist

A browser tells you the referrer — the page a visitor came from — and that is genuinely useful, but it stops short in three places. Email clients and native apps often send no referrer at all. Every link from one platform arrives as the same domain regardless of which post or ad produced it. And a QR code or an offline campaign has no referring page in the first place.

UTM parameters fill those gaps because you write them. They are the only part of your traffic data that describes your own intent rather than the browser’s observation — which is also why they are only as good as your discipline about them.

The rules that keep the data usable

• Lowercase everything. The values are case sensitive, so Facebook and facebook are two rows in every report, forever.
• Fix a vocabulary and write it down. Decide once whether paid search is cpc or paid, whether the source is google or google-ads. A shared list beats a convention nobody recorded.
• Never tag internal links. A UTM on a link between your own pages typically starts a new session and overwrites the campaign the visitor actually arrived on. Use an event property for internal promotions.
• Do not put anything private in them. UTMs are visible in the URL bar, copied into shared links, and logged everywhere. No emails, no user ids, no tokens.
• Use a builder. Hand-typed tags are where the inconsistencies come from — our UTM builder is free and requires no signup.

How they reach your reports

When a visitor lands on a tagged URL, the analytics SDK reads the query string and attaches the values to the events from that visit. From there they are ordinary properties: filter by them, break down by them, or feed them into channel classification, which combines UTM values with the referring domain to decide whether a visit was Paid Search, Organic Social, Email and so on.

In Pug, all five UTM values are read from the landing URL when the visit arrives and kept as their own fields on the event, so you can filter and break down by each of them separately rather than having them folded into a single “source” string. The marketing channel that sits alongside them is worked out on the server from the UTM values and the referring site together, so it cannot be set from the page itself.