Czy Firefox i Brave usuwają parametry UTM? Co przetrwa

Krótka odpowiedź: Firefox usuwa parametry zapytania, ale lista wydania, którą dokumentuje Mozilla, to głównie identyfikatory reklam i e-maili, takie jak fbclid i mkt_tok. Twoich tagów utm_source i utm_campaign na niej nie ma. Jeśli dane kampanii znikają, przyczyną częściej jest zablokowany skrypt, odrzucona zgoda albo strona docelowa, która gubi ciąg zapytania.

To poprawia twierdzenie, od którego ten wpis kiedyś się zaczynał, i ma to znaczenie, bo jeśli obwinisz zły mechanizm, naprawisz złą rzecz. Oto, co dokumentuje każda przeglądarka, co przetestować samemu i gdzie naprawdę leży strata. Same tagi opisuje parametry UTM wyjaśnione. O limitach pamięci i cookies przeczytasz w atrybucji kliknięć po Safari ITP.

Co dokumentuje każda przeglądarka

Wszystko poniżej pochodzi ze stron producentów, dostęp 2026-10-24. Tam, gdzie strona czegoś nie podawała, piszę o tym zamiast zgadywać.

Firefox. Dokumentacja usuwania z ciągu zapytania Mozilli mówi, że funkcja jest włączona w wydaniu w Enhanced Tracking Protection Strict, z początkową listą parametrów: mc_eid, oly_anon_id, oly_enc_id, __s, vero_id, _hsenc, mkt_tok i fbclid. Okna Private Browsing nie są domyślnie objęte; Mozilla pisze, że rozważa to i istnieje odpowiednia preferencja. Nightly używa rozszerzonej listy przechowywanej w Remote Settings, której ta strona nie przytacza. Żaden parametr utm_ nie pojawia się na liście wydania.

Safari. WebKit opisuje Link Tracking Protection jako część Private Browsing, usuwającą przed nawigacją podzbiór parametrów zapytania identyfikujących śledzenie między witrynami. Te same zabezpieczenia obejmują zwykłe przeglądanie, gdy użytkownik włączy ustawienie zaawansowanej ochrony przed śledzeniem i fingerprintingiem dla całego przeglądania. WebKit mówi, że parametry atrybucji, takie jak campaign, mogą przechodzić. Nie wymienia tagów utm_ w żadną stronę.

Brave. Filtr ciągu zapytania Brave ma reguły proste, warunkowe i ograniczone zakresem. Jedyny parametr, który wymienia jego wiki, to mkt_tok, usuwany poza adresami wypisania z listy. Pełna lista znajduje się w brave-core i na przeczytanych stronach nie udało mi się potwierdzić, czy jakikolwiek tag utm_ na niej jest. Nie potwierdziłem też z dokumentacji producenta zachowania Brave wobec GA4, więc żadnego nie twierdzę.

Gdzie więc giną dane UTM?

Trzy przyczyny tłumaczą większość i żadna nie brzmi "przeglądarka usunęła moje tagi".

1. Host docelowy gubi ciąg zapytania. Przekierowanie z ukośnikiem na końcu lub reguła hostingu może odrzucić wszystko po znaku zapytania. Dlaczego parametry UTM nie pojawiają się w GA4 przeprowadza przez to drzewo decyzyjne.
2. Skrypt analityczny się nie uruchamia. Ochrona przed śledzeniem i rozszerzenia blokują znane domeny analityczne. Tagi są w adresie URL; nic ich nie czyta.
3. Zgoda została odrzucona. Ten sam skutek, inny powód. Różnica między kliknięciami a sesjami w kliknięciach w krótkie linki a sesjach GA4 to w większości to plus boty i połączone sesje.

Prawdziwą ofiarą są identyfikatory kliknięć. fbclid jest na liście usuwania Firefoksa, więc identyfikatory kliknięć kierowane do Meta mogą znikać w trybie Strict, nawet gdy Twoje UTM przetrwają. Ma to znaczenie, jeśli polegasz na identyfikatorach kliknięć do dopasowania w platformie reklamowej. Identyfikatory kliknięć wyjaśnione opisują, które platformy używają których.

Przetestuj to na własnych linkach

Nie ufaj wpisowi na blogu, w tym temu, jeśli chodzi o listę zmieniającą się między wersjami. Zajmuje to pięć minut.

1. Utwórz krótki link do strony, którą kontrolujesz, z ?utm_source=test&utm_medium=test&utm_campaign=check&fbclid=abc&mkt_tok=xyz w adresie docelowym.
2. Otwórz go w Firefoksie z ochroną Strict, w Safari Private Browsing, w Brave i w Chrome.
3. Odczytaj końcowy pasek adresu w każdej. Czego brakuje, to właśnie to, co ta przeglądarka usuwa danego dnia.
4. Powtórz po większej aktualizacji przeglądarki, bo listy rosną.

Dlaczego fałszywa historia się rozchodzi

