UTM Rules: Which Ones to Block, Warn, or Just Log

Has your team ever gone quiet on a Friday launch because the link builder refused to save their link?

Mine has. I run linkutm.com, and I turned on nine UTM rules in a single afternoon in 2024. Every one of them was set to block. Within a week, two people had stopped using the builder entirely. They were not being difficult. They had a campaign to ship and a tool that kept saying no.

Here’s the thing. The rules were all correct. The severity was wrong.

A UTM rule is a machine-enforced constraint on a UTM parameter value. Lowercase only. No spaces. utm_medium must come from an approved list. Most articles about UTM rules stop at listing which rules to create. Almost none tell you what should happen when someone breaks one, and that decision matters more than the rule itself.

This article covers the part nobody writes about: rule severity. Which UTM rules deserve a hard block, which should only warn, which should quietly log, and how to roll a new rule out without your team routing around it.

Why Setting Every UTM Rule to “Block” Backfires

Blocking everything does not produce clean data. It produces a team that stops using your builder.

This is the failure mode I hit. When a rule blocks, the marketer has three options: fix the link, ask someone for help, or go somewhere else. Under deadline, the third option wins more often than marketing ops likes to admit. The link still gets built, just in a spreadsheet or Google’s Campaign URL Builder, with no rules at all.

So you end up worse off than before. Your builder shows perfect compliance because the non-compliant links were never created in it. Meanwhile GA4 fills up with untagged and mistagged traffic from links you cannot see.

The second failure is subtler. An over-strict rule set stops being a data quality tool and becomes a judgement call about legitimacy. I blocked utm_source=newsletter once because our convention said the source should name the specific publication. Turned out a partner genuinely called their product “Newsletter”. The rule was not wrong in general. It was wrong for that link, and there was no way to say so.

Honest limitation: loosening severity does mean some bad links ship. I accept that trade. A warn-tier rule that catches 80% of violations and keeps the whole team inside one tool beats a block-tier rule that catches 100% of the violations it sees while a third of the team creates links elsewhere.

The Three Severity Tiers for UTM Rules

Rule severity decides what happens when a link breaks a rule. Three tiers cover every case:

• Block. The link cannot be created until the value is fixed. Use for violations that are unambiguously wrong.
• Warn. The link is created, with a visible flag on it. Use where the value is probably wrong but might be legitimate.
• Log. The link is created with no interruption, and the violation is recorded for later review. Use while you are still learning whether the rule is even right.

I did not invent this. Software linting settled it years ago, and the parallel is exact.

ESLint gives every rule one of three severities: off (or 0), warn (or 1), and error (or 2). An error exits with a non-zero code, which breaks a CI pipeline or blocks a commit. A warn reports the problem and lets the code through.

ESLint’s own documentation says to use warn in three situations. Read them as a UTM rule checklist:

1. When introducing a new rule that will eventually be set to error
2. When the rule flags something that is not an actual build or runtime error
3. When the rule cannot determine with certainty that a problem has been found

Point one is the rollout argument. Point three is the utm_source=newsletter problem.

dbt adds the piece ESLint lacks: thresholds. A dbt test takes severity: error | warn (default error), plus error_if and warn_if conditions that both default to !=0. You can write:

data_tests:
  - unique:
      config:
        severity: error
        error_if: ">1000"
        warn_if: ">10"

That says: warn me past 10 failures, fail the build past 1,000. dbt also ships --warn-error, which promotes every warning to an error in one flag. That is exactly the switch you want when a rule graduates from trial to enforced.

Honest limitation: most UTM tools, including linkutm’s rules, do not expose numeric thresholds the way dbt does. You get enforcement on or off. The thresholds in this article are a mental model for deciding tiers, not a config you can paste.

Which UTM Rules Should Block, and Which Should Only Warn

The test is simple. Block only when a violation is unambiguously wrong and a machine can prove it. Warn when the value might be legitimate. Log when you are not yet sure the rule is correct.

Here is how I tier the nine rules most teams start with.

