Сразу вывод: перед пересылкой срезают query, который пишет в адрес «откуда вы пришли». Проверка — не «ссылка стала короче». Сверьте список снятых параметров, затем убедитесь, что pathname и id= / q= на месте. Очищенный URL — это не частный визит и не доказательство, что на посадочной нет счётчика.
Сначала одним предложением — ответ на запрос
UTM-метки и идентификаторы клика снимают до пересылки потому, что строка запроса входит в цель HTTP-запроса. Когда браузер запрашивает документ, utm_source, yclid, fbclid и gclid после вопросительного знака попадают в строку запроса; хост, обратный прокси и журнал доступа устроены так, чтобы их видеть. Вставили всю строку в чат или тикет — канал и номер клика ушли следующему, кто откроет ссылку.
Заметка для поддержки, маркетинга и тех, кто перед внешней рассылкой хочет разделить два вопроса: что уже написано в адресе и что всё равно случится после загрузки страницы. Она не заменяет инструкцию к очистке ссылки и не повторяет, какую кнопку нажать, чтобы получить короткий URL. Унести отсюда стоит другое: что пишут UTM и click ID, кто их наследует при пересылке, что срез ещё может доказать и как сверить список снятых параметров с вкладкой Network на этом устройстве.
Текст после вопросительного знака уходит в HTTP
RFC 3986 §3.4 определяет query как участок после первого ? и до fragment. RFC 9110 дальше фиксирует: целевой URI запроса содержит путь и query, но не fragment. Длинная адресная строка — не вопрос вкуса. Этот запрос документа отдаёт пары ключ–значение за вопросительным знаком другой стороне.
Fragment после решётки по умолчанию остаётся в текущей вкладке; как это сверить, уже разобрано в отдельной заметке. Здесь смотрим только на вопросительный знак. Обе правила стоит держать рядом, чтобы фразу «сервер не видит ключ после #» не прочитать как «сервер не видит и канал после ?».
Браузерный URLSearchParams разбирает query на пары, удаляет их по имени и собирает адрес заново. Очистка ссылки работает на этом слое: меняется строка, а не скрипты посадочной. Удалить utm_campaign не значит выключить пиксель или счётчик на чужом сайте.
UTM-метка пишет канал, а не декоративный хвост
И Google Analytics, и справка Яндекс Метрики по разметке описывают ручные UTM как набор query-параметров utm_*. Привычное соответствие такое: utm_source — источник, utm_medium — канал, utm_campaign — название кампании; рядом стоят utm_term, utm_content, utm_id и более новые поля вроде utm_source_platform. Официальный пример Google выглядит так: http://www.example.com/?utm_source=google&utm_medium=cpc&utm_campaign=summersale. Это формулировка из справки Analytics об источниках трафика, а не догадка чистильщика ссылок.
Для того, кто крутит кампанию, значения полезны: один и тот же материал можно отдельно посчитать из рассылки, описания ролика и закреплённого сообщения в Telegram. Для следующего, кто откроет ссылку, это открытая пометка. Если в тикете висит utm_source=vip_telegram&utm_campaign=refund_202609, дежурный, поиск по заявкам и будущий экспорт таблицы прочитают: «этот клик пришёл из закрытой акции».
Сама UTM-метка редко содержит паспорт или пароль. Она выдаёт контекст: какое письмо открыли, по какому объявлению кликнули, пришли ли по персональной ссылке из ответа поддержки. Как только этот контекст оказался в пересылаемом URL, он больше не живёт только в вашей вкладке.
Click ID пишет конкретный клик, а не имя кампании
Идентификатор клика ближе к «этому нажатию», чем к названию акции. В справке Метрики про yclid прямо сказано: параметр yclid добавляет в URL объявлений Яндекс Директ; типичная форма — https://example.com/?yclid=123. Чтобы потом сопоставить офлайн-конверсию, площадка часто просит снять значение из адреса и сохранить его, иногда в cookie или скрытом поле формы. Переслали ссылку с yclid коллеге — коллега при открытии снова отдаёт этот номер клика серверу посадочной.
У Google Ads автоматическая разметка дописывает gclid (Google Click Identifier). Официальный вид — www.example.com/?gclid=123xyz. Если автопометка включена и на сайте стоит Analytics, значение могут ещё записать в собственную cookie домена, чтобы поздние конверсии склеить с тем кликом. Это формулировка из справки Google Ads об автопометке, не классификация инструмента очистки.
В части сценариев после iOS 14 без согласия gclid больше не ставят. Google ввёл gbraid (веб → приложение) и wbraid (приложение → веб), чтобы измерение рекламы продолжалось в этих рамках. Разделение описано в справке Analytics про измерение кампаний на iOS 14+.
Со стороны Meta чаще встречается fbclid. Документация разработчика говорит: если в URL страницы есть этот query-параметр, Conversions API по-прежнему может собрать из него fbc; если на сайте стоит Meta Pixel, номер клика ещё пишут в собственную cookie _fbc в формате version.subdomainIndex.creationTime.fbclid. Источник — заметка Meta про fbp / fbc. Отдали коллеге адрес с fbclid — чужой сайт при её визите снова может положить «этот клик» себе в cookie и в следующие события.
Тот же класс имён появляется как msclkid, ttclid, twclid, li_fat_id. Каждое обслуживает свой рекламный кабинет. Общее свойство проще: стоит в query — едет в строке запроса; стоит в строке, которую вы пересылаете, — следующий человек её наследует.
Не ставьте опыт на боевой ссылке Директа, короткой ссылке с телефоном клиента или незамаскированном тикете. Подготовьте публичный пример и запишите в значения одноразовые канарейки. Вы сверяете query и строку запроса — а не снова раздаёте настоящий канал.
При пересылке следующий наследует весь query
Кнопка «поделиться», «копировать адрес» и долгое нажатие на сообщение в мессенджере почти всегда копируют полный текущий URL, а не короткий путь, который сайт показывает снаружи. В Telegram, VK и превью объявления это особенно заметно: вы думаете, что скопировали статью или карточку товара, а в буфере — pathname плюс хвост атрибуции.
Эти поля затем оказываются в трёх местах. Первое — текст чата или тикета, где их видят участники треда и любой поздний поиск. Второе — адресная строка другого человека и история, которая оттуда синхронизируется. Третье — запрос документа, который уходит при открытии: в журнале сервера лежит полный query. Удалить строку из своего чата не меняет ни тех, кто уже открыл, ни уже записанные логи.
Бросить мониторинговую ссылку кампании во внешнее объявление, вставить длинный адрес клиента в заявку как есть и повесить в issue воспроизведение с yclid или gclid — одно и то же действие. Контекст клика, который сидел в вашей адресной строке, стал меткой, которую может повторно использовать любой, кто видит эти символы.
Что срез может доказать и что в адресе ещё остаётся
Вывод, который поддерживает снятие меток, узкий — и лучше сразу это написать. Он доказывает: при этом списке имён и этом запуске известные utm_*, идентификаторы клика и (если включён более широкий режим) часть полей атрибуции исчезли из query. Pathname на месте; id=, q= и похожие рабочие параметры по задумке должны остаться, ссылка должна вести к тому же материалу.
Он не доказывает: на посадочной нет пикселя, у площадки нет собственных cookie, короткая ссылка после редиректа не допишет новые параметры, в фрагменте пути нет служебной метки, расширение не переписало буфер. Тем более не доказывает фразу «после открытия вас никто не узнает». Срезают ту строку, которую вы собираетесь отправить, а не следующую сессию просмотра.
Короткая ссылка — самый частый ложный успех. Сервис прячет настоящую цель в своём редиректе; вы чистите https://clck.ru/abc или https://vk.cc/abc, query часто пустой, инструмент отвечает «снимать нечего». Слежение сидит на длинном адресе после 302. Чтобы сверить, сначала откройте короткую ссылку в частном окне и скопируйте итоговый URL из адресной строки. Не делайте этот шаг на короткой ссылке с настоящими персональными данными.
| Что вы видите | Какой вывод это держит | Какой вывод это не держит |
|---|---|---|
| Ссылка стала короче | В query стало меньше символов | Уже анонимно, уже безопасно |
В списке снятых есть utm_*, yclid, fbclid |
Эти ключи удалены из текущего URL | Посадочная больше не запишет cookie Метрики, _fbc или Analytics |
id= и q= на месте |
Рабочие параметры локации сохранены по задумке | Каждый оставшийся ключ нужен делу |
| Короткая ссылка: «снимать нечего» | Эта короткая форма не совпала со списком | Длинный адрес после редиректа тоже чистый |
| В Network нет исходной ссылки | Этот запуск очистки не отправил исходник как прикладные данные | Расширение и клиент чата её тоже не сохраняли |
Сверка на месте: список снятых и Network
Слоган не доказательство. Проверку, которую можно закончить сразу, удобно держать в двух слоях: результат очистки и исходящий трафик. Подготовьте одноразовый пример, например:
https://example.com/article/42?id=42&q=aes&utm_source=telegram&utm_medium=social&utm_campaign=share_20260903&yclid=123canary&fbclid=IwAR0canaryfp&spm=demo.share.0
Канарейки положите в значения utm_campaign, yclid и fbclid. После очистки в чистом адресе не должно быть share_20260903, 123canary или IwAR0canaryfp; id=42 и q=aes должны остаться.
- Сначала прочитайте список снятых параметров. Там должны быть
utm_source,utm_medium,utm_campaign,yclid,fbclid; в более широком режиме туда же попадёт атрибуция маркетплейса вродеspm. Список пустой, а кажется, что «ссылка уже чистая», — сначала проверьте короткую ссылку или метку в пути. - Затем прочитайте pathname чистого адреса и оставшийся query. Пропал номер статьи или поисковое слово — это ложное срабатывание, такую строку не пересылайте.
- Откройте Network в инструментах разработчика, включите Preserve log, фильтр — All. Вставьте канарейку в поиск. Её не должно быть в строке запроса, теле и отправке аналитики.
Чистая ссылка FastPwd держит эту границу: разбор идёт в текущей вкладке, строка длиннее 8 КБ отклоняется, за один раз — не больше 100 строк; принимаются только http / https. Консервативный режим снимает только utm_* и идентификаторы клика, в том числе yclid, fbclid, gclid, gbraid, wbraid, msclkid. Стандартный режим дополнительно убирает _ga / _gl, почтовые mc_eid / mc_cid, атрибуцию вроде spm / scm, поля _x_*, share_token и — если не отмечено сохранение — ref / referrer. Pathname и id=, q= остаются. Инструмент открыли — и можно пользоваться, аккаунта нет. Аналитика пишет имена событий вроде «сделали очистку», исходник не записывает. Обещание всё равно остаётся обещанием: решают список снятых и Network в этом запуске.
Не уверены, рабочий ли ключ, — включите консервативный режим. Сначала уберите UTM и click ID из строки для пересылки, затем глазами решите, оставлять ли spm или ref. Ключ, которого нет в списке, список не снимет: например отладочный _ym_debug может остаться. Такой хвост удаляют вручную, а не надеждой, что «стало короче» закроет всё.
Три случая, когда кажется чисто, а срез не дошёл
Первый: слежение сидит в пути. Часть страниц «поделиться» отдаёт /s/xxxx или путь с префиксом канала, а query пустой. Удаление query по имени почти не меняет адрес. Сверять нужно канонический адрес после открытия, а не оболочку, которую только что выплюнула кнопка шаринга.
Второй: чистильщик трогает searchParams и не трогает hash. Если метку изредка записали после решётки, очистка query отрапортует успех. Сверка та же: положите рядом полный адрес из строки и полный результат, не смотрите только на участок до вопросительного знака.
Третий: вы почистили строку до вставки, а клиент при отправке дописал свои параметры. Некоторые приложения навешивают на внешнюю ссылку собственный click ID. После отправки откройте своё же сообщение в другом окне и ещё раз посмотрите адресную строку. Очистка происходит до вставки; после отправки нужна выборочная проверка.
Частые вопросы
Если убрать UTM-метки, следующего всё равно можно отслеживать?
Да. Срезают query той строки, которую вы пересылаете. На посадочной по-прежнему могут быть пиксель, собственные cookie и сессия входа. Документация Meta отдельно пишет: даже если в URL сейчас нет fbclid, сайт мог раньше записать _fbc, и поздние события снова его подхватят. Срез доказывает только отсутствие известных меток в этой URL, а не анонимность следующего визита.
Снимет ли очистка ещё и id статьи или поисковый запрос?
При очистке по списку имён pathname и рабочие query вроде id= или q= должны остаться. Если не уверены, включите консервативный режим: он убирает только utm_* и идентификаторы клика. После очистки читайте список снятых. Появился нужный вам ключ — этот результат не пересылайте.
Нужно ли сначала снимать метки с короткой ссылки?
У короткой ссылки часто нет своих UTM. Слежение сидит в длинном адресе после редиректа. Очистить только короткую форму обычно значит ничего не срезать. Сначала откройте её в частном окне и скопируйте итоговый URL из адресной строки. Не ставьте опыт на короткой ссылке с настоящими персональными данными; для проверки хватает публичного примера.
Когда я очищаю ссылку на FastPwd, уходит ли исходный адрес на сервер?
По описанию продукта разбор и снятие заканчиваются в текущей вкладке. Исходный URL не уходит как прикладные HTTP-данные и не пишется в аналитику. Аналитика записывает имена событий вроде «сделали очистку». Чтобы сверить этот запуск, ищите канарейку в Network: её не должно быть в строке запроса, теле и отправке статистики. На localhost аналитика по умолчанию не уходит — для картины ближе к реальному использованию повторите шаг на боевом домене.
Прогоните ту же ссылку в инструменте, который открыли — и сразу пользуйтесь
Если хотите потренироваться на странице, где список снятия написан явно, откройте очистку конфиденциальных данных FastPwd: регистрация не нужна. Вставьте пример выше, сначала консервативный режим, затем стандартный, и сравните чипы «снято». Должно быть видно: оба режима заберут UTM, yclid и fbclid; spm сдвинет только стандартный. В чистом результате id и q останутся.
На той же странице можно переключиться на маскирование текста и закрыть телефоны и почту в теле тикета; это тема другой заметки. Если коллеге нужно отдать целый секрет, переходите на Burn-Link: на этом устройстве шифрование идёт алгоритмом AES-256-GCM, сервер временно хранит только шифротекст, ключ стоит в ссылке после решётки. Только что очищенную рабочую ссылку и полный адрес Burn-Link в один и тот же чат вместе не кладите.
Перед следующей пересылкой держите три факта. Первый: вопросительный знак уходит в HTTP, канал и click ID пишутся именно там. Второй: срез меняет только ту строку, которую вы собираетесь отправить, и не выключает статистику посадочной. Третий: короткая ссылка, метка в пути и параметры, которые клиент допишет после отправки, требуют отдельной сверки. В собственную памятку по внешней рассылке стоит класть только то наблюдение, которое можно повторить.
Что ещё почитать
Вопросительный знак и решётку не стоит смешивать. Почему ключ можно класть после # и какой слой защиты пропадает, если вставить полную ссылку в чат, разобрано в Почему после решётки в URL можно класть ключ и когда эта защита ломается. Как до отправки сверить телефоны, номера документов и API-ключи в теле тикета — в Перед тем как вставить тикеты и логи в ИИ, сверьте, какие поля покинут это устройство. Если нужно отдельно убедиться, что сама очистка не отправила исходную ссылку как прикладные данные, возьмите канареечные шаги из Как проверить, что локальное шифрование в браузере не отправило открытый текст.