E.g. text, that is Doughnut Labs’ filled-in answer. Delete it and write your own.
Fill in the core parameter sections first (A through C). They apply to every link your team ships. The optional sections (D and E) only matter if you run paid search or add custom parameters. Section F sets your ID policy and applies to everyone. Section G matters if a conversion is recorded in a CRM rather than only in analytics, which is every sales-led business.
1
Agree on the core values
Work through sections A, B, and C to fix your source, medium, and campaign standards.
2
Add the optional parameters you actually use
Fill in sections D and E only if you run keyword-level paid search or need custom fields.
3
Set your ID policy
Section F decides when a link carries an ID instead of a readable name.
4
Say where the values get stored
Section G, if conversions are recorded in a CRM rather than only in analytics.
5
Publish and enforce
Move the finished standards into a shared builder or template so no one hand-types links.
A. Source standard (utm_source)
List every approved value for utm_source, and the one spelling each must always use. Add a rule for who can add a new source.
Who can add a new source to this list, and how?
E.g. Only the analytics lead. Request in the #marketing-ops channel; the list is updated before the campaign launches, never mid-flight.
Concept review: Source standard
Concept review: Source standard
utm_source records where the click came from: the platform, site, or property that sent the visitor. The value of the field comes almost entirely from everyone spelling each source the same way every time. To an analytics platform, facebook, Facebook, fb, and meta are four different sources, so one campaign can splinter into four rows that no longer add up.A fixed list is what prevents that. Teams differ on how granular the list should be: some fold Facebook and Instagram into one meta source and separate them by campaign or content, others keep them apart at the source level. Both work as long as the choice is written down and applied the same way by everyone. The failure mode is letting people invent new spellings on the fly.B. Medium standard (utm_medium)
List your approved utm_medium values. These are channel types, not platforms. Fix one spelling for each.
Concept review: Medium standard
Concept review: Medium standard
utm_medium records the type of channel, which is a different question from utm_source. Source is the specific platform (meta, google); medium is the category of marketing (paid_social, email). A common mix-up is putting a platform name in the medium field, which collapses the distinction the two fields exist to keep separate.Medium is also the field most analytics platforms use to sort traffic into channel groups. When a medium value does not match the vocabulary the platform expects, that traffic often lands in an “unassigned” or “other” bucket and drops out of your channel reports. That is why medium tends to be the most tightly controlled of the parameters: a small fixed list, matched to how your analytics tool groups channels, does more work here than anywhere else.C. Campaign standard (utm_campaign)
utm_campaign carries the campaign name you built in Campaign naming conventions. You do not invent a separate pattern here; you reuse the one you already defined at the campaign level.
Confirm which value goes in utm_campaign, and show one filled-in example.
When an ID replaces the readable name, see section F.
Channels with no platform campaign
Email and organic social have no ad platform campaign object, so there is no platform name to match.utm_campaign there carries the marketing campaign identifier instead, and that is the one place the rule above bends.
Record what these channels use, so the exception is deliberate rather than assumed:
Concept review: Campaign standard
Concept review: Campaign standard
utm_campaign ties a set of links back to a single promotion, launch, or initiative so you can measure it as one thing across every channel that carried it. Reusing your campaign naming convention here, rather than inventing a second pattern, is what keeps the UTM value and the campaign in your ad platform pointing at the same thing. If the two drift apart, a report built on UTMs no longer lines up with a report built in the ad platform.The campaign name is a real choice with tradeoffs, which is why the naming convention exists as its own document. A self-describing name like Meta-Instagram-Awareness-CBO-TOFU is easy to read in a report, but it also reveals strategy to anyone who inspects the link, and it breaks reporting the moment someone renames the campaign. That tension between readability and both privacy and stability is exactly what section F is for: use the readable name where a name is fine, and switch to an ID where it is not.D. Content and term standard (utm_content, utm_term)
These two parameters carry the names you built in the other two naming-convention documents. utm_content carries the ad set / ad group / variant name; utm_term carries the ad (creative) name. Reuse those names rather than inventing new values here.
Confirm which value goes in each parameter as your default.
Then document what each parameter holds on every platform you run, because the default does not survive contact with paid search.
If you need ad-level Search reporting in analytics, pick one route and record it:
Concept review: Content and term standard
Concept review: Content and term standard
utm_content and utm_term add detail below the campaign level, and the cleanest way to fill them is to reuse the names you already built one level down. utm_content takes the ad set / ad group / variant name, so the customer profile layer of the click is captured; utm_term takes the ad name, so the exact creative is captured. Reusing those names keeps your UTM reports lined up with the structure inside the ad platform instead of describing it a second, slightly different way.utm_term is worth documenting per platform, because the field does not mean the same thing everywhere. Its original use was the paid search keyword, and on Google Search that is still the natural fit. On Meta there is no keyword, so many teams repurpose utm_term for the ad name instead. Both are valid; what causes trouble is using it for the ad name on one platform and the keyword on another without writing that down, so a mixed report becomes impossible to read.On Google Search the two uses collide, and there is no arrangement that gets both. Teams tend to discover this months in, when someone tries to compare two responsive search ads in a dashboard and finds every row grouped by keyword instead. The choice itself is unremarkable; the cost is entirely in making it by accident. Recording which value the field carries, and what that leaves unavailable, is what turns it back into a decision someone can revisit.E. Custom parameters
List each custom parameter you use, what it carries, and where its value also lives so you are protected if it gets stripped.
Write your team’s rule for adding a custom parameter:
E.g. A custom parameter is added only when no standard field fits, and only if the same value is captured a second way. No critical value lives in a custom parameter alone.
Concept review: Custom parameters
Concept review: Custom parameters
Custom parameters carry information the five standard fields were never meant to hold, like an internal lead code or a referral partner ID. They are useful precisely because they are yours to define.They also carry a risk the standard fields mostly avoid. Some browsers and privacy tools strip query parameters they do not recognize, and they will often keep the
utm_ parameters while dropping your custom ones. When that happens the value disappears before your site ever sees it, with no error and no warning. This is why the backup-location column matters: a custom parameter is a fine place to pass a value, but a risky place to store the only copy of one. Teams that rely on custom parameters tend to pair each with a second capture method so a stripped parameter costs them nothing.F. ID versus name policy
Decide, per parameter, whether the link carries a readable name or a platform ID. Note the dynamic field you use to insert each ID.
Write the rule that tells someone which to reach for:
E.g. Use an ID wherever the readable name would leak strategy or could be renamed later. Source and medium stay as names because they are fixed, public categories. Campaign and ad set use IDs, mapped back to friendly names in the reporting tool.
Concept review: ID versus name policy
Concept review: ID versus name policy
Some ad platforms let you drop a dynamic field into a link, such as
{{campaign.id}}, and the platform fills in the real ID when the ad serves. The link then carries the ID instead of a name you typed. Choosing between a name and an ID comes down to two things: what the value reveals, and whether it can change.Readable names reveal strategy. A campaign named us_doughnutpro_launch_2026 tells anyone who inspects the link the region, product, promotion, and timing, and a name like purchasedlist_enterprise would tell them how the customer profile was sourced. Anyone who inspects the link, including the visitor and any competitor, sees it. An ID reveals none of it. Readable names also change: a person can rename a campaign or ad set at any time, sometimes by accident, and the moment a name changes, historical reports keyed on it split in two. A platform ID stays fixed for the life of the campaign, so the data stitches together even when someone edits a label.The cost of IDs is readability, since a raw ID means nothing to a human reading a report. That is why teams that tag with IDs usually map them back to friendly names inside the reporting tool, keeping stable values in the link and readable labels on the dashboard. Where a value is already a fixed, public category, like source and medium, a name carries no strategy and cannot drift, so there is often little to gain from an ID. Where you land on each parameter is yours to set here.G. Where the values get stored
A tagged link only pays off if the values survive the visit. On a same-session purchase, analytics holds them and nothing more is needed. On a deal that closes four months later, the link between the click and the deal exists only if the values were written onto the record at the moment of conversion, and are still there when the deal closes. Name the field each parameter lands in, and whether it holds the first or last touch.
Fields that travel from lead to deal: E.g. All source fields copy from the lead to the opportunity on conversion, so a closed deal still carries where it came from.
Who owns these fields: E.g. RevOps. Changes go through them, because a renamed field breaks the import silently.
How the values come back into the flat file:
Concept review: Where the values get stored
Concept review: Where the values get stored
This section exists because the UTM system has an endpoint that the parameters themselves cannot reach. A tag survives as long as the session does. A B2B deal outlives the session by months, and everything the tag knew is gone unless something wrote it down.Which is why the field names matter as much as the parameter names one level up. A source value written to a field nobody agreed on, or overwritten on the next visit, produces a CRM full of data that cannot be joined to anything. The failure is quiet: reports still run, they just credit the wrong channels, and the pattern they produce is consistent enough to look real.First versus last touch is the choice with the most consequence, and both are defensible. First touch answers “what brought them in,” which is what a prospecting budget is buying. Last touch answers “what closed them,” which is what a retargeting budget is buying. What does not work is one field holding whichever fired most recently, because the answer it gives then depends on how long the sales cycle was rather than on anything about the channels.
Build order recap
1
Fix source and medium as short, fixed lists
These control how your analytics tool groups channels, so they are the tightest.
2
Set the campaign pattern, then the ID policy
Decide the readable pattern first, then decide in section F where an ID replaces it.
3
Add content, term, and custom fields only where you use them
Blank is a valid answer. Format them now so they stay consistent later.
4
Move the finished standards into one builder
A shared builder or template applies every rule above automatically and stops hand-typed drift.
This workbook is built from the UTM parameters concept document. Keep the two in sync: the concept document explains how UTM parameters work, and this workbook records the specific standards your team has chosen.