Чи прибирають Firefox і Brave UTM-параметри? Що вціліє

Коротко: Firefox справді прибирає параметри запиту, але релізний список, який документує Mozilla, - це здебільшого ідентифікатори реклами та email, як-от fbclid і mkt_tok. Ваших тегів utm_source і utm_campaign там немає. Якщо дані кампанії зникають, причиною частіше є заблокований скрипт, відхилена згода або призначення, що відкидає рядок запиту.

Це виправляє твердження, з якого ця стаття раніше починалася, і це важливо, бо якщо звинуватити не той механізм, виправляти доведеться не те. Нижче - що документує кожен браузер, що перевірити самостійно і де насправді лежать втрати. Самі теги описано в UTM-параметри: пояснення. Про обмеження сховища й cookie дивіться атрибуція кліків після Safari ITP.

Що документує кожен браузер

Усе нижче взято зі сторінок вендорів, дата звернення 2026-10-24. Там, де сторінка нічого не казала, я так і пишу, а не вгадую.

Firefox. Документація Mozilla про очищення запиту каже, що в релізі воно ввімкнене в суворому режимі Enhanced Tracking Protection, з початковим списком параметрів: mc_eid, oly_anon_id, oly_enc_id, __s, vero_id, _hsenc, mkt_tok і fbclid. Вікна приватного перегляду за замовчуванням не охоплені; Mozilla каже, що розглядає це, і відповідне налаштування існує. Nightly використовує розширений список у Remote Settings, якого ця сторінка не відтворює. Жодного параметра utm_ у релізному списку немає.

Safari. WebKit описує Link Tracking Protection як частину приватного перегляду, що перед навігацією видаляє підмножину параметрів запиту, які ідентифікують міжсайтове відстеження. Той самий захист діє й у звичайному перегляді, коли користувач вмикає розширене налаштування відстеження та фінґерпринтингу для всього перегляду. WebKit каже, що параметри атрибуції на кшталт campaign пропускаються. Теги utm_ він не називає ні так, ні так.

Brave. Фільтр рядка запиту Brave має прості, умовні та обмежені за областю правила. Єдиний параметр, названий у його вікі, - mkt_tok, який видаляється, крім URL відписки. Повний список лежить у brave-core, і зі сторінок, які я прочитав, я не зміг підтвердити, чи є в ньому якийсь тег utm_. Також я не зміг підтвердити поведінку Brave щодо GA4 з документації вендора, тож її не стверджую.

Тож куди зникають UTM-дані?

Більшість пояснюють три причини, і жодна з них не "браузер видалив мої теги".

1. Хост призначення відкидає рядок запиту. Редирект із кінцевим слешем або правило хостингу можуть відкинути все після знака питання. Чому UTM-параметри не з'являються в GA4 проводить через це дерево рішень.
2. Скрипт аналітики не запускається. Захист від відстеження й розширення блокують відомі домени аналітики. Теги в URL є; їх ніхто не читає.
3. Згоду відхилено. Той самий ефект, інша причина. Розрив між кліками й сеансами в Кліки по коротких посиланнях і сеанси GA4 - це здебільшого вона плюс боти й об'єднані сеанси.

Справжня жертва - ідентифікатори кліків. fbclid є в списку прибирання Firefox, тож ідентифікатори кліків для Meta можуть зникати в суворому режимі, навіть коли ваші UTM виживають. Це важливо, якщо ви покладаєтеся на ідентифікатори кліків для зіставлення з рекламною платформою. Ідентифікатори кліків: пояснення описує, які платформи що використовують.

Перевірте на власних посиланнях

Не довіряйте блогу, зокрема цьому, у питанні списку, який змінюється між версіями. Це займає п'ять хвилин.

1. Створіть коротке посилання на сторінку, яку контролюєте, з ?utm_source=test&utm_medium=test&utm_campaign=check&fbclid=abc&mkt_tok=xyz у призначенні.
2. Відкрийте його у Firefox із суворим захистом, у приватному перегляді Safari, у Brave і в Chrome.
3. Прочитайте кінцевий адресний рядок у кожному. Чого бракує - те цей браузер прибирає цього дня.
4. Повторіть після великого оновлення браузера, бо списки зростають.

