UTM Naming Conventions: Build Campaign Labels Your Team Can Maintain

A workable UTM naming convention gives every campaign link a small, predictable set of labels. The team agrees what each field means, chooses values from a controlled dictionary, and records exceptions before links go live. The aim is to make a link understandable to someone who did not create it.

That sounds straightforward until three people launch the same offer. One writes LinkedIn, another writes linkedin, and a third writes li. The campaign appears under several labels. A fourth person copies an old link and adds another campaign parameter. Now the team has a naming problem and a URL problem.

This guide develops a practical standard for a Canadian marketing team: field definitions, a naming dictionary, an exception register, a local builder, and a repeatable review process. All businesses, campaigns, dates, identifiers and link examples used in the worked scenarios are fictional. They demonstrate decisions and checks, not client results or expected performance.

What a UTM naming convention should accomplish

A UTM is a campaign parameter attached to a destination URL. Google documents source, medium and campaign as core labels; content distinguishes creative or link variations, term identifies a paid keyword, and campaign ID provides an identifier. Google recommends consistent values and explains that different capitalization produces different parameter values. See Google’s campaign URL documentation.

The useful business question is more specific than “Can we track this?” Ask: “Can we distinguish this newsletter placement from the partner placement without rebuilding the report each month?” A good standard helps answer that question with labels the team can recognize and maintain.

Do not ask a URL to carry the entire marketing plan. Budgets, approval history, creative briefs, audience definitions, publishing schedules and customer records belong in their appropriate systems. The URL needs enough information to identify the distribution context. A campaign register can connect that context to the fuller plan.

Start with three practical tests. Can a new colleague choose an approved source without guessing? Can the reporting owner explain what changed when a label changes? Can the website owner reproduce the destination from the recorded link? If the answers depend on one person’s memory, the convention needs more structure.

A naming standard also has limits. A label states how a link was prepared. It does not prove who clicked, why they acted, whether they saw another campaign, or which interaction caused a purchase. Keep those questions separate from the task of making consistent labels.

Give each field one job

Write a short definition beside every field in the dictionary. Definitions should help someone make a choice under deadline pressure. Avoid definitions such as “the campaign source” that simply repeat the field name.

This field contract is a recommended operating convention, not a universal Google requirement. The companion builder implements the first five fields. It derives the campaign ID from the register and deliberately does not generate term or source-platform values. Google recommends setting every relevant UTM field, including source platform when applicable. A missing relevant field can appear as (not set); this starter is not a complete template for every integration. Extend it only after defining those fields and their tests.

Keep source and medium separate. A source answers where the distribution originates; a medium groups the type of distribution. The same platform can carry both paid and organic placements. A source of linkedin can therefore pair with paid_social or social in this example standard.

Do not create a different medium for every team or offer. Labels such as sales_team, fall_discount and brand_awareness describe other things. Putting them in medium makes comparisons harder because the field stops representing a consistent category.

Google’s default channel groups apply rules to traffic-source information; they are not simply a display of your preferred medium names. For example, manual Paid Social classification considers both a recognized social source and a paid medium pattern. A custom label may need a custom reporting rule. Check the current default channel definitions before assuming where a new combination will appear.

Build a controlled dictionary people can actually use

The dictionary is a list of approved values with meanings, ownership and lifecycle status. It should be small enough to scan. A dropdown with hundreds of unexplained entries is still a guessing exercise.

For each source, record the exact spelling, plain-language meaning, permitted mediums and whether the source is active. Keep aliases separately. If li historically meant LinkedIn, the alias record can explain it without letting new links use both spellings.

The offline medium is a deliberate custom category. It does not promise a corresponding default channel in Analytics. The team must decide how that category is reported. Likewise, the google / organic combination needs its campaign and content labels to distinguish a Business Profile link from other Google traffic.

