UTM-метки: что это, как создать и не сломать аналитику

Коротко. UTM-метки — это параметры в конце адреса страницы (?utm_source=…&utm_medium=…), которые счётчик читает при загрузке и записывает как источник визита. Сервер их игнорирует и отдаёт ту же страницу. Параметров пять: source, medium, campaign, content, term. Сами по себе метки не влияют на позиции, но ломают SEO, если параметризованные адреса попали в индекс или потерялись на редиректе.

Что такое UTM-метка простыми словами

UTM-метка — это пара «ключ=значение», дописанная к адресу страницы после знака вопроса. Несколько пар соединяются амперсандом. Аббревиатура пришла из Urchin Tracking Module — системы веб-аналитики, купленной Google в середине 2000-х; название прижилось и стало отраслевым стандартом де-факто, хотя никакого RFC на UTM не существует.

Вот как выглядит размеченная ссылка:

https://example.com/pricing?utm_source=vk&utm_medium=social&utm_campaign=autumn-sale

   https://example.com/pricing   — адрес страницы, он не меняется
   ?                             — начало строки параметров (query string)
   utm_source=vk                 — первая пара
   &                             — разделитель пар
   utm_medium=social             — вторая пара
   &utm_campaign=autumn-sale     — третья пара

Ключевое, что стоит понять сразу: метки — это не команда серверу. Веб-сервер отдаёт по такому адресу ровно ту же страницу, что и по чистому /pricing. Никакой обработки, никакого редиректа, никакого изменения контента — если только вы сами не написали код, который читает эти параметры.

Что происходит на стороне аналитики

Работу делает счётчик — скрипт Яндекс.Метрики, Google Analytics или любой другой системы, установленный на странице. Последовательность такая:

• Браузер загружает страницу по адресу с параметрами.
• Скрипт счётчика читает текущий адрес из браузера (location.search) и вытаскивает оттуда всё, что начинается на utm_.
• Найденные значения отправляются на сервер аналитики вместе с первым хитом и записываются как атрибуты визита или сессии.
• Дальше все действия пользователя — просмотры, цели, покупки — привязываются к этому источнику по правилам атрибуции конкретной системы.

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

Метка живёт ровно до первого хита. Если между кликом по рекламе и загрузкой страницы со счётчиком есть редирект, который выкидывает query string, вы потеряли не «часть данных», а весь источник целиком. Проверять цепочку редиректов нужно до запуска кампании, а не после.

Пять параметров UTM: source, medium, campaign, content и term

Стандартный набор — пять параметров. Формально ни один из них не обязателен: аналитика примет ссылку с одним utm_source. Практически рабочий минимум — source + medium + campaign, потому что без medium отчёт распадается на несуразную кашу из имён площадок.

Параметр	Рабочий минимум	Что кладут	Пример значения	Частая ошибка
utm_source	да	Конкретная площадка или отправитель — «откуда именно пришёл человек»	yandex, vk, newsletter, partner-blog	Кладут тип канала (cpc) вместо площадки
utm_medium	да	Тип канала — «каким способом он пришёл». Берётся из короткого закрытого словаря	cpc, email, social, banner, referral	Свободная фантазия: ppc, paid, cpc-ads в одном аккаунте
utm_campaign	да	Название кампании или акции — то, по чему вы будете группировать отчёт	autumn-sale, black-friday-2026	Дата в свободной форме, из-за чего сортировка ломается
utm_content	нет	Различение вариантов внутри одной кампании: креатив, баннер, позиция ссылки в письме	banner-300x250, footer-link, variant-b	Дублируют campaign вместо различения вариантов
utm_term	нет	Ключевая фраза. Исторически — для платного поиска	utm-метки, kupit-hosting	Кладут незакодированную фразу с пробелами

Чем utm_source отличается от utm_medium — главная путаница

Это разделение ломает больше отчётов, чем все остальные ошибки вместе взятые. Разница простая:

• source отвечает на вопрос «где?» — имя собственное площадки. yandex, google, vk, telegram, habr, newsletter-weekly.
• medium отвечает на вопрос «как?» — тип трафика, категория. cpc (платный клик), organic, email, social, referral, banner, qr.

Проверочный приём: значений medium в здоровом аккаунте должно быть 5–10 штук на весь бизнес, а значений source — сколько угодно. Если у вас в отчёте по medium три десятка строк, значит туда попало то, что должно было лечь в source или campaign.

