Elimină Firefox și Brave parametrii UTM? Ce supraviețuiește

Răspuns scurt: Firefox chiar elimină parametri de query, dar lista de versiune documentată de Mozilla conține mai ales identificatori de reclame și de email, precum fbclid și mkt_tok. Tag-urile tale utm_source și utm_campaign nu sunt pe ea. Dacă datele de campanie dispar, cauza este mai des un script blocat, consimțământul refuzat sau o destinație care aruncă query string-ul.

Asta corectează afirmația cu care începea acest articol și contează, fiindcă dacă dai vina pe mecanismul greșit repari lucrul greșit. Iată ce documentează fiecare browser, ce să testezi singur și unde se află de fapt pierderea. Pentru tag-urile în sine, vezi parametrii UTM explicați. Pentru limitele de stocare și cookie-uri, vezi atribuirea clicurilor după Safari ITP.

Ce documentează fiecare browser

Tot ce urmează provine din paginile furnizorilor, accesate la 2026-10-24. Unde o pagină nu spunea, o spun, în loc să ghicesc.

Firefox. Documentația Mozilla despre eliminarea parametrilor din query spune că funcția este activă în versiunea de release, în Enhanced Tracking Protection Strict, cu o listă inițială de parametri: mc_eid, oly_anon_id, oly_enc_id, __s, vero_id, _hsenc, mkt_tok și fbclid. Ferestrele Private Browsing nu sunt acoperite implicit; Mozilla spune că se gândește la asta și există o preferință. Nightly folosește o listă extinsă, ținută în Remote Settings, pe care pagina aceea nu o reproduce. Niciun parametru utm_ nu apare în lista de versiune.

Safari. WebKit descrie Link Tracking Protection ca parte din Private Browsing, care elimină înainte de navigare un subset de parametri de query ce identifică urmărirea cross-site. Aceleași protecții se aplică navigării obișnuite când un utilizator activează setarea avansată de urmărire și fingerprinting pentru toată navigarea. WebKit spune că parametrii de atribuire, precum campaign, au voie să treacă. Nu numește tag-urile utm_ în niciun sens.

Brave. Filtrul de query string al Brave are reguli simple, condiționate și cu domeniu limitat. Singurul parametru pe care îl numește wiki-ul lor este mkt_tok, eliminat cu excepția URL-urilor de dezabonare. Lista completă se află în brave-core și nu am putut confirma din paginile citite dacă vreun tag utm_ figurează pe ea. Nu am putut confirma nici comportamentul Brave față de GA4 din documentația furnizorului, așa că nu afirm unul.

Deci unde se duc datele UTM?

Trei cauze explică cea mai mare parte, și nici una nu este "browserul mi-a șters tag-urile".

1. Gazda destinației aruncă query string-ul. O redirecționare pentru slash final sau o regulă de hosting poate arunca tot ce urmează după semnul întrebării. De ce nu apar parametrii UTM în GA4 parcurge acest arbore de decizie.
2. Scriptul de analytics nu rulează. Protecția la urmărire și extensiile blochează domeniile cunoscute de analytics. Tag-urile sunt în URL; nimic nu le citește.
3. Consimțământul a fost refuzat. Același efect, alt motiv. Diferența dintre clicuri și sesiuni din Clicurile linkurilor scurte vs sesiunile GA4 este în mare parte aceasta, plus boți și sesiuni unite.

Identificatorii de click sunt adevărata victimă. fbclid este pe lista de eliminare a Firefox, deci ID-urile de click către Meta pot dispărea în modul Strict chiar dacă UTM-urile tale supraviețuiesc. Contează dacă te bazezi pe ID-urile de click pentru potrivirea cu platformele de reclame. ID-urile de click explicate arată ce platforme folosesc ce.

Testează pe propriile linkuri

Nu te baza pe un articol de blog, inclusiv acesta, pentru o listă care se schimbă între versiuni. Durează cinci minute.

1. Fă un link scurt către o pagină pe care o controlezi, cu ?utm_source=test&utm_medium=test&utm_campaign=check&fbclid=abc&mkt_tok=xyz pe destinație.
2. Deschide-l în Firefox cu protecție Strict, în Safari Private Browsing, în Brave și în Chrome.
3. Citește bara de adrese finală în fiecare. Ce lipsește este ceea ce elimină acel browser în acea zi.
4. Repetă după o actualizare majoră de browser, fiindcă listele cresc.

De ce se răspândește povestea greșită

