Firefox et Brave suppriment-ils les paramètres UTM ?

Réponse courte : Firefox supprime bien des paramètres de requête, mais la liste de la version stable documentée par Mozilla se compose surtout d'identifiants publicitaires et d'e-mail comme fbclid et mkt_tok. Vos balises utm_source et utm_campaign n'y figurent pas. Si les données de campagne disparaissent, la cause est plus souvent un script bloqué, un consentement refusé ou une destination qui abandonne la chaîne de requête.

Cela corrige l'affirmation par laquelle cet article s'ouvrait autrefois, et c'est important : si vous accusez le mauvais mécanisme, vous corrigez la mauvaise chose. Voici ce que chaque navigateur documente, ce que vous devez tester vous-même, et où se situe réellement la perte. Pour les balises elles-mêmes, voyez les paramètres UTM expliqués. Pour les limites de stockage et de cookies, voyez l'attribution des clics après Safari ITP.

Ce que chaque navigateur documente

Tout ce qui suit provient des pages des éditeurs, consultées le 2026-10-24. Quand une page ne le disait pas, je le dis au lieu de deviner.

Firefox. La documentation de Mozilla sur la suppression des paramètres de requête indique qu'elle est activée en version stable dans la protection renforcée contre le pistage en mode Strict, avec une liste initiale de paramètres : mc_eid, oly_anon_id, oly_enc_id, __s, vero_id, _hsenc, mkt_tok et fbclid. Les fenêtres de navigation privée ne sont pas couvertes par défaut ; Mozilla dit y réfléchir et une préférence existe. Nightly utilise une liste étendue conservée dans Remote Settings, que cette page ne reproduit pas. Aucun paramètre utm_ n'apparaît dans la liste de la version stable.

Safari. WebKit décrit la Link Tracking Protection comme une partie de la navigation privée, qui retire avant la navigation un sous-ensemble de paramètres de requête identifiant un pistage intersite. Les mêmes protections s'appliquent à la navigation normale lorsqu'un utilisateur active le réglage avancé de pistage et d'empreinte numérique pour toute la navigation. WebKit indique que des paramètres d'attribution comme campaign sont autorisés à passer. Il ne nomme pas les balises utm_, ni dans un sens ni dans l'autre.

Brave. Le filtre de chaîne de requête de Brave comporte des règles simples, conditionnelles et à portée limitée. Le seul paramètre que son wiki nomme est mkt_tok, retiré sauf sur les URL de désabonnement. La liste complète se trouve dans brave-core, et je n'ai pas pu confirmer, d'après les pages que j'ai lues, si une balise utm_ y figure. Je n'ai pas non plus pu confirmer le comportement de Brave envers GA4 d'après la documentation de l'éditeur, donc je n'en affirme aucun.

Alors, où vont les données UTM ?

Trois causes expliquent l'essentiel, et aucune n'est "le navigateur a supprimé mes balises".

1. L'hôte de destination abandonne la chaîne de requête. Une redirection de barre oblique finale ou une règle d'hébergement peut éliminer tout ce qui suit le point d'interrogation. Pourquoi les paramètres UTM n'apparaissent pas dans GA4 parcourt cet arbre de décision.
2. Le script d'analytique ne s'exécute pas. La protection contre le pistage et les extensions bloquent les domaines d'analytique connus. Les balises sont dans l'URL ; rien ne les lit.
3. Le consentement a été refusé. Même effet, autre raison. L'écart entre clics et sessions décrit dans Clics sur lien court vs sessions GA4 tient surtout à cela, plus les bots et les sessions fusionnées.

Les identifiants de clic sont la vraie victime. fbclid figure sur la liste de suppression de Firefox : les identifiants de clic destinés à Meta peuvent donc disparaître en mode Strict même si vos UTM survivent. C'est important si vous comptez sur les identifiants de clic pour le rapprochement avec les plateformes publicitaires. Les identifiants de clic expliqués indique quelles plateformes utilisent lesquels.

Testez sur vos propres liens

Ne faites pas confiance à un article de blog, celui-ci compris, pour une liste qui change d'une version à l'autre. Cela prend cinq minutes.

1. Créez un lien court vers une page que vous contrôlez, avec ?utm_source=test&utm_medium=test&utm_campaign=check&fbclid=abc&mkt_tok=xyz sur la destination.
2. Ouvrez-le dans Firefox avec la protection Strict, dans la navigation privée de Safari, dans Brave et dans Chrome.
3. Lisez la barre d'adresse finale dans chacun. Ce qui manque est ce que ce navigateur supprime ce jour-là.
4. Recommencez après chaque mise à jour majeure d'un navigateur, car les listes s'allongent.