Одна и та же площадка легко даёт разные medium: рассылка из ВКонтакте — это utm_source=vk&utm_medium=social, а платный пост там же — utm_source=vk&utm_medium=cpc. И наоборот, один medium собирает много source: utm_medium=email приходит и от newsletter, и от trigger-abandoned-cart, и от partner-digest.

Помимо классической пятёрки современные версии Google Analytics понимают дополнительные параметры вроде utm_id для сшивки с рекламными системами. Набор постепенно расширяется, поэтому опирайтесь на актуальную документацию вашей системы аналитики, а не на статьи; базовые пять поддерживают все.

Как создать UTM-метку вручную и что делает генератор UTM-меток

Ручная сборка занимает секунд двадцать и требует соблюдения нескольких механических правил:

• Первый параметр отделяется знаком ?, все следующие — знаком &.
• Если в адресе уже есть свои параметры (/catalog?page=2), метки добавляются через &, а не через второй ?.
• Только строчные латинские буквы, цифры, дефис и подчёркивание. Никаких пробелов, кириллицы и знаков препинания в значениях.
• Всё, что не влезает в этот набор, нужно закодировать (percent-encoding): пробел становится %20 или +, кириллица — последовательностью %D0%….
• Метки идут до якоря. Правильно /page?utm_source=vk#faq, неправильно /page#faq?utm_source=vk — во втором случае всё после решётки браузер вообще не отправит на сервер и не положит в query string.

# Плохо: пробелы, кириллица, второй вопросительный знак, разный регистр
https://example.com/catalog?page=2?utm_source=Яндекс&utm_medium=CPC&utm_campaign=осень 2026

# Хорошо: один ?, дальше &, всё строчными, латиница
https://example.com/catalog?page=2&utm_source=yandex&utm_medium=cpc&utm_campaign=autumn-2026

# Если кириллицу в utm_term всё-таки нужно сохранить — кодируем
https://example.com/?utm_source=yandex&utm_medium=cpc&utm_term=%D1%85%D0%BE%D1%81%D1%82%D0%B8%D0%BD%D0%B3

Проверить, как строка разберётся на стороне клиента, можно прямо в консоли браузера или в терминале:

# Разобрать query string по параметрам (python3 есть почти везде)
python3 - <<'EOF'
from urllib.parse import urlsplit, parse_qsl
u = "https://example.com/catalog?page=2&utm_source=yandex&utm_medium=cpc"
for k, v in parse_qsl(urlsplit(u).query):
    print(f"{k:15} = {v}")
EOF

# Корректно закодировать значение перед вставкой в ссылку
python3 -c "from urllib.parse import quote; print(quote('осенняя распродажа'))"

Что генератор UTM-меток делает, а что нет

Генератор — это форма с пятью полями, которая склеивает строку. Полезного в нём три вещи: он не даст забыть &, он корректно закодирует спецсимволы и обычно подсовывает список допустимых значений medium, что дисциплинирует команду. В версиях посерьёзнее есть сохранённые шаблоны и история, чтобы разные люди в компании не изобретали email, e-mail и mail параллельно.

Чего генератор не делает:

• не проверяет, что на целевой странице вообще стоит счётчик;
• не проверяет, доживут ли параметры до этой страницы через цепочку редиректов;
• не убирает дубли параметризованных адресов из индекса поисковика;
• не знает вашей внутренней договорённости о словаре и не помешает завести четвёртое написание одной и той же кампании.

Иначе говоря, генератор решает задачу синтаксиса. Все интересные проблемы — семантика словаря и техническое поведение сайта — остаются на вас.

UTM-метки в Яндекс.Метрике: где смотреть отчёт

Метрика читает UTM-параметры автоматически: ничего включать и настраивать не нужно, счётчик забирает их из адреса при первом хите визита. Дальше значения доступны двумя способами.

Первый — готовый отчёт по меткам в группе отчётов об источниках трафика. Он показывает дерево: source → medium → campaign, с возможностью развернуть вложенные уровни и добавить content и term. Второй, более гибкий, — добавить UTM как группировку (измерение) к любому другому отчёту. Так можно, например, посмотреть конверсию в цель в разрезе utm_content или поведение по Вебвизору только для одной кампании. Конкретные названия пунктов меню в интерфейсе периодически меняются, поэтому ориентируйтесь на группу «источники» и на список доступных группировок, а не на заученный путь кликов.

