How Do You Stop Your Campaign Reporting From Lying to You?

Why does your channel reporting not add up?

Almost always because the same channel was tagged several different ways. Not a tracking bug, a naming problem. Email, Email and e-mail become three separate rows, your real email number is split across all of them, and every summary built on top is quietly wrong.

This is the most common reporting failure I see, and it is completely preventable. It is also the least interesting problem to fix, which is exactly why it persists in so many teams until somebody finally sits down and does it.

Here is the convention I use and how to roll it out on a site that already has tagged links out in the world.

What do UTM parameters actually do?

They label a visit with where it came from, before your analytics has to guess. When somebody clicks a tagged link, those values travel in the URL and appear in your reporting. Without them, analytics falls back on whatever the browser passes along, which is often much less useful.

The mechanics are simple. Google documents that you start the parameter string with a question mark, list each parameter and value as a pair joined by an equals sign, and separate the pairs with an ampersand. The order of the parameters does not matter.

That simplicity is the trap. Because anyone can write a tagged URL by hand in ten seconds, everyone does, and nobody agrees on what to write. The technology is not the hard part here. The agreement is.

Which parameters should you always set?

Google's documentation lists utm_id, utm_source, utm_medium, utm_campaign, utm_source_platform, utm_term and utm_content among the parameters you can add. Its advice is unambiguous: if you are setting one, set all the relevant ones, and it singles out source, medium, campaign, id and source platform.

The reason is stated plainly in the same documentation. Missing parameters result in values appearing as not set in your reporting. A partially tagged link is not half useful, it is a row in your report that nobody can act on and everybody eventually learns to ignore.

My practical rule is that source, medium and campaign are mandatory for every link, always, with no exceptions for quick tests. The exceptions are how the mess starts, because a quick test link has a way of ending up in a newsletter that goes out to everyone.

Why does capitalisation break your reports?

Because the values are case sensitive and your analytics has no way to know you meant the same thing twice. Google's documentation says this directly, noting that utm_source=google is different from utm_source=Google, and that Meta and meta are treated as different values.

The same documentation makes the point about punctuation too, giving SpringSale and Spring_Sale as an example of two values considered distinct. So you can fragment a campaign not only by capitalisation but by an underscore somebody added because it looked tidier.

Google's recommendation is to use lowercase as a standard practice, and I would go further and make it an absolute rule. Lowercase everything, always, with no judgement calls. A rule that requires no thinking is a rule that survives a busy Friday.

How do you choose a naming convention that survives?

Pick values that describe the channel rather than the campaign of the moment, keep the vocabulary small, and write it down before anyone needs it. A convention with twelve allowed sources is usable. One that grows a new source every week is a list, not a convention.

Google's guidance adds a point worth taking seriously, which is to make your values match the internal platform names you already use so reporting does not fragment. If your team calls it paid social everywhere else, do not invent a different label for analytics.

Decide your separator once and never revisit it. Whether you use hyphens or underscores matters far less than that everybody uses the same one, since the documentation is explicit that the two produce distinct values.

Where should the convention actually live?

Somewhere the person building a link will already be, not in a document nobody opens. A shared sheet that generates the URL from dropdowns beats a written policy, because it removes the opportunity to type something new rather than relying on people to remember.

This is the single highest leverage change available here. Written conventions decay because they depend on memory and goodwill. A builder that only offers the approved values makes the correct thing the easiest thing, and the convention enforces itself.

If you already have a process for producing campaign links, extend that rather than adding a parallel one. Two systems for the same job means two vocabularies within a quarter, which is the reason to settle your tagging setup once and route everything through it.

What should you never put in a UTM parameter?

Anything personal. A URL is visible in browser history, in referrer headers, in server logs and in anything the visitor pastes into a chat. An email address or a customer identifier in a tracking parameter is a privacy problem you have spread across systems you do not control.

The second thing to avoid is tagging your own internal links. A campaign parameter describes where a visit came from, and a link between two of your own pages is not a new arrival. Check your analytics platform's documentation on how it handles campaign parameters mid session before you consider it.

The third is anything you will not recognise in six months. Values like test2 or final_v3 make sense on the day and are undecodable afterwards, at which point that traffic is effectively unattributed even though it was technically tracked.

How do you fix tags that are already in the wild?

You cannot change a link that has already been sent, so fix it in reporting rather than at the source. Build a mapping from every messy value you currently see to the clean value you want, and apply it wherever you report from.

Start by exporting every distinct source and medium value in your data. That list is usually shorter and uglier than people expect, and seeing it in one place is what finally makes the case for a convention to whoever needs convincing.

Then set a cutover date, tag everything new the correct way from that point, and keep the mapping for historical comparisons. A clean break with a documented mapping is much easier to explain than a slow migration where nobody can say which period is trustworthy, and it makes exporting a clean report for a client possible again.

What should you do next?

Export the distinct values of source and medium from the last ninety days and count how many of them mean the same thing as another one. That number is your reporting error, and it is usually the fastest way to get agreement that this work matters.

Then write your allowed vocabulary on one page, all lowercase, and build the link builder before you announce the policy. Announcing a convention without giving people a tool to follow it is how conventions die, and you will only get one attempt at the announcement.

If your channel numbers have never quite reconciled and you suspect this is why, send me what your source list looks like. I can usually spot the duplicates in a minute. Let's chat.