Чому хибна історія поширюється

"Браузери прибирають UTM" - охайне пояснення, тож його повторюють. Його також важко спростувати зсередини звіту GA4, бо відсутня кампанія виглядає однаково, хто б її не прибрав. Сеанс, віднесений до direct чи unassigned, може означати прибраний тег, редирект, що відкинув рядок запиту, або застосунок, який не надіслав реферер.

Ці випадки різняться тим, що ви можете виправити. Хост, що відкидає рядок запиту, - це зміна на сервері в один рядок. Заблокований скрипт поза вашим контролем, як і відхилений запит згоди. Прибрані ідентифікатори кліків мають значення, лише якщо ви збудували на них звітність. Звалення чотирьох випадків докупи як "браузери з приватністю" відправляє вас не туди, тому тест вище вартий більше за будь-який відсоток, який я міг би навести. Я навмисно його не наводжу: цифри частки приватних браузерів, що ходять мережею, походять з опитувань вендорів із різними визначеннями, а ваша аудиторія не є середньою.

Читаємо розподіл за вашими браузерами

Коли тест проведено, поставте числа на власний трафік. У GA4 розбийте сеанси за браузером для однієї кампанії й порівняйте з кількістю кліків по коротких посиланнях цієї кампанії за ті самі дати.

• Співвідношення сеансів до кліків у Chrome - базовий рівень. Воно несе звичні втрати на сканери, ботів і відмови.
• Помітно нижче співвідношення у Firefox або Safari вказує на блокування скриптів чи згоду, бо саме прибирання UTM не видалило б сеанс, лише його мітку кампанії.
• Нормальне співвідношення, але висока частка direct чи unassigned в одному браузері вказує на втрату тегів або ідентифікаторів кліків, а не на те, що тег не завантажився.

Другий шаблон вартий розслідування, і лише в ньому функція браузера справді видалила щось із надісланого вами. Усе інше - проблема видимості, яку ви керуєте базовим рівнем, а не помилка, яку виправляєте. Якщо ваші кліки й сеанси вже розходяться з не пов'язаних із браузерами причин, спершу розв'яжіть їх післяобідньою процедурою зі статті про кліки й сеанси.

Запишіть клік, поки браузер його не торкнувся

Що б браузер не робив, він робить це на цільовій сторінці. Коротке посилання розв'язується на редиректі й першим записує клік, тож те, що браузер прибере чи заблокує згодом, не змінить того, що клік відбувся.

В Elido edge-редирект записує подію кліку (посилання, час, країна та пристрій) у момент надсилання відповіді, а відомі краулери й боти попереднього перегляду не враховуються. Події кліків потім можна пересилати до GA4 та інших інструментів, про що розповідає серверне відстеження GA4 через редиректи.

Обмеження реальне: це відновлює підрахунок залучення, тобто що клік відбувся і яке це було посилання. Воно не відновлює сеанс на сторінці, події чи конверсію, якщо тег було заблоковано. Для виручки атрибутуйте замовлення посиланню на сервері, як у статті наскрізне відстеження UTM-кампаній.

Що робити

• Залишайте свої UTM. Задокументовані списки їх не зачіпають.
• Сприймайте ідентифікатори кліків на кшталт fbclid як такі, що втрачаються, і не будуйте звітність, яка їх потребує.
• Проводьте п'ятихвилинний тест вище після оновлень браузерів.
• Обгортайте кампанійні посилання в розмічене коротке посилання, щоб клік рахувався на редиректі. Аналітика посилань Elido показує ці підрахунки по кампаніях.
• Звіряйте кліки із сеансами GA4 по кампаніях і браузерах та стежте за співвідношенням у часі.

Читайте серію опорних статей

Це частина інженерного кластера. Почніть із наскрізного відстеження UTM-кампаній, щоб побачити весь конвеєр.

Читайте також у блозі

• Атрибуція кліків після Safari ITP
• UTM-параметри: повний посібник
• Кліки по коротких посиланнях і сеанси GA4
• Ідентифікатори кліків: gclid, fbclid, ttclid і msclkid
• Атрибуція без cookie: пояснення
• UTM-параметри не відображаються в GA4: причини й виправлення