Технические тонкости, которые чаще всего портят картину именно в Метрике:

• Источник фиксируется на входе в визит. Метка, встреченная на первой странице, размечает весь визит. Метка, встреченная на середине визита, — это уже переопределение источника со всеми последствиями (см. раздел об ошибках).
• Счётчик должен успеть отработать. Если код счётчика подключён асинхронно и стоит в самом низу тяжёлой страницы, часть пользователей уйдёт раньше — метка не запишется. Про поведение счётчика и запись сессий подробнее в материале Яндекс.Метрика и Вебвизор.
• Метрика различает UTM-метки и собственные метки Яндекса. Параметр yclid, который Директ добавляет при автоматической разметке, — это отдельный механизм связки, а не UTM. Они спокойно живут в одном адресе одновременно.

UTM-метки в Яндекс.Директе: разметка объявлений

В Директе есть два независимых способа передать данные в аналитику, и их регулярно путают.

Автоматическая разметка — Директ сам дописывает к ссылке служебный идентификатор клика (yclid), по которому Метрика подтягивает данные о кампании, объявлении и площадке напрямую из рекламной системы. Это работает без UTM и даёт больше подробностей, чем ручные метки, но данные видны только внутри связки Директ + Метрика.

Ручная UTM-разметка нужна, когда данные должны попасть куда-то ещё: в стороннюю аналитику, в CRM, в сквозной отчёт, в сводную таблицу вместе с другими каналами. Здесь помогают подстановочные параметры Директа — специальные конструкции в фигурных скобках, которые система заменяет на реальные значения в момент клика.

# Шаблон UTM для объявления в Яндекс.Директе
?utm_source=yandex
&utm_medium=cpc
&utm_campaign={campaign_id}
&utm_content={ad_id}
&utm_term={keyword}

# Собранная в одну строку версия для поля «Ссылка»:
https://example.com/?utm_source=yandex&utm_medium=cpc&utm_campaign={campaign_id}&utm_content={ad_id}&utm_term={keyword}

Несколько правил, которые экономят время:

• Держите utm_source=yandex и utm_medium=cpc константами. Соблазн написать utm_source=direct велик, но тогда органика и реклама Яндекса разъедутся по разным строкам отчёта не по типу трафика, а по названию — и сравнивать их станет неудобно.
• В utm_campaign удобнее класть идентификатор кампании, а не её название: имя вы поменяете, и исторические данные разойдутся на два ряда.
• Подставленная ключевая фраза может содержать пробелы. Проверяйте, как выглядит итоговый адрес после клика по реальному объявлению, а не только шаблон в интерфейсе.
• Набор доступных подстановок в рекламных системах со временем меняется — сверяйтесь со справкой рекламного кабинета перед массовой перезаливкой кампаний.

UTM-метки в Тильде и других конструкторах сайтов

С точки зрения конструктора сайтов UTM-метка — это просто «лишний хвост» в адресе, который он обязан проигнорировать и отдать нужную страницу. Практически все популярные конструкторы так и делают: query string не влияет на маршрутизацию. Поэтому вопрос «поддерживает ли Тильда UTM-метки» почти всегда имеет ответ «да, поддерживать тут нечего».

Реальные проблемы начинаются не с распознавания меток, а с трёх других мест, где конструктор принимает решения за вас:

1. Редиректы и «главное зеркало»

Конструктор обычно сам склеивает www и версию без него, а также поднимает HTTPS. Это редиректы, и вопрос ровно один: доедут ли параметры до конечного адреса. Хорошая новость — на серьёзных платформах доедут. Плохая — если поверх стоит ваш собственный редирект (например, со старого домена на новый), он вполне может параметры съесть. Проверять надо конкретную боевую ссылку, а не платформу в целом.

2. Внутренние ссылки в готовых блоках

Блоки вроде «акция» или «баннер» настраиваются через тот же интерфейс, что и внешние ссылки, и в них очень удобно вписать UTM. Это ошибка, причём самая дорогая из всех: метка на внутренней ссылке перебивает исходный источник визита. Человек пришёл из платного поиска, ткнул в баннер с utm_source=site&utm_medium=banner — и вся его дальнейшая активность, включая заявку, записалась на внутренний баннер. Реклама в отчёте обнулилась.

