Вырезают ли Firefox и Brave UTM-параметры?

Коротко: Firefox действительно вырезает параметры запроса, но список релиза, который документирует Mozilla, - это в основном рекламные и почтовые идентификаторы вроде 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: причины и решения