Какие данные слежения уходят, если вставить в чат полную ссылку с UTM

Полный URL из адресной строки ещё не значит «можно отправлять»

Маркетолог кидает коллеге посадочную страницу в Telegram. Поддержка вставляет адрес из жалобы в заявку. Разработчик копирует шаги воспроизведения в тред. Во всех трёх случаях самое дешёвое действие одно: выделить адресную строку, скопировать, вставить. Строка показывает полный URL текущего документа. По модели WHATWG URL там как минимум схема, хост, путь, query после ? и фрагмент после #. Фрагмент по умолчанию не входит в HTTP — об этом уже была отдельная заметка. Query едет и в строке запроса, и в буфере обмена.

Часто query странице не нужен. Вы могли прийти из письма с трекингом, из платного клика или из карточки соцсети, которая сама дописала токен. Странице достаточно /product/42. В строке же оказывается /product/42?utm_source=summer-mailer&utm_medium=email&utm_campaign=summer-sale&fbclid=…. Для аналитики это один атрибутируемый визит. Для следующего человека, который прочтёт строку, это побочный профиль, которому не место в заявке: из какой кампании вы пришли, кликали ли только что по объявлению, пронумеровал ли почтовый сервис этого получателя.

HTTPS защищает только передачу от подслушивания. Он не стирает адресную строку, историю браузера, историю чата, скриншоты и журналы доступа. Заметка OWASP про утечку через query-строку говорит прямо: даже по зашифрованному каналу query всё равно появляется в Referer, веб-журналах, общих системах, истории браузера, кэше и при взгляде через плечо. Вопрос перед отправкой не «безопасен ли этот сайт», а «нет ли после вопросительного знака меток, которым не следует покидать эту вкладку».

UTM описывает кампанию. Идентификатор клика описывает именно этот клик

Оба типа часто живут в одном URL. Задачи разные, и утечки разные. Первый тип — метки кампании, которые вы (или рекламная платформа) поставили сами. Справка Google Analytics называет их campaign parameters и даёт стандартный пример: https://www.example.com/?utm_source=summer-mailer&utm_medium=email&utm_campaign=summer-sale. Документация требует: если параметры уже ставите, используйте вместе utm_source, utm_medium и utm_campaign. Рядом бывают расширения: utm_id, utm_term, utm_content, utm_source_platform. Регистр важен: utm_source=google и utm_source=Google в отчёте разъедутся на две строки.

Обычно эти метки не кодируют конкретного человека. Они описывают канал и кампанию: какая рассылка, какая летняя акция, верхняя ссылка или нижняя. Но во внешний чат их всё равно не стоит тащить: получатель читает, какую кампанию вы крутите и был ли клик из письма или из оплаты, и по этому угадывает путь привлечения. Конкуренту или постороннему третьему лицу этого уже больше, чем нужно, чтобы «просто открыть страницу».

Второй тип — токен клика, который площадка дописывает сама. Частые имена: gclid у Google Ads, dclid у Display & Video 360, gbraid / wbraid в сценариях iOS, fbclid у Meta, msclkid у Microsoft Ads, twclid у X, а у почтовых сервисов — mc_eid. Их задача — сшить «этот клик» с собственной записью площадки, а не дать вам человеческое предложение. Значение получателю непрозрачно, площадке — читаемо. Переслать строку с fbclid или gclid значит отдать сшиваемый признак клика. Токены вроде mc_eid ближе к формуле «это письмо ушло в эту строку подписчика».

Есть и третий слой: собственные метки сайта или витрины. На маркетплейсах и контентных страницах встречаются spm, scm, pvid, share_token, refer_share_id. Это не спецификация UTM Google, но «просто карточка товара» после них несёт след, кто поделился и откуда. Политика, которая снимает только utm_*, этот слой оставляет. У Яндекс.Директа бывает свой yclid: его нет в стандартной таблице кликов многих чистильщиков, поэтому после автоматической очистки его всё равно стоит искать глазами.

Куда попадает query после вставки

CWE-598 — сейчас заголовок звучит как Use of HTTP Request With Sensitive Query String — формулирует дефект так: чувствительные данные положили в query. Дальше они оказываются в истории браузера, уезжают на другие сайты через Referer, пишутся в веб-журналы или копируются в другие записи. В выпуске 4.20 в апреле 2026 запись переименовали, чтобы подчеркнуть: query носит не только GET. POST, PUT и DELETE тоже могут. Смягчение конкретное: чувствительные данные — в тело запроса или в заголовки, не в query.