For this standard, use lowercase ASCII letters, digits and underscores for UTM values. Use one underscore between words, with no leading or trailing underscore. Keep a short, documented limit for each field; the example implementation allows up to 80 characters. That limit is a team readability rule, not a claim about Google’s maximum.

Do not silently remove accents or translate names during link creation. A bilingual team can agree on stable machine labels and maintain French and English descriptions beside them. For example, a workshop’s public French title may change while its registered campaign key remains the same. The key identifies the initiative; it does not replace public-facing copy.

Choose readable words over clever abbreviations. operations_workshop is easier to interpret than an acronym only the campaign manager remembers. If an abbreviation is already established, define it once and reuse it consistently.

Give dictionary changes a simple path. The requester explains the missing value, the reporting owner checks whether an existing value fits, and the dictionary owner records the decision. A backup owner should be able to complete the same task when the primary owner is away.

Keep campaign identity stable across channels

Use the campaign name to connect placements that serve the same planned initiative. Do not add the channel name to the campaign merely because the link will appear in an email. Source and medium already describe that distinction.

A fictional company, Northline Workshop Co., plans an operations workshop for the fourth quarter of 2026. Its campaign key is 2026q4_operations_workshop and its register ID is demo_c045_001. The newsletter, LinkedIn placements and association website link share those identifiers. Each placement gets its own source, medium and content.

A separate November field guide has the campaign key 2026m11_field_guide and ID demo_c045_002. It is a separate initiative because the team has defined a separate offer, landing page and reporting question. The date pattern describes the planned initiative, not the date of every click.

Evergreen activity needs a different rule. A permanent Business Profile website link can use evergreen_location_information with its own stable ID. Renaming it every month would create needless reporting divisions. Record the launch date in the register instead.

Allocate IDs centrally and never recycle them for unrelated initiatives. A campaign title can be understandable without being unique across all time; the ID provides a second anchor. Keep the name-to-ID relationship in one place so that copying a spreadsheet row cannot accidentally assign the wrong ID.

For a renamed initiative, distinguish a cosmetic title change from a new reporting identity. If the offer and scope are unchanged, retain the machine key and update the display title. If the business question has materially changed, create a new record and document the relationship. Do not quietly repurpose an old key.

Work through a placement plan before building links

The following plan is fictional. It contains no performance figures and makes no prediction about registrations. Its purpose is to show how one campaign can support several distribution contexts without inventing a new naming system for each.

The newsletter uses two content labels because the team wants to distinguish link positions. That distinction does not create a controlled experiment by itself. People may encounter both positions, and the placement audiences are not necessarily comparable. The labels identify the links; the research design determines what conclusions a comparison can support.

The team chooses a content pattern of format, placement or message, language, and version. It documents that pattern rather than allowing each person to reverse the order. A version changes when the creative or link placement changes in a way the team intends to distinguish. Correcting an unrelated typo in the campaign register does not automatically require a new content version.

The French placement uses the same campaign identity because it belongs to the same initiative. Its language is visible in the content label and its destination can include an approved language query. If the organization instead needs separate commercial programmes by language, it can define separate campaigns. Make that decision from the reporting question, not from an assumption that every translation is a new campaign.

Before generating anything, the reviewer checks the intended destination, source-medium pair, campaign ID and content label together. Individually valid labels can still form a misleading combination. For example, listing_event_en_v1 should not be assigned to the newsletter simply because it appears in the same campaign’s content list.

The companion register therefore specifies which source-medium pair each content label belongs to. The builder checks that relationship. This is useful when different teams share a campaign: the tool does not treat every approved word as interchangeable.

Build the URL without damaging its existing parts

A destination has separate components: scheme and host, path, optional query, and optional fragment. In a conventional campaign URL, UTMs belong in the query before the fragment. If a query already exists, additional parameters follow an ampersand rather than a second question mark. Google’s final URL guidance illustrates both existing parameters and fragments.

Consider the fictional destination https://example.com/workshop/?lang=fr#agenda. The lang=fr query chooses the French version, and #agenda identifies a section. The builder needs to retain both while adding the registered campaign labels.