"Przeglądarki usuwają UTM" to zgrabne wyjaśnienie, więc jest powtarzane. Trudno je też obalić z poziomu raportu GA4, bo brakująca kampania wygląda tak samo, bez względu na to, co ją usunęło. Sesja zaklasyfikowana jako bezpośrednia lub nieprzypisana może oznaczać usunięty tag, przekierowanie, które zgubiło ciąg zapytania, albo aplikację, która nigdy nie wysłała referrera.

Przypadki różnią się tym, co możesz naprawić. Host gubiący ciąg zapytania to jednoliniowa zmiana na serwerze. Zablokowany skrypt jest poza Twoją kontrolą, podobnie jak odrzucony baner zgody. Usunięte identyfikatory kliknięć mają znaczenie tylko wtedy, gdy zbudowałeś na nich raportowanie. Wrzucenie tych czterech do jednego worka "przeglądarki prywatności" wysyła Cię w złe miejsce, dlatego powyższy test jest wart więcej niż jakikolwiek procent, który mógłbym podać. Celowo go nie podaję: liczby krążące o udziale przeglądarek prywatności pochodzą z ankiet producentów o różnych definicjach, a Twoi odbiorcy nie są przeciętni.

Czytanie własnego podziału na przeglądarki

Gdy wykonasz test, nadaj liczby własnemu ruchowi. W GA4 podziel sesje według przeglądarki dla jednej kampanii i porównaj z liczbą kliknięć w krótki link tej kampanii z tych samych dat.

• Stosunek sesji do kliknięć w Chrome to punkt odniesienia. Niesie zwykłe straty na skanery, boty i porzucenia.
• Wyraźnie niższy stosunek w Firefoksie lub Safari wskazuje na blokowanie skryptów lub zgodę, bo samo usuwanie UTM nie usunęłoby sesji, tylko jej etykietę kampanii.
• Normalny stosunek, ale wysoki udział ruchu bezpośredniego lub nieprzypisanego w jednej przeglądarce wskazuje na gubienie tagów lub identyfikatorów kliknięć, a nie na to, że tag się nie załadował.

Ten drugi wzorzec warto ścigać i tylko w nim funkcja przeglądarki naprawdę usunęła coś, co wysłałeś. Cała reszta to problem widoczności, którym zarządzasz punktem odniesienia, a nie błąd do naprawienia. Jeśli Twoje kliknięcia i sesje już różnią się z powodów niezwiązanych z przeglądarkami, najpierw je wyjaśnij popołudniową rutyną z wpisu o kliknięciach a sesjach.

Zapisz kliknięcie, zanim przeglądarka go dotknie

Cokolwiek robi każda przeglądarka, robi to na stronie docelowej. Krótki link rozwiązuje się przy przekierowaniu i najpierw zapisuje kliknięcie, więc to, co przeglądarka usunie lub zablokuje potem, nie zmieni faktu, że kliknięcie się odbyło.

W Elido przekierowanie brzegowe zapisuje zdarzenie kliknięcia (link, czas, kraj i urządzenie) w chwili wysłania odpowiedzi, a znane roboty indeksujące i boty podglądów nie są liczone. Zdarzenia kliknięć można potem przekazywać do GA4 i innych narzędzi, co opisuje śledzenie GA4 po stronie serwera przez przekierowania.

Ograniczenie jest realne: to odzyskuje liczbę pozyskań, czyli fakt, że kliknięcie się odbyło, i który to był link. Nie odzyskuje sesji na stronie, zdarzeń ani konwersji, jeśli tag został zablokowany. Przychód przypisuj do linku po stronie serwera, jak w śledzeniu kampanii UTM od początku do końca.

Co robić

• Zachowaj swoje UTM. Udokumentowane listy ich nie dotyczą.
• Traktuj identyfikatory kliknięć, takie jak fbclid, jako stratne i nie buduj raportowania, które ich wymaga.
• Wykonuj powyższy pięciominutowy test po aktualizacjach przeglądarek.
• Opakuj linki kampanii w otagowany krótki link, żeby kliknięcie było liczone przy przekierowaniu. Analityka linków Elido pokazuje te liczby dla każdej kampanii.
• Uzgadniaj kliknięcia z sesjami GA4 dla każdej kampanii i przeglądarki oraz śledź stosunek w czasie.

Przeczytaj serię cornerstone

Ten wpis należy do klastra inżynieryjnego. Zacznij od śledzenia kampanii UTM od początku do końca, aby poznać cały potok.

Powiązane na blogu

• Atrybucja kliknięć po Safari ITP
• Parametry UTM wyjaśnione: kompletny przewodnik
• Kliknięcia w krótkie linki a sesje GA4
• Identyfikatory kliknięć: gclid, fbclid, ttclid i msclkid
• Atrybucja bez plików cookie, wyjaśniona
• Parametry UTM nie pojawiają się w GA4: przyczyny i poprawki