Your UTM tracking is leaking, and privacy browsers are the cause. Firefox, in Strict mode, strips known tracking parameters out of the URL before the page even loads. Brave takes a different route to the same place: it mostly leaves the parameters alone but blocks the analytics scripts that would read them. Either way, a UTM-tagged click can arrive at your landing page with the tags gone or the script that parses them blocked - and your campaign report quietly undercounts.
This is the query-string cousin of the Safari problem. The click attribution after Safari ITP piece covers storage and cookies; this one is about the URL parameters themselves being removed or ignored, which is a different mechanism with the same symptom.
Two Browsers, Two Mechanisms, One Broken Report
It helps to be precise, because "browsers strip UTMs" is only half true.
Firefox actually strips them. Its query-parameter-stripping feature, active in Strict Enhanced Tracking Protection, checks URL parameters against a list of known tracking identifiers and removes matches before the page loads. The default list is limited but real, and it is configurable, so the set only grows. A breakdown of browser click-ID and parameter stripping shows what that looks like across browsers.
Brave mostly blocks the readers. Brave's parameter stripping is inconsistent; what it reliably does is block the analytics scripts - GA4 among them - that would read the UTMs. The parameters may survive in the URL, but nothing on the page is allowed to parse them, so the effect on your report is the same: no attribution.
Add Safari's storage limits and you have a privacy trifecta. Industry testing puts privacy browsers at roughly a fifth to a quarter of visitors, with a chunk of US traffic on browsers that block default GA4 tracking outright. That is not a rounding error in a campaign report.
Why the UTM Approach Is Structurally Exposed
The UTM model assumes two things a privacy browser can break: that the tracking parameters survive the trip to your page, and that a script on that page gets to read them. Both happen at the destination, which is exactly where the browser's privacy features operate. You are asking the tags to survive a gauntlet built specifically to remove them.
This is not a reason to abandon UTMs - they still work fine in Chrome, which is most traffic - but it is a reason not to treat the landing-page UTM as the source of truth. It is a lossy channel, and the loss is concentrated in privacy-conscious audiences you probably care about.
Record the Click Before the Browser Touches It
The reliable fix is to move the measurement earlier: capture the click at the redirect, before the destination page and its scripts ever load. A short link does exactly that. When someone clicks go.acme.com/spring, the redirect resolves server-side and records the click - campaign, destination, timestamp - and only then sends the browser onward. Firefox stripping a query parameter on the landing page, or Brave blocking a script there, happens after the click is already counted. The tracking data lived in the redirect, not in a query string the browser could remove.
The nuance to keep honest: this does not recover the on-page behaviour analytics that Brave's script-blocking also breaks - if GA4 is blocked, your session and event data on that page are still affected. What the short link recovers is the acquisition signal: that the click happened, from which campaign. For most attribution questions, that is the number that was disappearing. And it is the same server-side principle behind measuring dark social - the click is recorded where the browser's privacy layer cannot reach.
You keep your UTM parameters for the browsers that honour them, and you wrap them in a short link so the click is counted even when they are stripped. Wrap your campaign links and the privacy-browser slice stops vanishing from your reports.
What to Do
- Stop treating the landing-page UTM as the single source of truth; it is lossy by design now.
- Wrap campaign links in a tagged short link so the click is recorded server-side at the redirect.
- Reconcile short-link click totals against GA4 to estimate how much your privacy-browser loss actually is.
- Keep UTMs - they are not dead, they are just no longer sufficient on their own.
Read the Cornerstone Series
This sits in the engineering cluster. The sibling reads are click attribution after Safari ITP and, for the tags, UTM parameters explained.
Related on the Blog
Frequently asked questions
Do Firefox and Brave strip UTM parameters?
Firefox does, in Strict mode: its query-parameter-stripping feature removes known tracking parameters, including some utm_ values, from the URL before the page loads. Brave is different - it mostly does not strip the parameters, it blocks the analytics scripts (like GA4) that would read them. The end result is similar: your UTM-based attribution breaks, just by two different mechanisms.
Why is my UTM tracking data disappearing?
Privacy browsers. Firefox Strict mode strips tracking query parameters, Brave blocks the analytics scripts that parse them, and Safari has its own storage limits. Together, privacy browsers are a meaningful slice of visitors - commonly estimated around a fifth to a quarter - so a chunk of your UTM-tagged clicks arrive with the tags gone or the script that reads them blocked.
How do I track campaigns if browsers strip UTM parameters?
Record the click before the destination page loads. A short link resolves server-side at the redirect and logs the click, campaign, and destination at that moment - before any browser strips a query parameter or blocks a script on the landing page. The tracking data is in the redirect, not in a query string the browser can remove.
Does stripping UTM parameters affect all browsers?
Not equally. Chrome does not strip by default, so most traffic still carries UTMs. Firefox (Strict), Brave, and Safari are where the loss concentrates. Because their combined share is large enough to distort a campaign report, the safe assumption is that a non-trivial fraction of every campaign's clicks are under-measured if you rely only on landing-page UTMs.
Is server-side tracking the answer to UTM stripping?
Recording the click server-side at a redirect is the most reliable answer, yes. It captures the click before the browser touches the destination URL or its scripts, so parameter stripping and script blocking cannot erase it. It does not de-anonymise anyone; it just moves the measurement to a point the browser's privacy features do not reach.
Try Elido
Paste a URL, get a working short link
No signup. Link lives for 30 days. Sign up to keep it forever.
Free, no signup required · 2 per day