Kort antwoord: Firefox verwijdert wel queryparameters, maar de releaselijst die Mozilla documenteert bestaat vooral uit advertentie- en e-mailidentifiers zoals fbclid en mkt_tok. Je utm_source- en utm_campaign-tags staan er niet op. Verdwijnt campagnedata, dan is de oorzaak vaker een geblokkeerd script, geweigerde toestemming of een bestemming die de querystring laat vallen.
Dat corrigeert de bewering waarmee dit artikel vroeger opende, en het doet ertoe, want wie het verkeerde mechanisme de schuld geeft, repareert het verkeerde. Hier staat wat elke browser documenteert, wat je zelf moet testen en waar het verlies echt zit. Voor de tags zelf zie UTM-parameters uitgelegd. Voor opslag- en cookielimieten zie klikattributie na Safari ITP.
Wat elke browser documenteert
Alles hieronder komt van pagina's van de aanbieders, geraadpleegd op 2026-10-24. Waar een pagina iets niet zei, zeg ik dat in plaats van te gokken.
Firefox. De documentatie over query stripping van Mozilla zegt dat het in de release is ingeschakeld in Enhanced Tracking Protection Strict, met een eerste lijst parameters: mc_eid, oly_anon_id, oly_enc_id, __s, vero_id, _hsenc, mkt_tok en fbclid. Privévensters vallen standaard niet onder de bescherming; Mozilla zegt dat het dat overweegt en dat er een voorkeursinstelling bestaat. Nightly gebruikt een uitgebreide lijst in Remote Settings, die die pagina niet weergeeft. In de releaselijst staat geen utm_-parameter.
Safari. WebKit beschrijft Link Tracking Protection als onderdeel van Privé-browsen, dat voor de navigatie een deel van de queryparameters verwijdert die cross-site tracking identificeren. Dezelfde beschermingen gelden voor gewoon browsen wanneer een gebruiker de geavanceerde instelling voor tracking en fingerprinting voor al het browsen aanzet. WebKit zegt dat toewijzingsparameters zoals campaign mogen doorkomen. Het noemt utm_-tags in geen van beide richtingen.
Brave. Het querystringfilter van Brave kent eenvoudige, voorwaardelijke en afgebakende regels. De ene parameter die de wiki noemt, is mkt_tok, dat wordt verwijderd behalve op uitschrijf-URL's. De volledige lijst staat in brave-core en ik kon uit de pagina's die ik las niet bevestigen of er een utm_-tag op staat. Ook het gedrag van Brave tegenover GA4 kon ik niet uit documentatie van de aanbieder bevestigen, dus daar zeg ik niets over.
Waar blijft de UTM-data dan?
Drie oorzaken verklaren het meeste, en geen daarvan is "de browser heeft mijn tags gewist".
- De bestemmingshost laat de querystring vallen. Een redirect met een slash aan het eind of een hostingregel kan alles na het vraagteken weggooien. Waarom UTM-parameters niet in GA4 verschijnen doorloopt deze beslisboom.
- Het analyticsscript draait niet. Trackingbescherming en extensies blokkeren bekende analyticsdomeinen. De tags staan in de URL; niets leest ze.
- Toestemming is geweigerd. Zelfde effect, andere reden. Het verschil tussen klikken en sessies in Klikken op korte links vs GA4-sessies komt grotendeels hierdoor plus bots en samengevoegde sessies.
De klik-ID's zijn het echte slachtoffer. fbclid staat op de striplijst van Firefox, dus klik-ID's richting Meta kunnen in de Strict-modus verdwijnen terwijl je UTM's blijven staan. Dat doet ertoe als je op klik-ID's vertrouwt om advertentieplatforms te koppelen. Klik-ID's uitgelegd behandelt welke platforms welke gebruiken.
Test het op je eigen links
Vertrouw niet op een blogartikel, dit ook niet, voor een lijst die tussen versies verandert. Het kost vijf minuten.
- Maak een korte link naar een pagina die je beheert, met
?utm_source=test&utm_medium=test&utm_campaign=check&fbclid=abc&mkt_tok=xyzop de bestemming. - Open hem in Firefox met Strict-bescherming, in Safari Privé-browsen, in Brave en in Chrome.
- Lees in elk de uiteindelijke adresbalk. Wat ontbreekt, is wat die browser die dag verwijdert.
- Herhaal na een grote browserupdate, want lijsten groeien.
Waarom het verkeerde verhaal zich verspreidt
"Browsers verwijderen UTM's" is een nette verklaring, dus wordt hij herhaald. Hij is ook moeilijk te weerleggen vanuit een GA4-rapport, want een ontbrekende campagne ziet er hetzelfde uit, wat hem ook heeft verwijderd. Een sessie onder direct of niet-toegewezen kan een weggehaalde tag betekenen, een redirect die de querystring liet vallen of een app die nooit een referrer stuurde.
De gevallen verschillen in wat je kunt oplossen. Een host die de querystring laat vallen is een server-aanpassing van één regel. Een geblokkeerd script valt buiten je controle, net als een geweigerde toestemmingsprompt. Weggehaalde klik-ID's tellen alleen als je rapportage erop hebt gebouwd. Ze alle vier op één hoop gooien als "privacybrowsers" stuurt je naar de verkeerde plek, en daarom is de test hierboven meer waard dan elk percentage dat ik zou kunnen noemen. Ik geef er bewust geen: de cijfers voor het marktaandeel van privacybrowsers die rondgaan, komen uit peilingen van aanbieders met verschillende definities, en jouw publiek is niet het gemiddelde.
Je eigen browserverdeling lezen
Heb je de test gedraaid, geef je eigen verkeer dan cijfers. Splits in GA4 de sessies van één campagne op browser en vergelijk ze met het aantal klikken op de korte link voor die campagne over dezelfde datums.
- De verhouding sessies tot klikken in Chrome is de nulmeting. Daar zitten de gebruikelijke verliezen door scanners, bots en afhakers in.
- Een duidelijk lagere verhouding in Firefox of Safari wijst op scriptblokkering of toestemming, want UTM-stripping alleen zou de sessie niet weghalen, alleen het campagnelabel.
- Een normale verhouding maar een hoog aandeel direct of niet-toegewezen in één browser wijst op verloren tags of klik-ID's en niet op een tag die niet laadt.
Dat tweede patroon is het patroon om achteraan te gaan, en het enige waarbij een browserfunctie echt iets heeft verwijderd wat jij stuurde. Al het andere is een zichtbaarheidsprobleem dat je met een nulmeting beheert, geen bug die je repareert. Verschillen je klikken en sessies al om redenen die niets met browsers te maken hebben, los die dan eerst op met de middagroutine in het artikel over klikken versus sessies.
Registreer de klik voordat de browser eraan komt
Wat elke browser ook doet, hij doet het op de landingspagina. Een korte link wordt bij de redirect afgehandeld en logt eerst de klik, dus wat de browser daarna verwijdert of blokkeert, verandert niets aan het feit dat de klik is gebeurd.
Bij Elido schrijft de edge-redirect het klikevent (link, tijd, land en apparaat) weg terwijl het antwoord wordt verstuurd, en bekende crawlers en previewbots worden niet meegeteld. Klikevents kunnen daarna worden doorgestuurd naar GA4 en andere tools, wat server-side tracking in GA4 via redirects behandelt.
De grens is echt: dit herstelt het aantal binnengekomen bezoeken, dus dat er een klik was en welke link het was. Het herstelt de sessie op de pagina, events of conversie niet als de tag was geblokkeerd. Wijs voor omzet bestellingen server-side aan een link toe, zoals in UTM-campagnes meten van begin tot eind.
Wat je doet
- Behoud je UTM's. De gedocumenteerde lijsten mikken er niet op.
- Beschouw klik-ID's als
fbclidals lekkend en bouw geen rapportage die ze nodig heeft. - Draai de test van vijf minuten hierboven na browserupdates.
- Verpak campagnelinks in een getagde korte link, zodat de klik bij de redirect wordt geteld. De linkanalytics van Elido toont die aantallen per campagne.
- Stem klikken af op GA4-sessies per campagne en per browser en volg de verhouding in de tijd.
Lees de cornerstone-reeks
Dit artikel hoort bij het engineering-cluster. Begin met UTM-campagnes meten van begin tot eind voor de volledige pijplijn.
Verwant op de blog
Veelgestelde vragen
Verwijdert Firefox UTM-parameters?
Standaard niet, volgens de releaselijst die Mozilla documenteert. Query stripping staat aan in de Strict-modus en verwijdert een korte lijst identifiers: mc_eid, oly_anon_id, oly_enc_id, __s, vero_id, _hsenc, mkt_tok en fbclid. utm_-parameters staan niet op die eerste lijst, dus een getagde link komt normaal intact aan. Mozilla zegt ook dat de lijst kan groeien, dus test in je eigen browser.
Verwijdert Brave UTM-parameters?
Brave verwijdert enkele bekende trackingparameters via een queryfilter, en sommige regels zijn voorwaardelijk, zoals mkt_tok, dat op uitschrijfpagina's blijft staan. Uit openbare documentatie kon ik niet bevestigen of utm_-tags op de filterlijst staan, dus beschouw het als onbekend en test in de huidige versie.
Verwijdert Safari UTM-parameters?
De Link Tracking Protection van Safari verwijdert een deel van de queryparameters die als cross-site trackers zijn aangemerkt, in Privé-browsen, en bij gewoon browsen als de gebruiker geavanceerde bescherming voor al het browsen aanzet. WebKit zegt dat parameters voor campagnetoewijzing mogen doorkomen, en het bericht noemt utm_-tags niet.
Waarom ontbreekt mijn UTM-data dan bij sommige bezoekers?
Meestal door iets anders dan stripping. De bestemmingshost laat de querystring vallen, de analyticstag wordt geblokkeerd of toestemming is geweigerd. Elk laat de klik echt, en de sessie of campagne ontbreekt in GA4.
Hoe meet ik campagnes als de tag of de URL-parameters verloren gaan?
Registreer de klik bij de redirect, voordat de landingspagina laadt. Een korte link legt de klik en de bestemming server-side vast, dus noch de verwerking van parameters noch het blokkeren van scripts op de pagina kan hem wissen. Het herstelt het aantal binnengekomen bezoeken, niet het gedrag op de pagina.
Hoe meet ik hoeveel ik kwijtraak aan privacybrowsers?
Vergelijk klikken op korte links met GA4-sessies per campagne en splits GA4 daarna op browser. Een groot verschil in Firefox of Safari maar niet in Chrome wijst op blokkeren of toestemming en niet op een kapotte link. Bouw de nulmeting over een paar weken op.
Probeer Elido
Plak een URL, krijg een werkende korte link
Geen aanmelding nodig. Link blijft 30 dagen actief. Meld je aan om hem voor altijd te bewaren.
Geen account nodig. Meld je gratis aan voor 50 links per maand.