In this post I will show you how to ensure that UTMs (tracking parameters) are really included in lander URL even after the coming iOS17 that is said to remove it.
…and all kinds of stuff you might want to know and do better.
In online marketing, having reliable tracking data is crucial to optimize your marketing. You don’t want to lose it or have it overridden with something misleading.
UTM-parameters are used to help to track and classify website traffic. Actually, to be more precise, for the purpose of knowing where the traffic is coming from.
The great thing with UTM-parameters is that everyone are using it, but that is also the problem!
Tracking services such as Google Analytics will use UTMs by default as filters in your visitor data. This helps to classify the incoming traffic so that you can get a better insight. The tracking classification helps you to know which marketing actions are producing a desired outcome; e.g. sales, subscriptions etc.
Clarification: By “UTMs” I mean “UTM” in plural.
UTMS ARE USUALLY RESPECTED, BUT NOT RESERVED
Commonly used UTMs are utm_source, utm_medium, utm_campaign, utm_term and utm_content. These are attached to an existing URL of a landing page. Instead of https://www.example.com/my-page/ the link could become https://www.example.com/my-page/?utm_source=facebook&utm_medium=cpm
UTMs themselves are not magical, they are just a naming convention (a name syntax), first introduced by Google. Today, they are “special” only because the marketing community agrees that they are. The “special” part is mainly about the fact that (probably) all tracking services use these as filters by default.
From a technical perspective, UTMs are just querystring parameters like any other. They are not immune to problems or misuse.
UTMs are not “reserved” in any way. Anyone can add them to their URL, just as easy as any other detail in the URL.
UTMs are as useful as they are respected. If they are not respected, they lose their utility. Therefore, UTMs should never ever be used for critical data! I’ll clarify why in the text below.
UTMS ARE EASILY “CORRUPTED”
I will use the word “platform” as synonym for “traffic source”. I’m doing this for semantics and readability to more clearly distinguish “traffic source” from “source”.
It happens that platforms (websites, apps etc) attach UTMs. If this is an UTM that you are already using in your URL it could override your existing parameter values. Nothing says that a platform will respect existing value or what it will do in such situation. (These things can be done manually too.)
In the case of iOS17, Apple can simply target those UTMs for total removal. Meaning, intentionally filter out or “strip” know UTM-parameters.
WHY DO PLATFORMS ADD UTMS AT ALL?
Well, that’s actually what UTMs are for, to attach data to the URL to convey information about where the traffic is coming from. But there’s more!
Platforms often want credit for generating traffic. This is understandable because that makes them more attractive to publish ads on. If a platform, that you never heard of, starts showing up in your website statistics as the source of traffic (utm_source=SomePlatform) you are likely to start exploring who they are.
In a sense, UTMs are both informative but also a way to gain visibility in visitor statistics.
All of the above is fine. The problem starts when you want to use your own values in the UTMs.
REAL LIFE EXAMPLE OF POSSIBLE UTM CORRUPTION
Say that you want to track how efficient traffic from your custom service chats is. You might decide on using this link syntax:
example.com/my-page/?utm_source=Customer_Service_Chat
(What you call the value is up to you. The “_” are used to make the entire value be seen by computers as one single word, but still be easily readable for you.)
The above link is great! You are adding a very clear classifier that, because you use the utm_source parameter, is also automatically being used as filter by Google Analytics etc.
A platform might apply its own UTM, which could override your UTM value with their own new value:
example.com/my-page/?utm_source=some-new-value
Now, when visitors arrive to your website, your tracking will show the latter, some-new-value. You will have no idea about that it’s actually from your chat.
The situation above could mislead you into thinking that your chat is not worth your time or money. This happened because you lost critical data!
I’ve seen examples of this happen (I just don’t remember where). This happens exactly because UTMs are so commonly used. There are no inherent mechanisms to avoid it. It’s all up to each platform if they respect existing UTM data and how they deal with it.
PLATFORMS OVERRIDING EXISTING UTMS IS NOT A “BUG” OR WRONG BEHAVIOR
The scenario above of the platform setting its own UTMs is actually the technically correct behavior.
Even though it’s you that sent the link to the client, that traffic (client clicking) will technically originate from the platform.
You might think that your UTMs should always be respected. Not so fast!
What happens if a link was copied from Platform1 (e.g. a newsletter) and shared heavily on Platform2 (e.g. TikTok)? If both platforms attach their own UTMs, which would you want to be included in the lander URL? — I’m guessing the latter.
See, there is no behavior that is categorically always prefered.
If you want to be sure that your tracking parameters are not overridden or dropped along the way, you need to go beyond the traditional UTM setup. If you don’t, any step along the way can easily “corrupt” your tracking intentions.
By “corrupt” I mean either changed or removed.
HOW ARE EXISTING UTMS DEALT WITH?
You can include same parameter multiple times and with different values: example.com/my-page/?utm_source=facebook&utm_source=some-new-value
The problem with the above is that it is now reported to the server as an array and not as a string. This requires special handling of the array. If you don’t do that the server can’t know which of the above you want so it will just skip it.
Question: If parameter exists, will it be added to create an array, will it be overridden or will the URL not be altered because the UTM exists already?
Answer: You never know in advance and you can never be sure it will never change.
In my experience, parameters are almost never added to create an array, as this would risk breaking both values if propper array handling is not in place, which it almost never is. (I bet many don’t even know about the array approach existed.) Beyond this, the behaviors vary.
Do not fool yourself into thinking that UTM behavior on one platform is representative of another. It’s not!
FACEBOOK ADS
(I do things differently nowadays so I am explaining the below based on my earlier experiences.)
If I remember correctly, Facebook Ads will skip altering or adding parameter if parameter already exists. So, if you have an utm_source in your Website URL and then add utm_source in the URL Parameters field, the latter will just be ignored.
But it’s messier than that. I am not sure but it seemed that having any parameters (querystring) in Website URL could lead to parameters in URL Parameters being ignored.
I am no sure if this is still true, or if there were only certain situations that caused this. All I know is that it was inconsistent and sometimes, seemingly identical ads, would produce different final URLs.
HOW TO BE SURE THAT FACEBOOK INCLUDES PARAMETERS, INCLUDING UTMS
I’ve stopped using URL Parameters due to inconsistencies that Facebook Ads seems to have. Instead I “hard code” all parameters into all links. This way I don’t have to rely on Facebook to do it properly.
I find this to be the only consistent way to include every parameter, including UTMs, in the lander URL.
To clarify: The “hard coding” refers specifically to Facebook and the fact that URL Parameters is not always attached to all links in the ad. So to avoid the risk of that happening, I simply include any and all tracking parameters, including UTMs in the Website URL and also in links in the Facebook ad Main Text.
MAXIMIZING THE ACCURACY AND VALIDITY OF TRACKING URL PARAMETERS
WARNING: I will describe customizations and alternatives to URL tracking parameters. These custom parameters will not be used as filters in you tracking service by default. You will have to set those filters by yourself.
Standard UTMs, on the other hand, have the special thing about them that they are used as filters by default.
Everything I have described about UTMs so far are not “bugs” (except the inconsistent behavior of Facebook, which is not really UTM-related). It’s just a standard that have lots of limitations.
The issues not being bugs does not help anything.
USE YOUR OWN NON-UTM PARAMETERS
Remember, UTMs are just normal querystring parameters. They are technically not special. Therefore, you can use your own parameters.
Example: example.com/my-page/?my_custom_tracking_parameter=facebook&utm_source=some-new-value
In the above, my_custom_tracking_parameter can whatever you want it to be as long as it makes sense to you.
You can have filters in Google Analytics (and other analytics software) to give you exactly the same insights as utm_source (or any other UTM-parameter).
You can also use as many different parameters as you want, for example: example.com/my-page/?customer_service_id=AlexS
Facebook’s fbclid, Google’s gclid and Pinterest’s epik are all custom tracking parameters. These will be filtered out in iOS17 because these are known custom parameters, meaning, Apple can intentionally target FB and Google to corrupt tracking.
Facebook et al could start using parameter names that are constantly change. I will not dig into how this can be done, but it can. I personally don’t see how Apple will benefit anything in the long run from these filtering without risking to filter out non-tracking parameters.
CAREFUL WITH YOUR CHOICE OF CUSTOM PARAMETERS!
Choosing custom tracking parameters assumed that you know exactly which parameters your website is currently using so you don’t set them by accident.
For example: example.com/my-page/?origin=Facebook
Maybe, just maybe, your system is already using origin as a part of your product filtering function where “origin” might refer to where the product is made.
So you might want to use origin=Facebook for tracking purposes, but then your system interprets that as “Show products made in country named Facebook”. Amount products shown in this situation? Maybe zero with a nasty “Sorry, we don’t have product that match your criteria!”
The same goes for custom platform parameters such as fbclid, gclid and others.
Unless you know your system inside and out, or even built it yourself *cough cough*, you might not feel comfortable using custom parameters. If you feel unsure, I would recommend “custom UTMs”.
CUSTOM UTMS
One of the reasons for using UTM’s utm_* syntax is to have a standard that will allow 3rd parties to add parameters, but in such way that it will not risk overriding a parameter that the website is using for some function.
For example: example.com/my-page/?search=something
Thanks to the acceptance of UTM you can be pretty sure that it’s unlikely that 3rd party will add/replace the search parameter to their links leading to your website.
Since UTM’s utm_* syntax is unrecognizable, I believe it’s safe to assume that programmers won’t use many, if any at all, parameters starting with utm_. Therefore, creating your custom parameters but adding utm_ as a prefix will lower the risk of “clashes” and potential overrides in the future.
Example: utm_my_custom_tracking_parameter
Again, don’t let the utm_ part fool you, the above is still just a querystring parameter like any other.
Using utm_ is just a way to differentiate your custom tracking parameters from critical parameters in a way that most will recognize.
If you see utm_country then you know, because it start with utm_, it’s likely a tracking parameter. You can’t say the same about using country. It’s a bit like a + in the beginning of phone numbers, most know that this signify that it’s an international number.
PARAMETERS FOR TRACKING WITHIN YOUR WEBSITE
Using utm_source within your own website is a big no-no. If you do, you are essentially resetting the source of the traffic to your own website. This risks to seriously screw with you statistics. Any conversion after an internal link containing utm_source would make it seem that the source of the traffic is, well, your site.
How about this instead: utm_internal_source where internal_ is a way to keep a very recognizable syntax but you yourself know that these are custom UTMs for internal traffic tracking only.
WRAP UP
- Never use UTMs for anything you deem critical.
- UTM parameters are not magical nor special.
- Don’t blindly rely on UTM working and stay unaltered.
- Use only custom tracking parameters if you are sure you are not overriding existing. If unsure use “custom” UTMs.
- Never use standard UTMs for internal tracking.
- Don’t rely on Facebook to properly add URL Parameters to Website URL.
- Except Facebook and Google to start using randomized parameters to get around Apple’s filtering attempts.
***
All this based on experience and occasionally going mad over issues relating to parameters, since 1998.
Some of these things are opinionated, mostly the usage of custom UTMs for internal tracking.
I am sure some people won’t agree with me, and that is totally fine. I am not claiming I know best or that I can’t be wrong about something.