"Browserele elimină UTM-urile" este o explicație ordonată, așa că se repetă. Este și una greu de infirmat din interiorul unui raport GA4, fiindcă o campanie lipsă arată la fel indiferent ce a eliminat-o. O sesiune încadrată la direct sau neatribuită poate însemna un tag eliminat, o redirecționare care a aruncat query string-ul sau o aplicație care nu a trimis niciodată un referrer.

Cazurile diferă prin ce poți repara. O gazdă care aruncă query string-ul este o schimbare de o linie pe server. Un script blocat este în afara controlului tău, la fel ca un prompt de consimțământ refuzat. ID-urile de click eliminate contează doar dacă ți-ai construit raportarea pe ele. Dacă le pui pe toate patru în aceeași oală, "browsere orientate spre confidențialitate", te trimiți în locul greșit, de aceea testul de mai sus valorează mai mult decât orice procent aș putea cita. Nu dau intenționat unul: cifrele care circulă despre cota browserelor de confidențialitate vin din sondaje ale furnizorilor, cu definiții diferite, iar publicul tău nu este cel mediu.

Cum citești împărțirea pe browsere a propriului trafic

După ce ai rulat testul, pune cifre pe propriul trafic. În GA4, împarte sesiunile pe browser pentru o campanie și compară-le cu numărul de clicuri ale linkului scurt pentru aceeași campanie, în aceleași date.

• Raportul dintre sesiuni și clicuri în Chrome este reperul. Poartă pierderile obișnuite din scannere, boți și abandon.
• Un raport clar mai mic în Firefox sau Safari indică blocarea scripturilor sau consimțământul, fiindcă doar eliminarea UTM nu ar scoate sesiunea, ci doar eticheta ei de campanie.
• Un raport normal, dar o cotă mare de direct sau neatribuit într-un singur browser indică tag-uri sau ID-uri de click pierdute, nu un tag care nu se încarcă.

Al doilea tipar este cel care merită urmărit și singurul în care o funcție de browser a eliminat de fapt ceva ce ai trimis. Tot restul este o problemă de vizibilitate pe care o gestionezi cu un reper, nu un bug pe care îl repari. Dacă clicurile și sesiunile tale diferă deja din motive fără legătură cu browserele, rezolvă-le mai întâi cu rutina de după-amiază din articolul despre clicuri vs sesiuni.

Înregistrează click-ul înainte ca browserul să-l atingă

Orice ar face fiecare browser, face la pagina de destinație. Un link scurt se rezolvă la redirecționare și loghează click-ul primul, deci ce elimină sau blochează browserul ulterior nu poate schimba faptul că click-ul a avut loc.

În Elido, redirecționarea de la edge scrie evenimentul de click (link, oră, țară și dispozitiv) în momentul în care se trimite răspunsul, iar crawlerele și boții de previzualizare cunoscuți nu sunt numărați. Evenimentele de click pot fi apoi redirecționate către GA4 și alte instrumente, ceea ce acoperă urmărirea server-side în GA4 prin redirecționări.

Limita e reală: asta recuperează numărul de achiziții, adică faptul că a avut loc un click și ce link a fost. Nu recuperează sesiunea de pe pagină, evenimentele sau conversia dacă tagul a fost blocat. Pentru venituri, atribuie comenzile unui link pe server, ca în urmărirea campaniilor UTM cap-coadă.

Ce să faci

• Păstrează-ți UTM-urile. Listele documentate nu le vizează.
• Tratează ID-urile de click precum fbclid ca nesigure și nu construi raportare care are nevoie de ele.
• Rulează testul de cinci minute de mai sus după actualizările de browser.
• Învelește linkurile de campanie într-un link scurt cu tag-uri, ca click-ul să fie numărat la redirecționare. Analytics-ul de linkuri Elido arată aceste numere pe campanie.
• Reconciliază clicurile cu sesiunile GA4 pe campanie și pe browser și urmărește raportul în timp.

Citește seria de articole de bază

Articolul face parte din clusterul engineering. Începe cu urmărirea campaniilor UTM cap-coadă pentru întregul pipeline.

Pe același subiect pe blog

• Atribuirea clicurilor după Safari ITP
• Parametrii UTM explicați: ghidul complet
• Clicurile linkurilor scurte vs sesiunile GA4
• ID-urile de click explicate: gclid, fbclid, ttclid și msclkid
• Atribuirea fără cookie-uri, explicată
• Parametrii UTM care nu apar în GA4: cauze și remedieri