The resulting shape is:

https://example.com/workshop/?lang=fr&utm_source=newsletter&utm_medium=email&utm_campaign=2026q4_operations_workshop&utm_id=demo_c045_001&utm_content=text_intro_fr_v1#agenda

This is an illustrative URL on a reserved example domain, not a live workshop or a link to distribute. Notice that the fragment remains at the end. Appending campaign text after #agenda would put it inside the fragment rather than the ordinary query.

Encoding is a separate concern from naming. Characters such as spaces and ampersands can have special meaning in URLs. Google’s URL encoding explanation recommends constructing URLs from components and using appropriate encoding. Its Maps-specific length limits are not a general UTM limit.

Our lowercase underscore convention avoids most encoding complications in new UTM values. Existing query values still need care. An approved value such as operations & planning must not introduce an extra parameter separator. Its query representation might be operations%20%26%20planning.

Do not encode an entire completed URL as if it were one value. Do not pre-encode a UTM label and then send it through a value encoder again. Double encoding can change %20 into %2520, producing a different value. Keep plain labels in the dictionary and encode components only when assembling the final link.

Also distinguish HTML escaping from URL encoding. In HTML source, an ampersand separating query parameters is written as &. In the actual URL copied into a campaign platform’s destination field, it is an ordinary &. Do not paste HTML entities into a field expecting a URL string.

Treat duplicate parameters as a failed check

Suppose an old link already contains utm_source=newsletter and someone adds utm_source=linkedin. There are now two values for the same key. A syntactically accepted URL does not tell the team which one its entire measurement chain will use.

The WHATWG URL standard allows query lists containing repeated names. Its get operation returns the first matching value; getAll returns all matches; set replaces one and removes other matches. Those API rules do not establish a universal GA4, redirect, server or vendor precedence rule.

The proposed team policy is stricter: reject every duplicate query key, and reject a destination containing any existing UTM before adding new ones. This avoids turning a repair into a hidden overwrite. It also means the builder is intentionally not idempotent: feeding its output back into itself returns an error. Start from the approved clean destination each time.

Some applications intentionally use repeated query keys for filters. That is valid application behaviour, but it is outside this starter builder’s supported contract. Have the website owner define and test an exception rather than weakening the duplicate rule for every campaign.

Use a local builder with narrow, explicit permissions

Download the UTM naming convention kit (ZIP; local builder, tests, templates and fictional examples).

The companion utm-builder.cjs creates strings locally. It does not contact the destination, send analytics data, store submitted values, or shorten links. Its dictionary contains fictional examples and must be adapted to approved public destinations before real use.

The design accepts exact registered base URLs rather than arbitrary websites. It then checks an intentionally narrow suffix: approved existing query keys and values, followed by an approved fragment. This is a constrained builder, not a replacement for a general-purpose browser URL parser.

The included rules require canonical HTTPS bases with dotted DNS names and simple lowercase paths. They disallow credentials, explicit ports, IP literals, malformed hostnames and unregistered paths. Query values must use component encoding, with malformed escapes and decoded controls rejected. Fragments must be registered simple lowercase anchors. The builder also refuses duplicate keys after decoding and existing tracking parameters. They also reject unknown input fields, unregistered campaign values and content assigned to the wrong source-medium pair.

Existing approved query text is preserved instead of being sorted or reserialized. This avoids unnecessary changes to its representation. Signed, authenticated, personalized and redirect-wrapper URLs are outside the supported use case. Do not add them to the dictionary to make an error disappear.

To use the companions, keep the builder, dictionary and test file together. Run the included tests with a local Node.js installation, then call the builder with the clean destination and registered labels. A sample command file produces the fictional French newsletter URL above. No account connection is required.

The builder deliberately refuses click identifiers such as gclid and linkers such as _gl on an input destination. It does not strip them from live visits. A copied visitor URL is the wrong starting point for a reusable campaign link; use the clean destination from the campaign register.

