Why UTM names split your reports

The split, with a concrete URL

Two people on the same campaign each build a link. One types utm_source=Facebook. The other types utm_source=facebook. Both URLs load the landing page. Both look finished. A week later the report has two source rows for what everyone thought was one campaign, and neither row matches the plan.

A third person uses fb because that is what last quarter's spreadsheet said. That is a third row. None of these is a malformed URL. The UTM validator will pass all three if source, medium, and campaign are present and unambiguous. Validity is the wrong check for this problem.

Exact strings, not nicknames

Campaign parameters are stored and grouped as the characters that arrived. Facebook and facebook differ by one bit of case. Analytics products do not have a built-in list of brand nicknames, and they should not: mail and email might be the same channel in one team and two channels in another. Guessing would silently merge rows a person meant to keep apart.

That is why the split is not a glitch. The product did what the field asked: treat the value as a string. The same rule applies to medium and campaign. Paid Social, paid-social, and paid_social are three mediums. Fall Launch and fall_launch are two campaigns. Hyphens, underscores, spaces, and capital letters are all load-bearing.

Encoding can hide a fourth kind of drift. A space in a query value may appear as a plus in one copy of a URL and as %20 in another. Both decode to a space. A name that was typed with a plus as a literal character is a different string. The URL encoder is the place to see that difference rather than to argue about it in a spreadsheet.

What a builder cannot prevent

Google's Campaign URL Builder, and this site's UTM builder, will both emit a tagged URL. That is the job. Neither one can know that last month the team saved facebook and this week someone typed Facebook. A builder checks that the parameter names are spelled utm_source, not that the values match a vocabulary the team agreed on.

Structural checks still matter. Duplicate utm_source keys, empty values, and tags placed after the fragment will wreck attribution in a different way. Run those through the validator. Then run the same URL through a naming check, because a clean structure can still split the report.

Pick one spelling and keep it

The cheapest rule that works is lowercase, hyphens or underscores picked once, and no spaces. Write it down. The specific convention matters less than using it twice. A document that says "Facebook ads are facebook / paid_social" is enough, as long as the next link is compared with that document before it is sent.

The naming-consistency checker stores that vocabulary in this browser after an explicit save. It flags case, spacing, and punctuation drift against the saved form. It does not rewrite the URL, and it does not guess that fb means facebook. Those are aliases a person has to decide. Automatic correction would be dangerous when a destination system expects the value you typed.

The vocabulary stays on the device. It is a guard at the moment a tagged link is made, not a hidden team workspace. Sharing it would need an account or a server, which these tools do not have.

What this page does not claim

It does not claim that any named analytics product is broken. It does not claim that Benchvale is the only place to catch the split. It claims one checkable thing: if two URLs carry different exact strings in the same UTM field, they will land in different rows, and you can catch that in the browser before the link is published.