{"id":13141,"date":"2026-09-23T07:35:00","date_gmt":"2026-09-23T05:35:00","guid":{"rendered":"https:\/\/www.lukaswojcik.com\/blog\/?p=13141"},"modified":"2026-09-09T13:21:43","modified_gmt":"2026-09-09T11:21:43","slug":"tutorial-double-encoded-utm-parameters-and-where-to-fix-them","status":"publish","type":"post","link":"https:\/\/www.lukaswojcik.com\/blog\/en\/digital-marketing\/tutorials-en-digital-marketing\/tutorial-double-encoded-utm-parameters-and-where-to-fix-them\/","title":{"rendered":"Tutorial: Double-Encoded UTM Parameters and Where to Fix Them"},"content":{"rendered":"

A campaign called Sommer Aktion<\/em> turns up in the report as Sommer%20Aktion<\/code>. Nothing is broken – the traffic arrived, the sessions are counted, the conversions are attributed. The name is simply wrong, and every filter, every comparison and every export inherits it.<\/p>\n

The cause is always the same: the value was encoded twice. What differs is where the second pass happened, and the report itself says how many passes there were.<\/p>\n

\n\"One
Each additional pass turns the percent sign of the previous one into %25. Counting them in the report gives the number of encodings.<\/figcaption><\/figure>\n

What Percent-Encoding Does, and What Happens Twice<\/h2>\n

A URL may only contain a limited set of characters. Everything else is written as a percent sign followed by the hexadecimal value of its bytes – a space becomes %20<\/code>, an ampersand %26<\/code>, a German u-umlaut becomes %C3%BC<\/code> because it is two bytes in UTF-8.<\/p>\n

The percent sign itself is one of the characters that has to be encoded, and that is the whole mechanism behind the problem. Encoding an already-encoded string converts each %<\/code> into %25<\/code>.<\/p>\n

Sommer Aktion          the value as written\nSommer%20Aktion        encoded once   - correct in a URL\nSommer%2520Aktion      encoded twice  - the %20 was encoded again\nSommer%252520Aktion    encoded three times<\/code><\/pre>\n
Reading it in the other direction is just as mechanical. A decoder turns %2520<\/code> back into %20<\/code>, which is a literal percent-two-zero rather than a space – so the value arrives as text with a percent sign in it, and that is what the report displays.<\/p>\n
The Three Places a Second Pass Comes From<\/h2>\n
A URL is rarely built in one step, and each additional step is a candidate.<\/p>\n
The first is the link builder itself. A tool that takes an already-assembled URL and encodes the whole thing produces exactly this. The tell is that the ampersands between the parameters are also affected: a URL containing %26utm_source%3D<\/code> was encoded as a whole rather than per component, and it does not even work as a link any more.<\/p>\n
The second is a click tracker. An email tool or an ad platform that wraps the destination as a parameter of its own address has to encode it once – correctly. If the destination was already encoded, the encoding of the wrapper is the second pass, and the result reaches the site intact but with doubled values.<\/p>\n
https:\/\/klick.beispiel\/r?u=https%3A%2F%2Fshop.example%2F%3Futm_campaign%3DSommer%2520Aktion\n                            \u2514\u2500\u2500 correct encoding of the destination \u2500\u2500\u2518  \u2514 already encoded \u2518<\/code><\/pre>\n
The third is a content management system. A field that stores a URL and escapes it on save, then escapes it again when rendering, produces the same result – and it is the one case where nothing in the marketing tooling is at fault, which is why it takes the longest to find.<\/p>\n
Telling the Cases Apart in the Report<\/h2>\n
The number of passes is readable from the value, and it points at a different culprit each time.<\/p>\n\n\n\n\n\n\n\n\n\n
In the report<\/th>\nPasses<\/th>\nWhere to look<\/th>\n<\/tr>\n<\/thead>\n
Sommer Aktion<\/td>\n1<\/td>\nCorrect – nothing to do<\/td>\n<\/tr>\n
Sommer%20Aktion<\/td>\n2<\/td>\nLink builder or click tracker<\/td>\n<\/tr>\n
Sommer%2520Aktion<\/td>\n3<\/td>\nTwo wrappers in a chain<\/td>\n<\/tr>\n
Sommer+Aktion<\/td>\n1<\/td>\nA different convention, see below<\/td>\n<\/tr>\n
Sommer%C3%A4Aktion<\/td>\n2<\/td>\nSame problem, non-ASCII character<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
The quickest way to see all of them at once is to sort the campaign dimension and look for a percent sign. A single filter on %<\/code> across campaign, source, medium, term and content finds every affected value in one pass, and the count next to it says how much traffic is landing in the wrong bucket.<\/p>\n
The last row is worth a note. An umlaut encoded once is %C3%A4<\/code>, and that is correct – the report should show the letter. Seeing the escape sequence in the report means it was encoded twice, exactly like the space.<\/p>\n
Encoding Components, Not URLs<\/h2>\n
The rule that prevents all of this is one sentence: encode each value on its own, then join them. Never encode a URL that already has parameters in it.<\/p>\n
const ziel   = \"https:\/\/shop.example\/sommer\";\nconst felder = {\n  utm_source:   \"newsletter\",\n  utm_medium:   \"email\",\n  utm_campaign: \"Sommer Aktion\",\n  utm_content:  \"kopfbild & titel\"\n};\n\nconst url = ziel + \"?\" + Object.entries(felder)\n  .map(([k, v]) => encodeURIComponent(k) + \"=\" + encodeURIComponent(v))\n  .join(\"&\");\n\n\/\/ https:\/\/shop.example\/sommer?utm_source=newsletter&utm_medium=email\n\/\/   &utm_campaign=Sommer%20Aktion&utm_content=kopfbild%20%26%20titel<\/code><\/pre>\n
The distinction between the two available functions matters here. encodeURIComponent<\/code> encodes everything that is not unreserved, including &<\/code>, =<\/code> and ?<\/code>, and it belongs on individual values. encodeURI<\/code> leaves exactly those characters alone because they have a structural meaning, and it belongs on a whole address that has not been encoded yet. Using the second one on a value is how an ampersand inside a campaign name splits it into two parameters.<\/p>\n
A simple habit closes the remaining gap: build the final URL once, and paste that string everywhere. A URL that is assembled again in a second tool is a URL that gets encoded again.<\/p>\n
The Space That Is Sometimes a Plus<\/h2>\n
Two conventions exist for a space in a query string, and both are in use.<\/p>\n
Percent-encoding writes %20<\/code>. Form encoding, the format a browser uses when submitting a form over GET, writes +<\/code>. Both are common in URLs, and the difference is that a decoder has to be told which one it is looking at: a generic URL decoder leaves the plus as a plus, a form decoder turns it into a space.<\/p>\n
The practical consequence is that a campaign name containing a plus sign cannot be distinguished from one containing a space, and which of the two a given tool reports is a property of that tool. Two systems can therefore disagree about the same campaign, and neither is wrong.<\/p>\n
The way out is to avoid the ambiguity rather than resolve it. Campaign values without spaces – sommer-aktion<\/code> rather than Sommer Aktion<\/code> – are unaffected by the whole question, and they also survive being lowercased, which some platforms do without asking. A naming convention that uses hyphens and lower case removes an entire class of report noise for the cost of looking slightly less pretty in a spreadsheet.<\/p>\n
Repairing What Is Already Recorded<\/h2>\n
Fixing the link stops new damage. The recorded sessions keep their values, and there are three ways to deal with them, in increasing order of permanence.<\/p>\n
In the report, two values that differ only in their encoding can be brought together by hand – a comparison, a segment, or a grouping in a spreadsheet. This is the honest option for a campaign that has ended: nothing is changed, the difference is simply accounted for.<\/p>\n
For a campaign that is still running, a rule at collection time is better. GA4 can rewrite an incoming parameter before it is stored, and the same is possible one step earlier in a tag – decode the value once, then write it back.<\/p>\n
function () {\n  var wert = {{URL - utm_campaign}};\n  if (!wert) { return undefined; }\n  \/\/ einmal zusaetzlich dekodieren, wenn ein %25 uebrig ist\n  while (\/%25\/.test(wert)) {\n    try { wert = decodeURIComponent(wert); } catch (e) { break; }\n  }\n  return wert;\n}<\/code><\/pre>\n
The try<\/code> around the decode is not decoration. A value containing a lone percent sign that is not a valid escape sequence makes decodeURIComponent<\/code> throw, and without the guard the variable returns nothing at all – which turns a cosmetic problem into a missing campaign.<\/p>\n
And in BigQuery, the historical rows can be corrected in the query rather than in the data, which keeps the raw export intact and is reversible.<\/p>\n
SELECT\n  REPLACE(REPLACE(kampagne, '%2520', ' '), '%20', ' ') AS kampagne_sauber,\n  COUNT(*) AS sitzungen\nFROM `projekt.dataset.sitzungen`\nGROUP BY kampagne_sauber\nORDER BY sitzungen DESC;<\/code><\/pre>\n
Which of the three is right depends on one question: whether the numbers are going into a report somebody will act on, or into an archive. For the first, correct at collection. For the second, correcting in the query is enough – and it leaves the evidence of what actually arrived.<\/p>\n
\n
Sources<\/h2>\n