Passing these checks means the string meets this dictionary’s rules. It does not mean that the hostname resolves publicly, the destination exists, redirects preserve parameters, a consent choice permits collection, or a report will show the expected attribution. Those are separate checks, with separate evidence.

Keep Google Ads auto-tagging in its own workflow

Do not turn off Google Ads auto-tagging to make a manually tagged URL look more uniform. Google recommends auto-tagging for its Ads integration and describes how it adds a click identifier. The naming dictionary should coexist with the platform’s configuration, not replace it.

Google’s manual and automatic tagging guidance says auto-tagged values normally supply source, medium and other traffic-classification dimensions when both approaches are used. Manual content and term can populate their manual dimensions. It also describes a fallback: when GCLID or DCLID cannot be used as intended and UTMs are present, cross-channel traffic-source values are derived exclusively from UTMs. Missing relevant fields can then matter.

That is why a universal “manual UTMs always win” rule is unsafe. A universal “UTMs never matter on auto-tagged links” rule is also unsafe. Write down the intended integration, dimensions and fallback behaviour with the person responsible for advertising measurement.

The starter builder is for manual campaign links and is not a Google Ads tracking-template generator. It does not expand platform macros, manage final URL suffixes or validate advertising templates. If the campaign platform adds parameters automatically, inspect its actual output and record that behaviour before adding another mechanism.

Keep click identifiers untouched through redirects. A lowercase naming policy applies to values your team controls, not to an entire URL. Lowercasing a path, encoded value, signature or click identifier can alter its meaning. Google specifically warns about changing the case of gclid in its auto-tagging troubleshooting documentation.

Test redirects and the destination separately

A builder can validate a string without following it. It cannot prove what a website, shortener, email platform or booking portal will do with that string. Record the entire route that a reader will encounter, including any platform-generated wrapper.

For an approved test, begin with the exact link from the intended placement. Open browser developer tools before navigating and preserve the network log. Inspect each redirect response and the eventual landing URL. Check that the relevant query values retain their spelling and that the page still performs its ordinary function.

Google’s auto-tagging check explains that redirect chains can lose gclid and that the parameter needs to be observable where the tag loads. The same practical review question applies to manually supplied labels: what reaches the measurement code? A visible URL alone is incomplete evidence because scripts may read or change it at different times.

Use a small review record: initial URL, redirect destinations, expected labels, observed labels, landing-page function, test date and reviewer role. If you cannot observe a third-party step, record that as unverified. Do not convert the absence of access into a claim that the labels survived.

A locale selector is a useful edge case. The visitor may arrive at an English page, select French, and trigger a redirect. If the organization expects campaign context to remain available, test that route specifically. The same applies to trailing-slash redirects, a moved landing page and mobile deep-link behaviour.

Check the outcome action too. A workshop page may load correctly while its registration button points to a different or broken destination. URL validation, page functionality and measurement validation are related, but one passing check cannot stand in for the others.

Do not create fake production enquiries or bookings merely to prove a tag. Use the organization’s approved testing procedure and clearly separate test activity from real records. Where a vendor provides no suitable test route, describe the remaining evidence gap.

Keep personal information out of every part of the URL

No person’s name, email address, phone number, patient identifier, account number or other identifying detail belongs in these campaign URLs. The rule covers the path, existing query, new UTMs and fragment. A short or encoded identifier can still identify someone.

Google’s guidance on avoiding personally identifiable information explicitly includes page URLs and campaign dimensions. It also describes data redaction as a best-effort measure for email addresses. Prevention at link creation remains necessary; a downstream redaction setting is not permission to place personal information in a URL.

Encoding is not anonymization. Turning an email address into percent-encoded text does not make it suitable for a campaign label. Nor should the team replace it with a hash and assume the privacy question has disappeared. Use campaign-level information that describes distribution, not a person.