Rule	Tier	Why
Lowercase only	Block	GA4 campaign dimension values are case sensitive, so Email and email split into two rows. Never legitimate.
No spaces in values	Block	Encodes as %20 and breaks on paste. Never legitimate.
Required: source, medium, campaign	Block	A link missing one of these cannot be attributed at all.
Empty parameter values	Block	utm_source= is strictly worse than no parameter.
utm_medium from approved list	Warn	New channels appear faster than your list updates. A block here is the single most common reason teams route around the builder.
Campaign name pattern	Warn	Patterns like 2026-q3-name break on genuine edge cases such as always-on campaigns.
Banned generic values (website, web, link)	Warn	Usually lazy, occasionally the partner’s actual name.
Campaign length cap	Log	Long names are ugly, not broken. Not worth an interruption.
No UTM tags on internal links	Log	High false-positive rate. Your builder often cannot tell an internal share from an external campaign.

Two opinions, stated plainly.

utm_medium should almost never block. It is the parameter most teams block first, because medium drives GA4’s channel grouping and a wrong value lands traffic in the wrong bucket. I understand the impulse. But an approved-value list is a controlled vocabulary, a fixed set of permitted values, and a controlled vocabulary is only as current as the person maintaining it. Block it and every new channel becomes a support ticket. Warn it, review the flags weekly, and add the real ones.

Lowercase should always block. It is the one rule with zero legitimate exceptions and the highest damage per violation. GA4 treats campaign dimension values as case sensitive, so one capital letter quietly splits a campaign across two report rows for its entire life.

For the specific errors worth writing rules against in the first place, I catalogued the 11 errors worth catching separately. This article assumes you already know which errors matter and is only about what severity to give them. The format itself, hyphens versus underscores and so on, belongs to your UTM naming conventions.

How to Dry-Run a UTM Rule Before You Enforce It

Never turn a new rule straight to block. Run it in log mode against links you already have, then promote it.

A dry run means running the rule without enforcing it, purely to count what it would have caught. It answers the only question that matters before enforcement: how many people am I about to interrupt?

Here is the rollout I use now, after the 2024 mess.

1. Write the rule in log tier first. No blocking, no warning banner. It records violations and nothing else.
2. Run it against your existing link library. Export your links and count matches. This is the dry run. If you are checking links already live in the wild, that is a UTM audit rather than a rule test, and it answers a different question.
3. Read the violation count against dbt’s threshold logic. Under 10 violations means the rule is safe to block now. Ten to a hundred means warn first and fix the backlog. Over a thousand means your convention has drifted from reality, and the rule is probably wrong, not the links.
4. Inspect the false positives by hand. This is the step people skip. Pull 20 flagged links and check each one. If more than two are legitimate, the rule stays at warn permanently.
5. Promote in one step, and announce it. Move log to warn, or warn to block, and tell the team in the same message. dbt’s --warn-error flag exists precisely because promotion should be one deliberate action, not a drift.
6. Re-run the count 30 days later. If violations did not fall, the rule is not teaching anyone anything. Either the message is unclear or the rule is wrong.

Step 3 is the one that saved me. When I finally dry-ran my campaign name pattern rule, it flagged 1,400 of about 1,900 links. The rule was not catching sloppiness. My pattern simply did not describe how the team actually named campaigns. I rewrote the pattern instead of enforcing it.

Honest limitation: a dry run only sees links inside your tool. Links people built in spreadsheets are invisible to it, which means your violation count is optimistic. Assume the real number is higher.

UTM Rules vs Conventions vs Governance vs Audits

These four get used interchangeably and they are not the same thing. The relationship is a chain, and each link does one job.

Term	What it is	Who or what does it
Convention	Written guidance on how values should be formatted	A document a human reads
Rule	The machine-enforced version of a convention	The link builder, at creation time
Validator	The engine that runs rules against a link	Software
Governance	Who decides what the rules are and who can change them	People and a decision process
Audit	Retrospective review of links that already shipped	A person, on a cadence