Большинство маркетинговых параметров — не пароли и не сессионные токены. Поверхность та же. Вставили полный URL в мессенджер — и уже есть как минимум такие копии: хранилище сообщений у сервиса, локальная история у получателя и, если он перешлёт дальше, хранилище следующего узла. Если ссылку откроют, журнал доступа целевого сайта запишет строку запроса с параметрами. Если страница затем подгрузит сторонний скрипт или картинку, полный URL может уехать ещё и в Referer на рекламный или аналитический хост. «Общие системы» из списка OWASP внутри компании обычны: заявки, документы, мониторинг ошибок, запись сессий. Ссылка, которую хотели только для воспроизведения, становится поисковой по открытому тексту.

Поэтому ответ «у нас же HTTPS» на вопрос про пересылку не работает. HTTPS мешает наблюдателю на пути прочитать открытый текст. Он не мешает вам самим вставить этот текст в следующую систему. Среди реальных дефектов CWE-598 — камера, которая клала пароль в query, и продукт связи, который клал токен доступа в GET. Это тот же класс ошибки, только тяжелее. UTM и идентификаторы клика обычно мягче. Механизм один: что стоит после вопросительного знака, то люди копируют и то системы пишут в журнал.

Referer может унести query третьей стороне

Копирование — активная пересылка. Есть и пассивная: после того как получатель открыл страницу, браузер по умолчанию сообщает следующим запросам, «откуда я пришёл». Стандартное имя заголовка — Referer (без одной r). Заметка MDN про приватность Referer приводит знакомый пример: на странице сброса пароля в подвале стоят ссылки на соцсети — клик наружу может отдать адрес с токеном социальной площадке. Стороннее изображение на странице тем же путём отправит текущий полный URL на хост картинки.

Сколько отправлять, браузер решает по Referrer-Policy. У Chrome и близких движков по умолчанию strict-origin-when-cross-origin: запросы на тот же источник могут нести полный URL (путь и query), кросс-источник без понижения протокола шлёт только origin (схема + хост + порт), переход с HTTPS на HTTP — ничего. Рекомендации web.dev по Referrer считают этот дефолт компромиссом между приватностью и пользой. Он закрывает часть случаев «полный query чужому хосту». Он не закрывает аналитику на том же источнике и не помогает, если сайт выставил unsafe-url или не задал политику, а старый клиент по-прежнему шлёт полный URL.

Для фразы «я просто отправил коллеге» Referer всё равно важен: как только коллега кликнет, вставленные utm_* и идентификаторы клика могут пройти ещё один прыжок. Если на посадочной есть сторонний пиксель, виджет поддержки или шрифт с CDN, а политика разрешает полный URL, эти параметры появятся в журналах тех хостов. Снять трекеры из query до отправки значит обрезать оба прыжка: открытый текст в истории чата и возможный Referer после открытия.

Сравнение с фрагментом стоит одной фразы. Ключ после # задуман так, чтобы не входить в строку запроса, поэтому его нет и в обычных реализациях Referer. У query такого слоя нет. Метки кампании и идентификаторы клика стоят после ?, чтобы серверы и скрипты их прочитали — именно поэтому они попадают в журналы. Проверить «вопросительный знак входит в запрос, решётка обычно нет» можно по шагам из Почему ключ после решётки в URL удобно класть и когда эта защита ломается.

Система может снять часть токенов. Это ещё не политика пересылки

У Apple есть встроенная обрезка. На странице Privacy Features защита от отслеживания ссылок описана так: когда вы делитесь ссылками в Сообщениях, лишняя информация, которую некоторые сайты дописывают в URL, удаляется, чтобы эти сайты не могли отслеживать вас или получателя. Отдельно описан приватный просмотр Safari: защита снимает трекинг, добавленный к URL, пока вы листаете. Apple публикует возможность, а не полный список ключей.

Официального полного списка нет. Сообщество (PrivacyTests.org и похожие сверки) часто называет gclid, fbclid, mc_eid, twclid, dclid. Метки кампании вроде utm_source обычно остаются. Границы покрытия тоже есть: обычный Safari, сторонний браузер и встроенный WebView в приложении — это не те же пути, что «поделиться в Сообщениях» или приватный просмотр. Получатель на Android, в настольном Chrome или по ссылке из Telegram и WhatsApp за вас ничего не снимет.