A dictionary reduces free-form entry but cannot guarantee privacy. A maintainer could approve an inappropriate value, and a harmless-looking code could carry a private meaning. The reviewer must understand what the registered destination, campaign and content values represent.

For a clinic, a generic location-information campaign is safer for this exercise than labels containing a patient’s condition, appointment or care history. The broader booking implementation belongs with the clinic’s privacy and platform owners. Canada Create’s online booking guide for clinics covers the booking journey; this naming process addresses only public campaign labels.

Use role names for ownership in a shared template, such as “campaign owner” or “reporting reviewer.” The public companion files use fictional values and role names throughout. An operational register can be managed under the organization’s own access controls, but it still should not become a place to paste customer-specific URLs.

Make exceptions visible, limited and reviewable

An exception register records why a link cannot follow the current standard, how it will be handled and when the exception ends. It is not a second dictionary where any value becomes acceptable.

Useful fields are exception ID, affected campaign or placement, requested departure, reason, reporting consequence, mitigation, accountable role, review date, status and closure evidence. The companion CSV provides those columns and clearly fictional sample records.

Choose an expiry or review date appropriate to the exception. A one-time printed run has a different lifespan from an integration limitation. An exception without an owner or review date is likely to become an undocumented permanent rule.

Do not make privacy a negotiable naming preference. An exception may authorize a custom medium or a separately tested technical route. It does not authorize personal information in the URL, broken links, fabricated results or unreviewed changes to an analytics account.

The exception CSV is a decision record; the builder does not automatically import it as permission. An approved technical change still requires a dictionary update or a separate implementation, appropriate tests and a version note. Keeping those steps distinct prevents a row marked “approved” from changing code unexpectedly.

Close an exception only when its closure evidence exists. “Partner asked us to fix it later” is not closure. Evidence might be a replacement URL accepted by the partner, a documented reporting mapping, or confirmation that an unused placement was cancelled.

Assign ownership at the points where errors enter

A small team can use three roles even when two people share them. The campaign owner defines the initiative and placements. The dictionary owner maintains approved labels. The reviewer checks the final link in context. The website or platform owner joins when redirects or integrations need attention.

Have the campaign owner submit a short link request containing the clean destination, campaign record, placement, language and intended launch. The dictionary owner should not need to infer the offer from a screenshot or reverse-engineer a link copied from a colleague’s browser.

Return one approved link with its register reference. Store that approved string where the publishing team already works. If a designer, media buyer or partner edits it, the edited link needs another check. The approved record should not be an earlier version that no longer matches the distributed asset.

For partners, provide the final destination and a plain instruction to preserve its parameters. Ask for the resulting placement URL or a review copy through the organization’s normal process. If the partner’s system wraps the link, validate the wrapper route as part of the launch checklist.

For internal website navigation, use an event or another appropriate interaction measurement design instead of inventing an acquisition campaign for every menu button. The goal is to avoid confusing an on-site interaction label with an external distribution source. This is a recommended measurement boundary, not a claim that every internal UTM click starts a new GA4 session.

In a larger programme, connect this ownership model to the existing B2B marketing strategy framework. Strategy determines the business question and accountability; the UTM standard makes one small part of that plan repeatable.

Migrate messy labels without rewriting history

Begin with a sample of links your team can legitimately inspect: active campaign records, current landing links and approved reporting exports. Classify the problems before changing anything. A spelling alias, an incorrect destination and a missing campaign record need different remedies.

Create a mapping table with old value, proposed canonical value, field, rationale, effective date and ambiguity note. An old li source might confidently map to linkedin if the campaign record supports it. A source named partner may be impossible to assign when several partners used it. Keep that uncertainty visible.

Set a date after which new links must use the dictionary. Update active links where the organization controls them and where the change is appropriate. Record the versions that remain in printed material, old emails and external publications. A naming change cannot retrieve every distributed copy.