Pourquoi la mauvaise histoire se répand

"Les navigateurs suppriment les UTM" est une explication bien rangée, donc on la répète. C'est aussi une explication difficile à réfuter depuis un rapport GA4, car une campagne manquante a le même aspect quelle que soit la cause. Une session classée en direct ou non attribuée peut signifier une balise supprimée, une redirection qui a abandonné la chaîne de requête, ou une application qui n'a jamais envoyé de référent.

Ces cas diffèrent par ce que vous pouvez corriger. Un hôte qui abandonne la chaîne de requête se règle d'une ligne côté serveur. Un script bloqué échappe à votre contrôle, tout comme une demande de consentement refusée. Les identifiants de clic supprimés ne comptent que si vous avez bâti vos rapports dessus. Mettre les quatre dans le même sac "navigateurs axés sur la confidentialité" vous envoie au mauvais endroit, et c'est pourquoi le test ci-dessus vaut mieux que n'importe quel pourcentage que je pourrais citer. Je n'en donne volontairement aucun : les chiffres qui circulent sur la part des navigateurs axés sur la confidentialité viennent d'enquêtes d'éditeurs aux définitions différentes, et votre audience n'est pas l'audience moyenne.

Lire votre propre répartition par navigateur

Une fois le test réalisé, chiffrez votre propre trafic. Dans GA4, répartissez les sessions par navigateur pour une campagne et comparez avec le nombre de clics sur lien court de cette campagne aux mêmes dates.

• Le ratio sessions/clics de Chrome est la référence. Il porte les pertes habituelles dues aux scanners, aux bots et aux abandons.
• Un ratio nettement plus bas dans Firefox ou Safari pointe vers le blocage de scripts ou le consentement, puisque la seule suppression des UTM n'éliminerait pas la session, seulement son étiquette de campagne.
• Un ratio normal mais une part élevée de direct ou de non attribué dans un navigateur pointe vers des balises ou des identifiants de clic perdus, pas vers une balise qui ne se charge pas.

Ce second schéma est celui qui vaut la peine d'être poursuivi, et c'est le seul où une fonction du navigateur a réellement retiré quelque chose que vous aviez envoyé. Tout le reste est un problème de visibilité que l'on gère avec une référence, pas un bug que l'on corrige. Si vos clics et vos sessions diffèrent déjà pour des raisons sans rapport avec les navigateurs, réglez d'abord celles-ci avec la routine d'un après-midi de l'article sur clics et sessions.

Enregistrer le clic avant que le navigateur n'y touche

Quoi que fasse chaque navigateur, il le fait sur la page d'atterrissage. Un lien court est résolu à la redirection et journalise le clic en premier : ce que le navigateur supprime ou bloque ensuite ne peut pas changer le fait que le clic a eu lieu.

Dans Elido, la redirection edge écrit l'événement de clic (lien, heure, pays et appareil) au moment où la réponse est envoyée, et les robots d'exploration et bots d'aperçu connus ne sont pas comptés. Les événements de clic peuvent ensuite être transférés vers GA4 et d'autres outils, ce que couvre le suivi GA4 côté serveur via les redirections.

La limite est réelle : cela rétablit le décompte d'acquisition, c'est-à-dire qu'un clic a eu lieu et sur quel lien. Cela ne rétablit pas la session sur la page, les événements ni la conversion si la balise était bloquée. Pour le revenu, attribuez les commandes à un lien côté serveur, comme dans suivre les campagnes UTM de bout en bout.

Que faire

• Gardez vos UTM. Les listes documentées ne les visent pas.
• Traitez les identifiants de clic comme fbclid comme sujets à pertes, et ne bâtissez pas de rapports qui en dépendent.
• Refaites le test de cinq minutes ci-dessus après les mises à jour de navigateurs.
• Enveloppez les liens de campagne dans un lien court balisé pour que le clic soit compté à la redirection. L'analytique de liens d'Elido affiche ces décomptes par campagne.
• Rapprochez les clics des sessions GA4 par campagne et par navigateur, et suivez le ratio dans le temps.

Lire la série de référence

Cet article fait partie du cluster ingénierie. Commencez par suivre les campagnes UTM de bout en bout pour le pipeline complet.

Sur le même sujet

• L'attribution des clics après Safari ITP
• Les paramètres UTM expliqués : le guide complet
• Clics sur liens courts vs sessions GA4
• Les identifiants de clic expliqués : gclid, fbclid, ttclid et msclkid
• L'attribution sans cookies expliquée
• Paramètres UTM absents de GA4 : causes et solutions