Значит, «телефон и так убирает параметры отслеживания» можно писать только так: на конкретной системе, в конкретном приложении часть идентификаторов клика может исчезнуть до открытия. Нельзя писать: строка, которую вы вставили в заявку, уже очищена. Пересылка случается в момент копирования, там, куда ОС ещё не зашла. Контролируете вы буфер обмена, а не то, снимет ли чужое устройство параметры ещё раз.

Что снимать и что оставлять

Правило, которое можно выполнить: сначала спросите, откроется ли страница без этого ключа. Товарный id, поисковый q, номер page, lang или query, который нужен самому документу, изменят ресурс, если их выкинуть. Метки кампании, идентификаторы клика, номера получателя письма и токены шаринга обычно меняют только атрибуцию, не саму страницу.

Второй вопрос — зачем ссылка. Коллеге, который воспроизводит ошибку, нужен стабильный адрес ресурса, а не utm_campaign=summer-sale. Клиенту, которому «откройте этот товар», нужен sku, а не ваш свежий gclid. UTM оставляйте только если задача именно такая: «зайдите по этой помеченной кампании, чтобы мы посчитали этот пересыл». Даже тогда свой идентификатор клика прикладывать не нужно.

Вручную легко пропустить ключ. Живая рекламная ссылка может нести пять-шесть полей utm_*, один идентификатор клика и два-три внутренних токена. Стирание справа налево часто убивает id и оставляет fbclid. Надёжнее идти по именам: снять любой префикс utm_; снять известную таблицу идентификаторов клика; если задача позволяет — ещё обычные ключи аналитики (_ga, _gl, mc_eid, mkt_tok) и типичную коммерческую атрибуцию. Путь, хост и рабочие query оставить. После этого смотреть список удалённых ключей, а не только «стало короче».

Консервативный и стандартный режимы — две склонности к риску, а не две степени анонимности. Консервативный: трогать только UTM и идентификаторы клика, незнакомые свои ключи не трогать, чтобы не снести рабочий параметр, которого вы ещё не видели. Стандартный: плюс обычная аналитика и коммерческая атрибуция — так удобнее, когда ссылка уходит за пределы компании или в публичное поле. Ни один режим не даёт права сказать «теперь анонимно». В пути всё ещё может быть имя пользователя. Query email= в таблицу UTM не входит. Очистка по правилам закрывает известные ключи слежения, а не любое чувствительное поле. Телефоны, паспортные номера и ключи в теле сообщения требуют отдельного маскирования. Не ждите, что снятие параметров URL закончит и эту работу.

Проверка на месте: список снятых ключей, затем Network

Слоган «локальная очистка, ничего не уходит» сам себя не доказывает. На месте видно три вещи: какие ключи сняли, какие остались и не ушёл ли исходный URL как рабочие данные.

Сначала соберите канарейку. Откройте публичную страницу без настоящего клиента и допишите ?utm_source=canary-share&utm_medium=email&utm_campaign=canary-2026&fbclid=canaryclid&id=42. Вставьте всю строку в поле очистки. После прогона четырёх трекерных ключей быть не должно, id=42 должен остаться. Если инструмент показывает список снятых имён, сверьте каждое. Не останавливайтесь на «URL стал короче».

Затем откройте Network в инструментах разработчика, включите Preserve log и в фильтре ищите canary-share или всю канареечную query. Её не должно быть в строке, query или теле XHR / Fetch и не должно быть в query или теле аналитики. Статика, стили и скрипты могут попасться — это файлы самой страницы. Провал — если исходная строка ушла как рабочее поле. Заголовок или путь со словами «privacy» или «очистка» ожидаемы. Полное содержимое поля ввода — нет.

1. Соберите канареечный URL с utm_*, fbclid и рабочим id. Не берите настоящего клиента и не берите имя живой кампании.
2. После очистки сверьте таблицу: трекерные ключи на стороне «удалено», id ещё в результирующем URL.
3. Найдите канареечную строку в Network. Попадание в любой рабочий запрос значит, что исходник покинул эту вкладку.

Доказательство узкое: в этом прогоне известные ключи слежения исчезли по правилу, рабочий ключ остался, исходник не ушёл из вкладки как наблюдаемое HTTP-поле. Оно не доказывает, что расширение никогда не читало поле ввода, и не доказывает, что свой трекер вне таблицы правил обработан. Сменили браузер или таблицу правил — прогоните канарейку снова.

