Firefox e Brave Eliminano i Parametri UTM? Cosa Sopravvive

Risposta breve: Firefox elimina davvero dei parametri di query, ma la lista di release documentata da Mozilla è composta soprattutto da identificatori pubblicitari e di email come fbclid e mkt_tok. I tuoi tag utm_source e utm_campaign non ci sono. Se i dati di campagna spariscono, la causa è più spesso uno script bloccato, un consenso negato o una destinazione che elimina la query string.

Questo corregge l'affermazione con cui questo articolo si apriva in passato, ed è importante, perché se incolpi il meccanismo sbagliato correggi la cosa sbagliata. Ecco cosa documenta ciascun browser, cosa provare in prima persona e dove si trova davvero la perdita. Per i tag in sé, vedi i parametri UTM spiegati. Per i limiti di storage e cookie, vedi l'attribuzione dei clic dopo Safari ITP.

Cosa Documenta Ciascun Browser

Tutto quanto segue proviene dalle pagine dei vendor, consultate il 2026-10-24. Dove una pagina non lo diceva, lo dico invece di tirare a indovinare.

Firefox. La documentazione sul query stripping di Mozilla dice che è abilitato in release in Enhanced Tracking Protection Strict, con una lista iniziale di parametri: mc_eid, oly_anon_id, oly_enc_id, __s, vero_id, _hsenc, mkt_tok e fbclid. Le finestre di navigazione privata non sono coperte per impostazione predefinita; Mozilla dice che sta valutando la cosa ed esiste una preferenza. Nightly usa una lista estesa conservata in Remote Settings, che quella pagina non riporta. Nessun parametro utm_ compare nella lista di release.

Safari. WebKit descrive Link Tracking Protection come parte della navigazione privata, che rimuove prima della navigazione un sottoinsieme di parametri di query che identificano il tracciamento cross-site. Le stesse protezioni valgono per la navigazione normale quando l'utente abilita l'impostazione avanzata di tracciamento e fingerprinting per tutta la navigazione. WebKit dice che parametri di attribuzione come campaign possono passare. Non nomina i tag utm_ in un senso né nell'altro.

Brave. Il filtro delle query string di Brave ha regole semplici, condizionali e con ambito. L'unico parametro nominato nella sua wiki è mkt_tok, rimosso tranne che negli URL di annullamento dell'iscrizione. La lista completa sta in brave-core, e dalle pagine che ho letto non ho potuto confermare se un tag utm_ ne faccia parte. Non ho nemmeno potuto confermare dalla documentazione del vendor il comportamento di Brave verso GA4, quindi non ne dichiaro uno.

Quindi Dove Vanno a Finire i Dati UTM?

Tre cause spiegano la maggior parte dei casi, e nessuna è "il browser ha cancellato i miei tag".

1. L'host di destinazione elimina la query string. Un redirect con slash finale o una regola dell'hosting può scartare tutto ciò che segue il punto interrogativo. Perché i parametri UTM non compaiono in GA4 percorre questo albero decisionale.
2. Lo script di analytics non viene eseguito. La protezione dal tracciamento e le estensioni bloccano i domini di analytics noti. I tag sono nell'URL; nulla li legge.
3. Il consenso è stato negato. Stesso effetto, motivo diverso. Lo scarto tra clic e sessioni in Clic sui Link Brevi vs Sessioni GA4 è soprattutto questo più bot e sessioni unite.

Le vere vittime sono gli identificatori di clic. fbclid è nella lista di Firefox, quindi gli ID di clic destinati a Meta possono sparire in modalità Strict anche quando i tuoi UTM sopravvivono. Conta se ti affidi agli ID di clic per l'abbinamento con le piattaforme pubblicitarie. Gli ID di clic spiegati spiega quali piattaforme usano quali.

Provalo sui Tuoi Link

Non fidarti di un articolo di blog, questo compreso, per una lista che cambia tra le versioni. Bastano cinque minuti.

1. Crea un link breve verso una pagina che controlli, con ?utm_source=test&utm_medium=test&utm_campaign=check&fbclid=abc&mkt_tok=xyz sulla destinazione.
2. Aprilo in Firefox con protezione Strict, in Safari in navigazione privata, in Brave e in Chrome.
3. Leggi la barra degli indirizzi finale in ciascuno. Ciò che manca è ciò che quel browser elimina in quel giorno.
4. Ripeti dopo un aggiornamento importante del browser, dato che le liste crescono.