Do not assume changing a destination today rewrites historical Analytics records. Reporting cleanup is a separate transformation with its own scope. Preserve original values in any working dataset and add a normalized reporting column rather than destroying the evidence that explains earlier differences.

When two campaigns share a name but represent different initiatives, resist merging them merely to make a chart tidy. Use date, campaign ID and source records to establish what can be separated. Where the evidence is insufficient, keep a clearly labelled unresolved category.

Read campaign reports with their uncertainty intact

Use the same reporting scope when comparing labels. A user’s initial acquisition, the source associated with a session and credit assigned to a key event answer different questions. Google’s channel documentation distinguishes these scopes. A report can be internally consistent and still answer a different question from the one the team intended.

UTMs do not solve attribution uncertainty. Someone can forward a newsletter link, return on another device, decline measurement, encounter several campaigns or complete an action offline. The original campaign label may remain on a shared URL even though the route by which the next reader received it has changed.

Separate observations from interpretations in the report. “This recorded session carried this campaign label” is an observation within the collection method. “This campaign caused the sale” is a stronger causal claim that requires more evidence. Consistent labels make that distinction easier to examine; they do not erase it.

For Business Profile links, use UTMs to label the website destination you control. They do not directly measure a call or direction request made entirely within Google. Google separately documents a Business Profile integration with Analytics that can bring profile-interaction metrics into Analytics. Linking those products is a separate implementation decision; adding UTMs does not create that integration. Canada Create’s Business Profile optimization guide addresses the broader profile; keep its activity measures distinct from tagged website visits.

Write a short limitations note beside any campaign comparison. Identify the reporting period, scope, collection gaps, known link changes and unresolved aliases. If a result could reflect a tracking change, investigate that possibility before presenting it as a change in customer behaviour.

Use a short checklist for every release

1. Confirm the initiative. The campaign name and ID identify the intended offer, and the register has an accountable owner.
2. Choose a registered placement. Source, medium, content and language agree with the asset being released.
3. Inspect the clean destination. It is an approved public page, with no personal information, copied visitor identifiers or authentication details.
4. Generate the URL. Existing approved queries and fragments remain intact; duplicate keys and previous UTMs are rejected.
5. Check the real distribution route. Review any platform wrapper or redirect and the final page’s function.
6. Validate measurement where authorized. Record what was observed and what remains unverified without treating a page load as attribution proof.
7. Record the released string. Keep the final URL, dictionary version, placement reference, date and reviewer role together.
8. Review after launch. Investigate unfamiliar labels and operational errors before expanding the convention.

The companion release-checklist CSV turns these questions into a reusable record. Blank outcome cells are intentional: they are not pre-filled approvals. Complete them from actual evidence for each release.

Keep maintenance smaller than the problem it prevents

Review the dictionary on a regular cadence suited to campaign volume. Check newly requested sources, recurring exceptions, unused labels and values that people repeatedly misunderstand. A monthly review may suit a modest programme; a busier team may need a short check before each batch.

Retire values without erasing their definitions. A source can be unavailable for new links while remaining documented for historical interpretation. Keep the retirement date and replacement rule, and avoid recycling the same value for a different meaning.

Measure the health of the process with operational questions: how often does a reviewer find a wrong destination, how many exceptions remain unresolved, and can another team member reproduce a link? Establish a baseline from your own work before setting targets. No universal percentage makes a convention successful.

The best sign of a useful standard is that ordinary requests become easy. A colleague can find the campaign, choose a placement, generate a valid string and understand why an unusual request needs review. The dictionary then supports the work instead of becoming another document that only its author understands.

Put the naming standard into everyday use

Start with one upcoming initiative and a few real placements. Agree on the field definitions, register the values, adapt the companion dictionary, and review the complete journey before broadening it. Preserve the distinction between a valid label, a functioning link and a supported business conclusion.

If your team needs help connecting campaign labels to a maintainable reporting process, contact Canada Create about your campaign measurement workflow.