Отработайте правила на странице, которая открывается без аккаунта

Если нужен инструмент, который печатает список снятых параметров на странице, начните с очистки данных MakePwd. Страница открывается сразу, без регистрации и без аккаунта. Разбор URL и снятие параметров идут в этой вкладке. По описанию продукта исходная строка не уходит как запрос и не пишется в analytics. Стандартный режим снимает utm_*, идентификаторы рекламных кликов, обычные параметры аналитики и типичные коммерческие метки из таблицы правил. Консервативный режим снимает только UTM и идентификаторы клика. Путь и рабочие параметры вроде id и q остаются. За один раз — не больше 100 адресов. Строка длиннее 8 КБ будет отклонена. Принимаются только http и https.

Тренируйтесь на канарейке выше, не на живом идентификаторе клика из текущей кампании. После прогона смотрите два места: список удалённых параметров в результате и Network на исходную строку. Список отвечает «те ли ключи я снял». Network отвечает «ушло ли это на сервер». Оба должны пройти, прежде чем коллеге можно сказать: вот ключи, которые я убрал, и канарейка в исходящих запросах не нашлась.

Очистка обрабатывает только форму ссылки. Телефоны, номера документов, почта и API-ключи в теле чата или заявки относятся к маскированию на той же странице: шаблон закрывает совпадения, человек перепроверяет. MakePwd не заявляет сертификацию GDPR или аналог. Если после очистки текст всё ещё должен остаться тайной, отправьте его один раз одноразовой ссылкой и оставьте ключ во фрагменте #. Целый файл зашифруйте на этом устройстве в шифровании файлов в .lock / .enc, затем передайте через облако или почту. Ни один из этих шагов не требует входа.

Частые вопросы

После снятия UTM получатель всё ещё откроет страницу?

Да, если рабочие параметры и путь на месте. UTM и идентификаторы клика служат атрибуции, не маршрутизации. Уберите utm_campaign или fbclid — посадочная должна открыться по пути и id. Если вышел 404 или другой результат, задели рабочий ключ. Переключитесь на консервативный режим и сверяйте ключи по одному.

HTTPS уже защищает эти параметры?

Не в момент пересылки. HTTPS снижает риск подслушивания на пути. Он не стирает адресную строку, историю, чат и журналы. OWASP прямо пишет: даже по зашифрованному каналу query всё равно появляется в Referer, веб-журналах, общих системах и истории браузера. Можно ли вставлять полный URL — отдельный вопрос от того, есть ли у сайта сертификат.

Apple сама снимает трекеры. Мне всё равно делать это руками?

Да. Системная функция работает на описанных путях вроде «поделиться в Сообщениях» и приватного просмотра Safari, полного списка ключей Apple не публикует. UTM обычно остаётся. Когда вы вставляете ссылку в заявку или в чат на Android, эти защиты за вас не сработают. Политика пересылки смотрит на буфер обмена, а не на то, снимет ли ОС получателя параметры ещё раз.

Чистая ссылка не удалит и товарный id?

Не должна, если инструмент идёт по именам. id, q и sku — не префикс utm_ и не входят в обычную таблицу идентификаторов клика. Проверка — канарейка, где рядом лежат трекерные ключи и рабочий ключ, и в результате исчезли только первые. Если сайт пишет слежение в своё имя, таблица правил его не узнает. Такой ключ удалите вручную или расширьте список.

Три вещи, которые стоит помнить перед следующей отправкой

Первое: выделить всю адресную строку ещё не значит «можно слать». Разложите query на метки кампании, идентификаторы клика, внутреннюю атрибуцию и рабочие параметры. По умолчанию оставлять стоит только последний тип. Второе: HTTPS и автоснятие системой не заменяют проверку буфера. Query попадает в историю, заявки и журналы и может пройти ещё раз через Referer. Третье: сверяйте два места — список удалённых ключей и поиск канарейки в Network.

Если следующий вопрос — не ушёл ли открытый текст из этой вкладки как рабочие данные, читайте Шифрование в браузере: как убедиться, что исходный текст не покинул устройство. Эта заметка только сводит «какие поля query не должны ехать вместе с полной ссылкой» к диапазону, который можно записать в вывод.