Perché Si Diffonde la Storia Sbagliata

"I browser eliminano gli UTM" è una spiegazione ordinata, quindi viene ripetuta. È anche difficile da smentire dall'interno di un report GA4, perché una campagna mancante appare uguale chiunque l'abbia rimossa. Una sessione archiviata come direct o non assegnata può significare un tag eliminato, un redirect che ha perso la query string o un'app che non ha mai inviato un referrer.

I casi differiscono per ciò che puoi correggere. Un host che elimina la query string è una modifica di una riga sul server. Uno script bloccato è fuori dal tuo controllo, e lo è anche un prompt di consenso negato. Gli ID di clic eliminati contano solo se hai costruito i report su di essi. Mettere i quattro insieme come "browser orientati alla privacy" ti manda nel posto sbagliato, ed è per questo che la prova sopra vale più di qualsiasi percentuale potrei citare. Non ne do una di proposito: le cifre che circolano sulla quota dei browser orientati alla privacy vengono da sondaggi di vendor con definizioni diverse, e il tuo pubblico non è quello medio.

Leggere la Tua Suddivisione per Browser

Dopo aver eseguito la prova, metti dei numeri sul tuo traffico. In GA4, suddividi le sessioni per browser per una campagna e confrontale con il conteggio dei clic del link breve per quella campagna nelle stesse date.

• Il rapporto sessioni/clic di Chrome è la baseline. Porta con sé le solite perdite di scanner, bot e abbandono.
• Un rapporto nettamente più basso in Firefox o Safari indica blocco degli script o consenso, dato che il solo stripping degli UTM non rimuoverebbe la sessione, solo la sua etichetta di campagna.
• Un rapporto normale ma una quota alta di direct o non assegnato in un browser indica tag o ID di clic persi, non un tag che non si carica.

Quel secondo schema è quello che vale la pena inseguire, ed è l'unico in cui una funzione del browser ha davvero rimosso qualcosa che avevi inviato. Tutto il resto è un problema di visibilità che gestisci con una baseline, non un bug da correggere. Se i tuoi clic e le tue sessioni differiscono già per ragioni non legate ai browser, risolvi prima quelle con la routine del pomeriggio nell'articolo su clic contro sessioni.

Registra il Clic Prima che il Browser Lo Tocchi

Qualunque cosa faccia ciascun browser, la fa sulla landing page. Un link breve si risolve al redirect e registra prima il clic, quindi ciò che il browser elimina o blocca dopo non può cambiare il fatto che il clic sia avvenuto.

In Elido il redirect edge scrive l'evento di clic (link, ora, paese e dispositivo) mentre la risposta viene inviata, e i crawler e i bot di anteprima noti non vengono contati. Gli eventi di clic possono poi essere inoltrati a GA4 e ad altri strumenti, come spiega il tracking GA4 lato server tramite redirect.

Il limite è reale: questo recupera il conteggio dell'acquisizione, cioè che un clic è avvenuto e di quale link. Non recupera la sessione sulla pagina, gli eventi o la conversione se il tag è stato bloccato. Per i ricavi, attribuisci gli ordini a un link lato server, come in tracciare le campagne UTM da un capo all'altro.

Cosa Fare

• Mantieni i tuoi UTM. Le liste documentate non li prendono di mira.
• Tratta gli ID di clic come fbclid come soggetti a perdite, e non costruire report che li richiedano.
• Esegui la prova di cinque minuti sopra dopo gli aggiornamenti dei browser.
• Avvolgi i link di campagna in un link breve taggato, così il clic viene contato al redirect. Le analytics dei link di Elido mostrano quei conteggi per campagna.
• Riconcilia i clic con le sessioni GA4 per campagna e per browser, e segui il rapporto nel tempo.

Leggi la Serie Cornerstone

Questo articolo fa parte del cluster engineering. Inizia con traccia le campagne UTM dall'inizio alla fine per la pipeline completa.

Correlati sul Blog

• Attribuzione dei clic dopo Safari ITP
• I parametri UTM spiegati: la guida completa
• Clic dei link brevi vs sessioni GA4
• Gli ID di clic spiegati: gclid, fbclid, ttclid e msclkid
• Attribuzione cookieless, spiegata
• Parametri UTM che non compaiono in GA4: cause e soluzioni