Read as a sentence: governance decides the convention, the rule enforces it, the validator runs it, and the audit catches what escaped.

Two distinctions worth stating outright, because I see them conflated weekly.

A convention without a rule is a preference. If the standard lives only in a Notion page, compliance depends on memory. That is not enforcement, and it is why documented conventions drift within a quarter.

A rule without governance is a bottleneck. Someone has to own which values are approved and how fast an exception gets resolved. That ownership question is a different discipline entirely, covered by UTM governance, and severity tiers do not substitute for it. Tiering your rules well reduces the number of exceptions. It does not remove the need for someone to handle the ones that remain.

The direction of the relationship also matters. Rules act at creation time, before a link exists. Audits act after the fact, on links already collecting clicks. A rule cannot fix historical GA4 data and an audit cannot stop tomorrow’s bad link. Teams that only do one of the two always have a gap.

What a Tiered Rule Set Still Will Not Fix

Severity tiers solve the enforcement problem. They do not solve four others.

Rules cannot repair data already in GA4. Campaign values are recorded at collection time. Fixing the rule today does nothing to last quarter’s reports. That data stays split.

Rules cannot see links built elsewhere. Every rule in this article applies only to links created inside your builder. A marketer pasting parameters by hand into an ad platform is outside the system entirely, whatever severity you set.

Rules cannot judge whether a campaign name is meaningful. A machine can verify 2026-q3-launch matches a pattern. It cannot tell you that three different teams used launch for three unrelated products. That is a vocabulary problem, and it needs a human reading the values.

Warn tiers get ignored. This is the honest cost of the whole approach. A flag nobody reviews is decoration. If you move rules to warn and never look at the flags, you have not tiered your rules, you have turned them off with extra steps. Put a recurring 20-minute review on someone’s calendar or keep the rule at block.

UTM Rules FAQs

Should UTM rules block or just warn?

Block only rules where a violation is unambiguously wrong and machine-checkable, such as uppercase characters, spaces, empty values, or a missing required parameter. Warn on rules where the flagged value could be legitimate, which includes approved-value lists for utm_medium and campaign name patterns. The practical test is whether a reasonable marketer could have a good reason for the value. If yes, warn.

Which UTM rules should I enforce first?

Start with lowercase enforcement and required parameters, both at block tier. Those two catch the highest-damage errors and have no legitimate exceptions, so they generate almost no friction. Add utm_medium vocabulary and campaign patterns afterwards at warn tier, once you have seen how often your team trips them.

How do I test a UTM rule before turning it on?

Run it in log mode against your existing link library and count how many links it would have flagged. Then inspect about 20 of those flagged links by hand to find false positives. Under 10 total violations means you can block immediately, and over a thousand usually means the rule does not match how your team actually works.

Why did my team stop using the UTM builder after I added rules?

Almost always because a rule blocks a value they need and there is no fast way to get an exception. People under deadline do not file requests, they route around the tool and build the link somewhere with no rules at all. Move the offending rule to warn, then find out which value they were trying to use and why.

Can UTM rules fix campaign data that is already wrong in GA4?

No. Rules run at link creation time, so they only affect links built after you turn them on. Historical campaign data stays exactly as it was recorded, including the split rows caused by casing errors. Correcting the record means a retrospective audit and, usually, a rebuilt report rather than fixed raw data.

Start With Two Rules, Not Nine

Real talk: my mistake in 2024 was not picking bad UTM rules. It was treating severity as an afterthought when it is the actual design decision.

If you are starting today, turn on two rules at block tier: lowercase only, and require source, medium, and campaign. That is it. Both are unambiguous, both catch real damage, and neither will send anyone back to a spreadsheet.

Then add one rule a month at log tier, dry-run it, read the violation count, and promote it only when the numbers say the rule matches reality. A small rule set your team actually uses beats a comprehensive one they work around.

Want to see what your current links would trip before you write any rules at all? Run a handful through the free UTM checker at linkutm and count what comes back.