3. Canonical и карта сайта

Конструкторы обычно проставляют rel="canonical" сами. Убедитесь, что канонический адрес отдаётся без параметров — это ровно то, что защищает вас от дублей. И проверьте, что параметризованные адреса не попадают в sitemap.xml: подробности в материале карта сайта sitemap.xml.

Никогда не ставьте UTM-метки на внутренние ссылки своего сайта. Для разметки внутренних переходов у систем аналитики есть отдельные механизмы — параметры кликов, события, цели. UTM предназначены исключительно для входящего трафика.

Чего UTM-метки не делают — и как они всё-таки ломают SEO

Сами по себе метки на ранжирование не влияют. Поисковый робот, придя по размеченному адресу, получит тот же HTML, что и по чистому: ни контент, ни заголовки, ни скорость не изменятся. Никакого прямого «плюса» или «минуса» к позициям здесь нет.

Проблема в другом. Для краулера каждый уникальный набор параметров — это отдельный URL. Три кампании на одну посадочную дают четыре адреса с одинаковым содержимым. Если такие адреса стали известны поисковику — попали в чужой блог, в соцсеть, в карту сайта, во внутреннюю перелинковку — начинается вполне осязаемый ущерб:

• Дубли в индексе. Один и тот же текст по нескольким адресам. Поисковик выбирает главный сам, и его выбор не обязан совпасть с вашим.
• Размывание сигналов. Внешние ссылки и поведенческие данные растекаются по клонам вместо того, чтобы накапливаться на одном адресе.
• Трата краулингового бюджета. Робот тратит обходы на пересъём одинаковых страниц. На небольшом сайте это малозаметно, на крупном каталоге — уже нет. Механику обхода разбираем в статье об индексации сайта.
• Мусор в выдаче. Пользователь видит в результатах адрес с чужой рекламной меткой и после клика попадает в чужую статистику.

Три механизма защиты и что из них работает где

Механизм	Яндекс	Google	Что делает
rel="canonical" без параметров	учитывает	учитывает	Указывает предпочтительный адрес. Базовая и обязательная мера для обеих систем
Clean-param в robots.txt	да, это директива Яндекса	нет, не поддерживается	Прямо говорит роботу игнорировать перечисленные параметры и склеивать адреса
Disallow: /*utm*	не рекомендуется	не рекомендуется	Запрещает обход. Робот не увидит canonical и не сможет склеить адреса — лечение хуже болезни

Начинайте всегда с canonical. Это единственный механизм, который понимают обе системы, и он же чинит проблему в корне: каноническим объявляется чистый адрес без параметров.

<!-- В <head> страницы, открытой по адресу /pricing?utm_source=vk -->
<link rel="canonical" href="https://example.com/pricing">

<!-- Проверка боевой страницы одной командой -->
curl -sSL 'https://example.com/pricing?utm_source=vk&utm_medium=social'   | grep -io '<link[^>]*canonical[^>]*>'

Второй слой — Clean-param. Это директива в robots.txt, которую понимает только Яндекс: у Google аналога нет, и в Search Console инструмент управления параметрами URL был свёрнут — вместо него Google предлагает опираться на canonical. Смешивать эти два подхода в одну рекомендацию нельзя, они относятся к разным поисковым системам.

# robots.txt — секция для Яндекса
User-agent: Yandex
Clean-param: utm_source&utm_medium&utm_campaign&utm_content&utm_term&yclid&gclid&fbclid /

# Синтаксис: Clean-param: параметры_через_амперсанд [префикс_пути]
# Путь в конце необязателен; без него правило действует на весь сайт.
# У директивы есть ограничение по длине — длинные списки
# разбивают на несколько строк Clean-param подряд.

Живой пример можно посмотреть прямо у нас — robots.txt enterno.io содержит строку Clean-param с полным набором рекламных параметров, включая utm_*, gclid, yclid и fbclid. Про остальные директивы файла — в разборе robots.txt.

Не закрывайте параметризованные адреса через Disallow. Запрет обхода не удаляет страницу из индекса — он лишь запрещает роботу её прочитать. Робот не увидит ваш canonical, не поймёт, что это дубль, и вполне может оставить адрес в выдаче без описания. Правильная пара — открытый обход плюс корректный canonical, а для Яндекса дополнительно Clean-param.

Типовые ошибки в UTM-метках

Регистр: Yandex и yandex — две разные строки

Значения меток передаются как есть, символ в символ. Часть систем аналитики приводит source и medium к нижнему регистру при построении отчётов, часть сохраняет исходное написание, и заранее вы не знаете, какой именно отчёт откроете через полгода. Итог предсказуем: в таблице появляются Yandex и yandex двумя строками с половиной трафика в каждой, а сравнение периодов разваливается.

Правило простое и не требует исключений: всё в нижнем регистре, всегда. Это касается и значений, и самих имён параметров — UTM_Source многие системы просто не распознают как метку.

Метки на внутренних ссылках обнуляют исходный источник

Разобрали выше на примере конструкторов, но ошибка встречается и в самописных сайтах: в письме о брошенной корзине ставят метку, в баннере внутри личного кабинета ставят метку, в кнопке «перейти к оплате» ставят метку. Каждая такая метка — переопределение источника посреди визита. В большинстве систем аналитики появление нового набора рекламных параметров трактуется как начало новой сессии с новым источником: старый источник закрывается, конверсия достаётся внутренней кнопке.

Симптом, по которому это ловится: в отчёте по источникам аномально много визитов с вашего же домена или с медиума вроде banner/site, а платные каналы показывают конверсию заметно ниже, чем говорят рекламные кабинеты.

Метки в canonical, sitemap и hreflang

Три места, где параметризованный адрес не должен появляться никогда. canonical с меткой объявляет каноническим именно размеченный адрес — вы своими руками просите поисковик индексировать рекламный клон. То же с картой сайта: она означает «вот адреса, которые я считаю правильными». Если генератор карты собирает URL из логов или из внутренних ссылок, туда легко утекают метки.

Потеря меток на редиректе

Самая техническая и самая обидная ошибка: ссылка размечена правильно, а в аналитику ничего не приходит. Причина — редирект по дороге, который отдаёт Location без query string. Классика — конфигурация веб-сервера, где вместо полного запроса подставляется только путь:

# nginx — метки теряются: $uri не содержит query string
location /old { return 301 https://example.com$uri; }

# nginx — метки сохраняются: $request_uri содержит путь И параметры
location /old { return 301 https://example.com$request_uri; }

# Apache mod_rewrite — если в подстановке есть свой '?',
# исходная query string отбрасывается. Возвращает её флаг QSA:
RewriteRule ^old/(.*)$ /new/$1?lang=ru [R=301,L,QSA]

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

Разнобой в словаре

Через год работы без единого словаря в отчёте живут cpc, ppc, paid, cpc_ads и context — и все они означают одно и то же. Лечится только организационно: один документ со списком допустимых medium, один генератор с выпадающим списком, ревью ссылок перед запуском кампании.

Метки и кэширование

Ещё один неочевидный побочный эффект. Кэш на CDN и кэш страниц на сервере обычно ключуются по полному URL вместе с query string. Значит, каждый уникальный набор меток — это отдельная запись в кэше и промах при первом заходе. Массовая рассылка с индивидуальной меткой на получателя способна и раздуть кэш, и дать всплеск нагрузки на бэкенд.

Лечится нормализацией ключа кэша: параметры utm_* исключаются из ключа, страница отдаётся из общего кэша. На счётчик это не влияет — он читает адрес из браузера, а не из ответа сервера, поэтому метка всё равно будет записана. Заголовки кэширования на боевой странице удобно посмотреть инструментом проверки HTTP-заголовков.

Как проверить UTM-метки на своём сайте

Порядок проверок — от механики к последствиям. Первые три пункта делаются до запуска кампании, последние два — регулярно.

1. Переживают ли метки редиректы

Главная проверка. Берёте боевую размеченную ссылку и смотрите, что осталось в конце цепочки:

# Пройти всю цепочку и показать итоговый адрес и число редиректов
curl -sSIL 'http://example.com/pricing?utm_source=vk&utm_medium=social'   -o /dev/null   -w 'final=%{url_effective}
redirects=%{num_redirects}
code=%{http_code}
'

# Показать каждый шаг цепочки: статусы и заголовки Location
curl -sSIL 'http://example.com/pricing?utm_source=vk&utm_medium=social'   | grep -iE '^(HTTP/|location:)'

В строке final= должны присутствовать все ваши параметры. Если их там нет — редирект по дороге выкидывает query string, и это чинится в конфигурации сервера, а не в ссылке. Наглядно ту же цепочку, со всеми промежуточными хопами, показывает проверка редиректов.

2. Какой canonical отдаёт размеченная страница

# canonical должен указывать на чистый адрес БЕЗ utm-параметров
curl -sSL 'https://example.com/pricing?utm_source=vk'   | grep -io '<link[^>]*canonical[^>]*>'

Ожидаемый результат — ссылка на https://example.com/pricing. Если в canonical оказались метки, правьте шаблон страницы: скорее всего, канонический адрес собирается из текущего URL целиком.

3. Корректен ли robots.txt

Проверьте, что Clean-param присутствует в секции Яндекса и что вы случайно не закрыли параметризованные адреса через Disallow. Синтаксис и область действия директив разбирает проверка robots.txt.

4. Не попали ли размеченные адреса в индекс

В Google это проверяется поисковым оператором — запрос вида site:example.com inurl:utm_ покажет проиндексированные параметризованные адреса. В Яндексе смотрите в Вебмастере раздел со страницами в поиске и фильтруйте список по подстроке utm. Любые находки означают, что где-то есть внешняя или внутренняя ссылка с меткой, а canonical её не перекрыл.

5. Общая гигиена дублей

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

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

Влияют ли UTM-метки на SEO?

Напрямую — нет. Сам факт наличия параметров в адресе не улучшает и не ухудшает позиции: поисковик получает тот же контент. Косвенно — да, если размеченные адреса стали известны роботу и породили дубли. Тогда страдают уникальность страницы в индексе и распределение сигналов. Лечится каноническим адресом без параметров, а для Яндекса дополнительно директивой Clean-param.

Нужно ли закрывать UTM-метки в robots.txt?

Закрывать через Disallow — нет, это вредно: робот не сможет прочитать страницу и увидеть canonical. Для Яндекса правильный инструмент — Clean-param, он не запрещает обход, а говорит склеивать адреса. Для Google в robots.txt делать ничего не нужно, всё решает canonical.

Чем utm_source отличается от utm_medium?

source — имя конкретной площадки («откуда»): yandex, vk, newsletter. medium — тип канала («каким способом»): cpc, social, email. Значений medium в компании должно быть единицы, значений source — сколько угодно. Если в отчёте по medium десятки строк, туда попало содержимое source или campaign.

Обязательно ли заполнять все пять параметров?

Формально ни один не обязателен — аналитика примет ссылку и с одним utm_source. Практический минимум — source, medium и campaign. Параметры content и term нужны, когда внутри одной кампании есть что различать: разные креативы, разные позиции ссылки в письме, разные ключевые фразы.

Почему в отчёте один источник разбился на две строки?

Три обычные причины, по убыванию частоты: разный регистр (Yandex и yandex), разное написание в словаре (email и e-mail), лишний пробел или символ, попавший в значение при копировании ссылки. Все три чинятся только на входе — уже записанные данные аналитика задним числом не переписывает.

Теряются ли UTM-метки при переходе с http на https?

Зависит от того, как настроен редирект. Корректная конфигурация подставляет полный запрос вместе с query string, и параметры доезжают. Некорректная подставляет только путь — метки исчезают молча, без ошибки. Проверяется одной командой curl -sSIL … -w '%{url_effective}': в итоговом адресе должны остаться все параметры.

Чеклист перед запуском кампании

• Все значения меток — строчными латинскими буквами, без пробелов и кириллицы.
• Заполнены как минимум source, medium и campaign; medium взят из общего словаря.
• Первый параметр отделён ?, остальные — &; если у страницы уже есть свои параметры, метки добавлены через &.
• Метки стоят до якоря #, а не после него.
• Боевая ссылка проверена через curl -sSIL: параметры доживают до конца цепочки редиректов.
• На целевой странице стоит счётчик и он срабатывает до ухода пользователя.
• rel="canonical" размеченной страницы указывает на чистый адрес без параметров.
• В секции Яндекса в robots.txt есть Clean-param с перечнем рекламных параметров.
• Параметризованные адреса не попадают в sitemap.xml.
• Ни одна внутренняя ссылка сайта не размечена UTM.
• Ключ кэша на CDN или на сервере не учитывает utm_*.
• Проверено, что размеченные адреса не индексируются: site:… inurl:utm_ и раздел страниц в поиске в Вебмастере.